Hi Ian and Florin, This problem of when and when not to use TGs was examined by Chien and and to some extent by me sometime last year IIRC. I think it is a compromise and mostly app. specific. Chien gave the useful stat. that TG + Shape3D takes ~3.6K (off the top of my head).
http://swjscmail1.java.sun.com/cgi-bin/wa?A2=ind0204&L=java3d-interest&P=R7684&D=1&O=D&m=29246 http://swjscmail1.java.sun.com/cgi-bin/wa?A2=ind0204&L=java3d-interest&P=R15076&D=1&H=0&O=D&T=1&m=29246 Rgds Raj Vaidya >On Wed, 26 Feb 2003 07:23:33 -0500, Ian M Nieves <[EMAIL PROTECTED]> >wrote: >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". ==========================================================================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".
