Dealing with big trees, I got an unexpected error. Of course, it is very logical for it to happen, but I did not forsee it. Here it is:
[java]Nov 22, 2013 7:24:15 PM com.jme3.app.Application handleError
SEVERE: Uncaught exception thrown in Thread[LWJGL Renderer Thread,5,main]
java.lang.StackOverflowError
at java.lang.ThreadLocal$ThreadLocalMap.getEntry(Unknown Source)
at java.lang.ThreadLocal$ThreadLocalMap.access$000(Unknown Source)
at java.lang.ThreadLocal.get(Unknown Source)
at com.jme3.util.TempVars.get(TempVars.java:97)
at com.jme3.bounding.BoundingBox.transform(BoundingBox.java:294)
at com.jme3.scene.Geometry.updateWorldBound(Geometry.java:283)
at com.jme3.scene.Spatial.updateGeometricState(Spatial.java:716)
at com.jme3.scene.Node.updateGeometricState(Node.java:175)
at com.jme3.scene.Node.updateGeometricState(Node.java:175)
at com.jme3.scene.Node.updateGeometricState(Node.java:175)
at com.jme3.scene.Node.updateGeometricState(Node.java:175)
at com.jme3.scene.Node.updateGeometricState(Node.java:175)
at com.jme3.scene.Node.updateGeometricState(Node.java:175)
at com.jme3.scene.Node.updateGeometricState(Node.java:175)
at com.jme3.scene.Node.updateGeometricState(Node.java:175)
at com.jme3.scene.Node.updateGeometricState(Node.java:175)
at com.jme3.scene.Node.updateGeometricState(Node.java:175)
at com.jme3.scene.Node.updateGeometricState(Node.java:175)
at com.jme3.scene.Node.updateGeometricState(Node.java:175)
at com.jme3.scene.Node.updateGeometricState(Node.java:175)
…[/java]
So the depth of the hierarchy got to where it causes stack overflow on its own update inside the engine. I cannot imagine any solution to this except for, probably, stitching the tree of manageable size parts, keeping them in spatial sync (especially if the tree nodes can move) not by the means of hierarchy, but by some trickery with controls. The controls will monitor the leaf node of a higher part, which is the parent of a lower part and the root of the lower part and place the latter one in the place of the first one and rotate accordingly…
Sounds like you are overloading the scene graph. Perhaps you are confusing game objects with scene objects?
My guess is that your tree should be a separate model and reflected in (MUCH) fewer visuals. Because if your scene graph is so deep as to cause stack overflow, it’s a big crazy monster.
Well, I am still researching the thing, so I have tried something that nearly gets to the SO error, but does not overgo the barrier. When constructed and rendered, the performance of this is very good, there are no lags and such… so the only sad thing is that nasty SO limitation here…
Not sure what you mean by confusing game objects and scene objects. If you mean that I should simplify the tree to use less hierarchy, for example, be one mesh and such, then I am not sure if this is possible because each node will lose the ability to be mouse-picked and modified individually. And if I am to maintain another layer of quads for mouse-picking, it is going to fail the same way. Or maybe you know how to retain individuality of the nodes? For example, in MineCraft they manage to do this for the pseudo-voxels but they are more ascetic than I can let it be.
The visual look of the tree is very ascetic already. And yes, it is big and crazy but it is a part of the task. It has to have the ability to reflect rather large (arbitrary) structures. And all nodes have to be very individual like being able to have own icons, every text is editable (it is already so, but the SO error adds some to it).
Here are pics of the work-in-progress:
Don’t judge too much, the graphics is still poor and there is no zooming and all is cluttered and bugz, but that’s ok, it’s just a rough rough prototype. See, it can be even like 100 bigger than that! Of course I intend to apply different techniques to not to display all at once, use windowing and such, but I suppose that nothing will take away the case of the too deep hierarchy. As I said, the data structures come from outside and I must handle them whatever it takes…
And just as a side question, I wonder, can the current graph processing be optimized for tail recursion?
@noncom said:
And just as a side question, I wonder, can the current graph processing be optimized for tail recursion?
Probably not. The implication is that your scene is already so poorly constructed that JME wouldn’t render it well anyway. Tail recursion would significantly complicate the code and imply a custom stack which would require some memory.
How deep was your graph when you got the issue? I just tried a test and was able to get a graph of depth 3599 before I got a stack overflow. That’s already more total objects than a JME scene should have anyway… let alone just depth.
It sounds like your tree was poorly constructed maybe. Perhaps your parent child relationships were not really parent child relationships.
I see… yeah, I admit, I have much yet to learn in this field… The tree coud have this much nodes, yes. Not that it was so deep, it’s just that sequential structures like lists represent a descending hierarhy themselves, where each next node is attached to the previous one. And the lists well could be thousands of elements long.
But, of course, anyway, I think that a human eye would not stand much more than about 300 operable objects (let alone the display space), and inoperable objects can be greatly simplified. Since I cannot compromise the idividuality of the elements, I think, I will simply create something like scrolling windows for lengthy structures. For example, a structure of 10000 elements long will only display like 30 to 50 lements…
Another way I can think of is to put everything in one mesh as far as it is possible, then use a quad-tree partitioning with z-order of the screen space to determine what is clicked… and specially display only the curently focused units as separate objects… but that sounds like complex…
@noncom said:
I see.. yeah, I admit, I have much yet to learn in this field.. The tree coud have this much nodes, yes. Not that it was so deep, it's just that sequential structures like lists represent a descending hierarhy themselves, where each next node is attached to the previous one. And the lists well could be thousands of elements long.
No, don’t do it that way. The children should be children of the parent… not children of each other. It doesn’t make sense, really.
I think what he meant is that you seemingly (mis)use the scenegraph as your data storage. You should have your data separate from the scenegraph so that you could link a scenegraph object to a leaf in your graph. This way you would not have to mirror your deep data structure in the scenegraph and you could even attach the visual representation of all leafs to one (root)node or construct a geometry including the picking algorithm, as you probably know best where to find your single objects (again using the external data).
@normen said:
I think what he meant is that you seemingly (mis)use the scenegraph as your data storage. You should have your data separate from the scenegraph so that you could link a scenegraph object to a leaf in your graph. This way you would not have to mirror your deep data structure in the scenegraph and you could even attach the visual representation of all leafs to one (root)node or construct a geometry including the picking algorithm, as you probably know best where to find your single objects (again using the external data).
Yep, that’s what I meant.
But even within the way he did it, he picked the most inefficient way where each tree child is actually a child of its sibling instead of the parent. Really really really needlessly deep hierarchies. Ironic to go from a data structure to an even more complicated scene structure.
Cool! I have followed the advises and the performance has increased much!
As for increasing complexity of the representation over the original data - yes. This is intended in a similar way like text representation in MS Word is much more complex than the text itself, or code representation in an IDE is more complex than the raw text file with code - it has highlighting, various additional symbols, regions awareness and such. Of course they might be using many optimizations too, but I am just trying to approach that land for the first time.
@noncom said:
Cool! I have followed the advises and the performance has increased much!
As for increasing complexity of the representation over the original data - yes. This is intended in a similar way like text representation in MS Word is much more complex than the text itself, or code representation in an IDE is more complex than the raw text file with code - it has highlighting, various additional symbols, regions awareness and such. Of course they might be using many optimizations too, but I am just trying to approach that land for the first time.
Well, there is “increasing complexity” that is necessary for the visualization and then there is “increasing complexity” that feels like it is easier but is actually harder. For example, an MS Word document doesn’t make every word the child of the previous word… because that would be silly.
Oh you meant that… I thought about the complexity of representation that gives additional overlay over the data, but you mean the inner organization… I see… subtler differences!
but it is a part of the task. It has to have the ability to reflect rather large (arbitrary) structures. And all nodes have to be very individual like being able to have own icons, every text is editable (it is already so, but the SO error adds some 
to it).
