AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |
Back to Blog
Flightgear 3.4 world scenery2/9/2024 ![]() I mean, let's face it, even features like Rembrandt (which can safely be considered to be unmaintained these days.) still linger around in the codebase - the osgEarth branches have seen at least /some/ activity recently. to have a fallback scheme in place), would not be such a bad move. I don't disagree at all - while the main benefits/use-case of having photoscenery/osgEarth support in FlightGear may seem fairly narrow, or even disputable, (depending on your interests/focus), the recent mapserver/terrasync "developments" would at least suggest that supporting additional scenery schemes/engines, even if just to improve the redundancy in the scenery department (i.e. it is unlikely that Thorsten will be overly enthusiastic about Rembrandt, osgEarth, Python or even a 3rd party weather engine using HLA, given his own focus of involvement/contributions (ALS, EarthView, Nasal/Advanced Weather). ![]() However, to be fair, it does make sense to look at someone's background/expertise and nature of involvement - e.g. providing osgEarth as an /option/ in response to Martin's decision not to provide the underlying base data for seamlessly re-generating scenery, and the feelings seem to be mixed - pretty much for all the reasons that Thorsten mentioned already. (I've recently been in touch with other contributors about this specifically, i.e. If you are interested in photo-scenery, and if you are able to patch/rebuild FlightGear from source, there's not too much involved in giving it a try - rebasing onto next/master is a different issue, which will require some git/C++ knowledge, but otherwise it's not rocket science.Īs has been said, it will look great for /some/ situations, and it will have limitations in others - however, given the current state of affairs in the scenery department, it would probably not be a bad idea to consider providing osgEarth at least as an /option/ - just like FlightGear has other features that are mutually exclusive and that have different advantages and disadvantages (think Rembrandt vs. ![]() Since the patch/merge request was put up for review, many months have passed - and the corresponding developer did continue working on his code (see the gitlab repository for details), but poweroftwo has also stated that he'll be busy with other work, so that he won't have too much time that he can dedicate to going through the review process again. That being said, there's nothing wrong with treating it as a startup/runtime (or even build time) option so that people can make up their own minds whether they want to use/support or even develop it. Realistically, osgEarth/photo-scenery is mutually exclusive with quite a few other features. In fact, for the time being, osgEarth works basically like a "black box" and it would be tons of work to make that work with existing effects/shaders in FlightGear. In summary, the osgEarth patch is great for many things, but will not be overly useful for many use-cases that Thorsten (and Curt) mentioned in the past (see the devel list for details). Thorsten is basically right - however, even if there was a holistic plan in place to favor osgEarth/photoscenery-based scenery, that would not necessarily be very representative - for instance, at some point, most core developers were contemplating/expressing interest in making Rembrandt (deferred rendering) the default startup mode - equally, others wanted to enable effects/shaders by default (which would basically lock out most people without certain hardware, absent some form of dynamic feature scaling). Thorsten Posts: 12480 Joined: Mon 9:33 am So it would seem nobody is really interested enough in investing the work to make it happen. The optional implementation of OSGEarth has basically stalled because the person who has done it has never re-submitted the patch in response to a round of comments. If you think about it, you may come to the conclusion it's not that exciting. Right now we have a scheme in which we know for every pixel what the terrain is - we can make planes sink in water, skies slide over snow, simulate bumpiness when landing in the field, move motorbikes over roads, let clouds form over surfaces which heat up in the sun - why'd we want to replace that by a scheme in which all we get is colored pixels?īesides, photo-scenery looks good when you view it under the same conditions it was taken - in different light or weather you get all sorts of shadows which are out of place, dusty terrain while it is raining on it and similar visual mismatches. The developer community don't seem convinced that it's the way to go. ![]() How come, is it too big a file or something? ![]()
0 Comments
Read More
Leave a Reply. |