i have tried using an object3d to hold 100 particles (my cloud effect) , using shader/uniform to locate every particle.
in this method, jpct doesn't need to sort all particles, only sort the object3d in a World. when particles within an object3d are close to each other, and the scene is not too complex, this method doesn't often cause sorting error, and it  saves sorting time, 1 vs 100(or 20 vs 2000) candidates to sort in my case, that should be quite some time.
imagine i want a particle emitter with varying quantity of particles, sometimes a few, sometimes 500 particles, adding/removing them as individual object3d, or only setting visibility while keeping them in a World,  not something i would prefer to do.
if they are only 1 object3d, i can use shader to easily make some of them disappear.
and 500 draw calls cost much more time than 1 drawcall.
so these are the benefits of using object3d like an emitter. not always good, but in some case, it's very good.
in my scene, there are often 20 clouds (2000 particles) on screen , my app runs 30fps without problem if they all look small on screen. test device has quadcore A53 which is low-end device now.
using quads can do it, but point sprites can save calculation.

what about the point mode in drawWireframe() ?
the object is still made of polygons, but only points are rendered.

i always use object3d.setOrientation(forward vec, up vec) .
up vec is negative of downward vec.
only 6 float values (two vec3) are needed.
you need vectors in world space.

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?

i just tried, it doesnt change. i think the first time the texture is used, alpha channel is automatically created.
if i remove the channel after the first time, i get a total black texture after render.
but to the npot texture of screen size, i cant call removeAlpha, or the app crashes.
i tried creating npot texture (but with pot size) for this case, but the result doesnt differ from Texture(x,y).

hi Egon,
i encounter a strange problem.
i want to render some clouds into textures and put them into rectangle meshes then put them back to the scene. the replaced method is putting the clouds directly into the scene.
there is a far scene where nothing but clouds are in, and the far scene is rendered without depth test/depth write.
i believe the environment for rtt is the same as the non rtt one - same shader, same depth test setting.
but the rtt texture doesnt look the same.
without rtt, the overlapping particles blend, the result looks thick. but with rtt it seems only one layer remains, which indicates a replace method rather than blending.
and even if the rtt texture has opaque background, the particles make the texture look-through. the below screenshots are comparison of 2 methods .
 the large white area is because i clear the rtt fb with color 0xffffffff, which is not necessary, but it indicates the opaque background was lost because of the particles. i also tried to use an opaque mesh as background, same result.
turning depth test on, doesnt change the result either.
the texture for rtt is created with Texture(x,y) method.
more strangely, the main scene is also rendered into a texture(npot) then blit into the true fb, but the clouds directly in main scene doesnt change the npot texture to transparent.

why would the rtt result be different from directly rendering into the main scene?

clouds , made of groups of randomly placed particles , rendered using a shader.