Your idea about a jPCT 2.0 project sounds like music to my ears  
While it's true we don't need another j3d clone, I don't think jPCT is or will be. Especially in combination with LWJGL it can be a lean an mean gaming API, LWJGL having similar qualities of being small yet powerful and easy to use.
If documented properly, it wouldn't be such a problem if some features were ignored or simplified in the software renderer. The software renderer of the unreal engine also didn't support all the engine's features for example.
One more question: Are you limiting the hw renderer's featureset because the current jPCT is designed as a software renderer or is it a design goal that both hw and sw renderers have identical features?

Hi,

First, I'd like to say I really like jPCT. It's stable, has a very intuitive API, and highly impressive software rendering.
But, as impressive as the software rendering is, I feel it's a bit of a let down too. Let me clarify  
I think jPCT has much potential for becoming a high end game engine but the fact that all has to be software rendered too restricts that potential somewhat. Maybe when the requirement that everything has to be software rendered too would be loosened a bit would make development of jPCT easier, like adding multitexturing and pixel shaders and stuff like that. Things that really require hardware muscle.
I know you (EgonOlsen) are very much into software rendering and that sw rendering is a great passion of you, and let me say once more you did a really great job with that (in fact I think jPCT is the best looking sw renderer I've ever seen, regardless of it being made with java), but I'm wondering what your views are about this.
Do you think software rendering will keep having a place in the future? I have the feeling that sw rendering's place will become smaller and smaller because nowadays every computer is equipped with 3D accelleration and I have the feeling that 1.1 applets are becoming obsolete. Maybe I'm wrong though, but the future of modern JVM's (or more specifically 'non MS JVMs') seems rather bright, and the MS JVM's rather bleak.
What do you think?

Best regards,
Erik

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.

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

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