When the simplification algorithm runs, the result mesh is added as a LOD mesh to the main mesh. You can recover the LOD levels of a mesh using getLODLevelAtDistance or getLODLevels: Mesh | Babylon.js Documentation (babylonjs.com), then clone the mesh you want (so it’s not attached to the main mesh anymore) and do whatever you want with it
Okay awesome! I’ll try this out and then I’ll render the edges of the resulting mesh to get a feel for the results. Which simplification algorithm does this use?
Looking at the name (and without digging too much into the algorithms), it doesn’t seem to be the same as the one you linked to. but it does provide good results
I was expecting the colors to look a bit off according to what the docs said, but I was hopping the overall shape of each mesh would be retained. I think this might have something to do with the meshes not being “optimized” - something to do with overlapping indices?
If this is the case, do either of you know how to fix this? The result I’m going for here with the collision meshes is that they represent a watered down version of the objects I want them to become physics imposters for, that way the memory load remains low when I instantiate mesh imposters for each.
The version we had implemented is not taking textures into account, and it does show. I don’t have any magic solution for that. What are the settings on your run?
@RaananW another thing I realized, some of these meshes are monolithic and contain many trees as well as other objects. The algorithm we’re using probably doesn’t realize the need to distinguish the individual shapes nearly so much as the overall shape of the cluster of trees and such.
quality 1.0 should provide the same result, but simplification will still run! Once could argue that if quality => 1.0 it should simply return the mesh (and I wouldn’t argue with you :-)) but it wasn’t implemented this way. Could be an improvement though!
I am sure some meshes will not work well with this algorithm. It doesn’t fit any type of mesh, and eventually is meant for Auto-LOD. I wouldn’t trust it as a simplification algorithms to meshes near the camera
Sorry, I am totally not updated… But TBH I doubt there are any new and exciting new players in this field. They were all invented at times when they were REALLY needed But this is just an assumption.
i think creating a map from the original model is probably much important than the decimation itself, like this:
For the sphere approximation, i guess the tldr is “We also proposed an algorithm…with a natural multi-resolution structure and an explicit control on its feature sensitivity”. That could be useful, but I think it’s probably safer to choose something being used by tons of people with budgets across projects in the billions of dollars. Implementing algorithms can be mentally rewarding but also time intensive, so I guess it really boils down to what you want to spend your time on
Yeah. I get where you’re coming from. I was exploring the SQEM algo because someone had already put in the work to implement it in c++. It was looking really exciting for a moment with the results I was getting until I realized that the researchers hadn’t yet figured out a good way to go back from spherical meshes to triangular meshes. So that was a dead end lol.
I did end up finding a great approach for the meantime:
Use blender to generate a height map for the scene