Florin, I am happy you found my explanation useful. Please keep the list updated on the progress you may make with this problem.
So then the current conclusion is that in order to control the memory usage of our applications, we must tradeoff between the memory usage of 1) Many transform groups attached to a single shared geometry AND 2) A single transform group attached to a single, but compound geometry containing all the original geometries. And as Florin pointed out, there are many shades of grey in between both solutions. You can achieve these shades of grey by adjusting the amount of geometry you share. To be more concrete, to go from strategy 2 to something that is a little more of strategy 1.. you would start with a single transform group and a single geometry that contains 10 spheres... and then move to using two transform groups, with each attached to a single geometry that contains 5 spheres! OBVIOUSLY you must make sure that the geometry for the combined 5 spheres is shared between the two Shape3Ds, or else you have saved no memory at all! THEREFORE, the degree of sharing you use IS the shade of grey between 1 and 2. Sincerely, Ian Nieves On Wed, 26 Feb 2003, Florin Herinean wrote: > You are perfectly right in your answer. The trick is to find the perfect > compromise between the two solutions. Thanks a lot to Ian for pointing that > very clearly and to Nitin who opened that thread. Now I know how I can > further improve the memory usage of my app. > > Cheers, > > Florin > > -----Ursprüngliche Nachricht----- > Von: Ian M Nieves [mailto:[EMAIL PROTECTED] > Gesendet: Mittwoch, 26. Februar 2003 12:37 > An: [EMAIL PROTECTED] > Betreff: Re: [JAVA3D] AW: [JAVA3D] Java 3D or GL4Java (also solution to > la rge number of geometry problem) > > > Nitin, > > You cannot get away from the fact that your application will consume large > amounts of memory. I will think for a little bit more about this one, but > it seems that you cannot excape reality here. > > The best you can hope for is to choose to either have: > 1) lots of transform groups and a single shared geometry > OR > 2) few transform groups and lots of independant geometry > > Use this heuristic: > If your shared geometry consumes more memory than a transform group, then > go for option 1. If the geometry uses less memory than the TG, use option > 2. You will have to use a rough estimate of what amount of memory a TG > consumes, since there is no STRICT and SIMPLE way of doing this > automatically in your program. > > Whichever one gives the best memory footprint and performance is the one > you should use. > > The overarching point here though is that OpenGL will not help you excape > this reality, nor will any other system. Please corret me if im wrong. > > The killer solution will inevitably be high level, and apply to most 3d > systems. > > Again, I will think about this problem a bit more. > > > Sincerely, > Ian Nieves > > > On Wed, 26 Feb 2003, Nitin.Jain wrote: > > > Ian, > > > > Thanks for taking pains of explaining the possible solution. But still in > > the approach '1', we will not be sharing the geometry if we want to > tranlate > > the atoms at there specific position, this would lead to a huge memory > > requirement for the geometry, given the fact that it is spheres and > > cylinder. am i grossly wrong somewhere...otherwise I have tried this, it > is > > even worse than creating number of TGs > > > > nitin > > > > -----Original Message----- > > From: Ian M Nieves [mailto:[EMAIL PROTECTED] > > Sent: Wednesday, February 26, 2003 4:38 PM > > To: [EMAIL PROTECTED] > > Subject: Re: [JAVA3D] AW: [JAVA3D] Java 3D or GL4Java (also solution to > > large number of geometry problem) > > > > > > Nitin, (and ALL) > > > > I have a similar system as you do.. Lots, LOTS of repeated geometry that > > must be rendered. I have not yet implemented my optimal solution, but I > > am quite sure it will work, and I will outline it to you, and the rest of > > the community. > > > > First observation: My solution doesnt care if the geometry is often > > repeated or not. It could process tons of different geometries as fast as > > if the geometries were all the same. > > > > Second observation: My solution works on systems where MOST of the > > geometries do not need to be simultaneously AND independantly > > manipullated. That is, when tons of things need to be changed > > independantly of each other. If that IS the case, then you NEED lots of > > readily available transform groups, and you must grin and bear it. > > > > Solution: > > 1) Dont waste your CPU time or memory in processing transform groups at > > runtime. When you add atoms to your molecule, transform the coordinates > > of your atom so that it is already in the coordinate space of the > > molecule, and a transform is not needed! The smaller the geometry, the > > cheaper this transformation is! Now you have only 1 transform group for > > the entire molecule! WOOHOO! (note, this will not prevent picking) > > > > 2) Big deal.. What if you want to move an atom? Well then, extract that > > shape3D from the molecule, which is easy, transform its coordinates back > > into world coordinates, slap the appropriate transform group on the > > Shape3d, and put the new transformgroup into your world! Now you can > > independantly manippulate that atom! Again, the simpler the geometry, the > > cheaper it wil be to put the atom into world coordinates. > > > > 3) Youre lucky that your geometry is all just spheres and cylinders. J3D > > has imlementations of these that SHARE geometry. This means that for the > > first instance of the geometry, the coordinates for the geometry are > > created, and memory is consumed. After this, all subsequent instances of > > the geometry simply REFERENCE the original coordiinates, and MUCH memory > > can be saved here. HOWEVER, this partial solution (step 3 only) is NOT > > COMPATIBLE with steps 1 and 2. This is because I believe that step 3 here > > requires that the coordinates are shared, and that you must use transform > > groups to place each instance within the world. So you will get killed on > > transform groups here. > > > > Therefore, do steps 1 and 2. 3 is good if youre not getting killed on > > transform groups. > > > > Thoughts? > > > > Sorry for the length of this email, but I believe this is a good solution, > > and will work, without knowing the specifics of your project. > > > > > > Sincerely, > > Ian Nieves > > > > > > > > On Wed, 26 Feb 2003, Nitin.Jain wrote: > > > > > Florin, > > > > > > I'll give you an example which was posted few weeks back in this forum. > > This > > > gives the problem of memory in certain kind of scenegraph. > > > In this we are trying to create 'n' shape 3Ds with there individual TGs. > > > This is for a molecular viewer where the geometry(would be shared) will > be > > > spheres or cylinders. > > > > > > The scene graph looks like this: > > > > > > BG->TG(n numbers)->Shape3D(n numbers)(No Geometry or Appearance added) > > > > > > Note that each of the Shape3D was added to a TG and then the TG was > added > > to > > > the BG. So the BG has n TGs with a Shape3D in each. The following were > > the > > > results: > > > > > > n Memory Used (MB) > > > ====================== > > > 1000 3.7 > > > 2000 8.1 > > > 3000 12.5 > > > 28000 115 > > > > > > The above memory requirement is only for the empty shape3D objects and > the > > > geometry hasn't been attached yet, which makes the matter even worse. I > > > could not find ANY WAY TO REDUCE THIS MEMORY. In OpenGL I can do all > this > > > matrix manupulation at the rendering time. Or make my own TG object > which > > is > > > not as heavy as Java3D's TG. > > > > > > regs, > > > nitin > > > > > > I'm attaching the original post by Ranjan George on this > > > > > > >>>>>>>>>>>>>>>>>>>>>>>> > > > Hi All, > > > Been struggling with this issue for quite a while now. > > > Requirement: To be able to display a molecule using spheres (for atoms) > > and > > > cylinders (for bonds between the atoms) on the Canvas3D. The size of > the > > > molecule can range from 1000s of atoms to 10000s of atoms. Number of > > bonds > > > per atom can be averaged at 2 to 3 per atom. Am giving you these > figures > > so > > > that you have an idea as to how huge and complex the molecule can be. > > > > > > I need to be able to make this molecule display on a machine with a > basic > > > configuration of 128MB RAM. Hence I performed the profiling for the > > > following graph: > > > > > > BG->TG(n numbers)->Shape3D(n numbers)(No Geometry or Appearance added) > > > > > > Note that each of the Shape3D was added to a TG and then the TG was > added > > to > > > the BG. So the BG has n TGs with a Shape3D in each. The following were > > the > > > results: > > > > > > n Memory Used (MB) > > > ====================== > > > 1000 3.7 > > > 2000 8.1 > > > 3000 12.5 > > > 28000 115 > > > > > > The last one probably representing a molecule size of 7000 to 8000 atoms > > and > > > gives OutOfMemory exception unless I give the -Xmx option to the JVM. > > > NOTE THAT EVEN THE GEOMETRIES OR APPEARANCE HASNT BEEN ADDED AND I > CANNOT > > > SHARE SHAPES AS EACH ATOM MAY HAVE A DIFFERENT APPEARANCE. > > > Even with the -Xmx option the system becomes pathetically slow as memory > > is > > > used from the hard disk. > > > > > > How do I solve this problem and minimize my memory utilization?? Any > > > thoughts on the above will be most welcome as I have tried all sorts of > > > things. > > > > > > The root of the whole problem seems to be becos Java3D does not give an > > > option of working on persistant data and neither provides any interfaces > > > which allow you to enable it to do so. > > > > > > I know this is a long mail. Hope you have the patience to go through > it. > > > > > > Thanks in advance. > > > > > > Ranjan > > > > > > > > > =========================================================================== > > > 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". > > > > > > > > > > > =========================================================================== > > 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". > > > > > > =========================================================================== > 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". > > =========================================================================== 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".
