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
[Flightgear-devel] Some community comments (was: Scenery Corner)
Hi Martin, I also find it rather interesting to read something about the 'invisible' work behind the scenery - thank you for letting us know. It's sometimes difficult to appreciate the work that is not directly seen, and it helps a lot if you tell us. Thanks for the hard work. However, there is one sentence in your descriptions which I did not like, because it expresses a sentiment which I do not like at all about the Flightgear community. Please let me take the time to explain. The sentence I mean is This sort of Scenery development is substantially different from craving for aaah's and oooh's on The Forum after you successfully managed to follow an elaborate and nicely illustrated recipe on how to build FlightGear Terrain. I don't know for a fact what you want to imply, but it reminds me of something for example Vivian expressed a while ago with regard to judging cockpits by visual detail. Vivian wrote: I would suggest that as such it has little value for a Flight Sim such as ours which values accuracy above all else. Bit of fun for the forum though. Let me now speak more to the audience at large, rather than to Martin personally... In both statements I read the following ideas (I don't know if you literally meant that - but that's what came across) * while the mailinglist is for real work, the forum is just for playing around * consequently, while the forum can be impressed by cheap tricks and eye candy, the 'real' development community cares about more important things such as accuracy Let me take a virtual needle and deflate the claims a bit. Until recently, Flightgear's idea of a weather change was that pressure, wind and visibility instantly jump from one value to another. Hardly what I would call accuracy. Doing it differently by means of an interpolation isn't even technically complicated (my 1/d weighted routine was 40 lines or so) or would require terrible computing power - there was just nobody sufficiently interested before 2.0.0 came out. Or, as Emmanuel Baranger has pointed out repeatedly, the fact the JSBSim planes can frequently land on water can hardly be called accurate. I could go on, but I think my point is clear - the Flightgear development community doesn't value accuracy as such, but each of you has some notion of where he would like to have more accuracy, and each of you has areas where he doesn't care about increased accuracy (for me, something like convective clouds behaving differently over water than over land is terribly important - having learned to fly gliders, I actually make use of the clues provided by the clouds... On the other hand, instruments not being precisely where they are in the original is not so important to me). So, by what argument can Vivian really claim that she values accuracy higher than I do, when she has been fine with throwing the physics of convective clouds out? I just can't see that any notion of accuracy is better than the other, and I think it's just plain wrong to think that way that one group of people likes accuracy and the other eye candy - visual detail is just another aspect of accuracy. So instead of alienating people who care about modelling, texturing, reflection shaders for exterior models and such things by referring to all that as 'fun for the forum', I think you'd be much better off by encouraging these people to improve the aspects they are interested in and kindly teaching them to value also the aspects which are important to you personally. Frankly, the elitist attitude expressed in such sentences bothers me. I feel much more welcome in the forum - and as a result I usually write much more of my observations, progress reports and ideas in the forum. I also usually get as good response as I get here. So if you only read the list, there's lots of info which you're missing. Doesn't have to bother anyone here - maybe it's just not interesting to you personally. But I think it's be way more useful to encourage people to help (there's plenty to do after all) than to regard them all as not seriously enough. So, now what happens - a few folks get involved, follow the elaborate and nicely illustrate recipe how to do things and actually produce scenery - to hear that what they do is just 'craving for aaah's and oooh's on The Forum', as opposed to 'the real thing'. Well - just how charming and encouraging is that? I happen to enjoy the custom France, custom Ireland and custom Eastern Europe sceneries. For me, an existing imperfect scenery is worth more than a non-existing perfect scenery which I may be able to use in the future. As far as I am concerned, the involved parties have earned their 'aahs and oohs' (so has Martin). So, I would prefer much if we could get around to respecting the work of others more - even if it's not what we are personally most interested. And to kindly teaching each other to appreciate the aspects of realism we value most, rather than considering anyone not sharing our personal
Re: [Flightgear-devel] Question about snow and rain norm property
Hi, Torsten, Thanks. This helped me. Since, with the fdm, the target is to identify the real time status of the terrain under, with snow-norm or with rain-norm and the target is to calculate the aircraft behavior against these parameters, If my understanding , about your idea, is right , it is better to use the newer properties /environment/barbaz. Thus, we don't mind if the values are fictive, coming from the user local customized weather, or real, coming from metar, or an intermediate value, due to the time-based interpolation controller, we only mind to use the ground simulation real time value at the aircraft simulation real time position. Doing that, i guess will avoid any difference in between , the visual on screen , and the calculated ground reaction. 2010/12/21 Torsten Dreyer tors...@t3r.de Hi, I just notice some modifications about the snow and rain norm property, which seems to be exposed twice. One place, in the /environment directory , which is new; and an other place in the /environment/metar directory , which is the old usable place. I am maintaining a lot of Aircraft, which are using these property ( snow and rain norm ) within the Aircraft JSBSIM FDM, ground reaction related. My question: right now, which place i must refer to ? the old one /environment/metar/rain or the new one /environment/rain or both, depending on , real weather in use, yes or no Won't it be better to get it exposed only once. The idea behind splitting these is to have the properties /environment/metar/foobar represent the weather as reported in the corresponding METAR and the properties /environment/barbaz represent the weather at you current position. These two are not necessarily the same. Currently, the values flow from /environment/metar to /environment with the time-based interpolation controller in $FGDATA/Environment/metarinterpolator.xml or any other environment controller, like the Local-Weather system from Thorsten Renk. Currently under development is to have more than one METAR report and be able to have lateral interpolation together with timed interpolation. These reports will live under /environment/metar[0], /environment/metar[1], etc. probably ordered by distance to current position. For the time being, you should be safe using snow and rain from /environment/metar but in the long run, you might have to think about which property to use: current position or at a certain airport. Hope this helps Torsten -- 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 -- Best regards, Henri, aka Alva Official grtux hangar maintainer -- 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
Re: [Flightgear-devel] Some community comments
Hi Thorsten, thorsten.i.r...@jyu.fi wrote: This sort of Scenery development is substantially different from craving for aaah's and oooh's on The Forum after you successfully managed to follow an elaborate and nicely illustrated recipe on how to build FlightGear Terrain. Hehe, I'm glad that I managed to catch at least one reader by putting this trap into my posting ;-) disregard - I'll post a serious response later, as soon as time permits. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- 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
Re: [Flightgear-devel] Some community comments (was: Scenery Corner)
Hi, First all, for some reason, i have been, only recently involved in the Flightgear life, though being an old user of flight simulators. I don't understand, that talk mailinglist versus forum. Each one can find easier to use one , or the other according to his feeling, or according to his resources (know how, computer, communication line ..). When reading both, i just noticed that there could be some stupidity said within the forum, which are the opportunity of long and sterile talk. Though, we can notice some debate, which are there, of a very high quality, unfortunately lost in the common recipient. Here, mailinglist, the talks and and questions are more selective and more accurate. Like Mr Spott said about his silent when is trying to achieve within the FlightGear project, the mailinglist population can be silent about the result. I f there is not any aaah's and oooh's that does not mean the user do not appreciate the quality. Thorsten, may i include some remark about your, here and there, answers. I can be wrong, and i can have misunderstood your mind, if yes, my apologizes. I do understand that you are positioning on the same range of quality, the eye candy, and, the realistic simulation and environment of an aircraft flight behavior. About model: There is a lot of aircraft ( too much) within flightgear which are eye candy perfect, with the full generic effect panoply stuff, unfortunately built with a crazy flight behavior making to laugh any user ( but young player ). Don't an unachieved Aircraft FDM which gives the priority to the flight specifications, and temporary do not process the behavior on ground (though i do not understand the Mr Baranger remark, you refer to), represents and promote the best of the flightgear potential ? Don't the first priority when making an Aircraft is to make a good fdm ? Don't the f16 or Lightning better than the f14 ? to me the answer is: the f14 is not the best one. Flight simulation does not mean special effect movie like. Or, we are talking something else,, which won't take place here. The higher range notation of any model must be first given to the flight behavior, the eye candy notation, is minor, only a packaging. About scenery: When i first got in touch with the Mr Spott 's scenery , i was impressed by the result, which is to me enough. Thus we can have an airborne over terrain which are not fictive. Yes better terrain profile and details ( for instance the st Marteen airport ) , are welcome, however, low details scenery is better than nothing, and i don't mind if i cannot find my house, or my preferred beach on the scenery. 2010/12/22 thorsten.i.r...@jyu.fi Hi Martin, I also find it rather interesting to read something about the 'invisible' work behind the scenery - thank you for letting us know. It's sometimes difficult to appreciate the work that is not directly seen, and it helps a lot if you tell us. Thanks for the hard work. However, there is one sentence in your descriptions which I did not like, because it expresses a sentiment which I do not like at all about the Flightgear community. Please let me take the time to explain. The sentence I mean is This sort of Scenery development is substantially different from craving for aaah's and oooh's on The Forum after you successfully managed to follow an elaborate and nicely illustrated recipe on how to build FlightGear Terrain. I don't know for a fact what you want to imply, but it reminds me of something for example Vivian expressed a while ago with regard to judging cockpits by visual detail. Vivian wrote: I would suggest that as such it has little value for a Flight Sim such as ours which values accuracy above all else. Bit of fun for the forum though. Let me now speak more to the audience at large, rather than to Martin personally... In both statements I read the following ideas (I don't know if you literally meant that - but that's what came across) * while the mailinglist is for real work, the forum is just for playing around * consequently, while the forum can be impressed by cheap tricks and eye candy, the 'real' development community cares about more important things such as accuracy Let me take a virtual needle and deflate the claims a bit. Until recently, Flightgear's idea of a weather change was that pressure, wind and visibility instantly jump from one value to another. Hardly what I would call accuracy. Doing it differently by means of an interpolation isn't even technically complicated (my 1/d weighted routine was 40 lines or so) or would require terrible computing power - there was just nobody sufficiently interested before 2.0.0 came out. Or, as Emmanuel Baranger has pointed out repeatedly, the fact the JSBSim planes can frequently land on water can hardly be called accurate. I could go on, but I think my point is clear - the Flightgear development community doesn't value accuracy as such, but
Re: [Flightgear-devel] Some community comments
To help put things in perspective, the people who are generating the beautiful scenery on the forum are using the same CORINE data set we are attempting to get into the scenery, and are using OSM roads, the license about which I am unsure. The advantage of this is we get to fly over higher quality land cover sooner than we otherwise would have, because we're also trying to get CORINE into the landcover database. However, with the exception of scenery models, no one is really developing anything new - just using existing data and programs to create the sceneries without much apparent thought to topology. This isn't bad as it gives us a larger, better area to fly through, and promotes scenery model creation. Still, none of the third party sceneries directly help the goal of adding data to the server or helping fix TerraGear to push out a new World Scenery package (and there will be a number of new places to explore in the next official version...) Cheers John -- 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] Some community comments
Hi Thorsten, thorsten.i.r...@jyu.fi wrote: Let me now speak more to the audience at large, rather than to Martin personally... In both statements I read the following ideas (I don't know if you literally meant that - but that's what came across) * while the mailinglist is for real work, the forum is just for playing around * consequently, while the forum can be impressed by cheap tricks and eye candy, the 'real' development community cares about more important things such as accuracy This is a rather incomplete and therefore, at least to my opinion, pretty unfortunate and unsuitable representation of a certain status quo. See, the mailing list is having a tradition of more then a decade for inter-developer-communication. It has not only survived my own familiarization with the FlightGear project but also quite a few other unfortunate side issues. List members - those who are often being pejoratively called the developers (mostly) by those who are not subscribed - have arranged themselves quite nicely with the list and, like myself, have established methods or tools which allow to gather much information in very little time. The FlightGear Web Forum is a completely different beast. I have to admit that I know just this single web forum from own experience, so my general understanding of web forums is quite limited. Anyway, here I'm referring to our forum only. To put it shortly: I've never ever seen any technically assisted communication channel where the cost-benefit ratio is as bad as on this forum - this isn't even surpassed by badly configured VoIP telephony systems So, where do you guess are you going to meet those who are primarily interested in efficient communication !? As a consequence, you'd rather likely meet a bigger fraction of those species on the forum who are driven by different intentions. It's easy as that. Let me take a virtual needle and deflate the claims a bit. Until recently, Flightgear's idea of a weather change was that pressure, wind and visibility instantly jump from one value to another. Hardly what I would call accuracy. [...] Sure, FlightGear is rather incomplete (the extent is always depending on the point of view). Every feature requires someone to implement it, every bug requires someone to fix it. Alleging that the developers don't understand the implications or don't care about them is pretty inappropriate. To pick your example up, I typically don't try to land a C172 on water, neither in FlightGear nor in real life. This doesn't imply that I'm accepting this bug/feature as good enough. In fact I _do_ feel annoyed that aircraft developers are forced to implement ugly hacks for seaplanes because the FDM doesn't properly handle this case (not sure if one of the FDM's is already having a consistent implementation of gear forces). On the other hand there are other topics which I'm concerned about much _more_ (aside from the substantial fact that FDM is not my domain). So do others. In consequence, the bug or feature remains unfixed until someone takes a stab at it. I could go on, but I think my point is clear - the Flightgear development community doesn't value accuracy as such, but each of you has some notion of where he would like to have more accuracy, [...] The entire debate about accuracy is moot as long as people not only take different measures but also refer to different definitions of accuracy. [...] So instead of alienating people who care about modelling, texturing, reflection shaders for exterior models and such things by referring to all that as 'fun for the forum', I think you'd be much better off by encouraging these people to improve the aspects they are interested in and kindly teaching them to value also the aspects which are important to you personally. Frankly, the elitist attitude expressed in such sentences bothers me. I feel much more welcome in the forum - and as a result I usually write much more of my observations, progress reports and ideas in the forum. I also usually get as good response as I get here. So if you only read the list, there's lots of info which you're missing. Been there, spent many, many hours on explaining the background behind the Scenemodels/MapServer efforts and finally left the forum after I realized that the not invented here attitude dramatically outperforms the idea of collaborating on a common goal (plus a couple of other reasons). So, now what happens - a few folks get involved, follow the elaborate and nicely illustrate recipe how to do things and actually produce scenery - to hear that what they do is just 'craving for aaah's and oooh's on The Forum', as opposed to 'the real thing'. Well - just how charming and encouraging is that? Being honest: I don't care. If people think that following a cooking recipe is their cup of tea, then I'm fine with it. If they call this Scenery development and behave like having reinvented the wheel, then
Re: [Flightgear-devel] Some community comments (was: Scenery Corner)
On Wed, Dec 22, 2010 at 11:03 AM, Thorsten Renk wrote: Let me take a virtual needle and deflate the claims a bit. Until recently, Flightgear's idea of a weather change was that pressure, wind and visibility instantly jump from one value to another. Hardly what I would call accuracy. Doing it differently by means of an interpolation isn't even technically complicated (my 1/d weighted routine was 40 lines or so) or would require terrible computing power - there was just nobody sufficiently interested before 2.0.0 came out. Sorry to be a pedant, but this isn't quite true. I implemented METAR weather interpolation prior to 2.0.0 in August 2007 using X-values. See git commit e1019eb359544e10811acdad6a7d61134b6af366 However, it's entirely possible that it was subsequently broken or you are talking about something else. -Stuart -- 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....
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] Some community comments
J. Holden wrote: [...] Still, none of the third party sceneries directly help the goal of adding data to the server or helping fix TerraGear to push out a new World Scenery package [...] Well said ! Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- 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] Some community comments
J. Holden wrote: [...] Still, none of the third party sceneries directly help the goal of adding data to the server or helping fix TerraGear to push out a new World Scenery package [...] Well said ! Martin. But increases the attractiveness of a whole project called FlightGear, as it shows that it is not difficult to make an attractive qualitity scenery for free, and enlarges the freedom of use to any users. -- 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] Some community comments
On Wed, Dec 22, 2010 at 1:39 PM, Martin Spott martin.sp...@mgras.net wrote: Being honest: I don't care. If people think that following a cooking And to be honest I don't understand why you started this discussion with such obvious trolling behavior and comments such as these? recipe is their cup of tea, then I'm fine with it. If they call this Scenery development and behave like having reinvented the wheel, then they're invited to reflect my comment. Now usually I just ignore you completely because I know from past experience are personalities don't mesh well, and I'll probably regret responding to you this time..but this is ridiculous. There are relatively few of us creating custom scenery from Corine and/or other data and making it available...I can seriously count them on one hand. Those few individuals, myself included, simply do not go around pretending we have reinvented the wheel or anything like that...nor are we looking for some ooh ahh factor. I personally am very open about what data I'm using, methods and tools I used, and have also made it quite clear on numerous occasions I'm not doing anything particulary noteworthy or new when it comes to generating the scenery from said data. We are simply trying to create the best scenery possible for ourselves and to the community at large ...to suggest otherwise is simply false. --Jacob -- 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] Some community comments
Hi Heiko, Heiko Schulz wrote: J. Holden wrote: [...] Still, none of the third party sceneries directly help the goal of adding data to the server or helping fix TerraGear to push out a new World Scenery package [...] Well said ! But increases the attractiveness of a whole project called FlightGear, [...] Depends on your very individual point of view. In contrast, I was confirmed that providing a seamless Terrain sounds quite appealing. Instead, having to assemble Scenery from a lot of different places if you're after a bigger chunk, especially if these chunks don't fit together properly, doesn't attract everyone. Neither does the public impression of why the hell does each of these fellows play in everyone's private sandboxes instead of collaborating on fixing their most pressing issues together. Anyhow I _do_ acknowledge a certain benefit for a certain 'type' of user, but I'd like to emphasize that this benefit doesn't necessarily scale to the entire (potential) user base. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- 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] Some community comments
Replying to Heiko: But increases the attractiveness of a whole project called FlightGear, as it shows that it is not difficult to make an attractive qualitity scenery for free, and enlarges the freedom of use to any users. I am not arguing that point - as I said the CORINE data is available to users before it is in the database, and that is fine. However, cleaning the data and placing the data into the database would be much more productive, as it would allow us to include the data in the world scenery release. Right now these are third party-only. I am in no way opposed to people creating third party scenery for FlightGear. However I believe there is a difference between, say, the Brest photoreal scenery, and the CORINE scenery, because we should be able to get CORINE scenery in the database for more than just France in the future, whereas I believe Brest is separate from the scenery package for licensing reasons? Cheers John -- 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] New release
It may not be an entirely good idea to release a FlightGear version without any usable ATIS. It appears that ATC/atis.cxx is a stub. It contains only one line of code. Meanwhile there is ye olde ATCDCL/atis.cxx, which contains code but is deprecated and is not compiled in the standard configuration. -- 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
[Flightgear-devel] EzineArticles.com
Hi there, I reported author 'Dan H Freeman' to that website as being misleading about his software and running a scam, explaining the situation with FlightGear and ProFlightSim. They asked if I was a 'representative' of FlightGear. I replied that I was a user of the software, but not deeply involved in the development/community as such. They then suggested that if the creators/operators of flightgear would like to contact them then please go ahead. So if anyone more entrenched in the development of fg would like to take up this offer to communicate with EzineArticles, regarding Dan H Freeman and his little enterprise, please let me know. I will forward the contact email address. The goal I suggested to EzineArticles would be to remove his articles from the site, due to the misleading nature of his business. I informed them of reports from people being ripped off by the scam, and about the use of mis-appropriated historical names on the websites and other immoral tactics being used, including the registration of the 'www.flightgear.us' domain. Regards, Chris Wilkinson, YBBN/BNE. -- 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] Some community comments
On Wed, 2010-12-22 at 23:16 +, Martin Spott wrote: Depends on your very individual point of view. In contrast, I was confirmed that providing a seamless Terrain sounds quite appealing. I agree completely with you on this issue. Instead, having to assemble Scenery from a lot of different places if you're after a bigger chunk, especially if these chunks don't fit together properly, doesn't attract everyone. Neither does the public impression of why the hell does each of these fellows play in everyone's private sandboxes instead of collaborating on fixing their most pressing issues together. Indeed. Here's why we played in our own sandboxes: I wanted to fly over my country with better looking scenery, and I damned well made it so. I was inspired by the custom France scenery and at the time I started to work on it I wasn't even aware of any similar project. Also, being a programmer myself and knowing how much I hate to write documentation, I made sure and documented every step of said process hoping it will be of some use to other potential developers. Initially I have found said scenery to be of subpar quality and only shared it with Emilian, a fellow countryman and developer of IAR80. However I have reached the conclusion that other users might want to fly over this particular chunk and shared it. I did not want in any way, shape or form to take the spotlight from your project, which I agree would be a better addition to Flightgear. Plus the fact that I used the same set of tools that you and the custom-scenery crew provides and without which it would have been impossible to generate any terrain. Anyhow I _do_ acknowledge a certain benefit for a certain 'type' of user, but I'd like to emphasize that this benefit doesn't necessarily scale to the entire (potential) user base. Where you see 'types' of users, I only see users. Most of these 'independently' developed scenery projects take advantage of OSM data, which is why they are released under CC by SA and also the reason they won't get integrated in the official distribution. However this does not mean that it is incompatible with Flightgear or that users can't enjoy it while waiting for a seamless integrated world terrain. I have only the highest expectations from your project, however in order to get many people involved and avoiding the same lone wolf approach, please use the wiki and provide more documentation and your experience to the community. Otherwise you will only see more 'flawed' terrain appear sooner rather than later. (this I might add is a characteristic of open development which should be regarded as it is rather than fought tooth and nail). Instead of endless discussions over this non-issue, time is better spent talking about the technical aspects involved in making Flightgear better. Best regards, Adrian Cheers, Martin. -- 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
