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
[Flightgear-devel] FGData and GIT...sans aircraft
Hey everyone, I need some help or at least some input here. Until now, I've kept my FGData folder up-to-date by vising the mapserver, checking the changelogs and manually downloading snapshots of subfolders. This is hardly convienient, but necessary, since I don't have disk space available for the aircraft. So what can be done about this? Can I... ...set up my own clone of the current master GIT branch and regularly merge the regular master one with it (without the aircraft folder, of course)? It would enable me to simply pull my clone via script/console command. ...download folders selectively with wget? I've tried this with wget and the download links supplied by the snapshot function, but all I get is a HTML file. I also think the header-UIDs of the folders (ex. h=c43152b3e8029be60c51b3e9efc1fc39211918ad) vary, so setting up a permanent, automated solution (via bash script) would require obtaining the current headers beforehand...provided that a wget-based download works in the first place. Other ideas? Buying a bigger HDD is out of the question for me. And I don't want to kick off that split fgdata and aircraft debate again (as it will surely lead nowhere). Regards, Björn -- 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
