I had a very similar problem. The way I solved was by keeping a reference to the texture components (BufferedImage, ImageComponent, etc) and without recreating them (after some recreations I had the OutOfMemory problem) I only changed their information to update the textures with new ones (only their data, without creating new objects) ... That way I was able to change them as much as I wanted without the OutOfMemory problem...
-----Original Message----- From: Discussion list for Java 3D API [mailto:[EMAIL PROTECTED] On Behalf Of Dola Woolfe Sent: Saturday, March 08, 2003 8:42 PM To: [EMAIL PROTECTED] Subject: Re: [JAVA3D] OutOfMemory w/o textures Thanks for the good advice. I did separate the two things, but I didn't try to render mulitple images in a single application outside a servlet. I will try that next and that should help locate the problem a little better. Thanks. Dola --- Bernd Fondermann <[EMAIL PROTECTED]> wrote: > On Friday 07 March 2003 16:51, Dola Woolfe wrote: > || Hi, > || > || I use j3d in a servlet that produces an image. > Every > || time the servlet is envoked, I create a Universe > stick > || a few objects into it, render to an offscreen > canvas > || and I get my BufferedImage. > || > || The problem is that it works (and works great!) > only > || the first time around! It *always* fails the > second > || time around (and on) with an Exception that I > would > || not expect: OutOfMemory. > || > || I know that there may be a problem with multiple > || universes in the same application, so I actually > reuse > || the same universe by detaching the old > BranchGroup and > || attaching a new one. > || > > Hi Dola, > > I like to suggest a slightly changed system > architecture. You have 2 problem > domains: > a) Providing a off-screen-rendered image with Java3D > b) Serving the image through a servlet > These two should be decoupled as much as possible. A > servlet request is a > short living process, the Java3D rendering service > is a long living process > (as you stated). You probably run into > uncontrollable concurrency and > multithreading issues here very quickly. > > Make the rendering service a true 'singleton'. > Synchronize the 'rendering > call'. First, test this functionality stand-alone, > without calling from a > Servlet. > > The behavior of Servlets may be delicate. You may > test your servlet code by > reading in BufferedImages from image files on the > harddisk. If this runs > without problems, connect both together. > > These hints may seem to be too unspecific or are > already known to you, but my > first guess is that you are running into > architectural problems which are not > Java3d specific in the first place. (I wrote a > similar mechanism and > experienced a bunch of problems, too.) > > Have fun, > > Bernd > > ======================================================================== === > 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". __________________________________________________ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/ ======================================================================== === 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".
