Lodding meshes belonging to a tree-like structure with MSFT_lod

[Kjue]

Hi! I'm doing a custom exporter from a source to get nice and structured glTF models as binary-glTF for my use case in BabylonJS. I modified it so that it comes equipped with the tags for MSFT_lod in place. I found I got it working to an extent with 3.1.1 version and I finally figured out that it's just simulating the loading of higher detail levels. So I checked out the latest as well. Trouble I'm seeing now after modifying the lod scheme in the loader for MSFT_lod, so that it would in fact use the addLODLevel function, is that the meshes that are part of the logical tree don't seem to hide away and I'm wondering why.

I did also figure out a potential getaway card with the idea, that since I have put the submeshes to contain anything that belongs to a leaf of a node into the same subbranch of the tree, I can pretty much flip the mechanism around and just reconstruct the tree form branches and would-be-boundingboxes to form a makeshift LODding scheme. It's not what I wanted per say, as I would love to control the scheme in the exporter side.

Now I am still thinking if even that will work if I cannot even make the branches disappear with addLODLevel(distance, null) calls. Help, please? Cheers!

[Guest]

We definitely need an example in the PG to understand your needs

[Guest]

Pinging @bghgary fyi

[Kjue]

I'll see if I can work it into PG. What I'm really trying to understand is the way that the lodder works in BJS, and under what principles. I have read through the sources already, and the documentation regarding the instanced meshes with lodding.

I tried modifying the MSFT_lod _loadNodeAsync to use the addLODLevel method instead of removing the meshes from the scene when a more detailed version was available. When I did that, the lod meshes worked as expected and disappeared with distance, while the higher detail meshes remained visible regardless of distance.

...
node._babylonMesh.addLODLevel(500, null);
lod._babylonMesh.addLODLevel(900, null);
...

 

[Guest]

This **should** work ! So definitely need a repro !

[Kjue]

Well okay, that was fairly straightforward to repro. Here it is. It also has a bug with the lighting scheme and toggling debug view will show the real colors. Don't know what that is about, it looked okay on my other code. The key item is that when one zooms out, the lod items disappear as expected and the other parts just stay as they are.

[Kjue]

Right and I also figured it out myself. There is a dualistic nature to the loop which was confusing. Turns out that different parts of the loop trigger at different times and the hierarchial parts are loaded later. So they are available as the _primitiveBabylonMeshes for the nodes. After I found that, it works charmingly and I can proceed with making the changes I need for the use case.

Would there be interest in using the lodding the way we are using it elsewhere too? The specification leaves the implementation detail open on this.

[Guest]

Pinging @bghgary for the spec remark

[bghgary]

2 hours ago, Kjue said:

Would there be interest in using the lodding the way we are using it elsewhere too?

I think it will be useful, but it needs to be configurable depending on the use case.

2 hours ago, Kjue said:

The specification leaves the implementation detail open on this.

Yes, the spec does not specify how the extension should be implemented as noted in the first statement of the Overview. This is done intentionally as it depends on the use case.

Examples of how the extension are used currently is listed in the spec as well here. BabylonJS is currently being used by remix3d.com to improve the time it takes to first render the model.

[Kjue]

I'll have to get back to this later. It did not span to my use case easily so I ended up modifying the lodding from source after all. I will keep looking at solutions for expansion.