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