ArrayIndexOutOfBoundsException in Object3D.init

[raft]

I'm creating an Object3D by supplying coordinates array:

Code Select Expand

new Object3D(coordinates[142509], uvs[95006], indices[480], TextureManager.TEXTURE_NOTFOUND);

numbers indicate the actual length of arrays. this code throws an java.lang.ArrayIndexOutOfBoundsException: 731. I dont know where that 731 comes from

here is a test case:

Code Select Expand

public class MeshTest {

public static void main(String[] args) throws Exception {
String file = "C:/tmp/bones_tmp/test_mesh.ser";

            FileInputStream fis = new FileInputStream(file);
ObjectInputStream in = new ObjectInputStream(fis);

float[] coordinates = (float[]) in.readObject();
float[] uvs = (float[]) in.readObject();
int[] indices = (int[]) in.readObject();

fis.close();

new Object3D(coordinates, uvs, indices, TextureManager.TEXTURE_NOTFOUND);

}

}


and test data: http://aptalkarga.com/tmp/test_mesh.ser

[EgonOlsen]

That 731 is the number of vertices. That method assumes that the number of indices defines the number of triangles...which seems reasonable to me. But with these arrays, there are 142509 coordinates but only 480 indices referencing them. That means that most of the coordinates are unused anyway. The method doesn't expect the mesh to be build this way. It expects that each coordinate will be used at least once.
Is there any reason for these strange sizes? I could try to fix the method, but that would create lots of coordinates and texture coordinates for no purpose.

[raft]

That 731 is the number of vertices. That method assumes that the number of indices defines the number of triangles...

ok, but doesnt the length of indices array actually define the number of indices?

...It expects that each coordinate will be used at least once.
Is there any reason for these strange sizes? I could try to fix the method, but that would create lots of coordinates and texture coordinates for no purpose.

Because the Ogre exporter exports it this way and jME's loader loads it as it's. Indeed these coordinates are shared among many objects (submeshes). in xml file all are used. but in Bones a new copy is used for each object and hence a waste as you said.

what options do we have here? reorganize arrays and discard unused vertices either in Bones or in Object3D?

[EgonOlsen]

what options do we have here? reorganize arrays and discard unused vertices either in Bones or in Object3D?

Yes. Does Bones somehow know that this is needed? Because i don't and i would like to avoid doing this all the time with no need in almost every case.

[raft]

what options do we have here? reorganize arrays and discard unused vertices either in Bones or in Object3D?

Yes. Does Bones somehow know that this is needed? Because i don't and i would like to avoid doing this all the time with no need in almost every case.

I guess so. If I get the thing correctly,

• iterate over indices array and look for min and max values
• reorganize arrays such that length of coordinates is (max-min)*3 and uvs (max-min)*2

btw, I still dont get where 731 comes from

[EgonOlsen]

That way, it might still contain a lot of overhead depending on how the coordinates are organized. I would rather take all triples and tuples from the xyz and uv that have an index in indices, copy them into a new structure and adjust the indices accordingly. That way, only indexed geometry remains in the arrays.

The 731 is the max vertex count+1...calculated based on the calculated triangle count which itself it somehow based on the number of indices...i don't know the exact formula that i'm using ATM, but that's the idea.

[raft]

That way, it might still contain a lot of overhead depending on how the coordinates are organized. I would rather take all triples and tuples from the xyz and uv that have an index in indices, copy them into a new structure and adjust the indices accordingly. That way, only indexed geometry remains in the arrays.

ah, of course. i wrote that without thinking in detail.. I'll try to implement that

but, IMHO, jPCT should be able handle that too. after all the given arrays are valid although they are not filled very efficiently. it doesnt need to compact the arrays but use that sparse arrays without an exception. just my 2 cents

[EgonOlsen]

I agree...i'll fix that.