Re: [Flightgear-devel] Rendering passes question

[Tim M. <tim...@gm...>]

On Thu, Jul 19, 2012 at 1:16 PM, Renk Thorsten <tho...@jy...> wrote:
>> This is an optimization to avoid running really expensive shaders on
>> geometry that will be hidden from view. The GPU has an "early Z"
>> capability and won't run a fragment shader if it knows the result will
>> be discarded.
>
> But that can't be all that is going on. In this case I'd expect that if I leave the pass out, the system would slow down. However, what actually happens when I remove the first pass is that the system runs just a bit faster, but I get z-ordering problems for distant objects which sometimes appear in front.
>
I realize that I'm not sure what you mean by the first pass. This
information is for the classic renderer:

In order to combat depth buffer precision problems, we draw the whole
scene in two passes, with a near camera and a far camera. See
Viewer/CameraGroup.cxx. The far view is drawn first, then the depth
buffer is cleared and the near scene is drawn on top. Within each of
those ranges we get good depth buffer precision.

Hmm, on further reflection, it's clear that you don't mean that. OK.
Within effects, we do a first pass that writes the depth buffer. If
you remove that pass and don't change anything else, you will see
artifacts because the later passes don't write to the depth buffer.

Within each camera pass (far camera, near camera), all the passes of a
technique are run.

> Do we actually draw all the scenery in one go, or on a per-tile basis?
All in one go, within the near/far scenes. All the geometry associated
with a pass is "collected" and rendered at once.

>Do we really not run the terrain fragment shader when the terrain is seen through the cockpit floor (my system seems to slow down even though no terrain is seen in the event and the framerate responds to my shader quality settings)?

That would be nice, but the near/far camera defeats that optimization :(
>
> Much to my annoyance, coordinate systems for instance are discontinuous across tile boundaries, which leads for instance to artefacts when using 3d noise to create variations in the fog density, but I don't know if coordinate discontinuities have anything to do with what we draw.

That's a different issue. Earth centric coordinates can't be stored in
single precision floating point at the required precision, so each
tile has a local coordinate system. A "world wide" noise basis would
be a good project.
>
> Somehow, this connects to the render bins, right?
Yes, the geometry for a pass is sorted into a specific render bin. The
cull phase does this. EffectCullVisitor walks the scene, putting
geometry into multiple render bins according to the pass description
in the effect files. Then all the render bins are rendered by OSG.
>
> Thanks, for any help, I'd really like to understand this better (I am reading up the theory as we talk...), so I promise to (mostly) ask Flightgear specific things.

The depth-pass-only pass is a well known optimization, but the fact it
is not helping implies that our bottleneck is not in fragment
processing. I've suspected for years that it lies on the CPU, and have
been trying to optimize our scene graph a bit...

Tim
>
> * Thorsten
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Flightgear-devel mailing list
> Fli...@li...
> https://lists.sourceforge.net/lists/listinfo/flightgear-devel