Hi there, I agree with Mr. Tugai. I have similar problems implementing a research project. I think we speak about different issues. Big model with standing geometry and only one TransformGroup will work well. The memory leak occurs, if you change the geometry as well as transformations during runtime (inside my project on living objects). It seems Java3D caches the geometry data (for what reason ever).
For example 7 cubes with a 10 letter Text3D label. If I only zoom the labels size (using a TransformGroup in front of the Text3D), Java3D needs up to 20MB!!!!! memory more, which is never given free again, until I destroy the whole scene manually. At the moment Java3D is good for visualisation. If you want to simulate real time models... good luck! I think that�s actually a big bug. And there is no way to work around. To destroy the whole scene and build it again takes too much time. The estimated amount of objects inside my project is far away from only 7 cubes. Regards Eike -----Urspr�ngliche Nachricht----- Von: Discussion list for Java 3D API [mailto:[EMAIL PROTECTED] Im Auftrag von M. Pfeiffer Gesendet: Mittwoch, 14. April 2004 08:22 An: [EMAIL PROTECTED] Betreff: Re: [JAVA3D] What happened? > Hmm.. No, Now I'm using test models, which are quite > small. But memory leak > is big (I am using mandrake linux 9.0 with radeon 8500 > and direct rendering). > Do not know, where is the reason. Just to give you an idea about the dimensions: My biggest scene uses more than 500 Shape3Ds, every with at least one BranchGroup and one TransformGroup (and of course some are textured). With some additional Groups which organize the data that makes much more than 1500 elements directly within the SceneGraph (Tranfrom3D-objects, GeometryData and so on not counted). Of course this scene needs some memory (and I had to increase the memory size the JVM uses with the option -Xmx) but I can't say that there is a big memory leak which makes working with such a scene impossible. So I really don't know why you have that big problems. > This is a bug, because even offscreen canvas has frames > (though you must > render it manually, by invoking renderOffScreenBuffer() > ). In addition, any > behavior that use this criterion, won't work in offscreen > canvas, which is > too bad. When you render off-screen, you have to switch the "frames" manually - so where is the problem in triggering the related Behaviors manually too? Thats what I did for an off-screen-scene. Michael ======================================================================== === 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".
