This has been an incredibly helpful response. Thanks a ton :)
On Mon, Dec 1, 2008 at 8:12 AM, Jean-Sébastien Guay < [EMAIL PROTECTED]> wrote: > Hello Dusten, > > 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. >> > > You just need to use a modeling tool and format which understand hierarchy, > and then use that. Many formats which normal modeling tools export support > this: COLLADA, OpenFlight, etc. Plus, there are plugins for both 3DSMax and > Blender (among others) to export to .osg directly. > > If you need anything else, you need to code it yourself, which shouldn't be > that complicated. Here we have a system which loads and interprets scripts > as you describe, plus it includes physical properties (we develop and sell a > physics engine after all :-) ), viewer configuration, input device > configuration, etc. > > Of course, once again the ability to do view frustum culling properly still > hinges on the grouping of close-by objects and a well-conditioned scene > graph, and at this point it's up to your loader to build the scene graph in > a way that will be close to optimal. You can give hints in your scripting > files for this (such as group names, where each object whose group name is > the same will be grouped together, or a radius + number of objects scheme, > where objects which are close by within a certain radius will be grouped > together up to a given number of objects). > > 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 totally agree with this. However, slight retraining for the realities of > real-time graphics is often necessary. Why do you think the 3D > artist/multimedia schools have different classes for game modeling and > fx/film modeling? Both have different tradeoffs and the modeler must keep > different things in mind while doing his job. (same goes for texture artist, > lighting artist, etc. when those positions are occupied by different people) > > 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. >> > > Not only is it not too complex, you don't have any choice. It's up to you > to provide OSG with a well-formed scene graph. If you don't, you probably > won't get great performance. Modeling tools by default make flat > hierarchies, but in both 3DSMax and Blender IIRC (and Maya, Softimage XSI, > etc. too, and of course Creator) there is a view which allows the modeler to > rearrange the hierarchy. Using this, along with a format which can export > the hierarchy properly will save you a lot of time trying to do the same > programmatically. > > But it would be -very- tedious for a level designer to heavily subdivide >> his or her model for culling purposes. >> > > It's not that tedious, and I didn't say you need to heavily subdivide. Just > keep the hierarchy in mind when building the levels, and do a rough > grouping. You will see large performance gains. > > 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. >> > > I'm not aware of anything in OSG to automatically build occlusion volumes > (from anything, not just from the lowest LOD), but then again I have never > used occlusion culling in OSG myself, so others may be better placed to > inform you on this. > > If you want my advice, start with making OSG's view frustum culling job > easier, that's the simplest to implement and will already get you massive > gains. > > > Hope this helps, > > J-S > -- > ______________________________________________________ > Jean-Sebastien Guay [EMAIL PROTECTED] > http://www.cm-labs.com/ > http://whitestar02.webhop.org/ > _______________________________________________ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org >
_______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
