search

rerun-io / rerun

Visualize streams of multimodal data. Fast, easy to use, and simple to integrate. Built in Rust using egui.
https://rerun.io/
Apache License 2.0
6.46k stars 317 forks source link

Depth offset moves lines and points in (Web)GL #4787

Open s-nie opened 9 months ago

s-nie commented 9 months ago

This may be related to https://github.com/rerun-io/rerun/issues/1025. There are also mentions of reduced depth precision with GL in the source code, but I couldn't find anything mentioning this specific issue.

While implementing a custom viewport based on re_renderer, I noticed a strange behavior when lines and points have a depth offset value. There seems to be some sort of parallax effect when the objects are not centered in the view. The effect is more pronounced the larger the offset value is. In the video below, I used a value of 200 for the manipulator gizmos and 0 for the spiral objects.

https://github.com/rerun-io/rerun/assets/73159570/40973529-9721-4c2e-880c-40f850719713

To Reproduce Steps to reproduce the behavior:

  1. Create a viewport
  2. Add points and lines to it with different depth offsets
  3. Move the camera in the viewport
  4. Run in (web)GL

Expected behavior The depth offset does not cause any translation based on the camera position. In the video above that would mean that the gizmos stay centered on the spirals.

Rerun version 0.12.0

Additional context Things look as expected with the vulkan backend.

Wumpf commented 9 months ago

Thanks for the report and the (pretty cool! :)) video documenting the behavior! You're right this is related to

The depth offset works with literally offsetting on the z axis which has all sort of problems. One of them being that it works very poorly in WebGL where we have to use much bigger steps which is the reason you're seeing this issue on WebGL but not with Vulkan. This happens because WebGL is the only platform where the normalized-device-coordinates depth range goes from -1 to 1 which messes with our depth precision (in particular because the conversion is patched in via wgpu which always assumes 0 to 1).

it's not written down, but we want to get away from the depth offset and instead have a way to influence the actual draw ordering, making this also related to

s-nie commented 9 months ago

Thanks for the quick response and explanation! Makes sense, then I'll know to be careful with depth offsets for now. Feel free to close this issue then, as the overarching issue is tracked in #1025 anyway.

Kudos for making re_renderer modular by the way, that made it super convenient to use without pulling in a mountain of dependencies :)

Wumpf commented 9 months ago

Let's keep it around, it's a good issue that highlights specific shortcomings that we haven't written down anywhere else :)

emilk commented 9 months ago

We haven't tested it I think, but based on Andreas' comment this should work much better on WebGPU