Hey folks,
LWJGLFont had a small bug in it that was eatting tons of memory. Basically under any circumstance where the string changed size (and possibly other circumstances) a new ByteBuffer was created, regardless of if the current buffer was already sufficient. In my gui where I am using Text in many places, this was ballooning into a serious issue in a few seconds flat.
Now that’s fixed (it reuses the buffer if big enough) and I can get on with life. 
Along those same lines, I have the following change in my home version of jME. Inside TriMesh.updateIndexBuffer() I use
if (indexBuffer==null || indexBuffer.capacity()<indices.length){
indexBuffer = ByteBuffer.allocateDirect(
4 * (triangleQuantity >= 0
? triangleQuantity * 3
: indices.length)).order(ByteOrder.nativeOrder())
.asIntBuffer();
}
instead of:
indexBuffer = ByteBuffer.allocateDirect(
4 * (triangleQuantity >= 0
? triangleQuantity * 3
: indices.length)).order(ByteOrder.nativeOrder())
.asIntBuffer();
DiscretLOD test that update the index buffer every frame have a very noticable speed up. I'm going to submit the change to CVS, unless there's some reason it's like this. If anyone happens to actually want a shorter index buffer, they can always call setIndexBuffer(null) and let it get recreated next run.
No, I think most of the other buffers already have something like that. Does it work with Area Clod Mesh?
HelloLOD (which uses AreaClodMesh) runs about 50+ FPS faster with it in.
Cool, although I was more worried about accuracy of the results than speed really.
HelloLOD looks fine, so does the Terrain when it’s an AutoClod, as well as the default model loading test, but triangle count isn’t correct. I looked into LWJGLRenderer and see this:
IntBuffer indices = t.getIndexAsBuffer();
if (statisticsOn) {
int adder = t.getIndexAsBuffer().capacity();
int vertAdder = t.getIndexAsBuffer().capacity();
numberOfTris += adder / 3;
numberOfVerts += vertAdder;
}
GL12.glDrawRangeElements(GL11.GL_TRIANGLES, 0, t.getVertQuantity(), indices);
So I change it too
IntBuffer indices = t.getIndexAsBuffer();
if (statisticsOn) {
// int adder = t.getIndexAsBuffer().capacity();
// int vertAdder = t.getIndexAsBuffer().capacity();
numberOfTris += t.getVertQuantity() * 3;
numberOfVerts += t.getVertQuantity();
}
GL12.glDrawRangeElements(GL11.GL_TRIANGLES, 0, t.getVertQuantity(), indices);
And it still doesn't work, so I look at ClodMesh and I see
// // reduce vertex count (vertices are properly ordered)
// vertQuantity = rkRecord.numbVerts;
// reduce triangle count (triangles are properly ordered)
triangleQuantity = rkRecord.numbTriangles;
I uncomment the // and it seems to work, but I notice you commented that when you added VBO. I was wondering why. Does commenting it out make the command
GL12.glDrawRangeElements(GL11.GL_TRIANGLES, 0, t.getVertQuantity(), indices);
Slower for AutoClodMesh (because vertQuantity is getting smaller). Just curious. I don't know too much about LWJGL.
So it looks just fine, but doesn't report correct vertex numbers because of that comment.
I think I commented that out because it threw errors on some cards, not sure actually. :?
We could try uncommenting it again and seeing what happens.
The current system of reporting isn’t totally correct. For example, a quad shows as 6 vertexes and 2 triangles when it’s really 4 vertexes and 2 triangles. What if LWJGLRenderer used this instead of what it does.
if (statisticsOn) {
numberOfTris += (t.getTriangleQuantity() >= 0
? t.getTriangleQuantity()
: t.getIndices().length/3);
numberOfVerts += (t.getVertQuantity() >=0
? t.getVertQuantity()
: t.getVertices().length);
}
and we changed the function
public int getTriangleQuantity() {
return indices.length/3;
}
to (which is what the name suggest)
public int getTriangleQuantity() {
return triangleQuantity;
}
Then everything works/reports fine, but now reports the number of vertexes as the number of vertexes in the vertexbuffer and triangles as the number of triangles the object should have. The way it is right now, the information is kind of redundant because number of triangles is always a third of the number of vertexes.
I don’t have an issue with that…