We’re evaluating various Java engines. I’ve read that Ardor3D is more like JME2.5 and JME3 is shader based, however the performance of JME3 gets me a bit worried.
It’s very interesting, because when you launch some tests (e.g. simple/scene water test) everything runs at thousands of fps until you look to horizon. Then while FPS counter still is reporting same FPS, looking around gets jerky. If you turn back to water (which is more complex than a plain image in the horizon), everything is suddenly back to ok.
It seems that this is related to huge images as it can be seen in other examples too. I could compile a list of where this lag occurs.
Any ideas what can be causing this and why this is happening? None of the Ardor3d examples show anything similar and I’m sure that my card is powerful enough because it runs Heroes Of Newerth without a hitch.
I have Nvidia Geforce 9800GT PCI-E card with 512mb of ram.
My system specs: Ubuntu 11.04, xorg Version: 1:7.6+4ubuntu3.1, nvidia binary drivers 270.41.06-0ubuntu1.
arturas@zeus:~/work/jme$ cat /proc/cpuinfo
processor : 0
vendor_id : AuthenticAMD
cpu family : 15
model : 67
model name : AMD Athlon(tm) 64 X2 Dual Core Processor 6000+
stepping : 3
cpu MHz : 1000.000
cache size : 1024 KB
physical id : 0
siblings : 2
core id : 0
cpu cores : 2
apicid : 0
initial apicid : 0
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt rdtscp lm 3dnowext 3dnow extd_apicid pni cx16 lahf_lm cmp_legacy svm extapic cr8_legacy
bogomips : 2009.55
clflush size : 64
cache_alignment : 64
address sizes : 40 bits physical, 48 bits virtual
power management: ts fid vid ttp tm stc
processor : 1
vendor_id : AuthenticAMD
cpu family : 15
model : 67
model name : AMD Athlon(tm) 64 X2 Dual Core Processor 6000+
stepping : 3
cpu MHz : 1000.000
cache size : 1024 KB
physical id : 0
siblings : 2
core id : 1
cpu cores : 2
apicid : 1
initial apicid : 1
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt rdtscp lm 3dnowext 3dnow extd_apicid pni cx16 lahf_lm cmp_legacy svm extapic cr8_legacy
bogomips : 2009.55
clflush size : 64
cache_alignment : 64
address sizes : 40 bits physical, 48 bits virtual
power management: ts fid vid ttp tm stc
You get “too high” fps probably. Theres an issue in the beta where high fps yields problems with movement (because the tpf is zero). The fix is already in the nightly and goes into the stable updates in some days I guess. Also the fps display isn’t trustworthy in the current beta.
About the question: All these engines perform the same when you make them do the same, they all use OpenGL so it depends on your graphics card how fast they render a mesh with a texture. Note however that the default shaders of jME3 are more advanced than the default jME2 or Ardor3D materials so there is probably more work involved for the GPU so when using the Unshaded material it should render just as fast.
@normen said:
You get "too high" fps probably. Theres an issue in the beta where high fps yields problems with movement (because the tpf is zero). The fix is already in the nightly and goes into the stable updates in some days I guess. Also the fps display isn't trustworthy in the current beta.
Where should I put nightlies for JME SDK to pick them up?
Just use the nightly update center when using the SDK (Tools->Plugins->Settings) or when using another IDE download from the nightly folder (download drop down above). I strongly suggest not using the nightly for production games, especially just for comparing fps (thats kinda silly anyway). You can get the same result by adding setTimer(new NanoTimer()); to your simpleInitApp.
thanks normen. Nightlies fixed it. I still wonder if brick wall/tower demo lags at start because of lots of physics interactions or cold-jvm. Could you comment it?
Hm, appears it’s not completely fixed. TestSkyLoading still glitches while moving. Turning on VSync fixes it.
The physics tests start out with adding lots of physics object to the physics space, the initial computations are in fact whats slowing the start down. When you have movement problems make sure its not due to excessive fps rates, no application would render 1000 fps it just makes no sense. You can enable vsync to see the performance of “normal” framerates.
appSettings.setVSync(true) or something, make sure you set the appSettings to the application before starting the application, you can select it in the settings menu at the start as well. Also don’t get the impression that you should extend “Application”, always extend “SimpleApplication”.
