On Wed, Oct 24, 2012 at 1:27 PM, Renk Thorsten <thorsten.i.r...@jyu.fi> wrote:
>> I realize that I'm confused about whether you are working on Stuart's
>> clouds in C++ or clouds in Nasal.
>> How are you generating the tracer? I gather that it
>> doesn't use any textures.
>
> If a flag is set in the cloud definition, after a cloud (consisting of a
> number of sprites) has been generated, a tracer is inserted at the same
> position in the center of the cloud. Currently only works if you insert
> clouds from Nasal. Formally a tracer is a cloud with just a single sprite,
> but a cloud with a top shade factor set to zero (i.e. a pitch-black top) -
> which is why we know in the shader it can't be a real cloud.
>
>> 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.
>
> I basically don't - if a vertex not belonging to a tracer arrives in
> tracer.vert, all the vertex shader does is to move it out of the view
> frustrum (come to think of it, the if-statement in the fragment shader
> shouldn't even be necessary - sorry, this is just mess in progress). Also the
> effect currently declares a texture which I'm not using because at some point
> I wanted to test round tracers.
>
If I understand correctly, you have only one model of the cloud, which
has a bunch of sprites and a few tracer polygons. I don't know if this
is practical in the current system, but I'm saying that it would be
better to draw only the tracers in the tracer pass and the sprites in
the real pass as you do know which is which in advance. I do
appreciate the clipping trick in the vertex shader :)
>> 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?
>
> By putting
>
> if (gl_FragCoord.y > 300) {discard;}
>
> early into the terrain fragment shader.
OK
>
>> 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.
>
> Thanks for the pointers - I'll have a look. How come it works for clouds
> then? The normal cloud passes all use alpha testing...
They don't write the Z buffer at all, do they?
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
