Plugin to spawn lights

[ahcorde]

I created a plugin to spawn lights in ignition-gazebo.

I have some questions and issues:

• Do you want to see the visual in the component inspector ? the same way we are visualizing link, collisions or lights for models ?
• I'm getting sometimes this error:

terminate called after throwing an instance of 'Ogre::RenderingAPIException'
 what():  OGRE EXCEPTION(3:RenderingAPIException): Fragment Program 537068800PixelShader_ps failed to compile. See compile log above for details. in GLSLShader::compile at /var/lib/jenkins/workspace/ogre-2.1-debbuilder/repo/RenderSystems/GL3Plus/src/GLSL/OgreGLSLShader.cpp (line 305)

• Where and how is the best place to create the LightVisual ? Right now it's in the RenderUtil.cc but when I remove the light from Gazebo in the component inspector the visual it's still there. Probably I should attach the Visual to the Light. Is this possible ?
  https://github.com/ignitionrobotics/ign-gazebo/blob/139e552a2fa2869794020313bea975143c7f273c/src/rendering/RenderUtil.cc#L404-L417

Signed-off-by: ahcorde ahcorde@gmail.com

[iche033]

Do you want to see the visual in the component inspector ? the same way we are visualizing link, collisions or lights for models ?

you mean the light visuals? I think it's fine to leave them out

I'm getting sometimes this error:

I see this when spawning a directional light. It could be that we can't have more than one directional lights in the scene. If that's the case, we can print a warning that only 1 directional light is supported for now

Where and how is the best place to create the LightVisual ? Right now it's in the RenderUtil.cc but when I remove the light from Gazebo in the component inspector the visual it's still there. Probably I should attach the Visual to the Light. Is this possible ?

yes you can attach LightVisual to Light. Since the they are all ign-rendering nodes, you can just do light->AddChild(lightVisual)

[ahcorde]

@iche033 I improved the implementation.

The issue with the lights is the following: When point lights and directionals are mixed the segfault appears

[iche033]

ok narrowed the the point vs directional light issue a bit more. Disabling the point light shadows makes them work now:

--- a/src/gui/plugins/lights/Lights.cc
+++ b/src/gui/plugins/lights/Lights.cc
@@ -86,7 +86,7 @@ void Lights::OnMode(const QString &_mode)
                                  "<sdf version=\"1.6\">"
                                  "<light type='point' name='pointlight'>"
                                    "<pose>0 0 2 0 0 0</pose>"
-                                   "<cast_shadows>true</cast_shadows>"
+                                   "<cast_shadows>false</cast_shadows>"
                                    "<diffuse>0.5 0.5 0.5 1</diffuse>"
                                    "<specular>0.5 0.5 0.5 1</specular>"
                                    "<attenuation>"

[ahcorde]

@iche033 It's ready for a review, thank you for the catch with the lights.

• Related with the PR Added LightVisual gz-rendering#202

[chapulina]

How about creating a convert function from sdf::LightType to std::string in Conversions.hh? It would be better to reuse the same logic in many places. I'm concerned that different plugins may use different strings (i.e. spot, SPOT...).

I can even see this function living in libSDFormat.

Also, I think that we should store the types as lowercase. The GUI can capitalize them as needed.

[ahcorde]

@iche033, I addressed the comment from @chapulina 2a79677

[chapulina]

Works great with the event change we talked about.

Besides the comment below, I have 2 requests:

• We should add the Lights plugin to the top toolbar next to the shapes in gui.config.
• Now that the lights have a visual, most example worlds will have a green square near the origin for the sun. This may confuse users. On Gazebo classic, I've seen many users confused about the floating green square, imagine if it's on the ground 😅 I suggest we move all suns in the examples to z=10, so it's in a more "sun-like" position. I think it's ok if this comes in a future PR though.

[chapulina]

I don't think it's a good idea to block the render thread. If this may take time to be completed, I suggest we queue it and process it when possible.

[ahcorde]

the right name for this variable is attempts, this loop has no relation with time or sleep. It's looking for an available entity ID.

[chapulina]

Ohh ok understood! I wonder if there's a chance of entity ID collision when new entities are inserted into the simulation from the backend. I didn't notice problems in my manual testing earlier.

[ahcorde]

In this method I can't access the ECM to call CreateEntity. Is there any other way to get an empty ID ?

[chapulina]

For the entity preview when spawning, there's this method in the Scene3D plugin:

https://github.com/ignitionrobotics/ign-gazebo/blob/766bb23eaca85ff60941e2ef852c4f286356fbcc/src/gui/plugins/scene3d/Scene3D.cc#L927-L937

That plugin isn't accessible from RenderUtil. But I think it could make sense to move the light visual logic from RenderUtil to Scene3d. The light visuals are only supposed to show on the client scene, not on the server. But RenderUtil is used by both scenes. I think this would be a big change and it may take longer to merge this PR though 😬

[ahcorde]

I can open an issue and merge this PR. Waht do you think @chapulina ?

[ahcorde]

friendly ping @chapulina

[chapulina]

An issue sounds good, thanks!

[ahcorde]

issue created #633

[ahcorde]

• Now that the lights have a visual, most example worlds will have a green square near the origin for the sun. This may confuse users. On Gazebo classic, I've seen many users confused about the floating green square, imagine if it's on the ground sweat_smile I suggest we move all suns in the examples to z=10, so it's in a more "sun-like" position. I think it's ok if this comes in a future PR though

@chapulina I made a quick review in the example folder. The suns' poses are already z=10

   <light type="directional" name="sun">
     <cast_shadows>true</cast_shadows>
     <pose>0 0 10 0 0 0</pose>
     <diffuse>1 1 1 1</diffuse>
     <specular>0.5 0.5 0.5 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>

[chapulina]

It's working for me! One last thing I noticed is that the directional light is spawned higher than the others, which may confuse users depending on their zoom level:

I think this is good to merge when the last 2 details are addressed, and if CI is happy.

[ahcorde]

@chapulina I fixed the two suggestions:

• a984f2e
• 73eb8eb

Feel free to squash and merge it

[ahcorde]

Failing tests are unrelated:

INTEGRATION_touch_plugin.test_ran
INTEGRATION_depth_camera.test_ran

Merging!