General > Feedback

The future of jPCT

(1/3) > >>

erikd:
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

EgonOlsen:
You definitely have a point here and i'm thinking about the future of jPCT too. I'm a bit undecided about all that...on the one hand, i like the fact that jPCT is small, simple to use and runs almost everywhere where Java runs. On the other hand, i would like to add more features for hardware that i can't do without leaving software behind...and sometimes it's even the other way 'round. Then again, do we really need another Java3D clone like Xith3D and OpenMind? jPCT is a bit "different" and i really want it to be that way.
Currently, i think that this may happen in the future: jPCT will basically continue as it is and i'll start a jPCT2.0 project in parallel with a redesigned API (something i'm avoiding at all costs with jPCT) and a better support for the features you mentioned. Will this version still have software rendering? Maybe, but i won't limit the hardware renderer's feature set anymore because of it.
Now that i'm typing this, i'm asking myself again: "Do we need another 3D API that works that way?"
However, all this won't happen tomorrow or within the next months, but i'm quite confident that i'll start such thing when jPCT in its current shape is totally maxed out.

erikd:
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?

EgonOlsen:

--- Quote from: "erikd" ---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?
--- End quote ---
A little bit of both... :wink: jPCT's basic idea was to provide fast software rendering. I never even thought about hardware support before LWJGL surfaced and even then, it took me some time (and some requests by others...) to convince myself to try it. I wanted to stay compatible with 1.1. and be able to run jPCT in applets. Applets are quite pissy about imported classes that aren't there even if you don't use them, so you have to hide Java2 class-usage from 1.1 by using the plugin-approach the FrameBuffer and the IRenderer are offering. This limits the knowledge about LJWGL/OpenGL to the GLRenderer and it requires some "tricks" to get things working. Blitting and RGBScaling are examples of this. So even if it's possible to add hardware features regardless of the software renderer, the current design makes it difficult to do that in a convenient way sometimes. On the other hand, i really don't want to change the API everytime and force people to refactor their applications every month. That's something i really hate to do myself, so i'm trying to avoid it...
jPCT's hardware support is quite separated from the rest of the engine. If it weren't, i would have to maintain two completely different rendering pipelines making the code/API a mess and the size would grow. That's the reason why jPCT isn't a polygon pusher...hardware T&L is used somehow, but not to an extent. HW and SW are basically using the same pipeline until drawing of the actual polygons starts.
And finally, i want sw and hw to behave as equal as possible. That's because i think that it's usefull for pushing 3D into the Java-world, like it was usefull for Unreal to offer a software mode. Aside from javagaming.org and similar communities, 3D in Java is not taking place IMO, so i think it's important to make is accessible for as much people as possible to show that it could be done and to show them how they may benefit from using it. When this is achieved, you can think about adding all the fancy features...but maybe in another engine...(jPCT2.0+  :wink: )

Linuxhippy:
I think software rendering is quite important!

The main reason why I use jPCT is the fact that its software renderer is just amazing and runs everywhere where quite a bit of java is present (MSJVM....).
Please do not give up the software-renderer, although I like the idea of not supporting all features...

Good luck and thanks a lot , lg Clemens

Navigation

[0] Message Index

[#] Next page