Author
Topic: jPCT benchmark? (Read 33529 times)

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.

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).

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.

Quote from: EgonOlsen

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.

Quote from: EgonOlsen

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

Yes, this is definitely a BIG PLUS!

Quote from: EgonOlsen

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.

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.

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.

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...

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.

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

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.

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!

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...