JME1 to JME2 - TriangleBatch

Troubleshooting General Help
1

I finally decided to make the plunge and translate my project to JME2, but I've hit a snag straight away that I can't see covered in the wiki page. I have a Grid that extends TriMesh (originally copied and adapted from Grid in AirCarrier), and makes use of TriangleBatch to do all sorts of stuff that I frankly don't understand:


 
TriangleBatch batch = getBatch(0);
batch.setVertexCount((xQuads + 1) * (yQuads + 1));
batch.setVertexBuffer(BufferUtils.createVector3Buffer(batch.getVertexCount()));
batch.setNormalBuffer(BufferUtils.createVector3Buffer(batch.getVertexCount()));
FloatBuffer tbuf = BufferUtils.createVector2Buffer(batch.getVertexCount());
setTextureBuffer(0,tbuf);
batch.setTriangleQuantity(2 * xQuads * yQuads);
batch.setIndexBuffer(BufferUtils.createIntBuffer(batch.getTriangleCount() * 3));



etc

Evidently there is no TriangleBatch in JME2. Can anyone give any pointers on how this should be done now? Is there a simple substitution class to use instead (I hope)?
2

This looks basically like a TriMesh or a QuadMesh to me, but I'm not familiar with jME 1.0 so there may be a nuance I don't understand.

3

Correct, TriangleBatches were done away with completely.

The TriMesh itself should replace getBatch(0)

I think something as simple as this may work:



setVertexCount((xQuads + 1) * (yQuads + 1));
setVertexBuffer(BufferUtils.createVector3Buffer(getVertexCount()));
setNormalBuffer(BufferUtils.createVector3Buffer(getVertexCount()));
FloatBuffer tbuf = BufferUtils.createVector2Buffer(getVertexCount());
setTextureBuffer(0,tbuf);
setTriangleQuantity(2 * xQuads * yQuads);
setIndexBuffer(BufferUtils.createIntBuffer(getTriangleCount() * 3));

4

Thanks guys, appreciate the help. It got me going… but only to run into the next set of problems



FloatBuffer texs = getTextureBuffers().get(0);

…

BufferUtils.setInBuffer(vert, getVertexBuffer(), ind);

…

etc etc



So I think I'm going to be sticking with JME1 after all. Unless there is any really pressing reason to go through this pain?

5

There isn't really a pressing reason. Decent applet deployment due to the more recent version of LWJGL was my reason. And compatability with some of the code and tools people are writing might be a good one.



But it is comparatively easy, it just looks complicated where things were removed. They all have straightforward equivalents, it's just a matter of finding them. The wiki, and side by side comparison of JME1 and JME2 jmetest code have most of the answers.



I can't remember those two off the top of my head but I think in most cases, multiple indexed buffers were just removed, so instead of get(0) or put(0), the data is just there in the parent.

6
richitis said:

Thanks guys, appreciate the help. It got me going... but only to run into the next set of problems

FloatBuffer texs = getTextureBuffers().get(0);
...
BufferUtils.setInBuffer(vert, getVertexBuffer(), ind);
...
etc etc

So I think I'm going to be sticking with JME1 after all. Unless there is any really pressing reason to go through this pain?


to access the texture coordinates for a particular unit do the following...

FloatBuffer buf = mesh.getTextureCoords(textureUnit).coords;

i'd advise moving to jme2 as it is far more stable and performant...