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

You may ignore the problem...the culling won't be performed using the octree nodes then but the objects' bounding boxes. If we aren't talking about zillions of objects here, this should be fast enough...
If not, you may have a look at Object3D.translateMesh(). This does a physical translation of the object in object space, so you may setup the translation for each object, call translateMesh() for each and merge them afterwards. This way, you should get one large object with the cubes at the correct positions.

Hope this helps.

Ok, i think i'll do a special version of 0.95 for you to test this and if it works out well, i'll add it to the "normal" version. I hope to get this done within the next week.

Using a MemoryImageSource in 1.1 instead of the BufferedImage is not that much of a performance problem, so don't worry about it.
jPCT clips (the software renderer culls to be exact) on the far clipping plane (can be set in Config). There is done some gross culling on a per object and per octree-node base, so if you decide to use octrees, the culling will be very fast on that plane, even if large portions of the landscape are not visible. If you want to fade out the landscape into another color than black, you need version 0.95 (to be released...) to make that effect look good.

Well, i don't know for sure. It *should* work that way, but i never tried it. For deploying applications that use LWJGL (http://www.lwjgl.org) (as jPCT does for OpenGL support), i suggest to use Java Webstart instead.
However, you may give the signed applet approach a try, but even if it works, it will never render into the applet itself, because LWJGL can't redirect its output into an AWT/Swing component. That the design of LWJGL..nothing you can do about that, i'm afraid.

After thinking some more about it and doing some tests, i discovered that there could be another problem: Imagine a maxPoly of 10 and 11 polygons that are exactly the same (same size, same orientation, same transformation, i.e. lying onto each other)...in that case, the spacial subdivision will subdivide and subdivide to get the polycount of the node down to 10 or lower but that will never happen (because jPCT doesn't split polygons to fit into the octree). This is not the only situation where this may happen (but it's simple to understand using this example), so maybe this is what happens to you.
I'm not quite sure what to do against this, i.e. how to detect this case. In your case, i would still say: play around with maxPoly...it should fix the problem. I'll also add a maxDepth to the constructor for the next version that takes care of the recursion not going too deep in these cases...but i'll also try if it's possible to avoid the problem at all.

Yes, a dummy object should never be added to the World. You can do it though, but it doesn't make much sense. The basic processing goes like this:

Iterate through all visible object in the world, calculate the object's transformation matrix by recursing through its parents, transform the object using the generated matrix, render the object.

If you don't add the box-object to the world, nothing will be rendered at all. The dummy object lends its transformations to the box-object. It doesn't cause the box object to be rendered. jPCT doesn't care if an object has childs, it just looks at the parent(s) for getting the transformation hierarchie. Maybe it's clearer if you use box1.addParent(levelObj) instead.

Dummy objects serve a single purpose: They lend their transformations to their childs. That's usefull for connecting objects transformation-wise. They are not something like nodes of a scenegraph, as jPCT isn't a fullblown scenegraph engine...it just takes some ideas from the scenegraph concept.

Hope this helps.

Edit: here's another thread dealing with object hierarchies: http://www.jpct.net/forum/viewtopic.php?t=53

It's a geometrical approach using a ray-polygon intersection test. I should really include an example of how to do it exactly in jPCT...
The object has to be "selectable" (see setSelectable() in Object3D) to be picked. None-selectable objects will still act as a "block" to the ray, i.e. if the object to be picked lies behind an object that is not selectable, the ray will still be blocked by that object and no object will be returned as picked.