• Content count

  • Joined

  • Last visited

  1. 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.
  2. 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.
  3. 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); ...
  4. 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!
  5. This was very easy to adapt from what @davrous mentioned. I suggest to implement a physically connected touch interface so that each physical connection gets a screen mapped point in 3D space from picked coordinates. The interface would simply move the picked points to match the finger positions as best as possible. This makes for a very intuitive interface, as the model stays under the connected styli/fingers directly. Zooming, panning and even 3D rotations come out of the box. For rotation I would lock the up vector, and just rotate accordingly. Below is the panning code. https://www.babylonjs-playground.com/#C2ZGCJ#1