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