Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Investigate color support in mesh files #31

Closed
diegoferigo opened this issue May 31, 2019 · 11 comments
Closed

Investigate color support in mesh files #31

diegoferigo opened this issue May 31, 2019 · 11 comments

Comments

@diegoferigo
Copy link
Member

diegoferigo commented May 31, 2019

As reported in #4, the colors are not properly displayed in our iCub models.

Despite this rendering problem, the models are loaded correctly and both links and joints are detected.

Here below an example with iCubGazeboV2_5:

ignition_gazebo

@traversaro
Copy link
Member

The graphic engine is OGRE or OGRE2 ?

@diegoferigo
Copy link
Member Author

diegoferigo commented May 31, 2019

I tried both, same result. Upstream they changed the scene plugin during the past 10 days (new one is GzScene3D) but it segfaults. Probably something is wrong in my compilation from sources of the entire suite. I tried their binaries but they are not yet updated.

@traversaro
Copy link
Member

traversaro commented May 31, 2019

Which sources of light do you have in your scene? If you just have ambient light and no point or direction source of light, a uniform color for the meshes is actually the expected outcome of the rendering process.

See for example for the Phong model https://en.wikipedia.org/wiki/Phong_shading#Phong_reflection_model :
Phong Shading model

@diegoferigo
Copy link
Member Author

diegoferigo commented May 31, 2019

I had the same suspect as well. The new worlds upstream added new light elements and I tried to do the same on our worlds. The only difference is that I can see the iCub shadow:

icub_with_sun

But note that this is using the old Scene3D plugin.

SDF element
    <light type="directional" name="sun">
      <cast_shadows>true</cast_shadows>
      <pose>0 0 10 0 0 0</pose>
      <diffuse>0.8 0.8 0.8 1</diffuse>
      <specular>0.2 0.2 0.2 1</specular>
      <attenuation>
        <range>1000</range>
        <constant>0.9</constant>
        <linear>0.01</linear>
        <quadratic>0.001</quadratic>
      </attenuation>
      <direction>-0.5 0.1 -0.9</direction>
    </light>

@traversaro
Copy link
Member

traversaro commented May 31, 2019

Have you tried rotating the model/changing the direction of light? If the model is in shadow w.r.t. to the only source of light, the only remaining light is indeed the diffuse one.

@diegoferigo
Copy link
Member Author

Just tried, no change. Good tentative, though.

@traversaro
Copy link
Member

Things I would try to investigate more the problem:

@diegoferigo diegoferigo added the good first issue Good for newcomers label Jul 7, 2019
This was referenced Oct 22, 2019
@diegoferigo diegoferigo added this to the v1.0 milestone Oct 22, 2019
@diegoferigo
Copy link
Member Author

diegoferigo commented Dec 12, 2019

During my tests with the new sdformat release (no more use parent model frame, fixed material/script element, etc) I wanted to give a quick shot to this problem. I tried to add the following to each visual elements of the links:

<material>
    <diffuse>1 1 1 1</diffuse>
</material>

And this is the result:

out

I'm not an expert on this, but as far as I know STL files do not support defining material properties. Probably the default behavior of the gazebo renderer changed, because on Gazebo Classic the same model is properly rendered (all white with shadows, similar to the result of the gif above).

@traversaro
Copy link
Member

So, it a nutshell in ignition-gazebo it seems that the default material for primitive shapes is different from the default material used for STL meshes. This sounds like a bug in ign-gazebo or some dependent library.

@diegoferigo
Copy link
Member Author

Yes, something similar. I couldn't find the source of the problem, but I'm not yet familiar with all the rendering-related codebase of the simulator.

@diegoferigo
Copy link
Member Author

We adopted the diffuse elements workaround, as reported in robotology/gym-ignition-models#1 and particularly robotology/gym-ignition-models@4e8b940.

We experienced a mesh problem also with the Panda model. The model was correctly inserted in the simulation but the visual elements were transparent. Citing @paolo-viceconte:

I discovered that both in https://github.com/mkrizmancic/franka_gazebo and in https://github.com/cpezzato/panda_simulation the visual meshes (i.e. all the *.dae files) have the transparent tag set to A_ONE, which seems to be ok only in old versions of gazebo. One possible solution is to set it to RGB_ZERO, as detailed in http://answers.gazebosim.org/question/20068/collada-model-is-not-visible-in-gazebo-89-if-transparent-a_one/.

Closing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants