I don't think the IRenderHook idea will work. The render hook gets triggered too late in the process, IIRC. At that stage, the lights have already been calculated.

I'm glad it worked!

Looking good!

Ok, I've updated https://jpct.de/download/beta/jpct_ae.jar. If that still doesn't have the same effect as display(), then I can do one more thing to it. Please let me know how it works out.

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.

It doesn't make much sense to use an Object3D for a particle system. I tried that, it didn't really work out as good as I hoped. It's better to use a single, billboarded object per particle. That's not highly efficient, but as long as you don't want to use particles extensively, it should be fine. At least that's what I'm doing and once I had it working, I never spent a second thought about it, because it was just fine IMHO.

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?

Thanks for the contribution. setExternalId() was actually meant to be used in such edge cases. You are right about the memory consumption. It's almost doubled for a normal configuration. You can work against this by using either the Virtualizer (http://www.jpct.net/jpct-ae/doc/com/threed/jpct/Virtualizer.html) or by setting keepPixelData on a Texture to false. Both methods will still peak out at double the memory usage at reload time.

There are several reasons for keeping the pixels. One is, that the upload has to happen again on a context change. Context changes happen far less now than on older Android versions but they still might. In case they do, you have to make sure to upload your texture again yourself or you'll get garbage (or all white). Another reason is that I need the pixel data to calculate the mipmaps myself for some devices. On some older ones, the mipmap calculation is simply broken and doesn't work at all. And the last one is, that the texture isn't aware of the GL rendering context or thread. It's a simple container and it can be created in any thread you like. So you somehow have to buffer the data until the upload is feasible.