// 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
🎉 Celebrating 25 Years of GameDev.net! 🎉
Not many can claim 25 years on the Internet! Join us in celebrating this milestone. Learn more about our history, and thank you for being a part of our community!
Java3D: Very "deep" scene graph (stack overflow issues)
Author
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.
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
Author
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...
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...
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!
...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!
Author
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 -> 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!
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
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.
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.
Author
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
- 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
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement