Skip to content
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

Mesh: fix LOD management #16038

Merged
merged 52 commits into from
Jan 7, 2025
Merged

Conversation

Popov72
Copy link
Contributor

@Popov72 Popov72 commented Jan 6, 2025

While working on the frame graph, I noticed that we had a problem with LOD management when using custom render target textures.
Take this PG:

https://playground.babylonjs.com/#WSWPUJ#1

The large sphere comes from the main rendering, which uses a camera located at a distance of 10 from the sphere.
The small sphere comes from a render target texture (RTT), which is displayed on a vertical plane and uses a camera located at a distance of 30 from the sphere.
A LOD (box) has been defined for the sphere, at a distance of 15.
We should therefore see a box instead of the small sphere, as 30 > 15.

What we see What we should see
image image

This doesn't work because the LOD is calculated for the main camera and reused for all custom RTTs.
The PR updates the LOD management by storing the LOD per camera.
In addition, I've introduced a cameraForLOD property in ObjectRenderer / RenderTargetTexture, because we may want to use a LOD for a camera that is different from ObjectRenderer.activeCamera (think of rendering from a light: the LOD should be retrieved from the main camera, not from the light's point of view). If not supplied, cameraForLOD=activeCamera to maintain backward compatibility.

Other changes in this PR are frame graph related:

  • added the camera entry to the shadow generator frame graph task. I hadn't originally added this entry because we didn't need it for rendering, but we do need it to retrieve a correct LOD (which is also why I added the new ObjectRenderer.cameraForLOD property).
  • fixed a bug with DoF task in WebGL
  • added visualization tests

Other changes:

  • fixed a state problem where the current frame buffer was not reset to the correct value at the end of createMultipleRenderTarget.
  • fixed shadowMap.customIsReadyFunction to correctly check readiness when ObjectRenderer.isReady is called.
  • improved debugging by updating engine render pass names when ObjectRenderer.name is updated

@bjsplat
Copy link
Collaborator

bjsplat commented Jan 6, 2025

Please make sure to label your PR with "bug", "new feature" or "breaking change" label(s).
To prevent this PR from going to the changelog marked it with the "skip changelog" label.

@bjsplat
Copy link
Collaborator

bjsplat commented Jan 6, 2025

@bjsplat
Copy link
Collaborator

bjsplat commented Jan 6, 2025

@bjsplat
Copy link
Collaborator

bjsplat commented Jan 6, 2025

@sebavan sebavan self-requested a review January 7, 2025 17:42
@sebavan sebavan marked this pull request as draft January 7, 2025 17:42
@Popov72 Popov72 marked this pull request as ready for review January 7, 2025 20:01
@sebavan sebavan merged commit d838e19 into BabylonJS:master Jan 7, 2025
14 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants