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