Re: [Flightgear-devel] More Rembrandt Feedback
>> No moon shadows? I see a long discussion coming up about how unrealistic >> this all is ;-) >> > > Did we not have a discussion a while back about our nights being too > dark? I > think moonlight would be great, but we would need to take into account > the > phases of the moon. Something to do as a future enhancement. I actually wanted to do that a while ago and asked for some help - there just didn't seem anyone interested around... [quote]Now that lightfields are in GIT, it occurred to me that we could have moonlight with this bit of technology relatively easy (before anyone mentions Project Rembrandt, I was thinking of rendering cloud layers in the moonlight, or snow-covered mountain ranges, i.e. for any distance from high altitude). The way I would imagine doing this is as follows: It would need the moon position passed to the shaders just like the sun, i.e. say as gl_lightSource[1].position. In addition it would need the moon phase (0: new moon, 1: full moon) as a property, to be passed as a uniform. A conditional statement would then check if the sunlight intensity is below some threshold, in which case it would simply switch over to the moon as primary light source (i.e. things are rendered either using sun or moon, but never both) with some smoothing, then simply moonlight and the different position is passed to the subsequent rendering steps, and voila - we could have relatively bright full moon nights, using the same light reduction rules on the ground due to clouds and fog which the sunlight rendering uses. Can the moon position info be passed in this way?[/quote] Cheers, * Thorsten -- 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] [Rembrandt] the plan
De: Martin Spott > > Frederic Bouvier wrote: > > > You can try the last code with > > --prop:/sim/rendering/no-16bit-buffer=true > > jive: 12:18:06 ~> find .fgfs* > find: No match. > jive: 12:18:17 ~> env | grep \^FG > FG_HOME=/opt/FlightGear > FG_ROOT=/home/martin/SCM/FlightGear/fgdata > jive: 12:18:19 ~> fgfs --prop:/sim/rendering/shaders/quality-level=0 > --timeofday=noon --enable-rembrandt > --prop:/sim/rendering/no-16bit-buffer=true > > > Starts with a funnily flickerling splash screen and results in this > image - still not perfect, but a lot better now: > > http://foxtrot.mgras.net/bitmap/FGFS/fgfs-rembrandt_02.png > > Log: > > http://foxtrot.mgras.net/bitmap/FGFS/fgfs-rembrandt_02.txt This shader error affects shadow rendering and for now, I don't have a replacement. The only thing I can propose for this kind of card, is to disable shadow rendering : --prop:/sim/rendering/shadows/enabled=false this property is settable at run time. It can also help people with performance problems. 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] [SPAM] Re: Apologies to Fred - more feedback
> De: Anders Gidenstam > > On Wed, 4 Apr 2012, James Turner wrote: > > > 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. > > One thing: I think ecNormal should be normalized before use - IIRC > the interpolation between the vertex shader output and the input to > individual fragments might change the length of the normal (since it typically > is linear in each dimension). Good point Anders. Can push that fix ? Thank you -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] [SPAM] Re: Apologies to Fred - more feedback
On Wed, 4 Apr 2012, James Turner wrote: > 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. One thing: I think ecNormal should be normalized before use - IIRC the interpolation between the vertex shader output and the input to individual fragments might change the length of the normal (since it typically is linear in each dimension). Cheers, Anders -- --- Anders Gidenstam WWW: http://gitorious.org/anders-hangar http://www.gidenstam.org/FlightGear/ -- 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
Re: [Flightgear-devel] More Rembrandt Feedback
The phase of the moon is pretty much just the angle difference between the sun light vector and the moon light vector. small angle = crescent moon, zero angle = solar eclipse, 45 degree angle = 1/4 moon, 90 degree angle = 1/2 moon, 135 degree angle = 3/4 moon, 179 degree angle = full moon, 180 degrees = another eclipse. On Apr 4, 2012 8:11 AM, "Vivian Meazza" wrote: > Torsten wrote > > > > > The cost of shadows is the difference in fps between night and day, as > > > shadow rendering is disabled at night. > > > > > > No moon shadows? I see a long discussion coming up about how unrealistic > > this all is ;-) > > > > Did we not have a discussion a while back about our nights being too dark? > I > think moonlight would be great, but we would need to take into account the > phases of the moon. Something to do as a future enhancement. > > Vivian > > > > > -- > 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] More Rembrandt Feedback
Torsten wrote > > The cost of shadows is the difference in fps between night and day, as > > shadow rendering is disabled at night. > > > No moon shadows? I see a long discussion coming up about how unrealistic > this all is ;-) > Did we not have a discussion a while back about our nights being too dark? I think moonlight would be great, but we would need to take into account the phases of the moon. Something to do as a future enhancement. Vivian -- 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] Updated Cub and c172p for Rembrandt
Am 03.04.2012 18:02, schrieb Gene Buckle: > On Tue, 3 Apr 2012, Martin Spott wrote: > >> Stuart Buchanan wrote: >> >>> How's the cockpit project going BTW? >> >> Having a sponsor to pay the transport would be cool ;-) >> >> Aside from that, we're looking for a couple of small (8-12" range), >> bright and preferrably identical colour TFT displays for the panel, >> because the mechanics of the yoke prevent installing bigger ones. >> > Martin, if you were to pick up a copy of Mike Powell's book "Building > Simulated Aircraft Instruments", you could fill that whole panel pretty > cheaply, including a servo based artificial horizon. I would be happy to > supply you with any custom metal parts that they need. Our fgpanel instruments can look realistic but nothing's better than the real thing... I have a couple of real instruments that are no longer airworthy and I am evaluating how to drive them from FlightGear. The VOR and ADF indicators are simple as they are driven electrically and creating the synchro signals should be doable with a microcontroller. The gyro and pressure instruments require some mechanical work and Mike Powell's website just induced the nice idea of aircoils into my brain. If he only had an e-Book for download! 17$ for overseas S&H adds nearly 50% to the price of the book :-( Torsten -- 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] More Rembrandt Feedback
> The cost of shadows is the difference in fps between night and day, as > shadow rendering is disabled at night. No moon shadows? I see a long discussion coming up about how unrealistic this all is ;-) Torsten -- 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
