Re: [Flightgear-devel] Comments and questions about model loading, model formats, and effects....
On Thu, Dec 16, 2010 at 5:17 PM, Jacob Burbach jmburb...@gmail.com wrote: Ok then, trying to make sense of this whole model effects loading code... Good luck; it goes with the territory :) In `modellib.cxx' the `loadFile' and `loadModel' functions, which check the file extensions for a `.ac' file and if so sets a flag for instantiation of effects. This flags is only checked in the 'ACOptimizePolicy::optimize' method in `ModelRegistry.cxx' and appears it's only purpose is to make sure non xml wrapped `.ac' files get the default model effect applied. This is done by calling an overloaded `instantiateEffects' function in `model.hxx' that simply calls the other version of the function with an empty effects property tree causing default model effect to get used. Ok... The support for raw .ac models exists for the random models associated with materials, which I think are the only use of non-wrapped models in FG. Perhaps you can include them directly in scenery too. ... So here is the kicker...`instantiateEffects' does indeed seem to be called for every single model wrapped in an xml regardless of whatever format that might be. So then it seems the effect code is simply failing silently on non ac3d formats. Perhaps in the `MakeEffectVisitor' or further up the chain somewhere who knows...deeper down the rabbit hole we go... So umm Tim...could you maybe explain the process of the whole model loading, getting effects applied, what the effects system expects from a model, the reasoning behind it and so on? There is a lot of static local functions and classes and so on in this code that is completely undocumented and not at all trivial to unwind and try and fit the pieces together. Would be really, really helpful if you could lay out the code flow here, what functions are involved and inter-dependent on each other, what processing is needed for the effect system to work, etcin the mean time I'll keep digging. I'm not going to document the whole model loading process; it would be nice one day to have better comments in the code, but this code has accreted over many years, starting long before my involvement with FG. At a very high level, when a model is loaded, its OSG subgraph is copied, except for its textures and geometry. This is not-optimal, but it allows animation of all models without a complicated optimizer. In the monster function sgLoad3DModel_internal, effects mentioned in the .xml file are gathered, along with any created implicitly by animations. An effect is associated with named objects in the model. The .XML file can also specify a default effect for the whole file; by default that is Effects/model-default.eff. The model itself is transformed by instantiateEffects, which uses MakeEffectVisitor. For each named object in the model, this MakeEffectVisitor sets the appropriate effect as a parent effect, and then creates a new effect for any osg::StateSet found, inheriting from the parent. osg::Geode objects are replaced with simgear::EffectGeode objects that will apply the effect at runtime. There is quite a bit of hair to share effects and avoid creating new ones where possible. The dependency on .ac exists at this level in MakeEffectVisitor. The visitor expects to find osg::StateSet objects only in osg::Geode objects i.e., near the leaves of the scene graph. It only works with the simple attributes created by the .ac loader (see makeParametersFromStateSet): osg::Material properties, smooth vs. flat shading, polygon culling, blending (for transparency), and one texture binding. Any other attributes are ignored. If you want to apply effects to other kinds of models, you would need to generalize MakeEffectVisitor in both directions. StateSet objects can appear in any scene graph node and also in the Geometry nodes that sit below osg::Geode. A more general effects visitor needs to track the graphics state as it traverses the scene graph and also needs to examine the geometry. Effects sit at the Geode level. Alternatively you could ignore any state attributes in the model and specify it all in the .xml file, but this would quickly get tiresome. I recommend you use the osgconv program to dump out the .osg representation of our .ac models and the models that interest you and get an idea of the differences you are up against. For .ac you should use our Optimizer options found in ModelRegistry.cxx; you can set them with the OSG_OPTIMIZER environment variable. I'll try to write more comments in the code over the next few weeks. In the mean time, keep hitting me with questions. I don't have the bandwidth to answer basic OSG questions, but I think you are beyond that and I'll do my best :) Tim -- Forrester recently released a report on the Return on Investment (ROI) of Google Apps. They found a 300% ROI, 38%-56% cost savings, and break-even within 7 months. Over 3 million businesses have
Re: [Flightgear-devel] Comments and questions about model loading, model formats, and effects....
On Wed, Dec 22, 2010 at 4:34 PM, Jacob Burbach jmburb...@gmail.com wrote: Hey thanks for taking the time to respond, especially during the holidays. So what I see currently in the model loading code in regard to effects is really something just hacked together to 'get er done' and make it work. Which is fine of course, but I think we can do better and I Pretty much. really believe we can do this in a general fashion that should work for all model formats...but still allow specific processing if needed. I mean yes, each model loader may organize a models scene graph a bit differently...but the effects/material system is only concerned with state sets and geode/geometry for it's purpose. And OSG makes it very easy to drill down through a scene graph to find those particular things so there really shouldn't be a problem here. Not to say that it I think general state tracking over the OSG state graph is pretty messy, but if you want to have a go at at, great! will be trivial of course, but certainly doable. I'll be working on it when things settle down after the holidays and will of course be bouncing ideas and design stuff at you so we can find the best way to get it done and into flightgear. I recommend you use the osgconv program to dump out the .osg representation of our .ac models and the models that interest you and get an idea of the differences you are up against. Already been doing this, along with writing some code using OSG to load/texture my model and dump them out to see how I can define more advanced techniques in the model files. I currently have multiple models in my scenery in osg2 binary (.osgb) format making use of multiple texture units and texcoords, some texenv stuff, and also some very nice anisotropic filtering ;) Sounds good; that's an advantage of using OSG and it's rich model format support. Tim Of course it would be much better if I could make use of flightgears material system, interface with flightgear properties, and. cheers! -- Forrester recently released a report on the Return on Investment (ROI) of Google Apps. They found a 300% ROI, 38%-56% cost savings, and break-even within 7 months. Over 3 million businesses have gone Google with Google Apps: an online email calendar, and document program that's accessible from your browser. Read the Forrester report: http://p.sf.net/sfu/googleapps-sfnew ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Comments and questions about model loading, model formats, and effects....
Ok then, trying to make sense of this whole model effects loading code... In `modellib.cxx' the `loadFile' and `loadModel' functions, which check the file extensions for a `.ac' file and if so sets a flag for instantiation of effects. This flags is only checked in the 'ACOptimizePolicy::optimize' method in `ModelRegistry.cxx' and appears it's only purpose is to make sure non xml wrapped `.ac' files get the default model effect applied. This is done by calling an overloaded `instantiateEffects' function in `model.hxx' that simply calls the other version of the function with an empty effects property tree causing default model effect to get used. Ok... Now models wrapped in xml (and thus any model with an effect attached) of course don't get any flags set in the `load*' functions and go a whole different path...through `SGReaderWriterXML' and friends. So then `sgLoad3DModel_internal' from `SGReaderWriterXML' seems to handle most the heavy lifting of parsing the xml file including any `effects' elements, and then itself calls `instantiateEffects'. In this case though it calls the non overloaded version and passes in any effect properties it found...which if there were none again causes default model effect to get applied. Now, in this xml loading path any models loaded from inside it, `.ac' or otherwise, never find there way to the `load*' functions in `modellib.cxx' thus never getting the instantiate effect flag, thus ensuring that `ACOptimizePolicy' (which does still get called) doesn't call the overloaded `instantiateEffects' since xml loader will call the non overloaded itself. Phew.. So here is the kicker...`instantiateEffects' does indeed seem to be called for every single model wrapped in an xml regardless of whatever format that might be. So then it seems the effect code is simply failing silently on non ac3d formats. Perhaps in the `MakeEffectVisitor' or further up the chain somewhere who knows...deeper down the rabbit hole we go... So umm Tim...could you maybe explain the process of the whole model loading, getting effects applied, what the effects system expects from a model, the reasoning behind it and so on? There is a lot of static local functions and classes and so on in this code that is completely undocumented and not at all trivial to unwind and try and fit the pieces together. Would be really, really helpful if you could lay out the code flow here, what functions are involved and inter-dependent on each other, what processing is needed for the effect system to work, etcin the mean time I'll keep digging. cheers! --Jacob -- Lotusphere 2011 Register now for Lotusphere 2011 and learn how to connect the dots, take your collaborative environment to the next level, and enter the era of Social Business. http://p.sf.net/sfu/lotusphere-d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Comments and questions about model loading, model formats, and effects....
On Mon, Dec 13, 2010 at 1:26 AM, Tim Moore timoor...@gmail.com wrote: I wrote the effects framework and am interested in improving it, of course. I can't guarantee in advance that any particular work will be committed, so you should undertake any hacking to fulfill your own needs and not solely because you think it will be committed. I'm willing to help if you want to dive in. Tim Of course I won't expect you to commit to adding any code I write, sight unseen and untested. As long as I know there is support for the idea from those maintaining that code and no one is against it I'm comfortable putting in the time. The project(s) I'm working on are for the community though, meaning they are and will be distributed freely to all users...so of course the functionality would need to be a core part of flightgear to be at all useful. But yeah, don't expect you to totally commit to adding something that doesn't yet exist... The major project I'm working on at the moment is the custom scenery for Innsbruck. And by custom scenery I don't mean just some airport models and a few landmarks and putting them in the db. I'm talking about a full fledged, highly detailed, very complex and complete scenery package...roads, highways, power lines, entire villages and cities accurate to real life. Think along the lines of something you expect from a payware scenery add on in one of those other flight sims. A lofty goal yes, but I'm confident in my abilities to achieve it as time permits, and have already committed more than a year to get to the current point. However to achieve such a goal, on such a scale, I'm really having to work outside the box. The standard and accepted flightgear way of single objects in ac3d format submitted to the database just won't work for this type of project. I am designing and modeling very large static geometries that fit to the terrain accurately. While ac3d format works 'ok' for simple models and techniques...it does not scale well for very large and detailed objects. The file size alone is a drawback, along with export times, load timesand the fact it doesn't support basic things like multiple texture coordinates / texture units. So what I really need, and what would benefit flightgear as a whole in long term, is a fairly efficient binary format that supports such features. Of course we can already load these formats and use them, and I am as best I can, but they aren't fully supported by flightgear yet as they could be / need to be. The classic flightgear xml material animations for example doesn't know anything about multiple texture coords, texture units, and so on...so we need (and prefer anyway) the modern material effect and shader support system you've designed in order to use these formats and features properly. Well, I feel I'm rambling on a bit again, but I hope that it at least makes it somewhat clear what I'm trying to achieve and why, and why I need the functionality I'm looking for. You can check my Innsbruck thread in the scenery section of the forums if your interested in details, methods, techniques, and tools I'm exploring for this...or just ask. I'm willing to help if you want to dive in. Thanks Tim, I will be diving in so expect some questions and such in the near future. ;-) thanks...cheers! --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
Re: [Flightgear-devel] Comments and questions about model loading, model formats, and effects....
On Sat, Dec 11, 2010 at 9:56 PM, Jacob Burbach jmburb...@gmail.com wrote: This is considered a feature, by some anyway :) I added this with the idea that one could optimize ac model and substitute the optimized version. It's never been used much and has led to complaints about getting the wrong cows. I still think the idea is a reasonable one, but perhaps it needs to be removed in its current form. Personally I think it's better that if I specify a certain file to be loaded that it is honored, rather than having something trying to be clever and second guess me in the background. 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. Effects only work with .ac files because the code knows how to extract material parameters from the loaded representation of the .ac files. Those parameters are used by the default effects in the Effects folder. It should be possible to apply a complete effect with no missing parameters to a named object in a different kind of file, but I haven't tried it. Tim 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. whole point about all the osg loaders...to abstract that stuff away as much as possible. 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 cheers! -- 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 -- 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
Re: [Flightgear-devel] Comments and questions about model loading, model formats, and effects....
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 changesnot 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
Re: [Flightgear-devel] Comments and questions about model loading, model formats, and effects....
On Sun, Dec 12, 2010 at 9:21 AM, Jacob Burbach jmburb...@gmail.com wrote: I do agree it is important to use models and even file formats optimized for performance. I've used a commercial simulation that made heavy use of model optimization. In this case all model creation was done using openflight (.flt) and then at load time an optimized version was created in native performer format I believe. This worked well, largely because the optimized file format was exclusively different from the artist file format. (and significantly boosted model load speeds on subsequent runs.) Would it be possible to come up with our own optimized model extension that would be unique and different from anything an artist might produce? I could see this heading off into a lot of work though. We maybe would want a global flag that specifies if model optimization should be turned on / off. Saving an optimized version of every model could significantly increase the harddrive footprint of our data tree. Just thinking out loud here ... Curt. -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://www.flightgear.org/blogs/category/curt/http://www.flightgear.org/blogs/category/personal/curt/ -- 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
Re: [Flightgear-devel] Comments and questions about model loading, model formats, and effects....
On Sun, Dec 12, 2010 at 10:51 AM, Curtis Olson curtol...@gmail.com wrote: On Sun, Dec 12, 2010 at 9:21 AM, Jacob Burbach jmburb...@gmail.com wrote: Would it be possible to come up with our own optimized model extension that would be unique and different from anything an artist might produce? I could see this heading off into a lot of work though. We maybe would want a global flag that specifies if model optimization should be turned on / off. Saving an optimized version of every model could significantly increase the harddrive footprint of our data tree. Just thinking out loud here ... Curt. Also thinking out loud... First thing to do in my opinion would be to put the ac3d format to rest and focus on one single, feature rich, capable, and portable format for fgfs content creators to work with. I think collada is probably an obvious choice for this. Then... a) Load the collada (or whatever) file directly, automatically caching it to native format / global cache somewhere for reuse. The loader would then check the cache first to see if a file is already there and load it from there, if not or if the source file has changed reload it and (re)cache it. This has advantage that content creators could just work with one format and everything else happens automatically behind the scenes without need to think about it. This also has disadvantage that when a user first loads new content (aircraft, scenery, etc) performance will be bad that first time as you have to load unoptimized and large files and then cache them. There is also the problem of content that is removed, still existing in cached form, and the amount of disk space needed growing much larger as you now, in some form or another, have multiple versions of the file in question on your disk. b) Provide a fgfs converter tool that takes the collada (or whatever) file the content creator works with and creates the fgfs native format out of it which can then be used by flightgear. This has the advantage that your always loading the native optimized format, there is no worry about how to handle caching in the background, or large amounts of space used for the cache, or how to hand orphaned items in the cache..etc. Also by having the converter provide various options for the content creator to enable/disable etc one puts more power in the content creators hands which is usually a good thing. Couple disadvantages would be that; 1. content creators have to convert the stuff before using it or distributing it, and 2. that end users get a native format they can't modify directly. Number 1 is not really a huge deal at all though, and could be easily automated too. Number 2 is easily addressed by simply having the fgfs converter tool work in both directions. Run the converter on the collada (or whatever) and you get the fgfs native format for distribution, run the converter on the native file and converts back to the collada (or whatever) format for import into your content creation app of choice for editing. I kind of prefer option b, as I think it provides the most flexibility for artists, simplicity for the engine, and no worries about larges amounts of space used by a global cache or secondary files, etc. That said, anything like that sort of thing would obviously take a lot of planning, work, and time to complete. Even if it was decided to go in that direction for the future, I think it would be important to allow for other formats than ac3d to work properly with the material/effects system first, so we have some much needed ability and performance possibilities in the short term. cheers --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
Re: [Flightgear-devel] Comments and questions about model loading, model formats, and effects....
Well, just adding the .osgb extension in modellib.cxx is not enough to trigger effect loading for it...no surprise I guess that some extra processing is needed in other places as well. Hmm, having to reverse engineer a bunch of undocumented model and effects code in simgear, as well as also learning and tracking osg calls doesn't sound very productive. So if someone familiar with the model loading and effects system would be kind of enough to fill me on the general flow of how things are loaded, what's required to extend it for other formats, what the effects system needs to work proper with it and so on I would really really appreciate it. 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
Re: [Flightgear-devel] Comments and questions about model loading, model formats, and effects....
On Sun, Dec 12, 2010 at 4:21 PM, Jacob Burbach jmburb...@gmail.com wrote: 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. I wrote the effects framework and am interested in improving it, of course. I can't guarantee in advance that any particular work will be committed, so you should undertake any hacking to fulfill your own needs and not solely because you think it will be committed. I'm willing to help if you want to dive in. Tim 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 -- 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
[Flightgear-devel] Comments and questions about model loading, model formats, and effects....
Hi all, I'm experimenting with various model file formats and the effects system and have some questions/comments. First I found that if you have a file 'model.ac', but also have a file 'model.osg', flightgear always loads the .osg version despite me explicitly requesting the '.ac' in the models xml file. Personally I don't see any point in automatically choosing one text based format over another, especially when I explicitly told the system I want the '.ac' via the model xml. So yeah is this considered some sort of feature..or just a bug...because it only served to frustrate me and waste my time until I realized what it was doing. Second up is does the effect system not work with anything other than '.ac' file format? With '.ac' my effect is loaded, using any other format I tried (.osg, .ive , .osgb, .osgt) the effect seems to be ignored. Is the effect system currently crippled to using only the ac3d format, or what's going on here? cheers! -- 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
Re: [Flightgear-devel] Comments and questions about model loading, model formats, and effects....
On Sat, Dec 11, 2010 at 7:01 PM, Jacob Burbach jmburb...@gmail.com wrote: Hi all, I'm experimenting with various model file formats and the effects system and have some questions/comments. First I found that if you have a file 'model.ac', but also have a file 'model.osg', flightgear always loads the .osg version despite me explicitly requesting the '.ac' in the models xml file. Personally I don't see any point in automatically choosing one text based format over another, especially when I explicitly told the system I want the '.ac' via the model xml. So yeah is this considered some sort of feature..or just a bug...because it only served to frustrate me and waste my time until I realized what it was doing. This is considered a feature, by some anyway :) I added this with the idea that one could optimize ac model and substitute the optimized version. It's never been used much and has led to complaints about getting the wrong cows. I still think the idea is a reasonable one, but perhaps it needs to be removed in its current form. Second up is does the effect system not work with anything other than '.ac' file format? With '.ac' my effect is loaded, using any other format I tried (.osg, .ive , .osgb, .osgt) the effect seems to be ignored. Is the effect system currently crippled to using only the ac3d format, or what's going on here? Effects only work with .ac files because the code knows how to extract material parameters from the loaded representation of the .ac files. Those parameters are used by the default effects in the Effects folder. It should be possible to apply a complete effect with no missing parameters to a named object in a different kind of file, but I haven't tried it. Tim cheers! -- 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 -- 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
Re: [Flightgear-devel] Comments and questions about model loading, model formats, and effects....
This is considered a feature, by some anyway :) I added this with the idea that one could optimize ac model and substitute the optimized version. It's never been used much and has led to complaints about getting the wrong cows. I still think the idea is a reasonable one, but perhaps it needs to be removed in its current form. Personally I think it's better that if I specify a certain file to be loaded that it is honored, rather than having something trying to be clever and second guess me in the background. Effects only work with .ac files because the code knows how to extract material parameters from the loaded representation of the .ac files. Those parameters are used by the default effects in the Effects folder. It should be possible to apply a complete effect with no missing parameters to a named object in a different kind of file, but I haven't tried it. Tim 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 whole point about all the osg loaders...to abstract that stuff away as much as possible. 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. cheers! -- 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
