On Wed, Oct 24, 2012 at 10:40 AM, Renk Thorsten <thorsten.i.r...@jyu.fi> wrote:
>> I haven't really been following this thread closely... are the
>> "tracers" basically occludes? Are they completely opaque?
>
> Yes, they're completely opaque. That's tracer.frag - if it gets a white
> gl_Color from the vertex shader, it's a real cloud and the fragment is
> dropped, if it gets any other color the pixel is that of a tracer it produces
> an opaque white pixel:
>
> void main(void)
> {
> if (gl_Color == vec4(1.0, 1.0, 1.0, 1.0)) // this is a real cloud
> {discard;}
> gl_FragColor = vec4 (1.0, 1.0, 1.0, 1.0);
> }
>
> 'occluders' would perhaps be a more intuitive name then...
Yes, I meant "occluders;" perhaps I was on "occludes" :)
>
>> One possible optimization for the cloud rendering would be to use
>> polygons that closely follow the outline of the sprite instead of
>> quads; this saves on fill costs.
>
> The tracer/occluder is supposed to deal with the whole cloud, not any
> individual sprite (individual sprites may be just a bit transparent even in
> the center, but a collection of 20 of them is no longer, and in any case
> doing it on a per-sprite basis means 20 times the load for the vertex
> shader). We don't know the shape of the cloud before we create them, and to
> generate a polygon representing in detail the opaque part of the final cloud
> which is a collection of sprites with varying transparency and looks
> different from various positions is something which sounds highly non-trivial
> to me. The tracer is just the simplest guess occluding part of the opaque
> core of the cloud. It doesn't need to be hugely efficient on an individual
> cloud, because there'll be hundreds of them in a row, so even if we get only
> 20 % of any individual cloud, the end result is that we get opaque everywhere
> after 10 clouds rather than doing a row of 200 everywhere.
>
I was thinking more of the sprite rendering, so my comment was a bit
off-topic here. How are you generating the tracer? I gather that it
doesn't use any textures.
I realize that I'm confused about whether you are working on Stuart's
clouds in C++ or clouds in Nasal. Your shader seems like an expensive
way to toggle between tracers and real sprites; it would be much
better to not render the sprite geometry at all in your tracer pass.
>> Also, I'm pretty sure you don't want two-sided lighting for the tracers.
>
> Okay - I'll switch this off then. But that can't explain the depth buffer
> issue, can it?
Probably not.
You should use a <color-mask type="vec4d">0 0 0 0</color-mask>
declaration to turn off color writes when rendering the tracers, since
you don't want them to actually appear in the output. That will save
you some fill costs.
As for not seeing much improvement when the terrain is occluded, I can
think of several possibilities. You said that "I've tested that I am
not vertex-shader dominated by discarding half the pixels of the
terrain in my field of view;" how did you do that?
This optimization depends on being able to do an "early Z" test to not
rasterize big regions of the terrain triangles and avoid running the
terrain shaders on those pixels that will fail the Z test, but this
can only be done if the shader can't affect the Z output value.
Writing the fragment depth would do that (urban shader), but the
classic offenders are "discard" and alpha testing. It's probably worth
checking that the terrain shaders aren't doing those things. A quick
look at terrain-default.eff shows that alpha-test is set to
"transparent" which, IIRC, means that it is set based on whether or
not the texture is transparent; it should probably just be "off."
Tim
------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct
_______________________________________________
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
