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 times....and 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
