Hello, I understand how this can be accomplished if a user is given a lot of control over the scene graph during map/level creation, but what I'm aiming for is the ability to load in a .3ds model (or otherwise) for level geometry and let the user place various prefabs such as crates, trees, cars, etc into the world; then, the composite level is exported to a .lua script so that it can be loaded again with all of the static and dynamic objects intact. The issue is of course, that I cannot possibly compete with blender or 3dsMax as a modeling program, and I shouldn't attempt to either. The users of this engine should be able to use existing, non-proprietary modeling software to create levels or items for their game. I believe it would be too complex to implement an automatic or user-friendly way to disassemble an existing set of level geometry, only to re-assemble with parenting.
A certain degree of the parent/child culling you mentioned is already implemented. For example, multiple 'levels' can be laid out on a grid for on-the-fly level streaming--each level being a parent to the static and dynamic objects contained within them. But it would be -very- tedious for a level designer to heavily subdivide his or her model for culling purposes. Is there some way to use a 'precise' bounding box on a single node, that takes the level geometry's lowest LOD for occlusion culling operations? At least this would allow detail objects to be culled away if the camera was 'in' the level, as it usually is. Thanks for your time, Dusten On Fri, Nov 28, 2008 at 3:33 PM, Jean-Sébastien Guay < [EMAIL PROTECTED]> wrote: > Hello Dusten, > > From what I understand about OSG's implementation of occlusion culling >> however, this can't be accomplished with a single, large model used for the >> static world geometry--as the camera is always within the bounding box. >> > > OSG's culling is hierarchical, so if you organize your scene correctly this > will be done automatically. A very flat graph of large numbers of objects is > really bad, but a really deep graph is bad too, so you need to experiment. > > Say you're making a building, you could build a room, then parent all rooms > to form a floor, then parent all floors to form the building, then add the > outside walls. > > When the viewer is in a room, for example, OSG will start at the top of the > graph, see that the bounds of the building as a whole are in view, descend > into the floors, cull away any floors whose bounds are not in view, descend > into the others, cull away any rooms whose bounds are not in view, and > render just the rooms whose bounds are in view (which should hopefully be > just the room you're in). It will also cull away things that are behind the > viewer or outside their field of view, so walls and furniture behind you > will be culled away. > > Including your small objects into that hierarchy so that they're parented > to the right parent will lower draw times too. However, if you have a very > large number of small objects, you will want to cluster them below a common > Group parent, so that if the whole group's bounds are not visible then it > will be culled in one shot instead of testing each small object's bounds > individually. A symptom that indicates you should do that is if your cull > times are very high but your draw times are normal. How many small objects > to cluster together is a balancing act that you should experiment with, as > performance will depend on your hardware and the current bottleneck in your > pipeline. > > There has been lots said in the past about how to properly balance a scene > graph, have a look through the archives. In general, it's called > "conditioning" a scene graph, and a scene graph that is badly balanced is > also called "badly conditioned", so you might want to search on those terms. > > Hope this helps, > > J-S > -- > ______________________________________________________ > Jean-Sebastien Guay [EMAIL PROTECTED] > http://www.cm-labs.com/ > http://whitestar02.webhop.org/ > _______________________________________________ > osg-users mailing list > [email protected] > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org >
_______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
