Two questions:
How are texture coordinates handled with CLOD?
Right now it seems that CLOD can only work on the basis of the entire object’s distance from camera… what about vertex distance such that in a terrain system the farthest parts of the terrain are reduced triangles but close up we have full detail?
The CLOD reduction algorityhm comes straight from Eberly (as is the general jME way) and is based on preserving the original shape of the object as much as possible (thus preventing ugly popping and such as in other methods)
That said, you’ll get best performance with a terrain that is cut into small terrainblocks. Then you get both reduction based on distance and shape preservation.
AreaClodMesh just doesn’t seem to be working for me.
AreaClodMesh clodmesh = new AreaClodMesh( "ACMChunk" + ch, trimesh, null);
clodmesh.setDistanceTolerance( 0.0f);
clodmesh.setTrisPerPixel( 0.1f );
clodmesh.setRenderState(ts);
clodmesh.setModelBound(bv);
clodmesh.updateModelBound();
I have chunks of my map in the trimesh. It's 20x20 quads( not Quads, but quads :) ). I have 200 chunks.
As I 'zoom' out the triangle count does not change at all.
I have no idea.
CLOD is Renanse’s perview, so I’m not sure what’s happening here. You code looks fine. Although I have never seen the distance tolerance set to 0. Does changing that to 1 have any effect?
As a test try running the TestTerrain class, but modify the code giving the constructor of the TerrainBlock a true value (this turns CLOD on).
Hey, just got back from surgery so this may not be clear… (pain pills are wonderful things.)
TestAutoClodMesh is what you should try… Just ran it myself and it’s not working anymore… sigh. Will look into what’s been changed (and who changed it ;))… more in a bit.
Update: Actually, the test does work… just seems to work way further back than it used to. still looking…
Ok, so here’s the thing… The decision to start cutting down on the tri count is based on the area of the mesh’s bounding volume. It uses that area and the trisperpixel field to decide the optimum number of triangles to target. This all still seems to work fine, nothing has been changed in the clod code since the time we announced it was working.
So why does it seem different? Well, for some reason the bounding sphere being used is about twice as big as it should be (hit b to turn on bounds in that test and see for yourself.) So, the calculation is getting an area that is way bigger and thus the triangle count stays high. So the real question (for the test anyway) is what happened to the bounding sphere. If I switch out for a bounding box, it works fine.
Ok, it was all my fault… :// When we converted scales from a single float to a vector3f, I multiplied the radius by scale.length… thus for a scale of (1,1,1) it was multiplying it by the squareroot of 3 instead of just 1 as it should have… so I’ve fixed this, it now multiplies by the largest value of the scale’s x y or z. This would have affected collision and other things if you were using bounding sphere… sorry!
I just realized somthing… I don’t use Bounding Spheres I use Bounding boxes…
Will it still work?
I’m testing.
Um… so does TestTerrain ://
But, I think I’ve figured out what’s going on.
I figured out that my Clod was never more than 1 record in size. The ClodCreator would never create any more. After looking through the code I realized that it’s probably because the triangles in my meshes don’t share indexes. Each quad is independant of the others, and therefore the creator would have a hard time figuring out how to add together triangles.
Again ://
Well, with my new way of texturing, I think I can actually use the Terrain stuff from jme :), so that’s good.
guurk said:
Um... so does TestTerrain ://
But, I think I've figured out what's going on.
I figured out that my Clod was never more than 1 record in size. The ClodCreator would never create any more. After looking through the code I realized that it's probably because the triangles in my meshes don't share indexes. Each quad is independant of the others, and therefore the creator would have a hard time figuring out how to add together triangles.
Again ://
Well, with my new way of texturing, I think I can actually use the Terrain stuff from jme :), so that's good.
Hi!
I've found same problem. How did you solve it?
Is there any way to combine such triangles?
Looking for the reason, I've found the code from the ColladaImporter class:
private Spatial processTriMesh(meshType mesh, geometryType geom)
throws Exception {
HashMap<Integer, ArrayList<MeshVertPair>> vertMap = new HashMap<Integer, ArrayList<MeshVertPair>>();
...
Vector3f[] v = (Vector3f[]) data;
StringTokenizer st = new StringTokenizer(tri.getp()
.getValue());
int vertCount = tri.getcount().intValue() * 3;
FloatBuffer vertBuffer = BufferUtils
.createVector3Buffer(vertCount);
triMesh.setVertexCount(vertCount);
for (int j = 0; j < vertCount; j++) {
// need to store the index in p to what j is for later
// processing the index to the vert for bones
int vertKey = Integer.parseInt(st.nextToken());
ArrayList<MeshVertPair> storage = vertMap.get(Integer
.valueOf(vertKey));
if (storage == null) {
storage = new ArrayList<MeshVertPair>();
storage.add(new MeshVertPair(triangleIndex, j));
vertMap.put(Integer.valueOf(vertKey), storage);
} else {
storage.add(new MeshVertPair(triangleIndex, j));
}
BufferUtils.setInBuffer(v[vertKey], vertBuffer, j);
for (int k = 0; k < maxOffset; k++) {
st.nextToken();
}
}
triMesh.setVertexBuffer(vertBuffer);
Seems like the vertMap hash should deal with shared vertexes, but it is incompleted.
Any ideas?