jPCT benchmark?

[Mr.Marbles]

I was just wondering if jPCT has ever been benchmarked against some of the other java scenegraph engines out there: jME, Java3D, Xith3D, etc. I've personally been working with jPCT for almost 2 years now and have never really considered performance vs. the "competition". So I thought this would something useful to consider.

Besides the fact that jPCT is probably the easiest to learn and supports both software/hardware rendering, are there any other advantages? I've read that Xith3D is a tuned version of Java3D basically aimed at higher performances, and jME was actually benchmarked against Xith3D and found to be faster in some cases. So jME seems to be a clear winner in terms of performance. However I've never seen jPCT benchmarked at all.

[EgonOlsen]

I once did a comparision based on a quake3-level-benchmark-application that someone ported to Xith, jME and Java3D. At that time, Java3D was the fastest, jME came behind it and Xith was the slowest by far (so much for tuned Java3D...). jPCT was somewhere around JME's performance, albeit i've to admit that the comparision wasn't a fair one because all the others used the BSP-information from the quake3-fileformat and the jPCT version used octrees. If this is good or bad for jPCT compared to the others is another question.
However, all engines have evolved since then, including jPCT. So this test may be no longer valid...i don't know.
To understand jPCT's advantages and its drawbacks, one has to understand the way it works which is fundamentally different from the others. In all other engines, the rendered "primitives" are objects, i.e. if you have a cube, you can assign ONE texture to each stage, set other attributes like transparency and stuff and when it comes to rendering, the object's properties are evaluated, the texture stages are set up accordingly and the cube is rendered as a whole using a vertex buffer or something like that. jPCT brakes objects down into triangles. If only one side (i.e. two triangles) of the cube is visible, only these triangles will be send to the card, not the whole cube. The drawback is, that jPCT does a lot of things in software while the other engines can do this hardware. Or in other words: Where other engines stop processing the geometry themselves and give up control to the graphics card, jPCT's pipeline continues in software. The point where it calls the hardware for support is simply later.
This can be slower for high polygon scenes, which is why i'm always claiming that jPCT isn't a real "polygon pusher". The cool thing with this approach is, that it simplyfies a lot of things for the developer. Where other engines allow one texture per stage and object, jPCT doesn't care. You can assign 1000 textures to one object wildly mixed through all texture stages. You can add and remove stages from single polygons at runtime. If you want to add 20 texture layers to a single polygon if something has hit the polygon, you can easily do it. You can't do that in any other engine. You can use different blending modes on different stages with different textures per polygon on a single object. jPCT will always try to optimize what you've done (it may fail sometimes, but it tries its very best...) to give you the best performance possible out of the mess that you've created... . Another thing made possible by this approach is, that you can use the normal GLRenderer as well as the AWTGLRenderer in the same way. You don't have to care about threads or put every jPCT related command into a gameloop-construction like you've to do in jME (IIRC).

[Mr.Marbles]

At that time, Java3D was the fastest, jME came behind it and Xith was the slowest by far (so much for tuned Java3D...).

However, all engines have evolved since then, including jPCT. So this test may be no longer valid...

Correct, it is no longer valid. I believe I know which comparison you're talking about. It's over at the jME forum. That discussion has greatly evolved since you last checked. It's now clear that jME is the fastest engine: http://www.jmonkeyengine.com/jmeforum/index.php?topic=2597.75

jPCT does a lot of things in software while the other engines can do this hardware

So would it be safe to say that the software processing of jPCT hinders its performance? I do understand that this is a trade-off for a more dev-friendly API but nevertheless it still sounds like a sort of performance bottleneck.

You can add and remove stages from single polygons at runtime. If you want to add 20 texture layers to a single polygon if something has hit the polygon, you can easily do it. You can't do that in any other engine.

From what I'm understanding here, jPCT's biggest strengths are in the texture management system? Please correct me if I'm wrong, I'd really like to understand this.

you can use the normal GLRenderer as well as the AWTGLRenderer in the same way

Yes, this is definitely a BIG PLUS! 

You don't have to care about threads or put every jPCT related command into a gameloop-construction like you've to do in jME

I'm not so sure about this, I've had some glitchy behavior if any objects in my scene were handled (i.e. manipulated) outside the main jPCT game loop.

[EgonOlsen]

So would it be safe to say that the software processing of jPCT hinders its performance? I do understand that this is a trade-off for a more dev-friendly API but nevertheless it still sounds like a sort of performance bottleneck.

I wouldn't call it a performance bottleneck, because it usually isn't one. However, if you want to stress the engine, then this is the way to do it, yes. The design wasn't choosen because it's dev-friendly (that's just a side-effect) but because jPCT is a software-hardware-rendering hybrid. In that way, it's similar to the first incarnation of the unreal engine, which showed a similar behaviour.

From what I'm understanding here, jPCT's biggest strengths are in the texture management system? Please correct me if I'm wrong, I'd really like to understand this.

Not the texture management itself but the management of different rendering states and such.

I'm not so sure about this, I've had some glitchy behavior if any objects in my scene were handled (i.e. manipulated) outside the main jPCT game loop.

jPCT isn't thread safe, so manipulating things in different threads can be a problem. But changing things from outside the game loop isn't. What i was talking about is, that you don't have to extend some GameLoop-class and are forced to put everything in an overridden gameLoop()-method or something. Nor do you have to ensure that everything happens in the awt event thread when using the AWTGLRenderer. You can still do everything whereever you want to. jPCT will make sure that it happens in the event thread.

[Mr.Marbles]

I once did a comparision based on a quake3-level-benchmark-application that someone ported to Xith, jME and Java3D.

Do you still have the jPCT benchmark available? I just came across this blog which revisited that Quake 3 benchmark using jME, Xith3D, and Java3D. It was done not too long ago, last october:
http://www.renanse.com/blog/2006/10/and-now-benchmarks-you-can-run.html

You can actually download the benchmarks and run them on your own system. If the jPCT Quake 3 benchmark is still available I'd like to run it just for comparison purposes 

[EgonOlsen]

No, i don't. I messed it up while doing some totally weird multitexturing tests with it a year ago or so. But even if i would, i doubt that it was the same version. Doesn't these tests do a real "benchmark run"? Sadly, i can't see for myself because i'm unable to start any of them...Webstart bombs out with an error message...

[Mr.Marbles]

Sadly, i can't see for myself because i'm unable to start any of them...Webstart bombs out with an error message...

Unfortunately, the benchmarks won't launch with Java 1.6.x. It only supports Java 1.5.x. This may be the problem.

In any case, the graphs show the information quite well. It's too bad the jPCT benchmark is not in working order. How tough is it to get that Quake level loaded? I may take a shot at it 

[EgonOlsen]

In any case, the graphs show the information quite well. It's too bad the jPCT benchmark is not in working order. How tough is it to get that Quake level loaded? I may take a shot at it 

I don't know...i never did. What i did was to convert from bsp-format to vrml-format to rt-format to 3ds-format...which is the "usual" way for me to make quake3-data loadable in jPCT without being forced to write a quake3 loader. But you'll lose bsp-information on the way. That's why i was using octrees instead. To make a "real" comparision, one would have to port the loader in that package. I once looked into it, found it to bothering and never looked at it again. However, it shouldn't be that hard once you decide that you really want to do it.

[Melssj5]

And compared to OGRE 3D? OGRE has shadows implementations. But i have not tested it yet.

[Mr.Marbles]

And compared to OGRE 3D?

This isn't really a fair comparison since OGRE 3D is written in C++

OGRE has shadows implementations

I believe most of the Java engines support some for of shadows as well.

[Melssj5]

But there is posible to run ogre in java! Well, I read on the web that ogre can works with java using some libraries.

Any way. pics of ogre oryects are really good. Hope jpct can achive on improving the light efects to make it look more real.

[JavaMan]

Hi, I don't want to dig up an ancient topic, but I had a question.
Is there any chance that in future releases of jpct that maybe the developer could use only objects with one texture and do the "more complicated stuff" so that way jpct could be a polygon pusher for those that wanted it that way? or is this already implemented in the current release? If that is the case, how do I use the engine for polygon pushing?
Thanks
Jman

[EgonOlsen]

I have plans for something like this, yes. I should be possible to "compile" an Object3D and use another render path for compiled ones that would be faster. However, this is a complete new render pipeline, so it isn't that easy. I don't know when it will come, but i think it will.

[JavaMan]

Ok, cool. I think that would be good, but I know that programming is lots of tedious work. I think that maybe it would bring more people to the engine. I love this engine: it is so easy to use. If it could do more polygons all the better!

thanks for the reply.
Jman

[EgonOlsen]

I have plans for something like this, yes. I should be possible to "compile" an Object3D and use another render path for compiled ones that would be faster. However, this is a complete new render pipeline, so it isn't that easy. I don't know when it will come, but i think it will.

Time to give this old thread a small update: I'm currently looking at that "compile" thing to see how/if it will fit in the current pipeline. So it's not forgotten, just delayed...