I am interested too for the source code ! ___________________________________________________
--- Brad Urani <[EMAIL PROTECTED]> wrote: > Can I see the source code for this? > > --- "Yazel, David J." <[EMAIL PROTECTED]> > wrote: > > When I said 6.6 million triangles it means that a > > terrain formed on our > > heightmap with no reduction would be 6.6 million > > triangles. Each of our > > heightmaps is 1280 x 1280. > > > > We do not use a behavior to wake up and load a > file. > > We have a thread that > > monitors your movement with respect to the > currently > > loaded quadtree. When > > we need to make a change, it usually involves > either > > splitting a larger quad > > into 4 or more smaller quads or combining back up > > the tree. So basically we > > recursively drop down through the tree and combine > > or split until we have > > fulfilled all the bounding policies. This then > > creates a list of nodes. We > > check this list against the "current" list. We > > build a scenegraph > > transaction. Into this transaction we place > > commands to detach all terrain > > patches we don't need, and to add all new patches. > > When we go to build the > > UpdateAddBranchGroup() transaction, we query the > > node for the branch group > > which we need to be loading. This in turn loads > the > > patch from our terrain > > paging system, builds the shapes, etc and puts > them > > in a branchgroup. So > > when we are done buildign the transaction we could > > have as little as 5 nodes > > (1 detatch and 4 addChild(), or 1 addChild() and 4 > > detach) up to as many as > > 40 changes. The larger sets of changes generally > > only happen when you make > > large jumps in space, since generally as you walk > > through the world it is > > constantly adjusting the quad tree to maintain the > > policies for the terrain. > > > > > > All our scenegraph changes are done as > transactions, > > which is just nothing > > more than a container holding a series of commands > > to be performed on the > > scenegraph. We place transactions on a queue > which > > is read on a single > > behavior and processed. The basic idea is that > all > > changes which must be > > done together to maintain the integrity of the > > scene. We throttle back the > > queue processing speed if the frame rate starts to > > drop. Because loading of > > the patches are done in another thread, and > because > > we yield the thread > > after loading each patch, there is not a large > > impact to the frame rate > > while building the transaction. > > > > > > Dave Yazel > > > > -----Original Message----- > > From: Lan Wu-Cavener [mailto:[EMAIL PROTECTED]] > > Sent: Wednesday, February 06, 2002 4:40 PM > > To: [EMAIL PROTECTED] > > Subject: Re: [JAVA3D] ROAM and GPU Usage > (off-topic) > > > > > > David: > > > > I am surprised to see your handling 6.6 million > > triangles. I can only have > > about 20,000 Shape3Ds in my scene and yet the > > performance is not good. I > > think that I probably should go for the preprocess > > approach. I know I am > > not dealing with terrain issue, but your approach > > gives me some new idea. I > > suppose that you have a behavior waken up every > > frame to check the viewer > > location and load file when it is necessary. > > > > It builds a render list of nodes which > > >*should* exist to fulfill the policies. This is > > passed to a controller that > > >compares it to the list of existing nodes. It > then > > builds a transaction > > >representing a series of attaches and detaches of > > the scene graph, and > > >requests the nodes to return their Shape3D's, the > > old branchgroups are > > >detached and get garbage collected, and the > unused > > children are then culled > > >from the tree. > > > > This part is done through J3D , isn't it? detach a > > big branchGroup takes a > > long time. How did you do to make it "not bad". > > > > Thank you for help me in switch node too! > > > > Lan Wu-Cavener > > Research Associate and Programmer > > Dept. of Landscape Architecture > > > > > =========================================================================== > > 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". > > > ===== > 3790 Colorado Ave. G Mobile: (303)641-8936 > Boulder, CO eFax: (305)723-2968 > 80303 [EMAIL PROTECTED] > > __________________________________________________ > Do You Yahoo!? > Send FREE Valentine eCards with Yahoo! Greetings! > http://greetings.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". __________________________________________________ Do You Yahoo!? Send FREE Valentine eCards with Yahoo! Greetings! http://greetings.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".
