Would someone mind giving me a quick rundown of the differences in the Shared Meshes, Shared Nodes and CloneImportExport?
Looking through the old posts is rather confusing, since these classes seem to have undergone several changes.
Okay, then I will give my understanding and hopefully someone will tell me if a I am all wrong
Shared Mesh: One single Mesh to lots of objects. Mesh is only sent to VCard once. Transforms work, but each mesh must use a single texturestate.
Shared Node: One single Node which shares all renderstates (??) (I think I am ALL wrong here). Different animations among a shared node are not possible.
Clone: Exact copy of a Node, spatial, etc. each copy has it's OWN mesh, renderstates and animation.
So, for example in my billiards game; there are 9 tables each with 16 balls. What would be the recommended (most efficient) construct to use? There are 17 textures states and 9 light states, one for each table, nothing is animated (currently) or deformable. Currently I am just cloning everything, but before I went head long into changing it I was wondering if someone would mind giving me a little feedback.
Thanks, 
Hmm, so either this is a really dumb question or the answer is posted somewhere obvious. Would someone mind at least pointing me in a direction that I can find out?
I Think, when all Objects have different renderStates, the best way is to don't use the Shared Stuff, and make it in a traditional way is the best.
I remember, I read somewhere SharedNode only is good for realy many copies of one object.
Sorry for late response, like perhabs the most, I thought you dont need this anymore 
Im still scratching my head about what to use for diff scenarios.
As a rule I tend to think that
a> if there is something that will get indivdually animated, then sharing meshes ( textures are OK ) wont work as is with JME.
b> if there is something used many times, but each one may have a diff rotation - use a shared node that containes shared node.
You really want to lock objects for performance, if you can lock it and share it, then it probably is the right way.
Thanx for the replies
I must be blind though, shared meshes is indeed posted in the Wiki
http://www.jmonkeyengine.com/wiki/doku.php?id=sharedmesh
However, the shared node is not.
Maybe someone with a firm understanding will post a little about shared meshes VS. shared nodes, it seems like it might be an area that is rather gray and easily confused. What makes matters a little worse is the shared node test case shows animation but it appears that all the frames are identical.
I would be happy to update the wiki (Shared Node) once I understand the differences a little better.
Sorry,
b should read …
b> if there is something used many times, but each one may have a diff rotation - use a shared node that contains shared meshes.
Thank you for the clarity, I also think using shared meshes for physics might be a no-no. I will try your trick of using shared meshes wrapped in a shared node though.
I think that the SharedMesh/SharedNode classes should be removed from jME 2.0, they are mostly supposed to cover a design flaw… Maybe there could be a special ModelManager class (similar to TextureManager) that automatically generates VBO/Displaylists for loaded models, caches them, possibly doing the loading in a different thread, and correctly sharing data between animated models…
Momoko_Fan said:
I think that the SharedMesh/SharedNode classes should be removed from jME 2.0, they are mostly supposed to cover a design flaw.. Maybe there could be a special ModelManager class (similar to TextureManager) that automatically generates VBO/Displaylists for loaded models, caches them, possibly doing the loading in a different thread, and correctly sharing data between animated models..
that sounds very much like my assetPool haha :D
Momoko_Fan said:
I think that the SharedMesh/SharedNode classes should be removed from jME 2.0, they are mostly supposed to cover a design flaw.. Maybe there could be a special ModelManager class (similar to TextureManager) that automatically generates VBO/Displaylists for loaded models, caches them, possibly doing the loading in a different thread, and correctly sharing data between animated models..
Would like the TextureManager to be revised first, then yes a ModelManager is a good idea.
The issues I see with TextureManager in its current state is the caching with TextureKey. A key and the texture are not closely coupled, you cannot find the key from a texture..
A key cannot be extended, this restricts custom keys that can hold pointers to the game logic. TextureManager cannot be customised as LWJGLTextureState extends it, this restricts custom caching. All of the loadTexture methods cache.
I am quite sure you can get a texture key from a texture. There's a method Texture.getTextureKey() which you can use, you can also make a texture key yourself if you know the URL and whether the image is flipped or not. Either way, I don't see why you would ever need access to the texture key…
What you're probably thinking is to create a generic resource caching and loading system, I don't think this would work. Models and textures must be handled in completely different ways, they are handled differently inside OpenGL and so need to be handled differently inside the manager classes.
Thanx Momoko_Fan
I will just continue working with what I have, but leaving extendability a primary goal.
Neakor:
Did you post the assetPool source under the UserCode section? Maybe it IS something that renanse or irrisor would want to know about…
Momoko_Fan said:
I am quite sure you can get a texture key from a texture. There's a method Texture.getTextureKey() which you can use, you can also make a texture key yourself if you know the URL and whether the image is flipped or not. Either way, I don't see why you would ever need access to the texture key..
Firstly, to allow a colourful and rich textured world, you need to manage images and flush them from the graphic card ( afaik ). Using a thread to test what images are used is a great way to find image redundancy. The texturekey is the bridge from what is being used, what is being cached and what is redundant.
Secondly, the whole point of where I see an issue is that the texture key is based on a URL. This wont account for images created on the fly, how can these get flushed ??