Open Amoki opened 3 years ago
Hi @xeolabs, This really decreases the rendering quality, feels like the render is done with an 800x600 resolution. Do you have any news?
I haven't got to this yet, no clues why. The only thing log depth buffer changes is the depth values written, so I have no clue yet how this would affect output resolution. As a workaround, I would leave log depth buffer disabled for now. It seems to have little benefit for BIM models so far, as far as I can see.
Unfortunately, we open building models and cityGML models without differentiation. As the log depth buffer setting is static at loading, we can't set it to true if the user loads an IFC model first then loads a cityGML model. If we reload the viewer when a new model needing log depth buffer is loaded, the user loses the current object states.
Disabling it is a real regression in our case :/
As snap to vertex needs logarithmicDepthBuffer, this issue is even more relevant.
Render without logarithmicDepthBuffer:
Render with logarithmicDepthBuffer:
Actually we don't need to enable log depth buf for snap-to-vertex any more.
I made the snapping shaders internally use a log depth buffer, regardless of whether we enable one for normal rendering or not, which fixes the snapping occlusion problem
discussion: https://github.com/xeokit/xeokit-sdk/pull/1062#issuecomment-1714362091
So, snapping should work OK with log depth buffer disabled.
Putting this on the 2.4 milestone in case there is something we can do for this, all the same
Describe the bug When using
logarithmicDepthBufferEnabled: true
, the model is more pixelated.With
logarithmicDepthBufferEnabled: false
: WithlogarithmicDepthBufferEnabled: true
:Depending on camera position, there is also some glitches when logarithmicDepthBuffer is enabled:
Expected behavior Same rendering for both
Desktop (please complete the following information): Tested on Ubuntu, Firefox and Chrome with and XKT v6 model model.zip