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.

Thanks for your help. mergeObjects is the method i need (i want to add an octree). The following code throws this exception:

Exception occurred during event dispatching:java.lang.StackOverflowError at com/threed/jpct/OcTree.createChildren at com/threed/jpct/OcTree.createChildren at com/threed/jpct/OcTree.createChildren at com/threed/jpct/OcTree.createChildren at com/threed/jpct/OcTree.createChildren at com/threed/jpct/OcTree.createChildren at com/threed/jpct/OcTree.createChildren at com/threed/jpct/OcTree.createChildren at com/threed/jpct/OcTree.createChildren at com/threed/jpct/OcTree.createChildren

You are trying to create the octree using a maxPoly-value of 12. The OcTree is build using recursion and if the recursion gets too deep, the stack will overflow. This is what happens to you here. I suggest that you use a maxPoly-value larger than 12 (try 100 for example). 12 seems to be very low even if the VM wouldn't puke on it. An OcTree with too few polygons in each leaf isn't efficient any more. Take the fps-demo as an example: It's using a value of 100. If i'm using 10, the tree gets so big, that traversing it every frame costs more time than it saves and the frames/sec are going down by around 20%.Play around with maxPoly to find a good (and working :wink: ) value. I think i'll add a "break if recursion gets too deep"-option into jPCT to avoid this problem in the future...i planned to do this anyway.

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.