Re: [Flightgear-devel] [Flightgear-commitlogs] FlightGear Base Package branch, master, updated. b0fd1613629ccb89622e3e268588ee69498263dc
On 22 Apr 2012, at 03:14, Flightgear-commitlogs wrote: Bravo updates.changed map range select;property-cycle too buggy Something to be fixed here? (In a backwards compatible way...) James -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Water shader issues
After the last related discussion, I've really been thinking a while if I should bring this up again or not. I don't want to annoy people just for the sake of it, I know open source development is often a thankless task in which one frequently gets to hear more complaints about things not working than thanks for things working, and all in all I perfer a pleasant atmosphere on the mailing list, and critique of someone's code tends to lead to the opposite. But then, we had a performance discussion, and I had my share of criticism about my use of Nasal slowing things down, and in the end it's information which is better transmitted than not. Let me nevertheless start off by thanking all the people who worked on the shader codes I've been looking at - I learned a lot about how this is done and what can be done by just taking things apart and putting it back together again, I have often enjoyed the effects before starting to mess with shaders myself, and I guess many others also do. I've been over the water sine wave shader again, seeing if I could make run it faster. What I found reminded me of something I (mean-spirited as I am) did to a PhD student starting to work for me. I asked him to write a code evaluating a quantum mechanical scattering process. He did so using an established general-purpose Monte Carlo integral solver. I wrote a code for the same problem, we compared the results and they were the same, so we did solve the same problem and had the same solution - just my code was 100 times faster. Afterwards, he was ready to accept that he can learn from me how to code physics properly. That miracle was accomplished by me telling the integral solver where performance is needed and where not (technically, this involves using an a priori suitably biased sampling distribution, which after the fact gets corrected by conditional probability calculus - which can be proven to work, but looks like black magic). To give a very simple simple example, if we want to evaluate r^2 pi and know r^2 with an accuracy of 10%, it isn't really a good strategy to spend an hour to calculate a billion digits of pi. It requires to understand the problem and not use all-purpose, but specially designed problem-solving strategies. The same accuracy statement is true of the shaders by the way - so far all I have seen use the Blinn–Phong shading model, so it's completely useless to aim for an accuracy beyond what that can deliver, because Blinn-Phong is already an approximation which limits the precision that can be achieved. Now, it struck me that the water shader computes wave patterns and foam on a meter-scale. It does so even for a pixel which is 120 km distant (and which probably represents an area of 100x400 m or so). We first calculate a very detailed wave pattern and foam for that pixel, then let the renderer average everything out again to give the pixel a color. That didn't strike me as a particularly efficient way to do things. I replaced the wave pattern in the distance by something that averages to the same thing. That's not the average wave pattern (=a flat surface) because reflected light intensity is a non-linear function of the surface distortion, but noise with the right amplitude, leading to the same standard deviation and the same average, gets the job done. I also asked not to compute any foam beyond some other distance. As a result, the shader performance jumped from 30 fps to 42 fps in a benchmark situation (ufo at 30.000 ft looking at the horizon, 120 km visibility range). In general, how much performance one spends on distant stuff doesn't influence the visuals drastically, because these pixels are more and more fogged and more and more details are averaged out. But more than 80% of the vertices in the scene are farther than half the visibility range, and a fair share of pixels is, and that's the stuff you see from a typical cockpit perspective. So in terms of performance, simplifying the rendering of distant objects counts a lot. I have spent 30 minutes testing the visual impression of my changes in different winds, in different light and from different altitudes, and I could not spot any problem - the shader just ran faster. Despite this, it's possible that there is a problematic situation somewhere. But the answer to this should not be to revert the changes, the proper answer should be to code an exception dealing with the particular problem. I did not get the impression that there was so far any attempt made to optimize the performance of the water sine shader. It's difficult to compare directly since I added the whole terrain haze and lightfield rendering, but I suspect that if all I did (remove redundant operations, throw per-frame constant computations out of the shader, do not use textures to sample constant colors, do not interpolate the normal of water, do simplified rendering for large distances,...) would be applied to the
Re: [Flightgear-devel] Water shader issues
On Sunday 22 April 2012 11:02:46 Renk Thorsten wrote: After the last related discussion, I've really been thinking a while if I should bring this up again or not. I don't want to annoy people just for the sake of it, I know open source development is often a thankless task in which one frequently gets to hear more complaints about things not working than thanks for things working, and all in all I perfer a pleasant atmosphere on the mailing list, and critique of someone's code tends to lead to the opposite. But then, we had a performance discussion, and I had my share of criticism about my use of Nasal slowing things down, and in the end it's information which is better transmitted than not. Let me nevertheless start off by thanking all the people who worked on the shader codes I've been looking at - I learned a lot about how this is done and what can be done by just taking things apart and putting it back together again, I have often enjoyed the effects before starting to mess with shaders myself, and I guess many others also do. I've been over the water sine wave shader again, seeing if I could make run it faster. What I found reminded me of something I (mean-spirited as I am) did to a PhD student starting to work for me. I asked him to write a code evaluating a quantum mechanical scattering process. He did so using an established general-purpose Monte Carlo integral solver. I wrote a code for the same problem, we compared the results and they were the same, so we did solve the same problem and had the same solution - just my code was 100 times faster. Afterwards, he was ready to accept that he can learn from me how to code physics properly. That miracle was accomplished by me telling the integral solver where performance is needed and where not (technically, this involves using an a priori suitably biased sampling distribution, which after the fact gets corrected by conditional probability calculus - which can be proven to work, but looks like black magic). To give a very simple simple example, if we want to evaluate r^2 pi and know r^2 with an accuracy of 10%, it isn't really a good strategy to spend an hour to calculate a billion digits of pi. It requires to understand the problem and not use all-purpose, but specially designed problem-solving strategies. The same accuracy statement is true of the shaders by the way - so far all I have seen use the Blinn–Phong shading model, so it's completely useless to aim for an accuracy beyond what that can deliver, because Blinn-Phong is already an approximation which limits the precision that can be achieved. Now, it struck me that the water shader computes wave patterns and foam on a meter-scale. It does so even for a pixel which is 120 km distant (and which probably represents an area of 100x400 m or so). We first calculate a very detailed wave pattern and foam for that pixel, then let the renderer average everything out again to give the pixel a color. That didn't strike me as a particularly efficient way to do things. I replaced the wave pattern in the distance by something that averages to the same thing. That's not the average wave pattern (=a flat surface) because reflected light intensity is a non-linear function of the surface distortion, but noise with the right amplitude, leading to the same standard deviation and the same average, gets the job done. I also asked not to compute any foam beyond some other distance. As a result, the shader performance jumped from 30 fps to 42 fps in a benchmark situation (ufo at 30.000 ft looking at the horizon, 120 km visibility range). In general, how much performance one spends on distant stuff doesn't influence the visuals drastically, because these pixels are more and more fogged and more and more details are averaged out. But more than 80% of the vertices in the scene are farther than half the visibility range, and a fair share of pixels is, and that's the stuff you see from a typical cockpit perspective. So in terms of performance, simplifying the rendering of distant objects counts a lot. I have spent 30 minutes testing the visual impression of my changes in different winds, in different light and from different altitudes, and I could not spot any problem - the shader just ran faster. Despite this, it's possible that there is a problematic situation somewhere. But the answer to this should not be to revert the changes, the proper answer should be to code an exception dealing with the particular problem. I did not get the impression that there was so far any attempt made to optimize the performance of the water sine shader. It's difficult to compare directly since I added the whole terrain haze and lightfield rendering, but I suspect that if all I did (remove redundant operations, throw per-frame constant computations out of the shader, do not use textures to sample constant colors, do not interpolate the normal of water,
Re: [Flightgear-devel] Water shader issues
2012/4/22 Renk Thorsten thorsten.i.r...@jyu.fi: After the last related discussion, I've really been thinking a while if I should bring this up again or not. I don't want to annoy people just for the sake of it, I know open source development is often a thankless task in which one frequently gets to hear more complaints about things not working than thanks for things working, and all in all I perfer a pleasant atmosphere on the mailing list, and critique of someone's code tends to lead to the opposite. But then, we had a performance discussion, and I had my share of criticism about my use of Nasal slowing things down, and in the end it's information which is better transmitted than not. Let me nevertheless start off by thanking all the people who worked on the shader codes I've been looking at - I learned a lot about how this is done and what can be done by just taking things apart and putting it back together again, I have often enjoyed the effects before starting to mess with shaders myself, and I guess many others also do. I've been over the water sine wave shader again, seeing if I could make run it faster. What I found reminded me of something I (mean-spirited as I am) did to a PhD student starting to work for me. I asked him to write a code evaluating a quantum mechanical scattering process. He did so using an established general-purpose Monte Carlo integral solver. I wrote a code for the same problem, we compared the results and they were the same, so we did solve the same problem and had the same solution - just my code was 100 times faster. Afterwards, he was ready to accept that he can learn from me how to code physics properly. That miracle was accomplished by me telling the integral solver where performance is needed and where not (technically, this involves using an a priori suitably biased sampling distribution, which after the fact gets corrected by conditional probability calculus - which can be proven to work, but looks like black magic). To give a very simple simple example, if we want to evaluate r^2 pi and know r^2 with an accuracy of 10%, it isn't really a good strategy to spend an hour to calculate a billion digits of pi. It requires to understand the problem and not use all-purpose, but specially designed problem-solving strategies. The same accuracy statement is true of the shaders by the way - so far all I have seen use the Blinn–Phong shading model, so it's completely useless to aim for an accuracy beyond what that can deliver, because Blinn-Phong is already an approximation which limits the precision that can be achieved. Now, it struck me that the water shader computes wave patterns and foam on a meter-scale. It does so even for a pixel which is 120 km distant (and which probably represents an area of 100x400 m or so). We first calculate a very detailed wave pattern and foam for that pixel, then let the renderer average everything out again to give the pixel a color. That didn't strike me as a particularly efficient way to do things. I replaced the wave pattern in the distance by something that averages to the same thing. That's not the average wave pattern (=a flat surface) because reflected light intensity is a non-linear function of the surface distortion, but noise with the right amplitude, leading to the same standard deviation and the same average, gets the job done. I also asked not to compute any foam beyond some other distance. As a result, the shader performance jumped from 30 fps to 42 fps in a benchmark situation (ufo at 30.000 ft looking at the horizon, 120 km visibility range). In general, how much performance one spends on distant stuff doesn't influence the visuals drastically, because these pixels are more and more fogged and more and more details are averaged out. But more than 80% of the vertices in the scene are farther than half the visibility range, and a fair share of pixels is, and that's the stuff you see from a typical cockpit perspective. So in terms of performance, simplifying the rendering of distant objects counts a lot. I have spent 30 minutes testing the visual impression of my changes in different winds, in different light and from different altitudes, and I could not spot any problem - the shader just ran faster. Despite this, it's possible that there is a problematic situation somewhere. But the answer to this should not be to revert the changes, the proper answer should be to code an exception dealing with the particular problem. I did not get the impression that there was so far any attempt made to optimize the performance of the water sine shader. It's difficult to compare directly since I added the whole terrain haze and lightfield rendering, but I suspect that if all I did (remove redundant operations, throw per-frame constant computations out of the shader, do not use textures to sample constant
Re: [Flightgear-devel] Water shader issues
On Sun, 2012-04-22 at 11:02 +, Renk Thorsten wrote: After the last related discussion, I've really been thinking a while if I should bring this up again or not. Let me just add to the discussion that 'technically perfect' always will look a tad odd to humans since the world around us is not perfect. It's the moment I added actuators (with delayed responses) to surface movements of the F-16 it did start to feel 'real' This discussion (and the one prior to this about flat ocean surface) is probably of the same magnitude; if the end result doesn't look obviously wrong it is probably just as good as a technically perfect solutions and might even feel more natural (because it's a bit imperfect like the world around us). Erik -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Water shader issues
I have one quick comment. Open-source projects tend to be merit based rather than authoritative. One could read Thorsten's message not as appealing to his authority, but simply trying to establish some merit points by referencing another situation outside the FlightGear project. Thorsten did not emphasize his work with sky and could shaders -- I assume not wanting to take his message over the top, and leaving it to the developers and contributors to connect the dots. Let me connect just a bit ... If you follow the forums, you will notice that Thorsten has been one of the few people that has really dived into trying to understand the subtle effects of lighting and shading and illumination and all of that as it relates to human perception -- with the end goal to make FlightGear sky, clouds, fog, haze, sunrises, sunsets, etc. far more realistic than they are now. He is way down into the subtleties that most of us would never think about except when he posts his screenshots we say WOW! I also say WOW! when I look at the water effects -- those have been a great addition too -- especially at a personal level because I do some marine aviation work for my day job and have been able to show some really nice results in the simulator that parallel reality quite closely. So I think Thorsten has way more than established his credibility within the FlightGear project. And also so has Emelian. One of the original flightgear contributors used to use a marine saying to describe what I think is going on here. Every man has his own way to tie up his boat. The great tradition of the FlightGear project is to try to find a way to offer both methods when faced with strong opinions about how the boat should be tied up. I don't know if that would be easy or hard in this case -- but could the changes be presented in a way where an average person could easily switch back and forth between them and look for rendering differences and performance differences? Thanks, Curt. On Apr 22, 2012 7:48 AM, Bertrand Coconnier bcoco...@gmail.com wrote: 2012/4/22 Renk Thorsten thorsten.i.r...@jyu.fi: After the last related discussion, I've really been thinking a while if I should bring this up again or not. I don't want to annoy people just for the sake of it, I know open source development is often a thankless task in which one frequently gets to hear more complaints about things not working than thanks for things working, and all in all I perfer a pleasant atmosphere on the mailing list, and critique of someone's code tends to lead to the opposite. But then, we had a performance discussion, and I had my share of criticism about my use of Nasal slowing things down, and in the end it's information which is better transmitted than not. Let me nevertheless start off by thanking all the people who worked on the shader codes I've been looking at - I learned a lot about how this is done and what can be done by just taking things apart and putting it back together again, I have often enjoyed the effects before starting to mess with shaders myself, and I guess many others also do. I've been over the water sine wave shader again, seeing if I could make run it faster. What I found reminded me of something I (mean-spirited as I am) did to a PhD student starting to work for me. I asked him to write a code evaluating a quantum mechanical scattering process. He did so using an established general-purpose Monte Carlo integral solver. I wrote a code for the same problem, we compared the results and they were the same, so we did solve the same problem and had the same solution - just my code was 100 times faster. Afterwards, he was ready to accept that he can learn from me how to code physics properly. That miracle was accomplished by me telling the integral solver where performance is needed and where not (technically, this involves using an a priori suitably biased sampling distribution, which after the fact gets corrected by conditional probability calculus - which can be proven to work, but looks like black magic). To give a very simple simple example, if we want to evaluate r^2 pi and know r^2 with an accuracy of 10%, it isn't really a good strategy to spend an hour to calculate a billion digits of pi. It requires to understand the problem and not use all-purpose, but specially designed problem-solving strategies. The same accuracy statement is true of the shaders by the way - so far all I have seen use the Blinn–Phong shading model, so it's completely useless to aim for an accuracy beyond what that can deliver, because Blinn-Phong is already an approximation which limits the precision that can be achieved. Now, it struck me that the water shader computes wave patterns and foam on a meter-scale. It does so even for a pixel which is 120 km distant (and which probably represents an area of 100x400 m or so). We first calculate a very detailed wave pattern and foam for that pixel, then let the renderer average
Re: [Flightgear-devel] An empassioned plea
a Mac Pro can get periodic upgrades just like any other PC or Linux box. As I hinted before Gene, those of us on limited budgets can't really justify the spend for a Mac Pro. Erik, You are forgiven :0) James, I think you have an advantage in that you run Linux on your Mac, so you can utilise the best of both worlds. I think this topic has been spent now. Thanks for all your replies. I shall just have to go on choosing which special effect to have switched on on any particular flight. Best regards, Vic p.s. Really looking forward to Rembrant (if it will run on my ancient hardware).-- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Water shader issues
Thorsten wrote -Original Message- From: Renk mailto:thorsten.i.r...@jyu.fi] Sent: 22 April 2012 12:03 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Water shader issues After the last related discussion, I've really been thinking a while if I should bring this up again or not. I don't want to annoy people just for the sake of it, I know open source development is often a thankless task in which one frequently gets to hear more complaints about things not working than thanks for things working, and all in all I perfer a pleasant atmosphere on the mailing list, and critique of someone's code tends to lead to the opposite. But then, we had a performance discussion, and I had my share of criticism about my use of Nasal slowing things down, and in the end it's information which is better transmitted than not. Let me nevertheless start off by thanking all the people who worked on the shader codes I've been looking at - I learned a lot about how this is done and what can be done by just taking things apart and putting it back together again, I have often enjoyed the effects before starting to mess with shaders myself, and I guess many others also do. I've been over the water sine wave shader again, seeing if I could make run it faster. What I found reminded me of something I (mean-spirited as I am) did to a PhD student starting to work for me. I asked him to write a code evaluating a quantum mechanical scattering process. He did so using an established general-purpose Monte Carlo integral solver. I wrote a code for the same problem, we compared the results and they were the same, so we did solve the same problem and had the same solution - just my code was 100 times faster. Afterwards, he was ready to accept that he can learn from me how to code physics properly. That miracle was accomplished by me telling the integral solver where performance is needed and where not (technically, this involves using an a priori suitably biased sampling distribution, which after the fact gets corrected by conditional probability calculus - which can be proven to work, but looks like black magic). To give a very simple simple example, if we want to evaluate r^2 pi and know r^2 with an accuracy of 10%, it isn't really a good strategy to spend an hour to calculate a billion digits of pi. It requires to understand the problem and not use all-purpose, but specially designed problem-solving strategies. The same accuracy statement is true of the shaders by the way - so far all I have seen use the Blinn-Phong shading model, so it's completely useless to aim for an accuracy beyond what that can deliver, because Blinn-Phong is already an approximation which limits the precision that can be achieved. Now, it struck me that the water shader computes wave patterns and foam on a meter-scale. It does so even for a pixel which is 120 km distant (and which probably represents an area of 100x400 m or so). We first calculate a very detailed wave pattern and foam for that pixel, then let the renderer average everything out again to give the pixel a color. That didn't strike me as a particularly efficient way to do things. I replaced the wave pattern in the distance by something that averages to the same thing. That's not the average wave pattern (=a flat surface) because reflected light intensity is a non-linear function of the surface distortion, but noise with the right amplitude, leading to the same standard deviation and the same average, gets the job done. I also asked not to compute any foam beyond some other distance. As a result, the shader performance jumped from 30 fps to 42 fps in a benchmark situation (ufo at 30.000 ft looking at the horizon, 120 km visibility range). In general, how much performance one spends on distant stuff doesn't influence the visuals drastically, because these pixels are more and more fogged and more and more details are averaged out. But more than 80% of the vertices in the scene are farther than half the visibility range, and a fair share of pixels is, and that's the stuff you see from a typical cockpit perspective. So in terms of performance, simplifying the rendering of distant objects counts a lot. I have spent 30 minutes testing the visual impression of my changes in different winds, in different light and from different altitudes, and I could not spot any problem - the shader just ran faster. Despite this, it's possible that there is a problematic situation somewhere. But the answer to this should not be to revert the changes, the proper answer should be to code an exception dealing with the particular problem. I did not get the impression that there was so far any attempt made to optimize the performance of the water sine shader. It's difficult to compare directly since I added the whole terrain haze and lightfield rendering, but I suspect that if all I did (remove redundant
Re: [Flightgear-devel] [Flightgear-commitlogs] FlightGear Base Package branch, master, updated. b0fd1613629ccb89622e3e268588ee69498263dc
On Sun, Apr 22, 2012 at 3:16 AM, James Turner zakal...@mac.com wrote: On 22 Apr 2012, at 03:14, Flightgear-commitlogs wrote: Bravo updates.changed map range select;property-cycle too buggy Something to be fixed here? (In a backwards compatible way...) James -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel Probably , I haven't looked at the code itself, but changing direction , cycling up and then down through the list, doesn't appear to continue from the current index... stepping up will work fine , then stepping down seems to jump to the end or start of the list . (if that explanation makes sense).I'll take a look and see if anything obvious pops out at me. Syd -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] An empassioned plea
On Sun, 22 Apr 2012, Vic Marriott wrote: a Mac Pro can get periodic upgrades just like any other PC or Linux box. As I hinted before Gene, those of us on limited budgets can't really justify the spend for a Mac Pro. Maybe not, but you could buy a used one and tweak it if you're insistant on having Apple hardware. Personally, I'd build the best white-box machine I could afford and throw Linux on it. g. -- Proud owner of F-15C 80-0007 http://www.f15sim.com - The only one of its kind. http://www.diy-cockpits.org/coll - Go Collimated or Go Home. Some people collect things for a hobby. Geeks collect hobbies. ScarletDME - The red hot Data Management Environment A Multi-Value database for the masses, not the classes. http://www.scarletdme.org - Get it _today_! Buying desktop hardware and installing a server OS doesn't make a server-class system any more than sitting in a puddle makes you a duck. [Cipher in a.s.r] -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Netiquette
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hello everyone, probably I'm not the right person to write this as my last code commit was ages ago - but I'm still following the discussions on this list: Currently I'm seeing quite a few mails with a full quote of the mail referring to (e.g. the Water shader issues thread). This doesn't help understanging the new point - it's causing the opposite, as the new comment has to be found in all the quotating... So can you please stick to the general rules about right quotating in mails as defined by the netiquette? Thank you, Chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iEYEAREIAAYFAk+UL+cACgkQoWM1JLkHou3gWQCeM+2VIUOoiH50suQJ2T/ulfP7 rAYAoIu3Fs4bVPyaXb6lIS8uF3vJE6PT =UiIN -END PGP SIGNATURE- -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Netiquette
On Sun, 22 Apr 2012, Christian Mayer wrote: Currently I'm seeing quite a few mails with a full quote of the mail referring to (e.g. the Water shader issues thread). This doesn't help understanging the new point - it's causing the opposite, as the new comment has to be found in all the quotating... My hero! \o/ :) g. -- Proud owner of F-15C 80-0007 http://www.f15sim.com - The only one of its kind. http://www.diy-cockpits.org/coll - Go Collimated or Go Home. Some people collect things for a hobby. Geeks collect hobbies. ScarletDME - The red hot Data Management Environment A Multi-Value database for the masses, not the classes. http://www.scarletdme.org - Get it _today_! Buying desktop hardware and installing a server OS doesn't make a server-class system any more than sitting in a puddle makes you a duck. [Cipher in a.s.r] -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Random Buildings
Am 19.04.12 17:52, schrieb Stuart Buchanan: On Thu, Apr 19, 2012 at 4:39 PM, rickbritto wrote: hello friends, Is possible to separate the random loading by types of buildings? Yes. The materials.xml file allows you to define different parameters for different landlclasses (e.g. Urban, Suburban, Commercial), and as mentioned above I'm adding parameters to control the ratio of the different building types. So a residential zone will have (say) 90% small buildings, and 10% medium, while an Urban zone will have 50% medium and 50% large. -Stuart -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel Hi Stuart Just a small question because I’m currently looking to OSM street data and try to use it for scenery creation ... in your last screenshot of your improvements I still see buildings on streets (not the streets on urban textures, I mean the real roads coming originally from road line shapefiles). Will it be possible not to cover/overlap roads with random buildings, or is this planned anyway and I missed this point? Cheers, Yves -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] California Scenery Update
I now have landcover for more than 2/3rds of the state of california batch processed, along with parts of Southern Oregon (including Crater Lake): http://www.stattosoftware.com/california_fg.png The exciting news is the very northern block actually is flush with the very southern edge of the Pacific Northwest scenery, so once all of this is actually turned from data into scenery, a flight from Seattle to Orange County will be possible without flying over any vmap0 scenery using data specifically generated for use in FlightGear - about 1000 miles in length. If you would like any of these chunks to turn into scenery yourself, please let me know - I will be uploading them to a server (not mapserver) in May. Thanks John -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
