The future of jPCT

[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]

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?

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

[bgilb]

Well, i think even if jPCT goes the way of xith etc it will still be much better. I tried xith and i tried lwjgl and that one monkey one hah. Both times i was let down because the simplicity wasn't there at ALL and thats where jPCT exceeds other ones. We just need more exposure to build the community. When i first came to this site I looked around thinking: "software renderer?! i dont need this!!!" a month or so later i came back and downloaded the fps demo and realized : " what the hell it has a option to change to OPENGL??? why wasn't this set to default!"

[EgonOlsen]

If you find jPCT easier than xith3d or jME, then the idea worked. jPCT's goals were ease of use and a small size. That's the reason why its whole functionality is build around the two monoliths World and Object3D. This may also have some drawbacks and it doesn't look very "stylish" but it's easier to understand and its clear where to search for specific methods IMHO.
It also tries to hide the difficult stuff from the user as long as he doesn't need it. That's something where the other approaches fail IMO. It's ridiculous to follow a discussion in the xith-forums if xith should come with a normal generator or not, or why the collision system is broken and won't be fixed and ODEJava is much better anyway...there's no question that there should be a normal generator in a 3D engine (in fact, it was one of the first things that i've added to jPCT) and it's mandatory to have a working collision system. With jPCT, you don't even have to know that normals exist and what they are good for. The same for collisions: It's one line of code to check for a collision. If you want more info about the collision, implement a CollisionListener and you are done. But you don't have to...
I agree, that the current website has its problems to promote the project. On your first visit, it looks like just another applet demo. The frontpage doesn't tell you anything about what this really is all about. That's partly due to the fact that it wasn't much more than a just another applet demo when i designed the page. I think i could do much better now, but it's a question of motivation. I think i have to do it sooner or later though.
However, when you search for "java 3d engine" on google, jPCT comes second with no trace of xith3d and jME...but obviously, this isn't enough to make people think that it's actually a mature and stable product.

[Remo]

I do agree that the main site doesnt promote the full power of jPCT. Its not bad at all tho but I think you should write another catchy demo soon!
I havent worked with xith3d or jME but I have worked a little on some c++ 3D engines and I can truly say that world and object3d make life much easier on the software design side.
Its a great product that I think you should promote more .

[rolz]

I recall the first time I came here looking for a 3d applet engine. The cool thing about jPCT was its simplicity, lightweightness and compatibility with older VMs. I still think it is the #1 solution for applets that need 3D.

 I admit i had a slight feeling of FUD after using jpct for a half of a year. It seemed that the development would stuck after going to desktop.  I did research on other engines jME and XITH and to my surprise they turned out to be even FUDer because of the feeling of incompleteness, overcomplexity and the way they are developed.

The right way to go is to consider JPCT not the silver bullet but stable and usable 3D java middleware. It does have own pros and cons thought but turns out to be well-suitable for most cases.

Talking about the future, i am not sure what are motivations for Egon to make this project evolve. JPCT is not affiliated by any business (I hope this is a subject to change in future to get motivation ), does not have community contributions, lacks demos and promotion. IMO working in these directions should reduce FUD and give the project more marketing value.

[Remo]

I recall the first time I came here looking for a 3d applet engine. The cool thing about jPCT was its simplicity, lightweightness and compatibility with older VMs. I still think it is the #1 solution for applets that need 3D.

 I admit i had a slight feeling of FUD after using jpct for a half of a year. It seemed that the development would stuck after going to desktop.  I did research on other engines jME and XITH and to my surprise they turned out to be even FUDer because of the feeling of incompleteness, overcomplexity and the way they are developed.

The right way to go is to consider JPCT not the silver bullet but stable and usable 3D java middleware. It does have own pros and cons thought but turns out to be well-suitable for most cases.

Talking about the future, i am not sure what are motivations for Egon to make this project evolve. JPCT is not affiliated by any business (I hope this is a subject to change in future to get motivation ), does not have community contributions, lacks demos and promotion. IMO working in these directions should reduce FUD and give the project more marketing value.

How about a demo show. Some of us could write a little app using jPCT . Something little that shows the strenght and capabilities of jPCT, nothing HUGE.

[EgonOlsen]

How about a demo show. Some of us could write a little app using jPCT . Something little that shows the strenght and capabilities of jPCT, nothing HUGE.

Feel free to contribute in any way you like. I will gladly host and/or link to any good demo you are throwing at me.

[Anonymous]

the thing that is nice about jpct is that it doesn't require a native dll download. it would be nice though if you could create an applet using the software-based renderer, but have an optional download to plugin a hardware-based renderer, so the the same software runs in either way.

[EgonOlsen]

it would be nice though if you could create an applet using the software-based renderer, but have an optional download to plugin a hardware-based renderer, so the the same software runs in either way.

I don't quite understand...you can already do that!