# Java3D: Very "deep" scene graph (stack overflow issues)

This topic is 4943 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

Hello all, I have a very deep scene graph (10,000+ spheres linked together, one by one). The scene graph compiles (via the BranchGroup::compile() method) fine, but the program always halts (with a StackOverflowError in Thread main) at the point where the scene graph is added to the Locale of the universe.

// Sample code... (in my custom VirtualUniverse subclass)

// Make a new "BallGroup" (reads in a bunch of coords, builds the graph)
BallGroup balls = new BallGroup(myfile.txt);

// Compile the scene graph (write disabled on all transforms)
viewRoot.compile(); // the "view" half of the scene graph
balls.compile();


The program works fine for fewer balls. I've tried forcing a larger VM stack size, but no reasonable value works. Anyone have any ideas? I'm going to go take a look at the source code for the Locale class, but I get the feeling that the problem has to do more with "drawing" the scene. Anyway, any help would be greatly appreciated. - Nate

##### Share on other sites

The StackOverflowError is generated just after javax.media.RasterRetained is loaded and before java.awt.Window is loaded.

If it isn't obvious, I'm a complete graphics programming newbie...especially with Java. Any help will be greatly appreciated. In the meantime, I'm continuing my search and profiling...

##### Share on other sites
Well, as you know the StackOverflowError is thrown when a stack overflow occurs because an application recurses too deeply.
...so the only solution seems simply to avoid such a huge recursion! :P Ok, nothing new here.
I guess the stack overflwow occurs because Java3D needs to travel the whole scenegraph to render it, and this, "recursively". Therefore, the only solution seems to build the scenegraph on an other way. After all, it's targeted at "usual" scenegraphs and not such extreme cases that you have.
So, what i suggest is to build all your balls and add all of them directly to the root, or in groups.
root -> myTransformGroup -> ball
and then handle the corresponding Transform3Ds on a recursive way or not to achieve what you desired.
However, i have no cetitude that it'll work either, but just built the tree and you'll see it directly.

good luck!

##### Share on other sites
Quote:
 Original post by misterX...Therefore, the only solution seems to build the scenegraph on an other way. After all, it's targeted at "usual" scenegraphs and not such extreme cases that you have.So, what i suggest is to build all your balls and add all of them directly to the root, or in groups.root -> myTransformGroup -> balland then handle the corresponding Transform3Ds on a recursive way or not to achieve what you desired.However, i have no cetitude that it'll work either, but just built the tree and you'll see it directly.good luck!

Thanks, misterX. I guess I can use a shallow tree and get creative with behavior node components...but I'm hoping it won't come to that. The fact that it is a chain is very intuitive and practical for this particular application.

One thing I don't understand is this: if I do balls.compile() and all transforms between the "Balls" are write/read/everything protected, shouldn't the compile method condense the 5000+ Spheres into a single, complex, Shape3D object? Then, the recursion wouldn't be very deep at all, correct? I seem to be missing something...

- Nate

##### Share on other sites
there isnt a single use for a recursion that deep i can think of. if you were to organize your spheres in a binary tree instead of a direct chain for example, youd only need log2(10000) recursions, ie nothing.

whats the point of a recursive datastructure when everything follows up in a linear fashion, if i might ask? if the relationship is purely linear, you could also keep your data in a conventional structure for all intents and purposes that im aware of, like an array or linked list, no?

maybe a more clear description of what you want to archieve will shed light on this problem.

##### Share on other sites
A more specific question: Does anyone know how the "BranchGroup::compile()" method REALLY does? It doesn't seem to be compiling in this situation (and according to the sun website, it should be).

- All TransformGroup nodes are write- and read-disabled
- All Shape3D objects (Spheres) are write- and read-disabled
- The Group objects in the scene graph can be referenced from outside the scene graph. That is, references to all the Balls (extend BranchGroup) are stored in an array...as well as being accessible via the scene graph.

The last bit worries me. Is it possible that the scene graph doesn't compile because there are references to the ball objects external to the scene graph? I'll try playing around...

- Nate