steps to take after Object3D.setMesh(mesh)

[raft]

hi,

i created an Object3D with zero triangles and set a mesh to it. after this either calling build() or recreateTextureCoords() throws a null pointer exception at recreateTextureCoords().

what other steps should i take to prepare the object ?

[EgonOlsen]

The Mesh just contains the geometry information. For example, it doesn't contain any texturing information. Those are part of the object itself (or at least bound to it in 1-to-1-relationship contained in a package private object). So by creating an Object3D with 0 polygons, no space is reserved for texturing information at all...hence the null pointer exception. You either have to create the initial object with the correct triangle size or...i'm not sure what else...what's the purpose of this? Why not create the object directly?

[raft]

ok, i can live with it. let me try..
the purpose is, to save a skinned object group and related information (skeleton, pose, joints, weights etc) to a stream and reload it.
i dont want to save Object3D itself as it gets too big and unnecessary. so i save the mesh only and restore object with that mesh

[raft]

ok, i got rid of exception but i cant get a correct render. i set the texture, call build() and recreateTextureCoords(). what else ?

[EgonOlsen]

What are you doing exactly now? Serializing the Object3D or just the Mesh and inject it into a newly created Object3D with the proper triangle count?

BTW: build() includes recreateTextureCoords(). There's no need to call it if you are already calling build() anyway.

[raft]

i serialize only the mesh and some skin data, not the Object3D. while reloading, create a Object3D with the triangle count of mesh, set the mesh, set texture and finally call build

a cycle very similar to Object3D(other object, true)

[EgonOlsen]

Well, as said: The Object3D contains the texturing information. And that means the u/v coordinates, not just the texture id. Can't you simply serialize what you drop in her anyway:

public Object3D(float[] coordinates, float[] uvs, int[] indices, int textureId)


? That's as short as it gets and not bound to any implementation. It could be reloaded at any time even if the Mesh's UID changes or something.

[raft]

ok. i can do that

[EgonOlsen]

Another option would be to extract texturing information from the Object3D by using the PolygonManager (possible unless you are using multi texturing, which the manager's getTextureUV()-method doesn't support) and recreate it at load time again by using the PM. Or i could write some getDump()/setDump()-methods for Object3D, but i really think that using the plain float[]-arrays is the better solution, isn't it?

[raft]

this is good enough. the only detail i dont like with this is, i should keep a copy of that coordinates in my object and user should manually discard it if not used. but no big deal

[EgonOlsen]

Ok, great. I've tried to reduce the space usage of a serialized Object3D anyway, but all i could squeeze out of it was approx. 1.1 KB/Object3D. Nothing to get crazy about...

[raft]

Well, as said: The Object3D contains the texturing information. And that means the u/v coordinates, not just the texture id.

just for curiosity, why is it that way btw ? isnt mesh a more natural location to put texture coordinates ? current scheme allows using same mesh with different coordinates but i guess there are very few cases requiring that and can be handled differently.

[EgonOlsen]

That's mostly an artefact of the software renderer. The software renderer uses different u/v-coordinates for rendering than the normalized ones that you load from a file. They depend on the texture(s), so two objects with the same u/v-mapping but different textures may use different rendering u/vs. So for the sw renderer, you obviously can't store these coordinates in a shared mesh. You could actually store the normalized ones there as you said, but i didn't want to separate the two. Basically, jPCT stores everything indexed in  Mesh and everything not indexed in Vectors (not public). Texture coords are not indexed in jPCT (unlike OpenGL), because i wanted to keep the geometry count as low as possible (i.e. index rate as high as possible).