Re: [Flightgear-devel] Apologies to Fred - more feedback
> I won't get the chance to fix this until after the weekend, but in > the meantime at least the Rembrandt performance problems with > random vegetation should be resolved. Already fixed ;) Regards, -Fred -- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Apologies to Fred - more feedback
On Wed, Apr 4, 2012 at 5:40 PM, Frederic Bouvier wrote: > The first thing to do it to convert the tree shader in a way it > outputs correctly normals and colors to the 3 buffers. As long > as you can see identically shaded objects in all three buffers, > it's not good. > > You may want to look into deferred-gbuffer[.vert/.frag] shaders > to see how to use gl_FragData instead of gl_FragColor. It's > important to leave out all kind of shading. If you want the > trees look cylindrical (put a better word here) and not flat, > you may bake a normal that is not strictly toward the viewer, > as it is really a flat billboard, but you can leave that for > later. I've managed to migrate the tree shaders to Rembrandt. Pretty straightforward - thanks for the good instructions and examples. I've checked in an update to git, but this morning realized that I'd made a mistake in the effect file (tree.eff) in allowing both non-Rembrandt and Rembrandt versions to co-exist. Specifically I've created two techniques with the same n= value, so the Rembrandt version is being over-written by the non-Rembrandt version. I won't get the chance to fix this until after the weekend, but in the meantime at least the Rembrandt performance problems with random vegetation should be resolved. -Stuart -- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Apologies to Fred - more feedback
> Fred wrote: > PS: is there a volunteer to restore shadow settings in the GUI ? Working on it ;) -- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Apologies to Fred - more feedback
> De: "Stuart Buchanan" > > On Wed, Apr 4, 2012 at 5:40 PM, Frederic Bouvier wrote: > > As for the performance, I have a vague recollection that you > > say that the trees are first drawn alpha-tested and then > > alpha-blended. Can you elaborate on this if it's true ? > > Yes. There's some documentation describing how it works > in Effects/tree.eff: > > > Trees are drawn in two passes. The first draws the opaque parts > with z writes enabled. The second draws the the transparent bits > with z testing enabled and z writes disabled. The transparent > tree silhouettes will blend correctly against the opaque > geometry. They may cause artifacts when blending against other > edges, but the overall "forest" is supposed to be nice and > fuzzy. There might also be artifacts when blending over other > transparent objects, but that's mostly unavoidable. > > Note: no sorting needed! > > Tim Moore was responsible for it, so I don't have any further > insight. By toggling the /sim/rendering/shadows/enabled, we can see that the performance problem is with rendering into the shadow maps. It is significant when the density is high Regards, -Fred PS: is there a volunteer to restore shadow settings in the GUI ? For the moment, there is the map size and the global toggle. There are properties in the preferences that we can try to reimplement later. There are also new parameters like the number of cascades (1 to 4) and the ranges for each cascade that would be interesting to have. -- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Apologies to Fred - more feedback
On Wed, Apr 4, 2012 at 5:40 PM, Frederic Bouvier wrote: > As for the performance, I have a vague recollection that you > say that the trees are first drawn alpha-tested and then > alpha-blended. Can you elaborate on this if it's true ? Yes. There's some documentation describing how it works in Effects/tree.eff: Trees are drawn in two passes. The first draws the opaque parts with z writes enabled. The second draws the the transparent bits with z testing enabled and z writes disabled. The transparent tree silhouettes will blend correctly against the opaque geometry. They may cause artifacts when blending against other edges, but the overall "forest" is supposed to be nice and fuzzy. There might also be artifacts when blending over other transparent objects, but that's mostly unavoidable. Note: no sorting needed! Tim Moore was responsible for it, so I don't have any further insight. -Stuart -- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Apologies to Fred - more feedback
> On 4 Apr 2012, at 17:22, Frederic Bouvier wrote: > > > It was part of a "fix" I pushed late yesterday night. My NVidia > > driver > > didn't protest though. > > > > Thank you for finding this and for the debugging help. > > No problem, delighted to help any way I can. > > I wasn't complaining at you, more at the state of GLSL where it seems > the combination of 'what works' varies for each person who tries - > but everything seems to work on nVidia ;) NV 7xxx and below have a broken opengl (at least in glsl) that impedes shadows for the moment. I have to admit they improve lately ;-) -Fred -- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Apologies to Fred - more feedback
> Martin wrote: > Oh yeah, isn't consistency a wonderful good !? I'm offering a > virtual Whisky for the task of adding a switch just to "disable > shaders" ;-) The original reason for that was discussed here: http://code.google.com/p/flightgear-bugs/issues/detail?id=643 I've commited a fix for it, now the skydome shader is disabled when /sim/rendering/shaders/quality-level=0. Note that the quality-slider has no effect on the skydome shader, because it is still experimental... Please test and serve yourself a whisky if it works ;-) -- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Apologies to Fred - more feedback
Hi Stuart, > > On Wed, Apr 4, 2012 at 5:05 PM, Frederic Bouvier wrote: > > You may also want to disable vegetation for better performance : > > --prop:/sim/rendering/random-vegetation=0 > > > > Regards, > > -Fred > > Fred, > > I'd like to help out fixing bugs/limitations in Rembrandt. Given > I wrote the random vegetation code, is this somewhere where > I could lend a hand? > > I had a look at the code last night, and tried just setting the > shadow camera to cull the vegetation nodes, but it didn't improve > performance in any significant way. Have you any thoughts > about how this should be fixed? > > BTW - very much appreciate the top quality puns from the last > couple of days! The first thing to do it to convert the tree shader in a way it outputs correctly normals and colors to the 3 buffers. As long as you can see identically shaded objects in all three buffers, it's not good. You may want to look into deferred-gbuffer[.vert/.frag] shaders to see how to use gl_FragData instead of gl_FragColor. It's important to leave out all kind of shading. If you want the trees look cylindrical (put a better word here) and not flat, you may bake a normal that is not strictly toward the viewer, as it is really a flat billboard, but you can leave that for later. I updated the wiki page to describe the new buffer layout. As for the performance, I have a vague recollection that you say that the trees are first drawn alpha-tested and then alpha-blended. Can you elaborate on this if it's true ? Don't hesitate to ask if something is not clear or incomplete. Regards, -Fred -- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Apologies to Fred - more feedback
On 4 Apr 2012, at 17:22, Frederic Bouvier wrote: > It was part of a "fix" I pushed late yesterday night. My NVidia driver > didn't protest though. > > Thank you for finding this and for the debugging help. No problem, delighted to help any way I can. I wasn't complaining at you, more at the state of GLSL where it seems the combination of 'what works' varies for each person who tries - but everything seems to work on nVidia ;) James -- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Apologies to Fred - more feedback
> On 4 Apr 2012, at 17:00, Frederic Bouvier wrote: > > > Thank you James, > > > > Can you push that to gitorious ? > > Done. > > Looking at the language docs, 'varying' in a fragment shader really > is a synonym for 'in', and hence, it makes sense (to me) that > assignment to an input is disallowed. > > But I'm curious, if *no one* else saw this issue, how tolerant most > drivers are. So far I have the impression my drivers (that's Ati / > Apple) are: > > - strict about the language compared to nVidia (or fglrx? or Ati > Windows?) > - have lower limits than other people's hardware / platforms > - aren't very up to date! (in terms of supported GLSL version) > > Taken together, this does *not* make me happy - but so long as we can > find a solution to each problem It was part of a "fix" I pushed late yesterday night. My NVidia driver didn't protest though. Thank you for finding this and for the debugging help. Regards, -Fred -- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Apologies to Fred - more feedback
On Wed, Apr 4, 2012 at 5:05 PM, Frederic Bouvier wrote: > You may also want to disable vegetation for better performance : > --prop:/sim/rendering/random-vegetation=0 > > Regards, > -Fred Fred, I'd like to help out fixing bugs/limitations in Rembrandt. Given I wrote the random vegetation code, is this somewhere where I could lend a hand? I had a look at the code last night, and tried just setting the shadow camera to cull the vegetation nodes, but it didn't improve performance in any significant way. Have you any thoughts about how this should be fixed? BTW - very much appreciate the top quality puns from the last couple of days! -Stuart -- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Apologies to Fred - more feedback
On 4 Apr 2012, at 17:00, Frederic Bouvier wrote: > Thank you James, > > Can you push that to gitorious ? Done. Looking at the language docs, 'varying' in a fragment shader really is a synonym for 'in', and hence, it makes sense (to me) that assignment to an input is disallowed. But I'm curious, if *no one* else saw this issue, how tolerant most drivers are. So far I have the impression my drivers (that's Ati / Apple) are: - strict about the language compared to nVidia (or fglrx? or Ati Windows?) - have lower limits than other people's hardware / platforms - aren't very up to date! (in terms of supported GLSL version) Taken together, this does *not* make me happy - but so long as we can find a solution to each problem James -- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Apologies to Fred - more feedback
Gijs de Rooy wrote: > From James Turner: >> On 4 Apr 2012, at 15:56, Frederic Bouvier wrote: >> > You disabled *all* shaders, right ? >> >> --prop:/sim/rendering/shaders/quality-level=0 > No FG at hand, but from memory: that doesn't disable the skydome shader. Oh yeah, isn't consistency a wonderful good !? I'm offering a virtual Whisky for the task of adding a switch just to "disable shaders" ;-) Cheers, Martin that's an old topic, isn't it :-) -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Apologies to Fred - more feedback
You may also want to disable vegetation for better performance : --prop:/sim/rendering/random-vegetation=0 Regards, -Fred - Mail original - > De: "Gijs de Rooy" > À: flightgear-devel@lists.sourceforge.net > Envoyé: Mercredi 4 Avril 2012 17:53:31 > Objet: Re: [Flightgear-devel] Apologies to Fred - more feedback > No FG at hand, but from memory: that doesn't disable the skydome > shader. You can use --prop:/sim/rendering/shaders/skydome=false > (IIRC) for that. > > From: zakal...@mac.com > > Date: Wed, 4 Apr 2012 16:04:11 +0100 > > To: flightgear-devel@lists.sourceforge.net > > Subject: Re: [Flightgear-devel] Apologies to Fred - more feedback > > > > > > On 4 Apr 2012, at 15:56, Frederic Bouvier wrote: > > > > > You disabled *all* shaders, right ? > > > > --prop:/sim/rendering/shaders/quality-level=0 > > > > In my fgfsrc. > > > > James > > > > > > -- > > Better than sec? Nothing is better than sec when it comes to > > monitoring Big Data applications. Try Boundary one-second > > resolution app monitoring today. Free. > > http://p.sf.net/sfu/Boundary-dev2dev > > ___ > > Flightgear-devel mailing list > > Flightgear-devel@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/flightgear-devel > -- > Better than sec? Nothing is better than sec when it comes to > monitoring Big Data applications. Try Boundary one-second > resolution app monitoring today. Free. > http://p.sf.net/sfu/Boundary-dev2dev > ___ > Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Apologies to Fred - more feedback
Thank you James, Can you push that to gitorious ? Regards, -Fred - Mail original - > De: "James Turner" > À: "FlightGear developers discussions" > > Envoyé: Mercredi 4 Avril 2012 17:51:13 > Objet: Re: [Flightgear-devel] Apologies to Fred - more feedback > > > On 4 Apr 2012, at 15:56, Frederic Bouvier wrote: > > > The shadow is rendered in the image in sunlight.frag so this is not > > the > > problem but the inputs are weird, so is the lighting. > > > > You disabled *all* shaders, right ? > > Just made (and pushed) a Simgear tweak to identify the shader names > :) > > FRAGMENT glCompileShader > "/Users/Shared/FGFS/data/Shaders/deferred-gbuffer.frag" FAILED > FRAGMENT Shader > "/Users/Shared/FGFS/data/Shaders/deferred-gbuffer.frag" infolog: > ERROR: 0:18: Left-hand-side of assignment must not be read-only > > Which apparently is: > > ecNormal = (2.0 * gl_Color.a - 1.0) * ecNormal; > > Guessing that writing to a 'varying' might be the issue, I made a > temporary: > >vec3 normal2 = (2.0 * gl_Color.a - 1.0) * ecNormal; >gl_FragData[0] = vec4( (normal2.xy + vec2(1.0,1.0)) * 0.5, >0.0, 1.0 ); > > And now everything looks good! The intermediate buffers, the shadows, > yes. > > Regards, > James > > -- > Better than sec? Nothing is better than sec when it comes to > monitoring Big Data applications. Try Boundary one-second > resolution app monitoring today. Free. > http://p.sf.net/sfu/Boundary-dev2dev > ___ > Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel > -- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Apologies to Fred - more feedback
No FG at hand, but from memory: that doesn't disable the skydome shader. You can use --prop:/sim/rendering/shaders/skydome=false (IIRC) for that. > From: zakal...@mac.com > Date: Wed, 4 Apr 2012 16:04:11 +0100 > To: flightgear-devel@lists.sourceforge.net > Subject: Re: [Flightgear-devel] Apologies to Fred - more feedback > > > On 4 Apr 2012, at 15:56, Frederic Bouvier wrote: > > > You disabled *all* shaders, right ? > > --prop:/sim/rendering/shaders/quality-level=0 > > In my fgfsrc. > > James > > > -- > Better than sec? Nothing is better than sec when it comes to > monitoring Big Data applications. Try Boundary one-second > resolution app monitoring today. Free. > http://p.sf.net/sfu/Boundary-dev2dev > ___ > Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Apologies to Fred - more feedback
On 4 Apr 2012, at 15:56, Frederic Bouvier wrote: > The shadow is rendered in the image in sunlight.frag so this is not the > problem but the inputs are weird, so is the lighting. > > You disabled *all* shaders, right ? Just made (and pushed) a Simgear tweak to identify the shader names :) FRAGMENT glCompileShader "/Users/Shared/FGFS/data/Shaders/deferred-gbuffer.frag" FAILED FRAGMENT Shader "/Users/Shared/FGFS/data/Shaders/deferred-gbuffer.frag" infolog: ERROR: 0:18: Left-hand-side of assignment must not be read-only Which apparently is: ecNormal = (2.0 * gl_Color.a - 1.0) * ecNormal; Guessing that writing to a 'varying' might be the issue, I made a temporary: vec3 normal2 = (2.0 * gl_Color.a - 1.0) * ecNormal; gl_FragData[0] = vec4( (normal2.xy + vec2(1.0,1.0)) * 0.5, 0.0, 1.0 ); And now everything looks good! The intermediate buffers, the shadows, yes. Regards, James -- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Apologies to Fred - more feedback
On 4 Apr 2012, at 15:56, Frederic Bouvier wrote: > You disabled *all* shaders, right ? --prop:/sim/rendering/shaders/quality-level=0 In my fgfsrc. James -- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Apologies to Fred - more feedback
Too quick. If the 3 buffers show the same image, it's because Multi Render Target (MRT) is not in action. The cause may be that technique 10 of model-default or terrain-default is not chosen. If technique 11 or 12 are used, because of a failed predicate. You get that. The shadow is rendered in the image in sunlight.frag so this is not the problem but the inputs are weird, so is the lighting. You disabled *all* shaders, right ? Regards, -Fred - Mail original - > De: "Frederic Bouvier" > À: "FlightGear developers discussions" > > Envoyé: Mercredi 4 Avril 2012 16:31:02 > Objet: Re: [Flightgear-devel] Apologies to Fred - more feedback > > Hi James, > > a quick reply, to say that most likely, the shader with a problem is > sunlight.frag > > Regards, > -Fred > > > - Mail original - > > De: "James Turner" > > À: "FlightGear developers discussions" > > > > Envoyé: Mercredi 4 Avril 2012 15:49:33 > > Objet: [Flightgear-devel] Apologies to Fred - more feedback > > > > Before I say anything else, please know this work is hugely > > appreciated, and if there's any more I can do to help, just ask. > > > > With latest everything, as of a few minutes ago, something odd has > > happened: > > > > http://files.goneabitbursar.com/fg/rembrandt-ati-mac-040412.png > > > > Note > > - the normal and specular buffers seem to have gone 'wrong' > > - but the actual shadow is being drawn without the previous > > Z-fighting issues (especially if I go for a drive) > > - the general lighting has gone weird - especially runway surfaces > > are very bright, and if I rotate the camera around the aircraft, > > at > > more than 180) degrees of views, the shadow is invisible. > > > > In the log I'm getting: > > can't find "Effects/ambient.eff" => Using default, builtin, > > Effects/ambient > > > > And (much) later on: > > > > GPS: someone accessed a deprecated > > property:/instrumentation/gps/wp/wp[1]/altitude-ft > > GPS: someone accessed a deprecated > > property:/instrumentation/gps/wp/wp[1]/altitude-ft > > Initializing Nasal Electrical System > > Loading tile 2892906.stg > > Loading stg file /Users/jmt/Library/Application > > Support/FlightGear/TerraSync/Objects/w010n50/w004n55/2892906.stg > > > > FRAGMENT glCompileShader "" FAILED FRAGMENT Shader "" infolog: > > ERROR: > > 0:18: Left-hand-side of assignment must not be read-only > > glLinkProgram "" FAILED Program "" infolog: ERROR: One or more > > attached shaders not successfully compiled > > > > ... we really need to fix something to include the shader code or > > file name or something :) > > > > James > > > > > > -- > > Better than sec? Nothing is better than sec when it comes to > > monitoring Big Data applications. Try Boundary one-second > > resolution app monitoring today. Free. > > http://p.sf.net/sfu/Boundary-dev2dev > > ___ > > Flightgear-devel mailing list > > Flightgear-devel@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/flightgear-devel > > > > -- > Better than sec? Nothing is better than sec when it comes to > monitoring Big Data applications. Try Boundary one-second > resolution app monitoring today. Free. > http://p.sf.net/sfu/Boundary-dev2dev > ___ > Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel > -- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Apologies to Fred - more feedback
Hi James, a quick reply, to say that most likely, the shader with a problem is sunlight.frag Regards, -Fred - Mail original - > De: "James Turner" > À: "FlightGear developers discussions" > > Envoyé: Mercredi 4 Avril 2012 15:49:33 > Objet: [Flightgear-devel] Apologies to Fred - more feedback > > Before I say anything else, please know this work is hugely > appreciated, and if there's any more I can do to help, just ask. > > With latest everything, as of a few minutes ago, something odd has > happened: > > http://files.goneabitbursar.com/fg/rembrandt-ati-mac-040412.png > > Note > - the normal and specular buffers seem to have gone 'wrong' > - but the actual shadow is being drawn without the previous > Z-fighting issues (especially if I go for a drive) > - the general lighting has gone weird - especially runway surfaces > are very bright, and if I rotate the camera around the aircraft, at > more than 180) degrees of views, the shadow is invisible. > > In the log I'm getting: > can't find "Effects/ambient.eff" => Using default, builtin, > Effects/ambient > > And (much) later on: > > GPS: someone accessed a deprecated > property:/instrumentation/gps/wp/wp[1]/altitude-ft > GPS: someone accessed a deprecated > property:/instrumentation/gps/wp/wp[1]/altitude-ft > Initializing Nasal Electrical System > Loading tile 2892906.stg > Loading stg file /Users/jmt/Library/Application > Support/FlightGear/TerraSync/Objects/w010n50/w004n55/2892906.stg > > FRAGMENT glCompileShader "" FAILED FRAGMENT Shader "" infolog: ERROR: > 0:18: Left-hand-side of assignment must not be read-only > glLinkProgram "" FAILED Program "" infolog: ERROR: One or more > attached shaders not successfully compiled > > ... we really need to fix something to include the shader code or > file name or something :) > > James > > > -- > Better than sec? Nothing is better than sec when it comes to > monitoring Big Data applications. Try Boundary one-second > resolution app monitoring today. Free. > http://p.sf.net/sfu/Boundary-dev2dev > ___ > Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel > -- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Apologies to Fred - more feedback
Before I say anything else, please know this work is hugely appreciated, and if there's any more I can do to help, just ask. With latest everything, as of a few minutes ago, something odd has happened: http://files.goneabitbursar.com/fg/rembrandt-ati-mac-040412.png Note - the normal and specular buffers seem to have gone 'wrong' - but the actual shadow is being drawn without the previous Z-fighting issues (especially if I go for a drive) - the general lighting has gone weird - especially runway surfaces are very bright, and if I rotate the camera around the aircraft, at more than 180) degrees of views, the shadow is invisible. In the log I'm getting: can't find "Effects/ambient.eff" => Using default, builtin, Effects/ambient And (much) later on: GPS: someone accessed a deprecated property:/instrumentation/gps/wp/wp[1]/altitude-ft GPS: someone accessed a deprecated property:/instrumentation/gps/wp/wp[1]/altitude-ft Initializing Nasal Electrical System Loading tile 2892906.stg Loading stg file /Users/jmt/Library/Application Support/FlightGear/TerraSync/Objects/w010n50/w004n55/2892906.stg FRAGMENT glCompileShader "" FAILED FRAGMENT Shader "" infolog: ERROR: 0:18: Left-hand-side of assignment must not be read-only glLinkProgram "" FAILED Program "" infolog: ERROR: One or more attached shaders not successfully compiled ... we really need to fix something to include the shader code or file name or something :) James -- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel