How does jPCT handle lighting in OGL?

[erikd]

Hi there,

I'm thinking about using jPCT in a game I'm working on, called 'Mazer'. It's currently at www.mycgiserver.com/~movegaga/mazer/mazer.jnlp and it uses plain LWJGL to render everything.
It currently uses a very simple way to render colored lighting using light maps and I was wondering if this 'Unreal-like lighting' can be achieved with jPCT too?
The way I'm doing it now heavily relies on a large z-Buffer and always shows some artefacts (how much depending on how many bits the z-Buffer has, ranging from barely noticable to huge z-buffer probs).
Does jPCT use openGL lighting, or does it implement light maps too?

Greetings,
Erik

[EgonOlsen]

I've seen Mazer before...as well as the zBuffer-flaws the lighting implementation causes... :wink:

To answer your question: jPCT can't to lightmaps, because it can't do multitexturing. This limitation comes from the fact that it's not hardware only but offers a software renderer too. Multitexturing in software is so expensive, that i decided against it and because the feature-set of both renderers should be as equal as possible, there is not support for it at all.
However, it does have its own T&L pipeline and offers a lighting similar to the native OpenGL lighting (i.e. vertex lighting). It supports ambient, specular (in two slightly different implementations) and diffuse lighting with an unlimited amount of lightsources (in theory...in practice, performance starts to drop when you are overusing light).

I guess you've already seen the "viewer"-test-app i posted on javagaming.org. What you see there is all vertex-lighting using some more or less randomly placed lightsources...and i think it looks quite well for vertex-lighting, so maybe this is still an option for your game.

BTW.: The software renderer supports overbright lighting, which increases the possibilities of vertex-lighting very much (i.e. the maximum light intensity per channel is not 1 but 32 in this case). Sadly, no current consumer hardware can do this, so the OpenGL renderer can't make use of it. The 3dfx Rampage would have supported it, if 3dfx would have just survived... :cry:

[erikd]

Thank you for your reply.  

I'm currently doing a last attempt to fix the z-Buffer problems. If it doesn't work, I think I'll switch over to jPCT to make my life easier as I don't think I'm qualified to do a full blown 3D engine. I can always increase tesselation to improve lighting quality...

Another question about lighting, though. You mentioned that although in theory the number of lightsources is unlimited, one will experience slow downs with large numbers of lights. I suppose this is to be expected, but is there some occlusion/visibility culling regarding lighting to help here? Or maybe I'll have to implement that myself?
The mazes will get quite big and there are lots of lights in there, you see...

Thanks,
Erik

[erikd]

BTW, although I can appreciate that you want the sw and hw renderers to look as close as possible, wouldn't it be an idea to be able to support lightmaps and multitexturing and such but having to enable those 'extras' through switches or something?
So that by default hw and sw look the same, unless you enable the hw specific goodies. And sooner or later, CPU's will be fast enough to do those things too in software eventually...
It seems a bit of a shame to limit an otherwise *great* 3D renderer because of performance limitations of rendering in software.

[EgonOlsen]

You mentioned that although in theory the number of lightsources is unlimited, one will experience slow downs with large numbers of lights. I suppose this is to be expected, but is there some occlusion/visibility culling regarding lighting to help here? Or maybe I'll have to implement that myself?

Per default, jPCT will take every active lightsource in a scene into account even if it only adds 0.0000000000001 of intensity. However, you can configure the engine, so that it discards lightsources that are too far away from a polygon (0.93 will improve the performance of this discarding a little bit). If you decide to use jPCT, we'll see what happens and if some more improvements are necessary in this area.  Anyway, i think it's quite fast the way it is now.

I already thought about adding multitexturing in one way or another but the OpenGL-only-way doesn't please me and adding it to the software renderer is possible (and not even that hard) but it would require to split the software renderer again into a multitexturing and a singletexturing one, because otherwise the performance of singletextured polygons will drop significantly too. That would make three of them at least... :?
Maybe i'll add it anyway one day or another, because i did that with most of the stuff i was undecided about (like OpenGL-support, the 3DS-loader, animations, texture-tiling...all things that weren't that much fun to do and because i'm lazy, i avoided adding them for some time but finally they made it into jPCT... :wink: ).
However, don't count on it to happen within the next few months...one can only do so much and there are still other things to do (like working on lighting performance... :wink: )

[EgonOlsen]

Related to this: The upcoming version 0.93 will (most likely) have support for RGB-scaling which can improve lighting quality/appearance. Here are some examples...


No scaling (this is what 0.92 would render)


2x scaling


4x scaling

While this isn't exactly what the software renderer offers (overbright lighting), it comes close to it. The software renderer will support the scaling too, of course.