a suggestion for the future of JPCT-AE

[MichaelJPCT]

Hi Egon,
i've used jpct engine for several years, i have the feeling that jpct is easy to use but with limited freedom for engine users.
for example, jpct doesn't deal with depth test/write, but they are very important in some cases. i have to call gl api directly outside the scope of jpct. luckily there is no bad influence.
another example, i wish to have single channel textures to save memory. nowadays gpu's are getting better, they might support more features. but jpct can't support every new feature of new gpu. at the same time, the management functionality of jpct is good. so what if jpct can interface with a texture created with gl api calls? then the user can have more freedom while still have the convenience of jpct.
so what i'm really suggesting is the ability to interface with objects created by gl calls outside jpct, because it's too much work to make the engine support every thing.
i read about defered rendering, and i believe a lot of developers would choose new techs like that. can jpct support the new techs? if jpct doesn't support them directly, can you make interfaces to let the users have the possibility to do them?

[EgonOlsen]

Deferred rendering will not work IMHO. It's too different. But apart from that, I'm not sure what exactly you are missing in terms of options to interface with GL directly? You have shaders, in which you can do everything you like, you have the IRenderHook, which you could use to inject your own calls directly into the render pipeline if you so desire and you have the option to use an externally generated texture ID for any texture.

I added these options for people who want more direct control. On the other hand, you are on your own from there on and have to make sure to not screw things up while doing your stuff. jPCT does quite a lot of (GL-)state management to keep things smooth. If you interfere with this internal state, things might get messy. But as long as you clean up after yourself, you should be good to go. So what exactly is missing?

[MichaelJPCT]

i think i haven't learned enough about the engine - i have only used the simpler portion of the engine.
i just read the java doc and i saw the setExternalId() method.
since you say you have added options for people who want more direct control, i think all i would need are already in the engine.
i think JPCT misses some showcase of advanced effects. i used to use Panda3d, in its community there are showcase of advanced rendering techniques, such as physics based rendering , which looks modern.
i am not graphics enthusiast so i don't do advanced graphics effects. i use JPCT-AE because it's convevient and i don't aim for pretty graphics.
in Projects page of the website, there are screenshots of many projects, but there are no highlights of graphics effects, it's hard for me (or some other people) to find out the best effects JPCT can do. some people, such as me , at the beginning, would think JPCT is an engine which can do simple graphics. but that is not the whole truth.
perhaps more efforts in showcasing would help people know better about the engine?

[EgonOlsen]

A showcase usually depends more on art skills than it does on technical skills and I'm not very good at art, so it proves to be difficult. The wiki covers some advanced topics, but they don't look too impressive in the end either.

jPCT(-AE) was designed to be simple to use. For that, I made some sacrifices concerning flexibility. There's a lot of stuff going on in the background (even more in desktop jPCT) to hide the GL related stuff. Then people demanded for more control, so I added some things that I could add without confusing people with it who don't want to use it. It's a balancing act. If you do too little, people can't do what they want to do. But if you go too far, you'll end up with something that's actually more complex than the "clean" solution would have been in the first place, because you have to hack your way into the innards of the engine to do it. You can see this in a lot of software projects. Often when something started out to be "simple", people added stuff on top of it so that it finally lost its simplicity and ended up as an abomination of the former idea (*cough* PHP *cough* Javascript *cough*).

That said, you already have some options (as mentioned). You can set an external texture ID, but it requires you to handle GL context changes yourself. You can use the IRenderHook to inject GL calls directly into the render pipeline (you just have to make sure to restore the proper state after you are done) and you can use shaders to do all kinds of things. For that, you can provide additional vertex attributes (in Mesh) to support even more fancy shader stuff. You can't do everything with all this, but quite a lot.