Well basicall I was wondering, if in JME3 i still have to keep a copy of the Meshdata for any animated object, in order, or if it is now possible to share that data between mutiple objets, not playing the same animation.
Empire Phoenix said:
Well basicall I was wondering, if in JME3 i still have to keep a copy of the Meshdata for any animated object, in order, or if it is now possible to share that data between mutiple objets, not playing the same animation.
Right now jme3 just includes a basic version of the jme2 ogrexml importer. But the plan is to have jme3 include basically only the ogrexml importer, but in a way more integrated way than jme2 did. So mesh/animation sharing will be definitely one thing that will be addressed.
Edit:
Having said that, keep in mind that meshes are one of the least memory intense things (think of textures) and that for physics softbodys etc. you will always need the separate mesh info.
Well, yes, however it hardly depends on the amount of meshes (and in JME2 there is the missing garbage collection problem as well), it greatly makes a difference if it is a player, and there are only 20 players in the map or if it is a spaceship weapon and a single ship can have hundrets of them 
But I'm glad to hear that sharing is planned, that will surely help reducing the needed amount of data.
Empire Phoenix said:
Well basicall I was wondering, if in JME3 i still have to keep a copy of the Meshdata for any animated object, in order, or if it is now possible to share that data between mutiple objets, not playing the same animation.
Assuming you're using hardware skinning and no vertex animation, then ALL data is shared. Mesh, Materials, Skeleton and Animations are all shared. If you're using software skinning, then each mesh has two duplicated buffers for the position and normal.
I assume vertex animation is the opposite of bone animation? If so then there is no problem i guess.
Well we reached the end of my knowledge, how do I know if a certain animation is using hardware skinning?
Empire Phoenix said:
I assume vertex animation is the opposite of bone animation?
No. Vertex animation means you deform a mesh. Bone animations can do that but they can also just move two separate meshes in respect to each other (e.g. a robots body and arms). This way you can share the mesh data because the single vertexes in the mesh do not change. If you do vertex animation, you will always have to store the info about the vertex locations for each deformed mesh.
So the idfference is how many meshes i use
jME3 will always use hardware skinning if you're using the LWJGL renderer since the minimum requirement is OpenGL2.
Anyway, this isn't in yet however, but will be there once the animation system is complete.
Momoko_Fan said:
jME3 will always use hardware skinning if you're using the LWJGL renderer since the minimum requirement is OpenGL2.
Anyway, this isn't in yet however, but will be there once the animation system is complete.
@Momoko_Fan The current way hardware skinning is done with OgreXML in JME2 the number of bones is set explicitly in the shader code to allocate the correct size of the array of bone matrices. Is this how you're planning on doing it in JME3, or have you thought of a better way? I might plan on jumping in to help to complete the animation system, with your ideas and my time permitting of course. I was just wondering what your thoughts were, since it seems you want to make hardware skinning standard in JME3 which I think is awesome.
Creating a shader for each number of bones would be very, very bad. It's better I think to have some common counts like 30, 40, 50, etc and use whichever one has the required # of bones.
Momoko_Fan said:
Creating a shader for each number of bones would be very, very bad. It's better I think to have some common counts like 30, 40, 50, etc and use whichever one has the required # of bones.
I wasn't thinking of it like that, I was thinking of how JME2 currently does hardware skinning. I don't think there should be set shader for hardware skinning, I think the user should be able to override it with they're own shader so they can have they're own lighting/normal maps/whatever code in it. Maybe there should be something that would parse a shader and if it finds @NumberOfBones (as an example), it would replace it with the actual number. But I'm also seeing what your saying maybe the standard hardware skinning shader should have a set of common counts of bones.
There wouldn't be a specific shader for skinning! That would kind of make the whole shader system useless. I think it would be integrated with the shader-lib system, so you can do something like #import "skinning.glsllib" then use inPositionAfterSkinning variable, if skinning is enabled in the material-defines, then the variable would cause a computation of the skinning, otherwise, it would just contain inPosition unaltered.
Ahh that makes more sense.