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".
