jPCT benchmark?

[JavaMan]

Is GLSL what is supposed to be used with the new hook? It looks rather complete for a complete Shultz-I no nothing-of the subject, so I wanted to make sure this is what I should learn before plunging in.

The hook doesn't force you to use one way or the other, but GLSL is what should be used nowadays IMHO. So does the "all-green-example" above. You can see the source code of the used shader in it. It's hard coded into the first attribute.

Thanks for the info. I will look into GLSL.

[EgonOlsen]

To come back to the beginning of this thread, i think it's time now for a little pissing contest. I haven't much experience with Xith3D or jME, so i relied on the tests that come with both engines and modified them (to be exact i simply changed the loaded models) to do some simple benchmarking on two machines.

At first, the results of rendering that high polygon car model that paul provided...

...on a Core2 Duo@3Ghz, some lowly NVidia Quadro GPU:

jPCT: 78 fps
jME: 34 fps
xith3D: 22 fps

The same thing rendered on my main machine, a Core2 Quad@3Ghz, ATI Radeon HD 4870:

jPCT: 580 fps
xith3D: 222 fps
jME: 30 fps

And finally, the famous Quake3-level from the xith/jME-benchmark...but just loaded as a model...i haven't converted the whole benchmark thing and only loaded it into xith and jPCT on the Quad core:

xith3D:
fps view: 91 fps
level view: 69 fps

jPCT:
fps view: 1000 fps
level view: 1000 fps

[raft]

wow

[Enk]

Impressive!

Simple and fast 

[zammbi]

Great results. I really did not know JPCT was that good. 1000fps compared to 91?! just wow...

[fireside]

Nice. 

[EgonOlsen]

It came to a surprise to me too. jPCT beated xith3D in that Quake3-level earlier even with the default pipeline, but some years have passed since then and i thought that the situation might have changed. Obviously not. The performance of the different engines is very interesting IMHO. Both machines have identical CPU power as long as you don't use more than 2 cores, which none of the engines does. In fact, i think jPCT is the only one that can offload at least some load to another thread/cpu. The high polygon car should be GPU limited. In jPCT and xith3D, it seems to be. In JME, it seems to be solely CPU limited, because otherwise, the much more powerful ATI should beat the crap out of the GeForce...but it doesn't. It's actually slower...
The Quake-level on xith3D suffers from whatever...maybe too many state changes or something. jPCT largely benefits from its past here IMHO. Because it's geometry throughput was always limited, i tweaked every other part to the death. And the compiled pipeline is still using large parts of the default pipeline, like the state sorting, the state management and such. This seems to pay off now...

[JavaMan]

That is sweet.

[zammbi]

Maybe you should show off your results over at JGO(and gloat  ), people will be surely interested in those results.

[.jayderyu]

That's really awesome. Though I think you should post the results on the JME and Xith forums with the all codes attached. While I like seeing JPCT doing so well it's surprising the performance difference is so vast. They may be able to see something in their code that's bottlenecking it.

[EgonOlsen]

Though I think you should post the results on the JME and Xith forums with the all codes attached. While I like seeing JPCT doing so well it's surprising the performance difference is so vast. They may be able to see something in their code that's bottlenecking it.

Honestly? I don't care about this. Both projects mainly focused on themselves for years now constantly ignoring what happens around (or before...) them. Back in the days when the Quake3-level-loader surfaced, jPCT already was on par with them. I had posted that somewhere but nobody cared. If anybody else feels the urge to wake them up (if there is anybody left to be waken up in case of xith3D), that's fine for me. I for sure won't. About the codes: There's nothing to attach. I simply used the benchmark and test programs that come with both engines. I just swapped the models.

[.jayderyu]

Fair enough then. If they didn't care back then. Then there really is much point. If you are using their own benchmark code then hey good enough. Gratz, the speed it really excellent.

Originally if I was going to do an application based program in jME for speed and feature extras, but after this performance i'll probably stick with JPCT. I doubt any of my projects will ever need heavy feature set like jme.

[EgonOlsen]

I doubt any of my projects will ever need heavy feature set like jme.

If you really need something for a project, just ask for it. It wouldn't be the first feature implemented on people's request if it fits somehow. There were always projects that have driven the engine with Technopolies (R.I.P.) being the strongest of them. Multi-texturing, multi-pass rendering, the AWTGLRenderer...they were all initially triggered by Technopolies.

[EgonOlsen]

Some results taken from my lower end machines:

The car-model loaded on a Core2Duo @ 2.66Ghz, Intel GMA 950 onboard graphics:

jPCT: 6fps
JME: 4fps
xith3D: crashed due to absence of glActiveTextureARB on that machine (which is a bogus message, because jPCT uses that too and runs fine)

The same model loaded on a Pentium 4M @2.2Ghz, Geforce 2MX Go:

jPCT: 3fps
xith3D: 1fps
JME: unknown (but feeled like 1+fps)...i wasn't able to enable the fps stats, just got a gray overlay instead

and finally on an Athlon X2 @2.2Ghz, Radeon HD 3650 AGP:

jPCT: 200fps
xith3D: 110fps
JME: 28fps

[AGP]

Dude, that is awesome. Congratulations, and thanks again for this great engine. I'm very happy to use nearly every day of my life (and I'm building some cool things with it right now).