Re: [Flightgear-devel] Apologies to Fred - more feedback

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

2012-04-05 Thread Stuart Buchanan
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

2012-04-04 Thread Gijs de Rooy

> 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

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

2012-04-04 Thread 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.

-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

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

2012-04-04 Thread Gijs de Rooy

> 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

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

2012-04-04 Thread James Turner

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

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

2012-04-04 Thread Stuart Buchanan
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

2012-04-04 Thread James Turner

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

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

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

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

2012-04-04 Thread Gijs de Rooy
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

2012-04-04 Thread James Turner

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

2012-04-04 Thread James Turner

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

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

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

2012-04-04 Thread James Turner
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