- Notifications
You must be signed in to change notification settings - Fork3.5k
Add MSFT_screencoverage support for MSFT_lod#16736
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 ourterms of service andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
base:master
Are you sure you want to change the base?
Uh oh!
There was an error while loading.Please reload this page.
Conversation
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/16736/merge/index.html#WGZLGJ#4600 Links to test babylon tools with this snapshot: https://playground.babylonjs.com/?snapshot=refs/pull/16736/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/16736/merge#BCU1XR#0 |
WebGL2 visualization test reporter: |
Visualization tests for WebGPU |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
Hi@bghgary, thank you for the feedback. Regarding the intended use, I’m working on rendering several high-poly meshes at once within a large scene in my project, and I want to improve rendering performance. |
MSFT_lod operates on a node of a scene hierarchy as opposed to on a single mesh. The glTF can have a completely different node hierarchy per LOD. For example, the high LOD of one hierarchy may have 10 nodes with 3 meshes but the low LOD may have only 2 nodes with 1 mesh. |
WebGL2 visualization test reporter: |
Visualization tests for WebGPU |
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/16736/merge/index.html#WGZLGJ#4600 Links to test babylon tools with this snapshot: https://playground.babylonjs.com/?snapshot=refs/pull/16736/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/16736/merge#BCU1XR#0 |
WebGL2 visualization test reporter: |
Visualization tests for WebGPU |
WebGL2 visualization test reporter: |
Visualization tests for WebGPU |
Visualization tests for WebGPU |
WebGL2 visualization test reporter: |
@bghgary |
WebGL2 visualization test reporter: |
Visualization tests for WebGPU |
1 similar comment
Visualization tests for WebGPU |
Thanks for the updates. It seems you are making changes to the core scene rendering code. It would be good to get input from@sebavan@deltakosh@Popov72 to review the approach. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
the changes in scene looks like they could potentially harm perf by increasing the code in evaluateActiveMeshes which is already a bottleneck I am wondering if there is a less intrusive way to do this ?
| @@ -1116,7 +1116,11 @@ export class Mesh extends AbstractMesh implements IGetSetVerticesData { | |||
| return this; | |||
| } | |||
| const bSphere = boundingSphere || this.getBoundingInfo().boundingSphere; | |||
| let bSphere = boundingSphere; | |||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
this looks like a potential breaking change I am not sure we should create the bounding sphere here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
This is meant to calculate screen coverage correctly when the highest-LOD root mesh has a hierarchy. I think the coverage should be computed over the root and its children.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
wouldnt in this case pick the wrong LOD ?
Let s say smthg tiny as a really large child, the hierarchy would be consider really large showing the highest details whereas it should only display the lowest ?
Any news@miudit ? |
This PR introduces MSFT_screencoverage support to MSFT_lod extension, enabling LOD switching based on screen coverage.
A previous implementation of screen coverage based LOD was submitted in#10509 but reverted in#11840 due to its reliance on a very specific model structure. This update removes the structural constraints and broadens support for arbitrary glTF models.