PBR textures for walls and floors in Ignition Gazebo #345
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
New feature implementation
Implemented feature
This PR is a followup of #342, and is to work towards #343. It adds support to
rmf_building_map_tools
for PBR textures to be used in Ignition, specifically metalness, roughness, normal, environment and light maps.Implementation description
The YAML format now has additional parameters for walls and floors that follow the same naming convention as the SDF metal PBR workflow.
For ease of review the PR doesn't yet include all the
rmf_traffic_editor
GUI work to include the parameters, hence they have to be added manually to the yaml file. An example gist for the office world that can be used to test the PR is here.Followup work will be to add the parameters to the
rmf_traffic_editor
GUI and autopopulate them when possible (i.e. if a[...]_Diffuse.png
texture is present, the Normal map should default to[...]_Normal.png
)Before the PR:
After the PR (notice the reflections on the floor for the ceiling lights given by the environment map. It looks better when moving around I promise!
While implementing I took the chance to do a small refactor of the wall parameters and how they were grouped by adding an equality operator to parameters, this made the implementation quite a bit cleaner (otherwise we had to keep comparing parameters manually every time a new one was added).
A small issue that I couldn't figure out yet is that the
model.material
file created here has duplicated entries which makes me think that the generate function is called twice for each wall / floor.It still works but it makes me wonder if there is some part of the map generator that is responsible for this issue and if there is a chance for optimizing it.