SharedMesh and collision tree

Troubleshooting General Help
21

Fantastic info, knowing how to draw a few boxes on the screen is one thing, knowing how to draw a few boxes efficiently is priceless.



Maybe a developer best practices paper would benefit many


Compare the memory usage as well. There's one area that the SharedMesh will shine...

Indeed mojo, less memory required is a major plus, as is less to garbage collect.
If you consider to basing the app on jdk 1.5, you will see many compiler and run time improovements. Guess that one of the issues you may face with this engine is pinpointing who is running jme and what jdk they are using.
Version 1.5 is closer if not comparable to the speed of c++ in alot of areas. 1.6 ( due in april i think ) will once again provide improovement. Think all the mac issues are resolved.
You have the user showcase, but there may be benefit in having working applications register with youreselves so you are able to contact them to see if it is feasable for them to upgrade to the next jvm. Or, do the IBM way and say you will not support jme v0.9 in six months time unless you have upgraded the jvm

you might also try this all again once the lockable mesh options are in place later in the week.

ill do that, was going to mention it in the last post, but decided not to pretend that i had a clue as to what lockable mesh's do under the cover
22

We actually recommend running jME in a java 1.5 vm (aka 5.0)… we just don't support 1.5 language syntax yet.  I see some compelling reasons to do so, but I'm guessing (and this is conjecture only) that when we do go 1.5 it will be a concentrated point release where all we do that release is go over every class and try to update and take advantage of the new syntax.  At the moment, it makes no sense to spend that time (it will just delay some crucial engine features) and adding the syntax in the meantime here and there in the code will needlessly limit and confuse.

23

Ok, this has really perplexed me



With VBO enabled on the trimesh

Individual      : FPS 29 ( is now faster than sharedmesh, i treble checked)

SharedMesh  : FPS 21

Cloned        : FPS 34



Makes shared mesh look like a villain


24

How did you enable VBO for the shared meshes? (you should set it on the original mesh, not the shared meshes themselves)

25

I did enable on the sphere itself, which is passed to the constructor of the SharedMesh



s1 = new SharedMesh(meshName + i, p);           
x = (float) Math.random() * randomSeed;
z = (float) Math.random() * randomSeed;
if(tb == null)s1.setLocalTranslation(new Vector3f(x, 50, z));
else s1.setLocalTranslation(new Vector3f(x, tb.getHeight(x, z)+10, z));      
s1.setLocalScale((int)(Math.random() * 3.0) + 1);
s1.setVBOInfo(new VBOInfo(true));
rootNode.attachChild(s1);

26

well, here you are doing it on the shared meshes, not the orginal mesh. Before going into your loop, you should do something like p.setVBOInfo(new VBOInfo(true))

What you have posted here, should give you about 700 warning messages when you run it.

27

DOH !!!



Time for a power nap me thinks



ok for sharedmesh fps is upto 33fps, but doesnt have the memoryover head.



I didnt benchmark start up and memory usage times.



Thanks