Please watch this thread:
http://www.jpct.net/forum2/index.php?PHPSESSID=54eda69e3525ead6ba966b555c49f03e&topic=809.msg9352#msg9352
This does not make me laugh. Has JME 2.0 become one of the slowest Java engine??? Is this benchmark a joke?
My gut senses something's fishy (most likely unintentional)
I don't think this benchmark is reliable.
[quote author=[IR]Radek link=topic=10879.msg82313#msg82313 date=1239278673]
I don’t think this benchmark is reliable.
[/quote]
Please can someone replay this benchmark? My PC is too weak.
http://www.javagaming.org/index.php/topic,20248.msg163114.html#msg163114
Well, you have to wonder which tests he is running (where's the code and the models, etc.?) and what versions of xith and jme, etc. Easy to claim a benchmark when you are the engine's author and you don't give out the exact code for others to try themselves.
That said, the 91 vs 1000 Q3 test thing is not very surprising if you follow that thread along… He added a feature to jpct that compiles everything down to just the fewest number of batches needed to render that scene. In other words, at a very elementary level imagine the Q3 level is a big triangle soup… go through that soup and separate out all the triangles that are using the same states. Combine those into one big mesh. Now instead of several thousand "bsp faces" you have a couple dozen meshes. Your polygon chomping card loves you. 
Great idea except it changes the nature of the "benchmark" since jme and xith are purposely processing it as an old fashioned BSP with visibility calcs, etc.
Then again, those numbers are kind of odd:
xith3D:
fps view: 91 fps
level view: 69 fps
jPCT:
fps view: 1000 fps
level view: 1000 fps
maybe i just don't know what "fps view" is, but on my older PC here at home (P4 2.4G, nVidia 7800) I get in the 200-500FPS range flying through the level for both Xith and jME.
edit: maybe those numbers are from altering the xith test to not use visibility sets. That would fall in line with the numbers.
- The car model is really nice
- It weighs in at about 1.1million triangles, so let's all be happy for Java engines showing these framerates.
- I get around 20FPS with jME just loading the car and dumping it in the scene.
- Just by doing model.lockMeshes(), that jumps to about 250FPS
- This is on a single core AMD Sempron 3400 with a 3650 AGP graphics card.
Alric said:
- It weighs in at about 1.1million triangles, so let's all be happy for Java engines showing these framerates.
Most definitely!
Alric said:
- Just by doing model.lockMeshes(), that jumps to about 250FPS
Yeah, likely he is not taking advantage of things like locking.
Also based on his comments about toggling the in-game stats, it looks like he has the thumb on the scales a bit as he is likely using SimpleGame with all its debugging and the render-to-texture statistics graphs... ;)
Hi all!
I don't really know where to answer…here or on JGO or in my own forum… 
Looks like lockMeshes() is similar to jPCT's compile(). What does JME do exactly, if the mesh isn't locked and what are the restrictions on a locked mesh when compared to an unlocked?
Hello!
I'm sure Renase or one of the others can give you more technical detail, but essentially jME lets you lock certain aspects of a Spatial to guide it on optimization. Locking options are bounds, meshes, shadows and branch.
You can lock some or all based on how you are going to use the mesh (eg. for completely static scenery you might lock all).
I used lock meshes based on the fact that a car is likely to move but not change shape. It means no changes to vertex, uv, normal or color data.
I don't think jME was having much fun churning all that data every update!
jPCT looks like a nice engine. Wish I had the time to give it a proper try
it looks very much like a biased test. the author just didnt post any useful information except the results. u need to have the actual test source code to prove the test results r valid.
neakor said:I've posted the used machines, the used model and which applications i used to test with. What else do you need? Anyway, i've retested on the Quadcore with a call to lockMeshes() added. Results are here: http://www.javagaming.org/index.php/topic,20248.msg163171.html#msg163171
it looks very much like a biased test. the author just didnt post any useful information except the results. u need to have the actual test source code to prove the test results r valid.