-
Notifications
You must be signed in to change notification settings - Fork 3.5k
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
Mesh: fix LOD management #16038
Conversation
… framegraph-internaltexture-refactor
… framegraph-internaltexture-refactor
… framegraph-internaltexture-refactor
… framegraph-resourcecont-shadowgen
… framegraph-resourcecont-shadowgen
… framegraph-resourcecont-shadowgen
… framegraph-compute
… framegraph-glow-layer
… framegraph-visu-tests
Please make sure to label your PR with "bug", "new feature" or "breaking change" label(s). |
Snapshot stored with reference name: Test environment: To test a playground add it to the URL, for example: https://snapshots-cvgtc2eugrd3cgfd.z01.azurefd.net/refs/pull/16038/merge/index.html#WGZLGJ#4600 Links to test babylon tools with this snapshot: https://playground.babylonjs.com/?snapshot=refs/pull/16038/merge To test the snapshot in the playground with a playground ID add it after the snapshot query string: https://playground.babylonjs.com/?snapshot=refs/pull/16038/merge#BCU1XR#0 |
Visualization tests for WebGPU (Experimental) |
WebGL2 visualization test reporter: |
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.
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 inObjectRenderer
/RenderTargetTexture
, because we may want to use a LOD for a camera that is different fromObjectRenderer.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:
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 newObjectRenderer.cameraForLOD
property).Other changes:
createMultipleRenderTarget
.shadowMap.customIsReadyFunction
to correctly check readiness whenObjectRenderer.isReady
is called.ObjectRenderer.name
is updated