These are some very good suggestions and they should be very easy to make some changes to check this out. We already "quiesce" the nodes, but we don't have to detach them, we can just set their valid vertex size to 0. This should be most efficient. We do compute the bounds ourselves for each shape and have always benefitted from the culling we get on the patches, so I think I will continue with that for now.
I must say that I think my team is a bit tired of my obsession with terrain :) It has gotten so I don't even like to mention terrain improvements on our weekly conference call. But we are working toward the goal of expanding from our test world to a production size world of 250,000 km and you need a real killer terrain system to handle that. BTW I do plan on pulling out and packaging the terrain stuff for donation to j3d.org at some point. I have been corresponding with Thatcher Ulrich (a real terrain genius IMHO and author of various chapters in Game Programming Gems) for over a year now, since we are using an evolved version of his adaptive quad trees. One particularly nasty problem was how to make sure that the adaptive tree did not decide to create triangles spanning a quad patch. We found that by falsly inflating the error metric for those vertices we could "protect" them from collapse and force seamless breaks between patches. Another improvement we have made is to allow different densities of sampling at different parts of the tree. This is different than the tree update which decides what triangles to render based on a "distance from view based error metric". The tree can only operate on what data it has been given, but it is possible to give it a point every 128 meters for very far away terrain. It is also possible to give it data at a meter or less resolution where needed (stream banks are very hard to do without this). Since all our terrain is calculated with layers of fractals we can dynamically sample where needed. Dave -----Original Message----- From: Justin Couch [mailto:[EMAIL PROTECTED]] Sent: Thursday, September 05, 2002 1:46 PM To: [EMAIL PROTECTED] Subject: Re: [JAVA3D] Elimination of pauses when inserting branchgroups Yazel, David J. wrote: > 1. Textures are loaded in a seperate thread. The pauses is not during this > time. > 2. The textures are by-ref > 3. The geometry for each patch is by-ref, infrequent > 4. Garbage collection is at a minimum, we are using pools and caches for > most heavyweight objects. > 5. The pactches are reused. When patches are removed they are placed into a > cache. When we need a new patch we get one from the cache, update the > texture and update the geometry. I think this is where you are going wrong. Adding and removing BranchGroups is a bad thing to do. The more you can keep the basic scene graph static in structure, the better. Many years ago we did a lot of benchmarking of various functions in Java3D. Add/remove of branchgroups was a really costly exercise, particularly compared to geometry. Although this was with J3D 1.1, the rough guide should still be valid. We found that branchgroup manipulation was roughly exponential in costs as you added more to the scene (it might be O(n^2) or something like that, but it certainly was not linear). Just adding and removing raw GeometryArrays was close to linear (NlogN IIRC). This, however, was before the GeometryUpdater interfaces became available. Given the current state of Java3D, it would be a fair assumption to say that the most efficient implementation is to decide on what you need for a static structure and then just use geometryUpdaters to maintain the visible geometry. In my ROAM code, we build the BranchGroups and Shape3D's once at the startup. After that, as the user wanders through the dataset, we just use the GeometryUpdater to control the visible geometry. If we find that we have too many patches for what needs to be displayed, we just set the validVertexCount to zero for that GeometryArray. That then goes into the the cache (but is never removed from the scenegraph) of available geometry so that if we have to shift in extra detail, we just pull it out and set the vertex count again. The advantage of doing this is that it allows you to also do deformable terrain with minimal cost too as you're already updating the vertices close to every frame. The reasons (that I can work out anyway) that this is more efficient is the way Java3D is setting up its internal culling. Each time you change the scene graph structure through the branchgroups, Java3D has to go through and recompute the bounds of the objects, not only your new stuff, but also the parent graph of where it has been added to. It has to add the structures to the render/cull queues and so on. However, by just working on the geometry, you avoid a lot of this unnecessary computation. This is particularly relevant if you can help the system along by setting explicit bounding boxes. Now there is no need to recalculate the bounds, just every frame during the culling pass the code works out that there are no valid vertices and skips the geometry without the need to do any other recalculations. There is a small extra cost of having to traverse into the valid bounding box area, but that is less than the overall system requirements from the BG handling and I doubt it makes significant impact in the overall scheme of things. -- Justin Couch http://www.vlc.com.au/~justin/ Java Architect & Bit Twiddler http://www.yumetech.com/ Author, Java 3D FAQ Maintainer http://www.j3d.org/ ------------------------------------------------------------------- "Humanism is dead. Animals think, feel; so do machines now. Neither man nor woman is the measure of all things. Every organism processes data according to its domain, its environment; you, with all your brains, would be useless in a mouse's universe..." - Greg Bear, Slant ------------------------------------------------------------------- =========================================================================== 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".
