gz-rendering icon indicating copy to clipboard operation
gz-rendering copied to clipboard

Ogre2 transparency issue

Open osrf-migration opened this issue 5 years ago • 3 comments

Original report (archived issue) by Ian Chen (Bitbucket: Ian Chen, GitHub: iche033).


When a visual is set to be transparent, sometimes the object behind the transparent object disappears / becomes as the camera pans from around it.

see gif in this comment: https://osrf-migration.github.io/ignition-gh-pages/#!/ignitionrobotics/ign-gazebo/pull-requests/547/add-support-for-setting-visual/diff#comment-140398963

I had a chance to play with it with the Cafe model (chosen since it’s quite a complex one) and observed some visual glitches.

… but you can see an object disappearing after the first window and the walls becoming white after the second.

osrf-migration avatar Mar 18 '20 04:03 osrf-migration

I can't see the GIF as it got eaten by the migration.

But it does sound like a regular order error. Alpha transparency is order dependent (e.g. just like a / b is not the same as b / a). If a glass cup is behind a window, the cup must be rendered before the window.

Ogre tries to estimate the distance to camera to render in the proper order, but it is only an approximation.

There are multiple solutions to this problem:

  1. Switch the transparency mode to an order-independent one (e.g. use Additive or Modulate instead of alpha blending. Modulate usually works fine for glass)
  2. Manually set the order by hand by tweaking the setRenderQueueGroup calls.
  3. In Ogre 2.3 we added Camera::mSortMode to try alternate approximations that may fit certain scenes better
  4. Implement from Ogre-side a an Order Independent Transparency solution. Although these are complex and expensive.

darksylinc avatar Apr 10 '21 21:04 darksylinc

found the gif. Scroll down a little to see the gif originally posted by @luca-della-vedova https://osrf-migration.github.io/ignition-gh-pages/#!/ignitionrobotics/ign-gazebo/pull-requests/547/page/1

I've created a cafe.sdf world file with a semi-transparent cafe model that reproduces the issue.

To run:

ign gazebo -v 4 cafe.sdf

Look through the windows / doors to see some of the objects disappearing.

I did some quick test changing blend type to SBT_MODULATE and SBT_ADD but no luck. I have not tried render queue groups yet as I think that'll need to be done on each individual submesh in the cafe mesh.

iche033 avatar Apr 12 '21 23:04 iche033

OH, it completely disappears.

This happens because the following two things are true at the same time:

  1. Windows are rendering first (they should be rendered last)
  2. Windows are writing to the depth buffer (usually depth_write is turned off for transparency to avoid these issues, however if objects are rendered out of order, order-dependent transparents such as alpha blending will appear on screen but will not be correct)

When you change both objects to modulate or add, it still doesn't work because the window is writing to the depth buffer, hence when the sofa is rendered later, it thinks it's behind a solid wall.

Thus either disable depth writes, or ensure proper order with render queue groups.

HlmsPbsDatablock::setTransparency should be automatically handling this btw. If you want full control by manually setting the macro- and blendblocks it's ok; just take a look at setTransparency is doing (like disabling the depth write) as reference.

Cheers

darksylinc avatar Apr 13 '21 00:04 darksylinc