Re: [Flightgear-devel] Regional textures merge request
Sorry for my impatience, but I think before one start to have tousands of custom scenery textures in fgdata we should discuss if such limited custom scenery changes makes sense to be in the (already heavy) fgdata repository. Okay, what would your answer to the following question be: 'We already have 400+ aircraft available, shouldn't we discuss if it makes any sense adding more aircraft to the already heavy fgdata repository?' The answer to the aircraft designers currently is 'Yes, keep adding, there is no restriction.' Why would scenery suddenly be a concern? I would think different if our problem were really thousands of people trying to commit their custom textures, but somehow I don't see that coming. I have been trying for years to get folks interested in texturing without any success, and if there are even 10 regional texture projects in the next years I will be surprised. So my prediction is that what will be added to scenery textures is actually less than what we can remove from FGData as obsolete weather textures, I don't see data size as a real concern here but the 'thousands of scenery textures' as a strawman argument. Also note that these are *not* custom scenery textures - they are regional textures for our default world scenery. This is not trying to by-pass a consistent world scenery, this is trying to support it. They're also not limited to a particular region - I've found that rice textures work nicely for irrigation in Hawaii for instance and European-agricultural patterns fit well my photos from the Caribbean. I may rot in custom scenery hell for what I write down here because I still have some kind of world scenery in mind ... Something I really fear meantime is a git-exploding texture folder in fgdata because of focus on better textures for small custom scenery projects. Again, regional textures are not custom scenery, they are a way to make world scenery richer. Yes, it's just as simple as this more or less useless comparison in this first post at the forums. The only thing that needs to be done here is improving landcover shapefiles to get more details, later changing some textures and materials.xml and providing a custom scenery project, trought whatever channel ... but when I look at this, why not being consistent and just go for detailed photo scenery at the end ? Looks wow all the time. (But once you will realize with photoscenery you're only flying at noon for the rest of your flightgear scenery life ;-) I beg to disagree. I never ever found any comparison of Flightgear with a real photograph useless. I often work for 2-3 hours trying to adjust parameters to reproduce a particular cloud scene just to see if it works theoretically and we have all relevant knobs in the code, or if there is something missing that should be added. But - why should the Caribbean be a custom scenery project? Is that now the stated design goal that people working on scenery should create their custom patches? As for photo-scenery, I guess your comment is somewhat skeptical? I think it's not feasible except for small areas because of sheer data size and license, and since I tend to work on solutions working for a larger scope, I didn't look into that. Here I will add a note to the concept of the transition shader I introduced a longer time ago. Stupid, but the idea was to have LESS texture files at the end to free resources. It was inspired by the idea of having natural structures, giving (transitional) patterns with different colour schemes, following water/clima/temperature or whatever parameters. *shrugs* You're talking to the guy who introduced a dust-cover into the shader to make dry desert areas more realistic in the current scheme. I don't think it's an either - or question, there are some things one can do better with a shader effect, and some which one can't. Shader code saves space on the harddisk, but takes a lot of framerate runtime - I'm guessing most people these days see framerate limits before harddisk limits, so it's easier to use a new texture for a complicated pattern than to create it in a shader. But simple patterns are rather limited - vertex altitude is about the only thing which you can use to introduce transition patterns, the rest you'd have to do with noise textures and such like. But personally I vote against having a big bunch of rural textures in a wow-fgdata for the moment. I would really like that new overall shader/texture concepts are tested and discussed well and gives proposals and roadmaps to all the scenery projects, eating less resources when possible. Otherwise I guess we will end up with a heavy archive of temporary custom scenery approaches. Again, the whole point of regional texturing is to make some regions of the world look more realistic without creating a private custom scenery project. I also don't understand why this should be seen as temporary? Scenery
Re: [Flightgear-devel] Regional textures merge request
On Wed, May 23, 2012 at 12:45 AM, Yves wrote: The GIS shapefile might be easy, but this will first need some new sg/fg and probably terragear code for such meta coverage. And more proposals, ideas and some kind of a scenery master plan. Using a GIS shapefile would simply be a case of some changes to simgear, materials.xml and a small shapefile checked into fgdata. I envisage something like the following syntax in the materials.xml file: shapefileworld.shp/shapefile regionNorthernEurope/region Simgear would simply check whether the tile lies within a polygon labeled with NorthernEurope in world.shp. Those developing regional texturing would need to use a simple shapefile editor (say QGIS) to draw a polygon that bounds the region for the material. In fact, we'd probably just need one shapefile defining the significant landmasses (Caribbean, Pacific, Northern Europe, Equatorial Africa). As Thorsten has already pointed out, this is really orthogonal to custom/world scenery, and is really about providing alternative ways to render the scenery data. I can understand your concern about increased texture sizes. Reducing the size of some of the regional textures is on my TODO list. I've avoided doing so thus far, as I wanted to fix the tiling at maximum resolution. -Stuart -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Regional textures merge request
On Tue, May 15, 2012 at 8:52 AM, Renk Thorsten wrote: Quick question to Stuart: Currently the conditionals for texture selection are done using /position/longitude-deg,... i.e. aircraft position. The actual tile position however is different from that by the visibility and an direction, which makes for some uncertainty. So, it'd be more consistent to place a condition on the position of the tile to be loaded rather than the aircraft - is that information exposed somewhere (or would it be difficult to do that)? Sorry for the delay in replying - I've been away. As Fred says, it would be possible, with some changes to the materials.xml format and the tile loader. However, I think we can do better. Martin Spott pointed out to me off-list that one could use a GIS shapefile to define a region. This would be much more flexible, allowing for non-rectangular areas to be defined. So, if we're going to change the tile loader, I'd want to go down that route instead. I doubt it would be too difficult, but as always it's a question of having enough time to do the coding. I'm probably going to have much reduced FG time for the next year or so, so I doubt I'll get around to it any time soon. -Stuart -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Regional textures merge request
On Tue, May 15, 2012 at 8:52 AM, Renk Thorsten wrote: Quick question to Stuart: Currently the conditionals for texture selection are done using /position/longitude-deg,... i.e. aircraft position. The actual tile position however is different from that by the visibility and an direction, which makes for some uncertainty. So, it'd be more consistent to place a condition on the position of the tile to be loaded rather than the aircraft - is that information exposed somewhere (or would it be difficult to do that)? Sorry for the delay in replying - I've been away. As Fred says, it would be possible, with some changes to the materials.xml format and the tile loader. However, I think we can do better. Martin Spott pointed out to me off-list that one could use a GIS shapefile to define a region. This would be much more flexible, allowing for non-rectangular areas to be defined. So, if we're going to change the tile loader, I'd want to go down that route instead. Hi Stuart Good point from Martin Spott off-list ;-) but anyway, has there ever been a proposal how this regions could be defined ? Is there a wiki, a readme or something ? I stumbled over an interesting system the last months, because I was looking for a landcover system with less inconsistency than corine or other systems ... and found a complete different approach which might be interesting for getting such materials/texture regions probably ? Not sure, but this could also lead to a new approach how to use textures at all with flightgear, but of course this is just a very vague assumption. LCCS is the only universally applicable classification system in operational use at present. It enables a comparison of land cover classes regardless of data source, economic sector or country. The LCCS method enhances the standardization process and minimizes the problem of dealing with a very large amount of pre-defined classes. Taken from here: http://www.glcn.org/sof_1_en.jsp Cheers, Yves -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Regional textures merge request
Hi Yves, flightg...@sablonier.ch wrote: Good point from Martin Spott off-list ;-) but anyway, has there ever been a proposal how this regions could be defined ? Is there a wiki, a readme or something ? Well, in case of doubt, a simple, easily maintained text list would serve the task of mapping country- or region-codes to the various texture sets. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Regional textures merge request
As Fred says, it would be possible, with some changes to the materials.xml format and the tile loader. However, I think we can do better. Martin Spott pointed out to me off-list that one could use a GIS shapefile to define a region. This would be much more flexible, allowing for non-rectangular areas to be defined. So, if we're going to change the tile loader, I'd want to go down that route instead. Well, I don't want to be greedy, I just wanted to know if it's trivial to do - what we have now is quite a bit better than what we had previously - it's just not perfect and still has some issues. But if that's how it stands, I'll create a merge request for my Hawaii project as it is (i.e. including the visibility-range dependent artefact generated by the transition from lush green to volcano red in shrub and tundra). I think it's still nice to fly Hawaii with the regional scheme. Hi Thorsten Sorry for my impatience, but I think before one start to have tousands of custom scenery textures in fgdata we should discuss if such limited custom scenery changes makes sense to be in the (already heavy) fgdata repository. What I like about conditioning on position is that it's simple - everyone can do it, and it already seems to inspire some to try to use the scheme: http://www.flightgear.org/forums/viewtopic.php?f=5t=16418 I may rot in custom scenery hell for what I write down here because I still have some kind of world scenery in mind ... Something I really fear meantime is a git-exploding texture folder in fgdata because of focus on better textures for small custom scenery projects. Yes, its just as simple as this more or less useless comparison in this first post at the forums. The only thing that needs to be done here is improving landcover shapefiles to get more details, later changing some textures and materials.xml and providing a custom scenery project, trought whatever channel ... but when I look at this, why not being consistent and just go for detailed photo scenery at the end ? Looks wow all the time. (But once you will realize with photoscenery youre only flying at noon for the rest of your flightgear scenery life ;-) I think that wouldn't be so easy with a GIS shapefile (I would not know how to start that way for instance). But if we ever move to a more faithful solution, e may have all the texture sets for various parts of the world already in place :-) - so we're not losing anything. The GIS shapefile might be easy, but this will first need some new sg/fg and probably terragear code for such meta coverage. And more proposals, ideas and some kind of a scenery master plan. Here I will add a note to the concept of the transition shader I introduced a longer time ago. Stupid, but the idea was to have LESS texture files at the end to free resources. It was inspired by the idea of having natural structures, giving (transitional) patterns with different colour schemes, following water/clima/temperature or whatever parameters. (The code for the texture/shader handling with transition shader was simply based on an idea of Tim Moore and an uncited/unknown contributor for the old but working crop shader). Parallel to the transition shader I had the idea for an improved texture system based completely on transitions, having a texture folder with some small structures and another with colour schemes, following some newly introduced meta-vegetation-parameters. Ok, I never finished this task because Im not able to introduce the new parameters to sg/fg code. But personally I vote against having a big bunch of rural textures in a wow-fgdata for the moment. I would really like that new overall shader/texture concepts are tested and discussed well and gives proposals and roadmaps to all the scenery projects, eating less resources when possible. Otherwise I guess we will end up with a heavy archive of temporary custom scenery approaches. Cheers, Yves -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Regional textures merge request
Quick question to Stuart: Currently the conditionals for texture selection are done using /position/longitude-deg,... i.e. aircraft position. The actual tile position however is different from that by the visibility and an direction, which makes for some uncertainty. So, it'd be more consistent to place a condition on the position of the tile to be loaded rather than the aircraft - is that information exposed somewhere (or would it be difficult to do that)? * Thorsten -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Regional textures merge request
Hi Thorsten, Quick question to Stuart: Currently the conditionals for texture selection are done using /position/longitude-deg,... i.e. aircraft position. The actual tile position however is different from that by the visibility and an direction, which makes for some uncertainty. So, it'd be more consistent to place a condition on the position of the tile to be loaded rather than the aircraft - is that information exposed somewhere (or would it be difficult to do that)? I suspect that special keywords in the format of the material file and a change in the tile loader are required to do that. Regards, -Fred -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Regional textures merge request
Stuart Snip ... It is possible to use the same scheme to change sea color (this is asked now and then in the forum), but that would produce sharp transitions which don't look very natural - I've cooked up a different scheme to smoothly change base (= for clear sky) sea color (which is then modified by the environment) which seems to be working just fine. All this needs is the following information # St. Maarten s = seaColorPoint.new(18.03, -63.11, 1.0,0.08, 0.40, 0.425); which is latitude, longitude, weight (in 1000 km), (rgb) - if the weight is 1, the declaration will be valid about 1000 km around the specified radius, if the weight is 0.1, it will be valid about 100 km, and so on. So please consider submitting any sea color information in this form rather than as a regional texture statement. I see/sea what you mean, having done a grep in Nasal/local_weather and found it in sea_colors.nas. Nice solution. Might be worth a note in the next newsletter to suggest that people submit sea colors. 50 years ago I joined the Royal Navy to see the world, and what did I see? I saw the sea. So far as I remember, it's mostly dark blue, apart from where the river outflows make it a muddy colour. Where the sea is deep (more than approx. 50m) it is pretty much the same everywhere. The Caribbean is not a light blue/green, apart from shallow water over sandy beaches. Of course there are phytoplankton blooms, but these are of a transient nature. This scheme introduces yet another for loop in Nasal, of undetermined size. This potentially introduces yet another source of stagger to FG, or it would if it worked, but as far as I can see it never runs here. Is it meant? Or do I need to do something to make it work? Nevertheless, perhaps it has promise in introducing muddy water. Vivian -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Regional textures merge request
This scheme introduces yet another for loop in Nasal, of undetermined size. This potentially introduces yet another source of stagger to FG, or it would if it worked, but as far as I can see it never runs here. Is it meant? Well, anticipating your reaction, yes, at this point it's meant not to run by default. It is an experimental feature which you get to see only when running Advanced Weather and lightfield shaders - meant as a proof of concept, borrowing the load-by-default structure of Advanced Weather. I wouldn't dream of sneaking any Nasal loop running by default into FGData, I know very well how that would be received. If the idea catches, I will bother to give it a separate on-demand control structure. Having said that, your argument about performance is actually rather far fetched. The loop runs every 5 seconds (!), in each loop iteration it updates the distance table for one single interpolation point (i.e. the loop performance consumption doesn't really increase even if you have 1000 interpolation points in there because I'm not doing 1000 distances per iteration, I'm doing one), so I seriously doubt you will ever be able to measure the performance footprint of the thing even if you try really hard. So, I don't think there's a good case against this apart from general dislike of Nasal solutions. Nevertheless, perhaps it has promise in introducing muddy water. It's an interpolation system. The output depends on the input - how to determine reasonable input is quite a different matter. My take on that is that, for whatever reason, I never got the impression that the North Sea ever looked like the Mediterrainean to me. So there is more to water color than just the reflected sky. In any case, having the possibility to change things runtime seems perferable to me over not having it. The scheme is certainly not completely realistic and also a bit simplistic - but it's more realistic than a constant water color everywhere, and it is so at the expense of one distance computation every 5 seconds (and sums which don't really count because basic arithmetics is dead-cheap to do). Cheers, * Thorsten -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Regional textures merge request
Thorsten This scheme introduces yet another for loop in Nasal, of undetermined size. This potentially introduces yet another source of stagger to FG, or it would if it worked, but as far as I can see it never runs here. Is it meant? Well, anticipating your reaction, yes, at this point it's meant not to run by default. It is an experimental feature which you get to see only when running Advanced Weather and lightfield shaders - meant as a proof of concept, borrowing the load-by-default structure of Advanced Weather. I wouldn't dream of sneaking any Nasal loop running by default into FGData, I know very well how that would be received. If the idea catches, I will bother to give it a separate on-demand control structure. Hmm I've got something wrong here then - if I understand that right I select Advanced Weather, and skydome and the sea colour stuff should run? I get this: http://dl.dropbox.com/u/57645542/fgfs-screen-190.png It doesn't seem to have any interpolation. Having said that, your argument about performance is actually rather far fetched. The loop runs every 5 seconds (!), in each loop iteration it updates the distance table for one single interpolation point (i.e. the loop performance consumption doesn't really increase even if you have 1000 interpolation points in there because I'm not doing 1000 distances per iteration, I'm doing one), so I seriously doubt you will ever be able to measure the performance footprint of the thing even if you try really hard. So, I don't think there's a good case against this apart from general dislike of Nasal solutions. I was thinking of this for loop for (var i = 0; i ivector_size; i = i + 1) I take the view that any for loop is not good, but if ivector_size is small, I guess it won't matter. I put a print statement inside this loop - and so far I've not seen it run. I also put print statements in the sea_color_loop, and one in init_sea_colors, but they don't run either. I'm definitely missing something here. Nevertheless, perhaps it has promise in introducing muddy water. It's an interpolation system. The output depends on the input - how to determine reasonable input is quite a different matter. My take on that is that, for whatever reason, I never got the impression that the North Sea ever looked like the Mediterrainean to me. So there is more to water color than just the reflected sky. In any case, having the possibility to change things runtime seems perferable to me over not having it. There are good sources for sea colour out there - here is one: http://oceancolor.gsfc.nasa.gov/FEATURE/IMAGES/A2008129125500.Scotland.png The Northern North Sea, away from the turbidity and major river outfalls of the Southern North Sea, is indistinguishable from the Atlantic, the other side of Scotland. There are many examples in this archive, and if there are differences in the deep ocean colour in any of the oceans they are darned hard to spot. Similarly, if there is a difference between the Atlantic and the Mediterranean, it's very hard to see. The scheme is certainly not completely realistic and also a bit simplistic - but it's more realistic than a constant water color everywhere, and it is so at the expense of one distance computation every 5 seconds (and sums which don't really count because basic arithmetics is dead-cheap to do). Whilst variations in the blue of the deep oceans is arguably not worth the effort, there are many regions where the deep ocean blue is not appropriate - the outflows of major rivers, the turbid shallower seas and so forth We can do muddy. Phytoplankton blooms! To difficult! Hope I can make this work soon Vivian -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Regional textures merge request
Hi Thorsten, I have a merge request adding an optional materials.xml definition with regional texturing here: https://gitorious.org/fg/fgdata/merge_requests/149 This is now checked in. Thanks very much for trail-blazing with these regionalized textures and the re-organized materials format. Do let me know if you think there's anything in the infrastructure that gets in the way, or you feel is inefficient. What I haven't done yet is to make use of the effects Adrian originally had included into his materials.xml, or to provide placement masks for the new textures. Also, some of the European textures have tiling problems and are really more suitable for hires custom scenery than for default scenery. I've checked it in unchanged, but I'm going to spend a little time - fixing the tiling issue - removing the American Football field in the town texture, which isn't really appropriate for Europe! - adding a placement mask - reducing the size of the textures - at the moment I think they are a bit too large - 9MB in some cases. The regional concept really is more powerful if people start contributing special textures from their part of the world. The idea and implementation is pretty easy - all exceptions go before the default declaration. An exception to the exception (say, specific Irish textures with a Europe declaration present) go in front of the less detailed. And so on. Basically, the first valid declaration is taken. Yes, I'm hoping that someone with an interest in the Caribbean will create some new materials for that region. With the random buildings feature they should also be able to create realistic towns with the characteristic orange or green roofing, plus some more appropriate tree textures. It is possible to use the same scheme to change sea color (this is asked now and then in the forum), but that would produce sharp transitions which don't look very natural - I've cooked up a different scheme to smoothly change base (= for clear sky) sea color (which is then modified by the environment) which seems to be working just fine. All this needs is the following information # St. Maarten s = seaColorPoint.new(18.03, -63.11, 1.0,0.08, 0.40, 0.425); which is latitude, longitude, weight (in 1000 km), (rgb) - if the weight is 1, the declaration will be valid about 1000 km around the specified radius, if the weight is 0.1, it will be valid about 100 km, and so on. So please consider submitting any sea color information in this form rather than as a regional texture statement. I see/sea what you mean, having done a grep in Nasal/local_weather and found it in sea_colors.nas. Nice solution. Might be worth a note in the next newsletter to suggest that people submit sea colors. -Stuart -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
