Re: [Flightgear-devel] Workaround: c172p on MacBook Pro with Intel HD3000
Presumably you could just ask osg or the gl to discard the top mip level(s) rather than altering the source art to work around apple's driver bugs? -- 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] Workaround: c172p on MacBook Pro with Intel HD3000
Hi, on some Mac Models with Intel HD 3000 graphics flightgear showed a really nasty flickering effect. I had the problem with c172p and the bumpspec shader effect enabled. After a lot of investigations I discovered that actually "size matters". I get this kind of flickering artifacts if texture maps are larger than 2048x2048, even with a trivial shader prog. Unfortunately the dimensions of the textures in Aircraft/c172p/Models/Livery fuselage-normal.png tail-normal.png wing-normal.png are 4096x4096. Please resize these textures to 2048x2048, since we do not loose to much eye candy anyway. Greetings, Olaf BTW: GL_MAX_TEXTURE_SIZE is 8192 according to https://developer.apple.com/graphicsimaging/opengl/capabilities/GLInfo_1072.html -- 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] Adding Airports
The airports I would like to add within my area of interest are HUJI Jinja, HUKJ Kajjansi, and HUKK Kakira. They are all in Uganda - many Ugandan airports are not in the database, but there are also less than five airports with paved runways in the country, as far as I can tell. How can I append the .tpj files to apt.dat? Also what's the best way to get these airports submitted to the database, is the answer still Robin Peel? 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
Re: [Flightgear-devel] Adding Airports
Hi John Are this strips/fields missing in apt.dat 810 and 850 ? Do this strips have a FAA code or is it outside U.S. ? Cheers, Yves - Ursprüngliche Nachricht - Von: "FlightGear developers discussions" An: Cc: Gesendet:Fri, 13 Apr 2012 08:23:54 -0700 (PDT) Betreff:[Flightgear-devel] Adding Airports I have made a couple airports which are not in the airport database in the 8.10 format in TaxiDraw. Before anyone tells me about 8.50 these airports are nothing more than missing grass/dirt airstrips. What is the best way to add them to apt.dat, so I might be able to use Terragear with these airstrips included? 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 -- 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:
>
> > Plus, if you neglect the curvature effect in every relevant vector,
> > the rendering artefacts at the tile boundaries must go away, because
> > the differences in rendering geometry between tiles go away, and
> > they're the only thing which can introduce the artefacts in the first
place.
>
> Turns out I was wrong here - found and eliminated the tile boundary bug.
>
> The problematic thing seems to be refTex in the following code block of
the
> water_sine fragment shader:
>
> //load reflection
> vec4 tmp = vec4(lightdir, 0.0);
> vec4 refTex = texture2D(water_reflection, vec2(tmp)) ;
> vec4 refTexGrey = texture2D(water_reflection_grey, vec2(tmp)) ;
> vec4 refl ;
>
> if(cover >= 1.5){
> refl= normalize(refTex);
> }
> else
> {
> refl = normalize(refTexGrey);
> refl.r *= (0.75 + 0.15 * cover);
> refl.g *= (0.80 + 0.15 * cover);
> refl.b *= (0.875 + 0.125 * cover);
> refl.a *= 1.0;
> }
>
> If refTex is replaced by refTexGrey, the problem goes away (but the sea
> becomes grey even in sunshine), so there's something odd with the texture
> (?). But the whole block is actually obsolete. It basically loads a
128x128
> homogeneous grey and a 128x128 homogeneous white texture, samples
> both, since both textures are homogeneous it finds the same color every
> time no matter where it is sampled, then chooses one of the textures and
> discards the other one to determine an (rgb) vector to be modified for
cloud
> cover.
>
> Apparently we have the GPU power and texture memory by the bucketful
> so that we can use that procedure to determine a color vector. On the way,
I
> also eliminated a few normalize(some_vector); statements of vectors which
> were already normalized before passing them, so the whole shader has
> other obsolete steps as well.
>
> Not that I would be an expert in shader design, but about the same output
> (without tiling artefacts) can be achieved in a two-liner:
>
> // basic water color
> vec4 refl = vec4 (0.148, 0.27, 0.3, 1.0);
>
> // de-saturate for reduced light
> refl.rgb = mix(refl.rgb, vec3 (0.248, 0.248, 0.248), 1.0 -
smoothstep(0.4, 1.0,
> scattering));
>
> That has the neat side effect that we could even pass the basic color as a
> uniform from outside the shader and change the water color smoothly from
> the shore to deep ocean and dependent on latitude (the weather system
> happens to know if there's terrain in the vicinity or not).
>
> Feel free to do whatever you want with the information provided, after all
> it's open source...Oh, and why do I read so often that coding in Nasal is
a
> problem for the performance actually?
>
I don't think your analysis can be correct; are you saying that the
surrounding if.. else statement is a non op? The intention is to set the
reflection colour as white if cover >= 1.5 else set it to grey. AFAIK it
works that way as well. Something wrong with the texture? I don't think so.
It also works with your modification. If we had a better input with which to
set the sea colour to reflect the sky conditions then I would have used it.
It's all an attempt to emulate the cloud cover over the sea and stop it
being a lovely blue in the middle of a storm. I don't see that your
modification honours this intent. The basic colour of the sea is, without
the effects of particulates and phytoplankton in the water, salinity,
reflection from the bottom and other factors, a surprisingly dark blue, but
when there is cloud cover present the sea is more grey.
Proximity of land is only a very rough guide to depth of water. You can go a
long way from shore in the North Sea without finding deep water, but the sea
gets very deep very fast off the Azores. If we can represent all this
better, then I'm all for it.
Vivian
--
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] Water shader issues
> Plus, if you neglect the curvature effect in every relevant vector, the
> rendering artefacts at the tile boundaries must go away, because the
> differences in rendering geometry between tiles go away, and they're the
> only thing which can introduce the artefacts in the first place.
Turns out I was wrong here - found and eliminated the tile boundary bug.
The problematic thing seems to be refTex in the following code block of the
water_sine fragment shader:
//load reflection
vec4 tmp = vec4(lightdir, 0.0);
vec4 refTex = texture2D(water_reflection, vec2(tmp)) ;
vec4 refTexGrey = texture2D(water_reflection_grey, vec2(tmp)) ;
vec4 refl ;
if(cover >= 1.5){
refl= normalize(refTex);
}
else
{
refl = normalize(refTexGrey);
refl.r *= (0.75 + 0.15 * cover);
refl.g *= (0.80 + 0.15 * cover);
refl.b *= (0.875 + 0.125 * cover);
refl.a *= 1.0;
}
If refTex is replaced by refTexGrey, the problem goes away (but the sea becomes
grey even in sunshine), so there's something odd with the texture (?). But the
whole block is actually obsolete. It basically loads a 128x128 homogeneous grey
and a 128x128 homogeneous white texture, samples both, since both textures are
homogeneous it finds the same color every time no matter where it is sampled,
then chooses one of the textures and discards the other one to determine an
(rgb) vector to be modified for cloud cover.
Apparently we have the GPU power and texture memory by the bucketful so that we
can use that procedure to determine a color vector. On the way, I also
eliminated a few normalize(some_vector); statements of vectors which were
already normalized before passing them, so the whole shader has other obsolete
steps as well.
Not that I would be an expert in shader design, but about the same output
(without tiling artefacts) can be achieved in a two-liner:
// basic water color
vec4 refl = vec4 (0.148, 0.27, 0.3, 1.0);
// de-saturate for reduced light
refl.rgb = mix(refl.rgb, vec3 (0.248, 0.248, 0.248), 1.0 - smoothstep(0.4,
1.0, scattering));
That has the neat side effect that we could even pass the basic color as a
uniform from outside the shader and change the water color smoothly from the
shore to deep ocean and dependent on latitude (the weather system happens to
know if there's terrain in the vicinity or not).
Feel free to do whatever you want with the information provided, after all it's
open source...Oh, and why do I read so often that coding in Nasal is a problem
for the performance actually?
* Thorsten
--
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] Adding Airports
I have made a couple airports which are not in the airport database in the 8.10 format in TaxiDraw. Before anyone tells me about 8.50 these airports are nothing more than missing grass/dirt airstrips. What is the best way to add them to apt.dat, so I might be able to use Terragear with these airstrips included? 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
Re: [Flightgear-devel] List Etiquette was airport list
Sorry. I have the settings corrected now.
gapalp
gap...@gapalp.net
> Original Message
> Subject: Re: [Flightgear-devel] List Etiquette was airport list
> From: Ron Jensen
> Date: Fri, April 13, 2012 9:12 am
> To: FlightGear developers discussions
>
>
>
> On Thursday 12 April 2012 16:11:14 gap...@gapalp.net wrote:
> > Wow, this works better, is simpler code, and is much
> > faster! Plus it will be easy to allow the user to pass configurations such
> > as range and airport type as mentioned, to suit GA planes or
> > heavies. AirportInfoFilter
> > filter; double maxRange =
> > 300.0; FGPositioned::List results =
> > FGPositioned::findWithinRange(globals->get_aircraft_position(), range,
> > &filter); FGPositioned::sortByRange(results,
> > globals->get_aircraft_position()); string
> > dest[results.size()]; for (unsigned int i=0; i <
> > results.size(); i++) {
> > dest[i] = results[i]->ident();
> > }gapalp > href="mailto:gap...@gapalp.net";>gap...@gapalp.net >iv>
>
>
> Please send your mails to this list in plain text not HTML.
>
> Thank you,
>
> Ron
>
> --
> 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
--
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] Now Rembrandt here...
On Thu, 12 Apr 2012, Frederic Bouvier wrote: > > Here is a video with a steady view to see shadow stability. > > http://youtu.be/JtEXIn2yL94 > > I also added 3 different sequences with different levels of filtering. > Filtering is not yet configurable but is selectable in the > sunlight shader with simple code modification. > Fred, is there a reason the shadows on the instrument faces are so jumpy? 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] List Etiquette was airport list
On Thursday 12 April 2012 16:11:14 gap...@gapalp.net wrote:
> Wow, this works better, is simpler code, and is much
> faster! Plus it will be easy to allow the user to pass configurations such
> as range and airport type as mentioned, to suit GA planes or
> heavies. AirportInfoFilter
> filter; double maxRange =
> 300.0; FGPositioned::List results =
> FGPositioned::findWithinRange(globals->get_aircraft_position(), range,
> &filter); FGPositioned::sortByRange(results,
> globals->get_aircraft_position()); string
> dest[results.size()]; for (unsigned int i=0; i <
> results.size(); i++) {
> dest[i] = results[i]->ident();
> }gapalp href="mailto:gap...@gapalp.net";>gap...@gapalp.netiv>
Please send your mails to this list in plain text not HTML.
Thank you,
Ron
--
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] Shader - Environment interfacing issues
> If it looks right in one limited test case, doesn't mean it's right, or > the proper way to deal with it (so it won't backfire later on) Look, basic ray optics says that the error in ray propagation I make by neglecting the curvature is linear proportional to the error in normal angle which I make by neglecting curvature. So in order to estimate the error in reflection, I need to estimate the error in normal angle. If I go a distance d, the normal angle changes by arctan (d/R) where R is the radius of earth. For any rendering distance we can achieve d/R is a very small number O(100km / 6000km) ~ 0.016. For small arguments, I can expand arctan(x) ~ x, so the angle changes by 0.016 or 0.9 degrees at the edge of the visibility. In the region where we actually see details of wave patterns and reflection, the error is a factor 10 less. However, on top of the normal I add wave noise, and the distortion of the normal by a wave can easily be 30-45 degrees. Compare this with 0.1 degrees error in the near range due to neglected curvature and you will come to the conclusion that any halfway realistic wave pattern easily masks any curvature errors I could possibly make with really high accuracy. This is mathematics. Not a limited test case. Plus, if you neglect the curvature effect in every relevant vector, the rendering artefacts at the tile boundaries must go away, because the differences in rendering geometry between tiles go away, and they're the only thing which can introduce the artefacts in the first place. There's simply no point in trying to solve a problem exactly if you can show by error analysis that a Taylor approximation gets you the desired result much faster and cheaper. Trust an old physicist on that point... :-) * Thorsten -- 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] Shader - Environment interfacing issues
> Actualy it makes assumptions about the lighting scheme used, and it > "boosts" the visible reflection of the sun using a texture instead > of the light's specular in the specular pass. > That gets to be less aparent in the Rembrandt specular pass.(That > would be easily converted by using the sun position, but we don't > have that in the geometry pass :( ) > One other issue that needs to be investigated is the changing > specular position related to camera direction in Rembrandt (the > leads to the ugly black banding in other objects too). It's > visible on any object at certain surface to camera angle. I pushed a different way to encode normals, with a shader to collect utility functions (see normal_encode and normal_decode in gbuffer-functions.frag). That may improve the banding. Regards, -Fred -- 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] Now Rembrandt here...
On Fri, 13 Apr 2012 06:23:23 +, Renk wrote in message : > > Here is a video with a steady view to see shadow stability. > > Okay, thanks, that's helpful. My flickering is a bit worse than in > the first case in this video, but not much. ..what happens if you run your video card at a slower frame rate? -- ..med vennlig hilsen = with Kind Regards from Arnt Karlsen ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. -- 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] (no subject)
On Friday 13 April 2012 11:00:14 Renk Thorsten wrote: > >> 'flat' = 'For any visibility we can actually render, the normal (before > >> wave > >> noise) is (0,0,1) in model space to such a good approximation that you > >> won't spot the difference to the actual normal including earth > >> curvature if > >> I show you a picture.' > >> > >> Cheers, > >> > >> * Thorsten > > > > That will give you even worse lighting difference between tiles, and will > > shurely give you ugly artefacts and wrong speculars in relation with the > > sun > > Basic ray optics says no such thing will happen, and basic ray optics turns > out to be right - I just ran a changed shader - if anything, the tile > boundary artefacts are reduced (actually I expected them to be gone, but > there's probably another vector in the game). > > Cheers, > > * Thorsten If it looks right in one limited test case, doesn't mean it's right, or the proper way to deal with it (so it won't backfire later on) But feel free to do whatever you want with the information provided, and the code, after all it's open source... Emilian -- 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] Shader - Environment interfacing issues
On Friday 13 April 2012 12:35:57 Frederic Bouvier wrote: > Emilian can testify that the current water shader is extremely > difficult to convert to Rembrandt because it doesn't have a > clear reference frame. It seems to work in object space but > with assumptions on the object-to-world transformation. > My gut feeling is that it was originally a demo from another > project and added to FG without much thought, and a lot of > trials and errors. As the writer of the urban shader, I am > thinking of rewriting the Rembrandt version of the water shader > in the same spirit. > > Regards, > -Fred Actualy it makes assumptions about the lighting scheme used, and it "boosts" the visible reflection of the sun using a texture instead ofthe light's specular in the specular pass. That gets to be less aparent in the Rembrandt specular pass.(That would be easily converted by using the sun position, but we don't have that in the geometry pass :( ) One other issue that needs to be investigated is the changing specular position related to camera direction in Rembrandt (the leads to the ugly black banding in other objects too). It's visible on any object at certain surface to camera angle. -Regards, Emilian -- 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] (no subject)
>> 'flat' = 'For any visibility we can actually render, the normal (before >> wave >> noise) is (0,0,1) in model space to such a good approximation that you >> won't spot the difference to the actual normal including earth >> curvature if >> I show you a picture.' >> >> Cheers, >> >> * Thorsten > That will give you even worse lighting difference between tiles, and will > shurely give you ugly artefacts and wrong speculars in relation with the > sun > Basic ray optics says no such thing will happen, and basic ray optics turns out to be right - I just ran a changed shader - if anything, the tile boundary artefacts are reduced (actually I expected them to be gone, but there's probably another vector in the game). Cheers, * Thorsten -- 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] Shader - Environment interfacing issues
On Friday 13 April 2012 10:42:48 Renk Thorsten wrote: > > Apart that the earth is a sphere and ocean tiles are large pieces > > of terrain where the curvature is quite apparent, how whould you > > define flat ? > > 'flat' = 'For any visibility we can actually render, the normal (before wave > noise) is (0,0,1) in model space to such a good approximation that you > won't spot the difference to the actual normal including earth curvature if > I show you a picture.' > > Cheers, > > * Thorsten That will give you even worse lighting difference between tiles, and will shurely give you ugly artefacts and wrong speculars in relation with the sun ;) Emilian -- 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] Shader - Environment interfacing issues
On Friday 13 April 2012 10:09:12 Renk Thorsten wrote: > > To be safe you need to limit yourself to 32 float varyings. > > Note: a vec3 counts as 3 float varyings, a vec4 as 4 etc. > > Okay thanks, then I am safe. Btw (spotted this while checking) - is there > any particular reason to compute a normal from gl_Normal in the vertex > shader, use a full varying vec3 to pass it to the fragment shader and add > noise there? I mean, this is a water surface, it ought to be flat up to > tiny corrections before adding noise... > > * Thorsten Yes because you don't have acces to gl_Normal in a fragment shader, and because the water surface is not a perfectly flat surface, it's a sphere patch (a low resolution one), so the normal varies between vertices. Emilian -- 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] Shader - Environment interfacing issues
> Apart that the earth is a sphere and ocean tiles are large pieces > of terrain where the curvature is quite apparent, how whould you > define flat ? 'flat' = 'For any visibility we can actually render, the normal (before wave noise) is (0,0,1) in model space to such a good approximation that you won't spot the difference to the actual normal including earth curvature if I show you a picture.' Cheers, * Thorsten -- 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] Shader - Environment interfacing issues
> De: Renk Thorsten > > > To be safe you need to limit yourself to 32 float varyings. > > Note: a vec3 counts as 3 float varyings, a vec4 as 4 etc. > > Okay thanks, then I am safe. Btw (spotted this while checking) - is > there any particular reason to compute a normal from gl_Normal in > the vertex shader, use a full varying vec3 to pass it to the > fragment shader and add noise there? I mean, this is a water > surface, it ought to be flat up to tiny corrections before adding > noise... Apart that the earth is a sphere and ocean tiles are large pieces of terrain where the curvature is quite apparent, how whould you define flat ? In which reference frame ? The simplest way is to think that before applying normal mapping and noise perturbation, the surface of things is perpendicular to its the normal. Emilian can testify that the current water shader is extremely difficult to convert to Rembrandt because it doesn't have a clear reference frame. It seems to work in object space but with assumptions on the object-to-world transformation. My gut feeling is that it was originally a demo from another project and added to FG without much thought, and a lot of trials and errors. As the writer of the urban shader, I am thinking of rewriting the Rembrandt version of the water shader in the same spirit. Regards, -Fred -- 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] Shader - Environment interfacing issues
> To be safe you need to limit yourself to 32 float varyings. > Note: a vec3 counts as 3 float varyings, a vec4 as 4 etc. Okay thanks, then I am safe. Btw (spotted this while checking) - is there any particular reason to compute a normal from gl_Normal in the vertex shader, use a full varying vec3 to pass it to the fragment shader and add noise there? I mean, this is a water surface, it ought to be flat up to tiny corrections before adding noise... * Thorsten -- 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] Shader - Environment interfacing issues
> Emilian proposes the weather system to be agnostic about the shaders,
> not the shaders to be agnostic about weather.
Advanced Weather works based on abstraction layers. The high levels are unaware
of any technical issues ('we have a tile with 6/8 Nimbostratus coverage and
light rain'), as the weather is set up, lower layers gradually generate the
technical information (What cloud rendering technology is to be used to draw
the Nimbostratus cover? What shader is the cloud rendered with? Do we need to
compute atmosphere scattering values given the visibility or not? ).
The low layers cannot be unaware of shaders, because for instance a cloud
defined in the new way is defined by different parameters than a cloud in the
old way and the weather system has to have this information.
The weather system as such is fairly agnostic about what shaders actually
render visibility or skydome. The information is written, but the weather
system doesn't care if a shader parses it or not.
> Anyhow, starting at an even higher level of detail, the weather system
> might be required to know where sunlight actually hits the ground
I've been thinking about this early on, but what matters for convection is
actually the time history of sun irradiation of a spot, so you'd need to know
how the cloud cover evolved over the last few hours at a location, not how it
currently is.
Cheers,
* Thorsten
--
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] Shader - Environment interfacing issues
On Fri, 2012-04-13 at 11:53 +0300, Emilian Huminiuc wrote: > To be safe you need to limit yourself to 32 float varyings. > Note: a vec3 counts as 3 float varyings, a vec4 as 4 etc. Ah I dind't know there was a difference between floats and vectors. 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] Shader - Environment interfacing issues
Renk Thorsten wrote: Emilian wrote: >> It would be good to make it Weather system agnostic from the >> effect/shader side of things, don't you think? > > No. > > If you want to render atmospheric light effects, the shader needs to > know the structure of the atmosphere and at what altitude the light > attenuation due to clouds occurs, and the only system which has this > information is the weather system, so the effect side can not be > agnostic to what goes on in the weather system. Emilian proposes the weather system to be agnostic about the shaders, not the shaders to be agnostic about weather. Anyhow, starting at an even higher level of detail, the weather system might be required to know where sunlight actually hits the ground Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- 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 Fri, 2012-04-13 at 09:25 +0100, Vic Marriott wrote: > Hi, > > More and more, the FG forums are showing that the most recent improvements, > added to the existing code, are too memory consuming for operation on > anything less than a high powered, up-to-date, well equipped computer. > > Though I, and probably most other FG users, am delighted that improvements > from your efforts continue at such a rate, can I please ask the hard-core > developers to give some thought to making the current set of bells and > whistles more memory friendly. > > There is little more frustrating than to read about the marvellous additions, > but then being unable to run them without FG slowing down to unusable levels. > > There is only so much users can do to keep their computers as up-to-date as > possible, but simple things like the lack of funds can easily put a limit on > that. > > Please consider having a concerted effort towards making FG less memory > hungry. It's probably not so much about memory consuming but more about resource consuming. But be assured that most new options are easily turned off. 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] Shader - Environment interfacing issues
On Fri, 2012-04-13 at 08:45 +, Renk Thorsten wrote: > > Not when the varying number is limited. So you gain a bit of speed, but > > you lose a lot of compatibility.(think ATi/intel, or OSS drivers for nVidia) > > You gain a lot of speed. But what is the max. allowed number of varying? It's > difficult to code anything when there is some upper limit, but I just don't > know what it is. Seven is the upper limit for most older cards, nowadays it can go up to 16 if I'm not mistaken. 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] Shader - Environment interfacing issues
On Friday 13 April 2012 08:45:26 Renk Thorsten wrote: > > (*)No it's not bad design, it's a conscious hack around the state that > > the environment interface was in when the shader was developed. > > Something like a property rule or a Nasal script outside the shader would > have done the trick as well... But I'm not arguing why it's done the way it > is, and I don't want to talk down the great work that has been done with > the water shader, I think we agree that a proper weather/environment > interface is the way to go. > > It would be good to make it Weather system agnostic from the > > effect/shader side of things, don't you think? > > No. > > If you want to render atmospheric light effects, the shader needs to know > the structure of the atmosphere and at what altitude the light attenuation > due to clouds occurs, and the only system which has this information is the > weather system, so the effect side can not be agnostic to what goes on in > the weather system. > > It should be agnostic to how the weather system internally determines and > manages these parameters, but I don't think we need to argue that passing a > single 'ground light intensity' is superior to passing 5 cloud layer > coverages and determining ground light intensity from that inside the > fragment shader. > > Currently the issue is that I determine many parameters characterizing the > light attenuation in the atmosphere dynamically in Advanced Weather but > insert default values into environment.xml which are never changed by Basic > Weather, so Basic Weather runs with lightfields, but doesn't produce > realistic results because the defaults aren't ever adapted to the actual > weather situation. If so desired, someone can insert computations/property > rules/whatever... into Basic Weather to set these things dynamically - that > is what I'm talking about. > > I don't see the value in inserting a heuristics for determining such > parameters dynamically from the native parameters of Basic Weather inside > the lightfield shaders, because that degrades performance quite a lot, and > I have spent weeks optimizing the computations to get decent performance. > In my view, this heuristics should be outside the shaders. You got me wrong there, I meant that what the shader sees in the proerty tree should be weather system (basic or advanced) independent. The shader doesn't need to know if the value comes from either, it just needs the value to be there no matter one's preferences for weather simulation. So in short, a common interface between the various weather implementations and the rest. > > Not when the varying number is limited. So you gain a bit of speed, but > > you lose a lot of compatibility.(think ATi/intel, or OSS drivers for > > nVidia) > You gain a lot of speed. But what is the max. allowed number of varying? > It's difficult to code anything when there is some upper limit, but I just > don't know what it is. > > Cheers, > > * Thorsten To be safe you need to limit yourself to 32 float varyings. Note: a vec3 counts as 3 float varyings, a vec4 as 4 etc. Regards, Emilian -- 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] Shader - Environment interfacing issues
> (*)No it's not bad design, it's a conscious hack around the state that > the environment interface was in when the shader was developed. Something like a property rule or a Nasal script outside the shader would have done the trick as well... But I'm not arguing why it's done the way it is, and I don't want to talk down the great work that has been done with the water shader, I think we agree that a proper weather/environment interface is the way to go. > It would be good to make it Weather system agnostic from the > effect/shader side of things, don't you think? No. If you want to render atmospheric light effects, the shader needs to know the structure of the atmosphere and at what altitude the light attenuation due to clouds occurs, and the only system which has this information is the weather system, so the effect side can not be agnostic to what goes on in the weather system. It should be agnostic to how the weather system internally determines and manages these parameters, but I don't think we need to argue that passing a single 'ground light intensity' is superior to passing 5 cloud layer coverages and determining ground light intensity from that inside the fragment shader. Currently the issue is that I determine many parameters characterizing the light attenuation in the atmosphere dynamically in Advanced Weather but insert default values into environment.xml which are never changed by Basic Weather, so Basic Weather runs with lightfields, but doesn't produce realistic results because the defaults aren't ever adapted to the actual weather situation. If so desired, someone can insert computations/property rules/whatever... into Basic Weather to set these things dynamically - that is what I'm talking about. I don't see the value in inserting a heuristics for determining such parameters dynamically from the native parameters of Basic Weather inside the lightfield shaders, because that degrades performance quite a lot, and I have spent weeks optimizing the computations to get decent performance. In my view, this heuristics should be outside the shaders. > Not when the varying number is limited. So you gain a bit of speed, but > you lose a lot of compatibility.(think ATi/intel, or OSS drivers for nVidia) You gain a lot of speed. But what is the max. allowed number of varying? It's difficult to code anything when there is some upper limit, but I just don't know what it is. Cheers, * Thorsten -- 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] An empassioned plea
Hi, More and more, the FG forums are showing that the most recent improvements, added to the existing code, are too memory consuming for operation on anything less than a high powered, up-to-date, well equipped computer. Though I, and probably most other FG users, am delighted that improvements from your efforts continue at such a rate, can I please ask the hard-core developers to give some thought to making the current set of bells and whistles more memory friendly. There is little more frustrating than to read about the marvellous additions, but then being unable to run them without FG slowing down to unusable levels. There is only so much users can do to keep their computers as up-to-date as possible, but simple things like the lack of funds can easily put a limit on that. Please consider having a concerted effort towards making FG less memory hungry. Best regards, Vic -- 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] Shader - Environment interfacing issues
On Friday 13 April 2012 07:05:40 Renk Thorsten wrote: > > I know that Vivian and Emilian had the plan to separate fog and light > computations from the shaders and have them in general functions to be > called by all shaders. While this is very elegant and maintenance friendly, > I've come across a few issues in converting the water shader which aren't > really trivial for that approach: > > 1) The water shader doesn't actually use the full amount of light > information, it just uses the diffuse channel and assigns that rgb value to > both ambient and specular light while diffuse scattering isn't computed at > all. A general light function returning ambient, diffuse and specular would > waste ~2/3 of its computation time here. See below*. > 2) The precise implementation matters a lot - calling the light where it is > used (in the fragment shader) is significantly slower than calling it in > the vertex shader (water vertices are sparse...) and passing it as a > varying vec3 to the fragment shader. > > So, if one generalizes light, one has to do it in such a way that diffuse, > specular and ambient are separate functions and implement it in a clever > way. But then Not when the varying number is limited. So you gain a bit of speed, but you lose a lot of compatibility.(think ATi/intel, or OSS drivers for nVidia) > > 3) Light and fog lighting computations share a lot of stuff - the whole > relative geometry between eye, sun and vertex altitude determining the > light at low sun has to be solved once in a dedicated do-it-all shader. If > the light function is generalized, somehow lots of vectors and parameters > have to be either passed or re-computed, which presumably slows things down > (I'm not sure how a general include framework would look like and whether > parameters would need to be passed inside the function call or as varying > from the vertex shader...) No it doesn't, it's not a separate shader, it's a separate function in the same shader (think of it as equivalent the #include system). At compile time the two files are concatenated resulting in a single shader. > I've also looked at the environment interface of the water shader and > changed it drastically in the lightfield version. In my view, determining > the cloud coverage on a per-fragment basis by passing 5 uniforms into the > shader and evaluating them in the fragment shader is bad design. Things > which are constants in the whole scene per frame need to be determined > outside the shader and passed as a single uniform. Doing so gains me ~20% > more performance in my test case. (*)No it's not bad design, it's a conscious hack around the state that the environment interface was in when the shader was developed. And it's an attempt to make it work with both sytems. IIRC there was a request posted on this same ML at that time that the environment properties be extended, and unified between weather models, but there was no action take on that. So Vivian (and I in the transition shader) had to work with what was available. > Question: Currently basic weather is not properly supported by the framework > because I've pulled many computations outside the shaders to be passed as > uniforms. Are people interested in keeping Basic Weather and lightfield > shading compatible? If yes, let me know and I can help setting this up, > it's not difficult, it just requires Basic Weather to compute a few things > which used to be in the shaders. If no, please also let me know then I > don't bother trying to set up reasonable defaults. It would be good to make it Weather system agnostic from the effect/shader side of things, don't you think? > > Cheers, > > * Thorsten Regards, Emilian -- 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] Shader - Environment interfacing issues
I've made a case study converting the high quality water shader (my favourite shader effect :-) ) to lightfield rendering in the last two days (see some pics in the forum here http://www.flightgear.org/forums/viewtopic.php?f=47&t=14755&start=150#p155110 sunrises with water reflection look awesome - but the water shader is probably the only thing which eats more performance than the lightfields...). The water shader slider (if on or above 4) is now honoured even when lightfield shading are on. Since someone (FredB?) promoted the lightfield to technique 5, water now has to use 4 - are we running into any limitataions with these numbers, or can we simply shift everything back if needed? I know that Vivian and Emilian had the plan to separate fog and light computations from the shaders and have them in general functions to be called by all shaders. While this is very elegant and maintenance friendly, I've come across a few issues in converting the water shader which aren't really trivial for that approach: 1) The water shader doesn't actually use the full amount of light information, it just uses the diffuse channel and assigns that rgb value to both ambient and specular light while diffuse scattering isn't computed at all. A general light function returning ambient, diffuse and specular would waste ~2/3 of its computation time here. 2) The precise implementation matters a lot - calling the light where it is used (in the fragment shader) is significantly slower than calling it in the vertex shader (water vertices are sparse...) and passing it as a varying vec3 to the fragment shader. So, if one generalizes light, one has to do it in such a way that diffuse, specular and ambient are separate functions and implement it in a clever way. But then 3) Light and fog lighting computations share a lot of stuff - the whole relative geometry between eye, sun and vertex altitude determining the light at low sun has to be solved once in a dedicated do-it-all shader. If the light function is generalized, somehow lots of vectors and parameters have to be either passed or re-computed, which presumably slows things down (I'm not sure how a general include framework would look like and whether parameters would need to be passed inside the function call or as varying from the vertex shader...) 4) I spent just 1/3 of my time getting the shader working, then 2/3 removing double tasks. The water shader does a lot of things already which the fog and light computations need later, so I can use what's already there instead of re-compute it, which speeds things up noticeably - something which is difficult to anticipate when writing a general function. 5) Last, water being water being always flat and hence never able to shadow the fog allows to drop some computations without loss of accuracy which again speeds things up - which a general fog function could never do. So to me it seems we can have either maintenance-friendly shaders or fast shaders. Given the rather staggering framerate impact of the water shader, personally I prefer a fast shader - I can live with having to spend an hour updating light computations across several files, but I can't live with a framerate of 5 fps. Can we get some other opinions on that question? I've also looked at the environment interface of the water shader and changed it drastically in the lightfield version. In my view, determining the cloud coverage on a per-fragment basis by passing 5 uniforms into the shader and evaluating them in the fragment shader is bad design. Things which are constants in the whole scene per frame need to be determined outside the shader and passed as a single uniform. Doing so gains me ~20% more performance in my test case. I've started to set up an interface in environment/surface/ which is populated with the relevant environment at the ground beneath the aircraft (average wind, current wind, ground light intensity,...) and started using that from the lightfield shaders. I would hope that we can eventually gather all shader/environment crosstalk there. Question: Currently basic weather is not properly supported by the framework because I've pulled many computations outside the shaders to be passed as uniforms. Are people interested in keeping Basic Weather and lightfield shading compatible? If yes, let me know and I can help setting this up, it's not difficult, it just requires Basic Weather to compute a few things which used to be in the shaders. If no, please also let me know then I don't bother trying to set up reasonable defaults. Question II: I would ask that the rendering GUI is modified. The label of the skydome shader should be changed into something like 'Advanced atmospheric light model' with an added warning '(this will disable some shaders)'. The Rayleigh, Mie and density selection panel is obsolete for the user (the weather system sets these based on its atmosphere layer model) and sho
