Sign in to follow this  
EggHatcher

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

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();

locale.addBranchGraph(viewRoot);
locale.addBranchGraph(balls); // RUNTIME ERROR HERE


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 this post


Link to post
Share on other sites
More info:

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 this post


Link to post
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[i] -> ball[i]
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 this post


Link to post
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[i] -> ball[i]
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!


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 this post


Link to post
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 this post


Link to post
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

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this