[Flightgear-devel] Shader - Environment interfacing issues

2012-04-13 Thread Renk Thorsten
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 awes

Re: [Flightgear-devel] Shader - Environment interfacing issues

2012-04-13 Thread Emilian Huminiuc
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

[Flightgear-devel] An empassioned plea

2012-04-13 Thread Vic Marriott
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

Re: [Flightgear-devel] Shader - Environment interfacing issues

2012-04-13 Thread Renk Thorsten
> (*)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, an

Re: [Flightgear-devel] Shader - Environment interfacing issues

2012-04-13 Thread Emilian Huminiuc
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 a

Re: [Flightgear-devel] Shader - Environment interfacing issues

2012-04-13 Thread Erik Hofman
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

Re: [Flightgear-devel] An empassioned plea

2012-04-13 Thread Erik Hofman
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. > > Thoug

Re: [Flightgear-devel] Shader - Environment interfacing issues

2012-04-13 Thread Martin Spott
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

Re: [Flightgear-devel] Shader - Environment interfacing issues

2012-04-13 Thread Erik Hofman
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

Re: [Flightgear-devel] Shader - Environment interfacing issues

2012-04-13 Thread Renk Thorsten
> 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 th

Re: [Flightgear-devel] Shader - Environment interfacing issues

2012-04-13 Thread 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 ve

Re: [Flightgear-devel] Shader - Environment interfacing issues

2012-04-13 Thread Frederic Bouvier
> 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 ver

Re: [Flightgear-devel] Shader - Environment interfacing issues

2012-04-13 Thread Renk Thorsten
> 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 y

Re: [Flightgear-devel] Shader - Environment interfacing issues

2012-04-13 Thread Emilian Huminiuc
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 nor

Re: [Flightgear-devel] Shader - Environment interfacing issues

2012-04-13 Thread Emilian Huminiuc
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 > nois

[Flightgear-devel] (no subject)

2012-04-13 Thread Renk Thorsten
>> '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

Re: [Flightgear-devel] Shader - Environment interfacing issues

2012-04-13 Thread Emilian Huminiuc
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 transform

Re: [Flightgear-devel] (no subject)

2012-04-13 Thread Emilian Huminiuc
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

Re: [Flightgear-devel] Now Rembrandt here...

2012-04-13 Thread Arnt Karlsen
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

Re: [Flightgear-devel] Shader - Environment interfacing issues

2012-04-13 Thread Frederic Bouvier
> 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 su

Re: [Flightgear-devel] Shader - Environment interfacing issues

2012-04-13 Thread Renk 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) 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

Re: [Flightgear-devel] List Etiquette was airport list

2012-04-13 Thread Ron Jensen
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;   

Re: [Flightgear-devel] Now Rembrandt here...

2012-04-13 Thread Gene Buckle
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 wit

Re: [Flightgear-devel] List Etiquette was airport list

2012-04-13 Thread gapalp
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

[Flightgear-devel] Adding Airports

2012-04-13 Thread J. Holden
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 a

[Flightgear-devel] Water shader issues

2012-04-13 Thread Renk Thorsten
> 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

Re: [Flightgear-devel] Water shader issues

2012-04-13 Thread Vivian Meazza
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 t

Re: [Flightgear-devel] Adding Airports

2012-04-13 Thread flightgear
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] Addi

Re: [Flightgear-devel] Adding Airports

2012-04-13 Thread J. Holden
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 appen

[Flightgear-devel] Workaround: c172p on MacBook Pro with Intel HD3000

2012-04-13 Thread Olaf Flebbe
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 text

Re: [Flightgear-devel] Workaround: c172p on MacBook Pro with Intel HD3000

2012-04-13 Thread Chris Forbes
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 K