jPCT benchmark?

[JavaMan]

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.

[zammbi]

Great, glad your still looking into ways to make it even more faster 

[fireside]

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. 

[EgonOlsen]

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.

[EgonOlsen]

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



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

[JavaMan]

That is fantastic! I can't wait to get my hands on it, when you finish.

[EgonOlsen]

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

[JavaMan]

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.

[C3R14L.K1L4]

Great news!

[.jayderyu]

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

[EgonOlsen]

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

[.jayderyu]

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

[EgonOlsen]

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

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

[.jayderyu]

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.

[JavaMan]

So, the only option that is lost from going non-compiled to compiled would be ability to change texture UVs on the fly?