Wideanglecamera equidistant mapping bounding fix #3135
Conversation
| @@ -1515,7 +1515,7 @@ fragment_program Gazebo/WideLensMapFS glsl | |||
| param_named c2 float 1 | |||
| param_named c3 float 0 | |||
| param_named f float 1 | |||
| param_named fun float3 0 1 | |||
| param_named fun float3 0 0 1 | |||
There was a problem hiding this comment.
This line might not change anything, but it seemed odd to not complete the default float3 values
There was a problem hiding this comment.
If float3 0 1 was working before, wouldn't Ogre have been interpreting it as float3 0 1 0? This looks like it would change behavior from using atan(param) to using param.
There was a problem hiding this comment.
I think it could be 0 0 1 to match the default fun value of id specified here (which is defined to be UnitZ here.)
It may not matter that much though as the values specified here in the material script are the initial values but should be overriden every frame by the SetUniformVariables call
| @@ -1515,7 +1515,7 @@ fragment_program Gazebo/WideLensMapFS glsl | |||
| param_named c2 float 1 | |||
| param_named c3 float 0 | |||
| param_named f float 1 | |||
| param_named fun float3 0 1 | |||
| param_named fun float3 0 0 1 | |||
There was a problem hiding this comment.
I think it could be 0 0 1 to match the default fun value of id specified here (which is defined to be UnitZ here.)
It may not matter that much though as the values specified here in the material script are the initial values but should be overriden every frame by the SetUniformVariables call
Currently when using a
wideanglecamerasensor with a lens type ofequidistant, the actual image data gets restricted to a small circular region with the rest of the image having a gray ring around it. See the images below for the image that is produced for anequidistantlens with an HFOV of 1.5708, 2.0, and 3.14159.The issue appears to be in
wide_lens_map_fp.glslon Line 38. The valuethetagets calculated withasin(param)driving the equation iffun.xis 1 (which is true forequisolid_angleandorthographiclens types). The way this equation is written becomes problematic for other lens types, though, when theparam > 1since the resulting value ofasin(param)becomes undefined.This PR is to add a check for function type to avoid the undefined
asincomputation. See the images below for anequidistantlens with an HFOV of 1.5708, 2.0, and 3.14159 after this fix.