Re: [Flightgear-devel] Rendering strategies

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

On Wed, Nov 27, 2013 at 10:32 AM, Renk Thorsten <tho...@jy...>wrote:
...

> > As ever, there’s a balance here between investing time improving the
> > current rendering pipeline and going for a totally new scheme as Tim
> > suggested - again I hope once we have things split up people will be
> > easier able to experiment with more radical rendering solutions.
>
> One problem is that we need to co-ordinate efforts in some way. I code
> shader effects and that's quite a handful to do - that means I have to live
> with the terrain mesh as it comes to the vertex shader and the info
> available at this point. So if precomputing some quantities at terrain
> generation time helps the rendering, then there needs to be co-ordination
> to do this. And ideally, that would mean that all issues and possibilities
> get on the table, problems get discussed and then we learn what's best.
>
> Yeah, I regret the lack of coordination between the terrain generation
pipeline and the rendering side. There's a lot of work done at load time
because the .btg format is considered immutable.
 >This is going to be another lengthy mail from my side, so... feel free to
skip them. I'm trying to sketch what I view as somewhat problematic.
I believe that most of your mail can be summarized thusly:
>my first question is 'Why?' - I don't understand why this would be a good
long-term strategy.

And that is certainly a fair question. I apologize for the drive-by nature
of my suggestions. It's obvious that I haven't done much FG hacking lately;
any regret I feel about that is tempered by the satisfaction of seeing
others become quite expert in the rendering side of things and do very cool
projects.

Now, Tim, I do respect your knowledge very much (same for Mathias), but
> when I read your list here,
>
> > 1) Change scenery to use a regular grid.
>
I will assert that this is the only sane way to do terrain LOD. The regular
nature of grids, even non-regular grids as formed by data aligned to
geographic coordinates, makes them far easier to decimate than the
triangulated irregular network (TIN) that FG now uses, and transitions
between different levels of detail are similarly much more tractable.

When I say regular grid, I also mean that a terrain tile has a single
texture attached to it at a particular level of detail. The current TIN
approach of mapping many different textures to individual  polygons in a
tile is extremely costly in terms of performance. It was a reasonable thing
to do 20 years ago when it was essential to reduce the number of polygons
in the terrain, but today it is not.

Now, FG is not Google Earth, but many uses of FG aren't that different from
the use cases of a global terrain viewer; some people want a Space Shuttle
simulator, others want to do nape-of-the-earth helicopter flying. IFR
people don't care :) The point is that the rendering should be flexible
enough to handle these different scenarios, especially given that so much
work is going into building detailed terrain.

The one advantage that the TIN approach has over a regular grid is that
vector features, such as roads, streams, and coastlines, are infinitely
sharp, whereas in a texture map scheme these features inevitably look
pixelated as you get close to them. We could take the position that we
don't care except at airports, and treat airports as special polygonal
models that are embedded in the terrain. (That might be desirable in any
case). However, if we assume that we do want to fly low and close to roads
and other vector features, then my next two points come into play:

> 2) Commit to using Rembrandt always.
>
I should have been more sensitive to FG politics when I suggested this. I
haven't used Rembrandt or the ALS stuff much and don't have anything
intelligent to say about the performance of either in current FG. What I
meant by "Rembrandt" is "a deferred renderer." The important requirement
for me is having the depth buffer and triangle normals available as input
to following render stages, which enables this:

> > 3) Apply roads and other vector features as decals.
>
> which allows vector features to be rendered on top of a terrain skin at
whatever resolution is required.

It's not the only solution for getting sharp vector features. The
glPolygonOffset approach mentioned by Peter Sadronzinski is an alternative,
though it is a pain to avoid artifacts without a lot of ad-hoc hackery.
Another approach is used by MSFS X, which generates the terrain texture for
a tile at a given LOD completely at run time (on the CPU!), including
vector features, so that the appropriate texture resolution for sharp
vector features is always available. Nevertheless, I think the approach I
hint at is most interesting for FG. It is not too radical in terms of
current rendering technology and techniques, is implementable in OSG, and
should be quite educational for those who might choose to take it on.

>
> For instance, I fancy that by now I understand enough of the concept of
> deferred rendering that I have a clue what the advantages and disadvantages
> are. A minimal geometry pass makes you largely insensitive to scenery
> vertex count. Rendering only the pixels in the subsequent buffer means you
> do less work if scenery features obscure each other, and you're able to
> specifically tag certain regions, allowing for e.g. multiple lights and
> projection passes for shadows and decals.
>
> But it also means that you need to do all computations in the fragment
> shader, there'll be no cheap interpolation of an expensive, but slowly
> varying function across triangles (that's how ALS light values are obtained
> for instance).  And z-buffering isn't really very effective in a flightsim
> in many situations, you often see pretty much all of the mesh there is to
> see. So for me it's not a given that deferred rendering could compute ALS
> faster - what I do know is that ALS slows down quite a bit if I compute
> light values in the fragment shader.
>
> There isn't anything different about "fragment shaders" on current
hardware, but I assume you know that and are referring to the fact that in
a deferred renderer these shaders are potentially run on every screen
pixel. Are these values that are viewer position dependent, or are they
constant for a given altitude and sun angle? I could imagine ways in which
the calculation could be simplified if you are now able to get good results
interpolating over polygons; you could also store the interpolated values
or some component of them in the renderer's G-Buffer.
...

> So would commiting to Rembrandt be a good strategy for people who like the
> Rembrandt options, or really for everyone else?
>
> ...

>
> But in actual reality, the discussions run that it's posited up-front that
> Rembrant is obviously better, the fact that it doesn't run acceptably for
> many users is then put aside, and I find myself in the ignorant corner.

...
Again, I meant to refer to deferred rendering in general; the sole
implementation of that in FG is Rembrandt :) I'm not familar with the
particular performance problems of Rembrandt. There are performance issues
all over in FG; attacking them would help both deferred and forward
rendering techniques.

>
>
Well, maybe I am - but wouldn't it be better if the people who know better
> would educate me then? Obviously I can write algorithms which tackle
> complex problems, both for weather and shaders, so when I lack some
> information, wouldn't time for an actual discussion and explanation be well
> spent if the next two years of my work then go into a problem which is
> considered more useful?
>
> Yes; I do realize that my curt suggestions may be obnoxious. However, I
need to maximize my limited time too, and there is plenty of information
out there on the different techniques and their approaches.
...

> I don't think that a long-term strategy will go anywhere except to massive
> disappointments if we don't talk about
>
> 1) What is it we actually want to optimize? Framerate? Infinite resolution
> vector terrain rendering? Away from vector terrain rendering towards
> procedural/photo? Something else?
> 2) What is the best way to get there? How do we make enough people
> understand what we're trying to do and what their part should ideally  be?
>
My response was in the context of handling higher resolution terrain.

> 3) How do we not leave users with other hardware behind?

That has always been a profound question... The solution probably lies
along the lines of having different rendering back ends, as James alluded
to.

Tim