On Sun, Dec 12, 2010 at 5:50 AM, Tim Moore <timoor...@gmail.com> wrote: > That depends on whether you view fgfs as a model preview tool or as a > real-time program. I don't mean to be snarky in saying that; as hardware > improves, the balance between what should be done before runtime and what > can be done at model load time changes. But I think you can see that, for > optimal real-time performance, it would be best to load an optimized form > of a model. I do agree it is important to use models and even file formats optimized for performance. I believe however, that those optimizations should be done in the content creation suite itself and/or when exporting the model to its final format used in engine. Not to say the engine couldn't try to do some extra optimization after loading a model, and even cache that loaded data somewhere for reuse, say a fast binary cache for example. However it should always load the artist specified file first, and reload / recache it any time that source file changes....not just arbitrarily pick a different file behind the scenes.
I don't mean to be overly critical or put down someones hard work or anything, but you said yourself it was a feature rarely used and often complained about. >> Damn, was hoping I was just doing something wrong...I really need >> this. I think we should at the very least support OSG native formats >> (osg,ive,osgb,osgt). But really, shouldn't we get be reading the >> pertinent data from OSG interfaces after the plugin has loaded it up, >> rather than doing file specific stuff at all? I thought that was the > > Yes, and of course we do that. .ac is a very simple format, so it is easy > to walk the graph of a loaded .ac file and extract the material and texture > bindings. This becomes much harder as you move to the general OSG formats, > as these bindings could be anywhere in the scene graph, above or below the > named objects. .osg files can even contain their own "effects" in the form > of shader programs or osgFX nodes. Of course it's probably not just a simple task, and I didn't mean to try and trivialize it by just saying 'use osg' data. I do believe it is quite important for content creators to have access to smaller, faster, and more capable (preferably binary) file formats. The ac3d file is nice that it's simple and human readable and so on, but it's also very a limited format, and does not scale well at all with more complex and larger models and techniques. >> So what can I do to help move this along? I do really need it for my >> projects as the ac3d format just doesn't cut it for me. >> > Look at the source in simgear/scene/model, find where it looks for .ac > files, and change it. modellib.cxx:143, for example. > Tim Will do. I take it your the maintainer/creator of this particular bit of code then? I feel this is very important for the future of fgfs graphics and performance wise and I'm quite willing to put in some work to make it happen. I do need to know there is support for this idea to be rolled into fgfs though, that I won't be wasting my time for something that won't be used...or not receive any support on. thanks! --Jacob ------------------------------------------------------------------------------ Oracle to DB2 Conversion Guide: Learn learn about native support for PL/SQL, new data types, scalar functions, improved concurrency, built-in packages, OCI, SQL*Plus, data movement tools, best practices and more. http://p.sf.net/sfu/oracle-sfdev2dev _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
