Hi there! Well I have problem with ClodMesh class which doesn't work. I create a trimesh by passing array of triangles and vertices. Once trimesh is reconstructed I try to use ClodMesh to decimate triangles from it but using method setTargetRecord doesn't change anything… Why? I've tried some test classes in jME and it work correctly.
Have I done something wrong?
Outline of code:
TriMesh mesh = new TriMesh();
mesh.reconstruct(...) // I'm passing float buffers here
...
...
... // updates, setting renderstate, etc.
ClodMesh clod = new ClodMesh("thing", mesh, null);
...
...
clod.setTargetRecord(clod.getTargetRecord + 200) // and nothing happens
I have been looking into this and I don't see a failure and my experience with ClodMesh is limited. It would be nice if you can provide SimpleGame based example.
Is your mesh drawn correctly (without the ClodMesh)?
Also note that RenderStates are not copied to your ClodMesh, you need to set them as well in the ClodMesh and update everything after creating it and setting the target record. Try different values for the target record as well.
I don't think that the CollapseRecords are being generated correctly then, this is generally due to the CLOD stuff not being able to handle that particular mesh (I believe there are some specific rules to follow when making a CLOD model, but can't remember). If you have to have CLOD then you might want to look at the javadoc (theres at least one reference to the paper the algorithm was based on) or you might want to consider using DLODs (distance switch models…)
Lod is quite critical for my application. It produce mesh with about 4,000,000 to 6,000,000 triangles per one mesh and I need to control number of triangles with diffrent lod. Any ideas? Memory is also critical.
mesh with about 4,000,000 to 6,000,000 triangles per one mesh
:-o :-o :-o
UMMM, then using CLOD (continous level of detail, the mesh is CONSTANTLY changing) is probably going to require a super computer ;).
I would highly recommend you use DLODs (discreet level of detail; lower models are pre-built by modeler and then only the distance to the camera is checked and a lower/higher quality model is substituted when needed). Although this requires separate models it is akin to pre-processing ALL the mesh data that the CLOD algorithm has to do on the fly. Also, the collapse records use roughly the same amount of memory that separate models would; so basically CLOD has the same memory footprint as DLOD, but it has to process alot more 'stuff' at runtime. As well as the added loading time to create all the collapse records (which can take much longer than just loading separate models anyway).
I think in your case you are doing all the mesh creation on the fly, so would suggest you figure out a way to have that algorithm produce several 'levels' of detail. I like using a 1/4 falloff, so 4 LODs would be like this: (4,0000,000/HIGH->1,000,000/MED->250,000->low->125,000->ugly(or even use billboarding for the final LOD)...
Hope that helps... :)
p.s. what the heck are you doing that you need that kinda detail?? (GIS surveying for NASA perhaps? :P)
AHH, just FYI that is a HUGE number of tris (although it IS structured in a way that modern v-cards like).
How many different meshes we talking here? and what kind of frame rates are you getting? and are you doing any tree separation stuff to speed it up? (inquiring minds wanna know ;))
