|
From: Tim M. <tim...@gm...> - 2013-11-27 13:38:42
|
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 |