www.jpct.net
jPCT - a 3d engine for Java => Support => Topic started by: Mr.Marbles on April 25, 2007, 07:20:14 pm
-
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... ;D. 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).
-
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 (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.
-
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.
-
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
(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 ;)
-
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... :'(
-
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 :)
-
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.
-
And compared to OGRE 3D? OGRE has shadows implementations. But i have not tested it yet.
-
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.
-
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.
-
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? ;D
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!
thanks for the reply. ;D
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.
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... ;)
-
Wow! That sounds great! I know you are just looking into this, but do you have an idea as to when an alpha might be available? I wanted more polys than what jPCT seems to be able to do, so I was looking into jME. But, I would really like to use jPCT instead of jME becuase well, jPCT is so much simpler to use.
-
Great, glad your still looking into ways to make it even more faster :)
-
It seems like compiling would only make the models load faster to me. Not that I know anything. I'm all for more speed as long as the library stays small. That's the clear difference between JME and Jpct and I hope it stays that way.
-
It seems like compiling would only make the models load faster to me. Not that I know anything. I'm all for more speed as long as the library stays small. That's the clear difference between JME and Jpct and I hope it stays that way.
No, they won't load faster. Compiling them will happen at run time and is only valid for the hardware renderer. Adding that feature won't increase the size of the library very much. To the public, there will be two new methods, compile() and decompile()...that's basically all...plus maybe a few helper methods like isCompiled() or something.
-
Status report: It's coming along nicely...there's still a lot of work to do, but compiling itself works pretty well so far. Right now, i'm compiling the objects into simple vertex arrays, i.e. no VBOs and such (will come later...i just don't want to open another can of worms right now). Some features like environment mapping are still missing and i have to rewrite the multi-threaded GLRenders too.
Here's good old Beethoven rendered using a compiled object (you can't tell...the default pipeline will look exactly the same... ;)):
(http://www.jpct.net/pix/beethoven_new.jpg)
Even using only simple vertex arrays, it renders around 6 times as fast as with the default render pipeline (330fps compared to 55fps). A simpler test scene benefits by the factor of 4, a very complex scene which results in over 1000 vertex arrays when compiled jumps from 5fps to 20. However, some scenes suffer from compiling them...it's not that the old pipeline will be obsolete with this one...
-
That is fantastic! I can't wait to get my hands on it, when you finish.
-
Update: Beethoven is at 1700fps now, the more complex model at 125fps. That's around 25-30 times faster than before this change (tested on my Radeon HD 4870/Core2 Quad @ 3Ghz)... ;D
-
If you keep increasing fps at this rate, I won't be able to post because of my keyboard shorting out with all my drool. ;D
-
Great news!
-
OK just to be clear on this.
A compiled Object will be rendered over at the Video Card, while a non-compiled Object will still be rendered on the CPU.
A compiled Object will not be dynamicly changeable as much as a non compiled object?
I'm pretty good that. I don't really change my objects after creating them anyway?.
-
A compiled Object will be rendered over at the Video Card, while a non-compiled Object will still be rendered on the CPU.
A compiled Object will not be dynamicly changeable as much as a non compiled object?
Yes, that's basically how it works. In addition, animated objects can be compiled too, but the result will be slower than with static objects...but maybe still faster than using the CPU. I guess it depends in that case.
Compiled objects have some limitations: Their lightMul-value (see Config.lightMul) is implicitly 1 regardless of the setting in Config, because that's the way OpenGL's lighting works. And a compiled object can't use more texture layers than the hardware supports, i.e. 4 on almost any current card and 2 on older ones like GeForce2 and similar. The cpu based pipeline has no limitation here (in theory...in practice, it will become slow anyway with too many layers).
-
Ok that's cool. We will also be able to have objects that are either compiled or non compiled? If that's the case that could be very cool. The many "simpler" objects can be done on the GPU while more complex characters could be located on the CPU.
Will it be possible to change textures. If I were to say out of my 2(old card) have a decal texture. Could I modify the decal texture?
Also I was wondering since there is new pipeline being made. Is it possible that there might be easier to allow access to the shader tech? I would really like to see Cell shading someday :P
-
Yes, you can intermix the two modes happily without a problem. In fact, this is something that came to a surprise to me after i've added the first bits of the new stuff...i tried to mix both and it worked right from the beginning... ;D
About the textures...it depends. You can always do a setTexture(...) on a compiled object without a problem. You may as well modify the u/v-coordinates if you've compiled it as "dynamic", which is slower but still faster than cpu processing, at least on my machine. What you can't do is to modify the texture of a single polygon. The compiled object simply won't reflect this change. For a decal, i would go for extra decal polygons on top of the scene's geometry anyway (Robombs does this for example).
And finally about shaders: I guess so. I've no real experience with shaders, but as long as you stay in the pipeline for compiled objects, it should be possible. Maybe i'll add some hooks later that allow people to hook right into the pipeline and do custom stuff...
-
That's sounds good. I'll keep the poly-decal idea in mind. I was thinking about a more unlimted customized tattoo placement by modifying the base texture.
As for the shader thing. I know you don't have too much interest. I was just hoping having a "hook" that we could set some LWJGL classes into the object/world/renderpipeline so that we could just access the shader tech in general. I really don't mind it not being part of the integrated JPCT.
-
So, the only option that is lost from going non-compiled to compiled would be ability to change texture UVs on the fly?
-
So, the only option that is lost from going non-compiled to compiled would be ability to change texture UVs on the fly?
Plus the limitation in the number of texture layers and some more or less minor things where the pipelines differ due to the way OpenGL does some things (specular lighting looks a little bit different as well as environment mapping, the mentioned Config.lightMul=1 of the compiled pipeline...that kind of stuff. But that's nothing to go crazy about...).
-
Oh, yes. I forgot :-[ about the texture layer limit and lightMul.
-
Also I was wondering since there is new pipeline being made. Is it possible that there might be easier to allow access to the shader tech? I would really like to see Cell shading someday :P
I've written a test shader (which sets every fragment's color to green... ;D) and hooked it into the pipeline by using the IRenderHook that i've specified for this. It worked fine. The code is pretty simple:
import java.nio.*;
import com.threed.jpct.*;
import org.lwjgl.*;
import org.lwjgl.opengl.*;
public class MyFirstShader implements IRenderHook {
private String myShaderSource="void main() {gl_FragColor = vec4(0.0,1.0,0.0,1.0);}";
private int prg=0;
private int fragShade=0;
private boolean init=false;
public void beforeRendering(int polyID) {
if (!init) {
init();
}
ARBShaderObjects.glUseProgramObjectARB(prg);
}
public void afterRendering(int polyID) {
ARBShaderObjects.glUseProgramObjectARB(0);
}
public void onDispose() {
ARBShaderObjects.glDeleteObjectARB(fragShade);
ARBShaderObjects.glDeleteObjectARB(prg);
}
public boolean repeatRendering() {
return false;
}
private void init() {
prg=ARBShaderObjects.glCreateProgramObjectARB();
fragShade=ARBShaderObjects.glCreateShaderObjectARB(ARBFragmentShader.GL_FRAGMENT_SHADER_ARB);
byte[] src=myShaderSource.getBytes();
ByteBuffer shader = BufferUtils.createByteBuffer(src.length);
shader.put(src);
shader.flip();
ARBShaderObjects.glShaderSourceARB(fragShade, shader);
ARBShaderObjects.glCompileShaderARB(fragShade);
ARBShaderObjects.glAttachObjectARB(prg, fragShade);
ARBShaderObjects.glLinkProgramARB(prg);
Logger.log("Shader compiled!", Logger.MESSAGE);
init=true;
}
}
-
If you keep increasing fps at this rate, I won't be able to post because of my keyboard shorting out with all my drool. ;D
Beethoven is at 3700fps now on my machine. I don't think, it'll go much further. Maybe 4000 is possible somehow, but i think that i'm coming closer to the limit of this setup... ;D
Edit: It's @4000fps now...
-
Small update: Beethoven is @4200fps now...
Apart from beethoven, i changed Robombs to use compiled objects for most of the entities in the game. I discovered two small bugs while doing so, which are fixed now. Now, it just works fine...it didn't help much performance wise, because Robombs is quite low poly anyway.
However, i consider this to be an important milestone for this new feature. I think we are going beta with it really soon...(fingers crossed...).
-
I'm actually a little more excited about the shader hooks, even though I know nothing about shaders at this point. ;D
-
I admit that i'm pretty excited about the shader hook and the extra FPS. I don't think my projects will ever really need it, but who knows. With the shader hook I will certainly be looking at JPCT it for a bigger project I may start working on someday.
-
...well, then...here's a screen shot of the famous "all green shader" postet above:
(http://www.jpct.net/pix/all_green.png)
;D ;D ;D
(That's really a screen shot of it, not just something that i made with Photoshop...)
-
All Right!!! I can see I'll have some shader studying to do for my next project after the one I'm currently working on.
-
very impressive Egon 8) it's very nice to come back to jPCT forum from time to time and see major improvements like this ;D
so does this mean all disadvantage of jPCT for large scenes has gone ? i mean because of the overhead of its hybrid pipeline.. i also wonder how octrees fit into this pipeline: will they loose their significance ?
again, really very impressive 8)
r a f t
-
All Right!!! I can see I'll have some shader studying to do for my next project after the one I'm currently working on.
You and me both, but then again maybe someone will make a cell shader that I can use.
-
so does this mean all disadvantage of jPCT for large scenes has gone ? i mean because of the overhead of its hybrid pipeline.. i also wonder how octrees fit into this pipeline: will they loose their significance ?
Yes, that overhead is gone for compiled objects. Currently, a compiled object still consumes a little bit more memory than it has to in some caes, but i'll fix this in a later version.
About octrees...actually no. They are still quite useful, but not necessarily for rendering. For collision detection, they still help a lot. For rendering...i'm undecided. The tests that i made showed a performance decrease when using them for rendering, because they tend to split the batches too much. When you compile an object, it will be split in a number of batches based on states (i.e. textures, blending modes...). If you use an octree in addition, the splitting includes the tree's leaves too. On a large terrain, this may still help...on a Quake3 level, it doesn't. That's the reason why i've added the option to use an octree for collision detection only.
-
Hi all,
With all this excitement over the new shader hook, it must be something worth looking into. I, um, have no idea what it is. So, I did a search and found this tutorial on the lwjgl wiki site. http://lwjgl.org/wiki/doku.php/lwjgl/tutorials/opengl/basicshaders (http://lwjgl.org/wiki/doku.php/lwjgl/tutorials/opengl/basicshaders). 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.
Oh, and by the way Egon, I didn't notice (for some reason??) that Beethoven was up to 4300. I'm sitting very far back in my chair so I won't have to replace another keyboard ;) Great job!
-
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.
-
In reply to raft's question about octrees, here are some performance statistics taken on my main machine (Core2 Quad@3Ghz, Radeon HD 4870, Vista, Java 6) displaying a typical FPS-view of a Quake3 level. Using other geometry, another view and another machine, the results can be completely different. Anyway:
Default pipeline:
no octree: 305fps
coarse octree: 300fps
finer octree: 340fps
Compiled pipeline:
no octree: 950fps
coarse octree: 450fps
finer octree: 305fps
You can see that the normal pipeline benefits from the finer octree, because it takes the geometry load away from the pipeline very early. Using the octree on the normal pipeline causes additional overhead for processing the tree, but doesn't require more state changes in the pipeline than without it. The coarse tree doesn't help, because it can't discard enough geometry to make up for the additional processing needed.
The compiled pipeline on the other hand is the complete opposite. The hardware has no problems with processing the complete geometry of a Quake3-level each frame, but using the octree causes more render calls and more state changes (because of smaller render batchs), slowing it down.
Keep in mind that these results are only valid for a quite low poly object displayed using a hardware with high poly throughput. When rendering a landscape or similar on an Intel onboard chipset, it may be a different story.
-
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. :)
-
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
;D
-
wow ;D
-
Impressive!
Simple and fast 8)
-
Great results. I really did not know JPCT was that good. 1000fps compared to 91?! just wow...
-
Nice.
-
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...
-
That is sweet.
-
Maybe you should show off your results over at JGO(and gloat :P), people will be surely interested in those results.
-
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.
-
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.
-
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.
-
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.
-
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
-
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).
-
An update, triggered by this thread: http://www.javagaming.org/index.php/topic,20248.0.html (http://www.javagaming.org/index.php/topic,20248.0.html)
There's a switch in JME to lock the meshes, which improves performance by a huge amount and i managed to load it into Java3D.
Taken from the thread on JGO:
So on the Core2 Quad@3Ghz, ATI Radeon HD 4870, Java6, Vista Ultimate, we now have:
jPCT: 580fps
JME: 520fps
xith3D: 220fps
Java3D: 120fps (with some visual glitches, but that could be a bug in the loader)
-
Hehe, I read those other forums - sounds like there might be some bruised egos. I love how people are quick to say the test was rigged without actually trying it for themselves..
-
I was watching the talk on the jME forum earlier today. You've stirred the pot a little Egon. :) Of course, with speed increase like that, how could it not?
I am happy jpct is still faster than jME. With jME1.0 considered outdated, and jME considered a "pre-release" and now some talk of jME3.0. Its a little hard to decide what to use.
-
Well finally. I'm glad that my suggestion that the tests get out their came about. I'm also glad that the various other groups aren't living in an isolated bubble including this one ;).
The new tests performance seem to be much better. Glad to see JME and JPCT running pretty darn well. Though I feel sorry for the guy who is doing DzzD with no benchmark with him.
I agree the other guy seems there are some bruised egos. Who knows maybe this can be an eye opener for various Java 3d engines to grow and be a serious comipitor for PC games :)
In the end seems like my design decisions are about the same. JPCT for my Applets and smaller stuff. Hurray for the upcoming Shader support :)
-
Yeah seemed that post did stir a little....
Sorry about that EgonOlsen.
But competition causes improvements :)
-
Hey the soup being stirred was awesome. Though I think some of the members could have handled it better. Rather than jumping to accusations of either bias results, code just opening a line of dialog of what are "you" doing... would have been better.
-
Yeah it was great. They could of handled it better.
Nice to see Java3D also being compared in the last test, we most likely going see many tests of people trying different ways to increase there fps :)
-
Yep, it's great how i got blamed for being biased and stuff but only one person actually tried it for himself (and came up with the lockMeshes()-call of which i wasn't aware). They all claim to be "best performers", but they never actually try and compare.
-
It's hard to do comparisons. Like with the lock-mesh, you'd have to be a regular Jme user to know about it. There was that other test a while back that insisted on bsp collision even though it's not being used that much anymore. Also, the engines fill different niches. I use Jpct because of it's size. If I were really intent on features I would think about Jme because it has a lot, but mostly I want an applet to boot up in reasonable amount of time and still provide a game that's entertaining. Now I'll be able to experiment with a hardware game after my current software game is finished. Which is the other thing I like about Jpct, it has a meaningful software engine that can keep the game really small.
-
Really I don't see much point of JME if you already know JPCT. There are many physics libraries which can work just fine for JPCT.
I guess it has a particle engine, which there isn't many libraries for that. Maybe something JPCT could add in the future?
EgonOlsen do you have a plan of what you going to add/update for the future? Or do you just add/update when needed?
-
I guess it has a particle engine, which there isn't many libraries for that. Maybe something JPCT could add in the future?
There is a demo for a particle system on the demos page. Currently it throws an Exception, but it worked before.
-
There is a demo for a particle system on the demos page. Currently it throws an Exception, but it worked before.
I throws an exception, if your system is too fast...yeah, stupid bug. I would fix it, but i can't find the sources. Maybe i'll write a new one, it's not much work at all.
-
I did another test with the tank model. Results can be found in the JGO thread here: http://www.javagaming.org/index.php/topic,20248.msg163263.html#msg163263 (http://www.javagaming.org/index.php/topic,20248.msg163263.html#msg163263)
I'm ready to be accused of being biased and testing wrong again, but i did the best i could with all tested engines.
-
Personally with their hurt feelings they should go about to create their own test that does the same thing. You know your engine. They know there engine. It is only fair that you can setup your engine under the most basic principles. If they feel that their engine is underperforming and your being bias they can create their test benchmark code themselves.
It's not nice accusing others until talking about it first The blatantly ignoring your own efforts to be fair under what you understand of their engine.
oh well getting kicked in the pants does this to people. I'm sure it will get sorted out and the various teams will do what they feel to improve their engine.
I do appreciate 3DzzD though. He's handling the entire thing very well and mature.
-
I'm sure it will get sorted out and the various teams will do what they feel to improve their engine.
...
I do appreciate 3DzzD though. He's handling the entire thing very well and mature.
Good point. Rather than getting involved in the mud slinging, DzzD took advantage of the oportunity to discover and fix some bugs with his engine (and in the process he jumped up two spots to outperform both JME and xith3D in the tank test ;D).
-
I put an Nvidia 7600 gt in my system yesterday and the car program went from 8 frames to 90. I had an onboard Nvidia 6100, which actually is still quite a bit better than an onboard intel chip. That's always been a problem with computers, there's such a huge difference in game speed depending on the hardware. I prefer to write to low end hardware myself since I'm an amateur and I need every eyeball I can get to even get someone to play them, but a few of the games I've been playing were getting too much like slide shows. I'll still be able to switch sockets and test with the 6100 easily.
As far as the tests go, those are all respectable scores so I think it says a lot for java as a gaming platform. When you consider ease of use and ease of making an internet game, plus complete cross platform without recompile, it's hard to beat.
-
I'm very happy to see this jump on jpct. Some months ago I studied almost all 3D game engines / APIs in java (for my AI project) and got divided between jpct and jme.
For the first one I had the impression of simplicity but at the same time of missing features, when compared to jme. I also had the impression jme was faster but seeing this now... it's always nice to know the API you know the most is improving a lot.
I just did not understood this compiled thingy...
I've played with very detailed models in jpct and saw java's process cpu go way up... yeah, the engine was doing some kind of hidden surface removal in software (else the java's process was stalled quite probably at some SwapBuffers() or glFlush() methods) so what does this Model3D.compile() do, exactly?
-
I just did not understood this compiled thingy...
I've played with very detailed models in jpct and saw java's process cpu go way up... yeah, the engine was doing some kind of hidden surface removal in software (else the java's process was stalled quite probably at some SwapBuffers() or glFlush() methods) so what does this Model3D.compile() do, exactly?
It restructures the Object3D for optimized rendering and, depending on the compile-mode, puts the result into vertex arrays or display lists. As long as you are not artificially limiting the frame rate by using a sleep or at least Vsync, any engine will consume 100% of at least one CPU because it will pump out data as fast as possible. It's a myth that the cpu sits there doing nothing while the gpu does all the work.
-
It restructures the Object3D for optimized rendering and, depending on the compile-mode, puts the result into vertex arrays or display lists.
Humm... I thought that was done already...
Then it's obviously that caching the geometry on the gpu (or using DLs which also stores more data and optimizes it) is faster than before, as the api was sending the commands in realtime :o
I've coded in OpenGL before and I can tell (by personal experience, using nVidia drivers ::)) that DLs are faster than compiled vertex arrays and vertex buffer objects (VBOs), but that depends on the driver. As you know, a DL is created once and can't be changed anymore, so the driver can optimize it's data and command as it sees best. In the extreme, it can even issue the gl commands in a total different order.
As long as you are not artificially limiting the frame rate by using a sleep or at least Vsync, any engine will consume 100% of at least one CPU because it will pump out data as fast as possible. It's a myth that the cpu sits there doing nothing while the gpu does all the work.
I forgot that detail... OOPS :-\
-
Humm... I thought that was done already...
Not exactly. The former/default pipeline is a hardware/software hybrid pipeline. It does these things, but at runtime and on the CPU.
I've coded in OpenGL before and I can tell (by personal experience, using nVidia drivers ::)) that DLs are faster than compiled vertex arrays and vertex buffer objects (VBOs), but that depends on the driver. As you know, a DL is created once and can't be changed anymore, so the driver can optimize it's data and command as it sees best. In the extreme, it can even issue the gl commands in a total different order.
I'm using DL for static geometry and VA for dynamic. There's no support for VBO yet. I'm using indexed or not indexed geometry depending on what you choose when compiling the object. Default is indexed for static and not indexed for dynamic.