-
Notifications
You must be signed in to change notification settings - Fork 486
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
Wide angle lens flare occlusion bug #3273
Comments
While working on the new gazebo version, I noticed a potential bug in the classic version and wide angle cameras: In LensFlareCompositorListener::WideAngleCameraPosScale, regardless of which face camera is being rendered, will loop through all cameras, find the first one facing towards the sun; and do calculations based on that. That will work fine for the face camera that matches the calculation. But for the rest of the 5 cameras, it should be using the camera currently being rendered, not the camera facing towards the sun. The new-gazebo version I ported uses the camera currently being rendered. I would also not rule out that the wrong camera is being selected due to using |
Note: when I talk about |
I just noticed an additional issue while testing #3276. When attempting to occlude the wide-angle camera with other objects, such as the |
hmm are the bugs there before the changes in #3276? For the second case with the brick wall, one thing to check is if the camera used for occlusion checking has the correct near / far clip planes. |
yes, I took those screenshots using gazebo 11.12.0, without the changes from #3276. We should set up a demo world with both the heightmap and the occluding box to test it all at once. |
I run into this problem when implementing this hack:
The problems I had in gz-rendering is that the cameras have potentially different FOVs and Aspect Ratios (cubemap camera vs "stitching" camera). This causes slight offsets in the lens flare location in 2D space from where it really should be; therefore when we perform the ray cast, it returns there are no occluders. Another problem is that because the LensFlare is done after stitching, it is not lens-distorted. So if a cube in front of the camera is "enlarged" by the distortion, it will look like it should occlude the lens flare. This may be a limitation of the hack (assuming there are no other bugs present) |
From external collaborator:
We have been noticing some issues with wideangle cameras in gazebo not always rendering the lens flares even when the sun is in clear sight. I added some print statements in LensFlare.cc and I can see that the issue is that FirstContact (called here) will often return true for intersection even when nothing is actually in between the camera and light source, which results in the scale shader uniform getting cleared.
I combined elements of gazebo's lensflare_plugin.world and heightmap.world to make an easy testing environment that demonstrates this issue. Please see the attached screenshots. The first shows a wideangle camera and a normal camera side-by-side, but the wideangle camera does not have a visible flare. The second screenshot shows the two cameras arbitrarily rotated to find an orientation that correctly produces the lens flare in both. I have also attached the test world - try it out yourself and rotate around the cameras to see how things change. You can also try removing the heightmap, which seems to help a bit, but the problem doesn't fully go away.
Any ideas why the lens flare occlusion checking isn't working very well with wideangle cameras?
lensflare_plugin.world
To reproduce:
Press
Ctrl + t
to bring up the topic window, scroll down to thegazebo.msgs.ImageStamped
section, and double click on the 2 topic names to bring up the image display window. You'll see that lens flare is visible in the regular camera view but not the wide angle camera viewThe text was updated successfully, but these errors were encountered: