Eike,
Without seeing your program, here is my guess to the problem
you having.In general, Java 3D operates via message passing.Imagine you have a user thread, that isn't bounded by the j3d frame rate, transmitting TG change requests to j3d. It is very likely that the user thread is running at a much high rate than your system j3d frame rate; often can be a million times greater. In such situation, a huge backlog of messages is created in the j3d's message queue, hence consuming memory. This is very bad for performance and a potential cause to "Out-Of-Memory". If possible, the best approach is to do the scene update via j3d's behavior, which is in sync. with j3d frame rate.
- Chien Yang Java 3D, Sun Microsystems Inc.
Eike Tauscher wrote:
...sounds interesting. I will try it, to get the memory back. Do you know something about the TransformGroup problem? I have created a basic class called Object3D sub-classed from TransformGroup. Inside a two dimensional view, the user can move a point (or more...), by dragging. The 3D shape of this point is a cube inside Java3D (using my Object3D class). If the point is moved, I set the translation according to the new coordinates. I don’t create new Objects but if I do this, the memory usage increases. If there 10 points moving at the same time (with Text3D labels)... 20MB and growing.
I've found some similar inside the forum:
http://forum.java.sun.com/thread.jsp?forum=21&thread=404881
Regards Eike
-----Ursprüngliche Nachricht----- Von: Discussion list for Java 3D API [mailto:[EMAIL PROTECTED] Im Auftrag von N. Vaidya Gesendet: Mittwoch, 14. April 2004 15:18 An: [EMAIL PROTECTED] Betreff: Re: [JAVA3D] AW: [JAVA3D] What happened?
Hmmm...I think it is something like this.
Suppose I've a live BranchGroup which is the parent of a subgraph containing possibly other Groups and, in particular, Shape3D's with possibly many Appearances and Geometries. If I detach this BranchGroup then my experience has been that the memory corresponding to that BranchGroup and its subgraph components will not be released *until* you attach and detach another BranchGroup. And, of course, when you detach that second BranchGroup you'll again see a memory leak corresponding to that second BranchGroup.
Now, this may not seem like a big problem since the memory is retained only between successive BG detaches. However, imagine a situation when apart from visualizing the geometry, I'd also be doing other memory allocations as part of a computational steering framework, for example, then it does become a big issue. The dummy attach/detach seem to be an effective workaround for my problem presently.
I'm not 100% sure that this leak occurs in general with each and every BranchGroup, or, if it is a function of the various kinds of capabilities such as By_ref, U_C_I_O, etc.
The general advice that I have from Chien, hope that I paraphrase him correctly and which may or may not be a fix for this particular problem, is to perform all BG detaches (and probably attaches too) from within a behavior especially if the attaches and detaches are very !!!rapid!!!.
Vaidya
=========================================================================== To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff JAVA3D-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
=========================================================================== To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff JAVA3D-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
