well first of all jme3 already does shared meshes, and i don't see ther an yperformance problems.
secondly do you call the above cade every frame?? or just once?
Also you really should sue the AssetManager for loading textures/,materials
This is jME2 you're talking about, not jME3, so I am going to move this thread to the appropriate forum.
Momoko_Fan said:
This is jME2 you're talking about, not jME3, so I am going to move this thread to the appropriate forum.
Could have sworn I pulled down jME3 from source, must have crossed my wires somewhere. I do have a full jME3 branch somewhere I can compare against.
Empire Phoenix said:
well first of all jme3 already does shared meshes, and i don't see ther an yperformance problems.
secondly do you call the above cade every frame?? or just once?
Also you really should sue the AssetManager for loading textures/,materials
Negative. Just once to create the texture. Then it is added to a texture state on a mesh that is later used to create a sharedmesh from. The logic in the code has not changed since jME 1, which is why I ask if there are any known performance issues related to applying texture states.
The assetmanager/texturemanager was not used by the co-developer who wrote the openflight model loader library for the Sun RGBA image loader. Eventually I'll move all the code into the proper framework. Our customer does not fund much of our jME work, so its been frustrating to say the least.
in the svn go to branches und use the one named jme3, If you want to use jme3.
Empire Phoenix said:
in the svn go to branches und use the one named jme3, If you want to use jme3.
Thanks, I already have that. The issue was a mislabeled /trunk checkout that I grabbed and ran with a without looking back. I had a jme3 branch for android, but haven't messed with it yet. One look at the namespace and it was obvious.