Flat surfaces are being tessellated. Therefore the reviewer has made the point that it's use in such examples aren't needed. Along with the other points made (distance objects using low textures, low poly count AI planes, etc). While I agree with the observation of the author of that review you obviously don't. I don't agree with why you think he's wrong as you aren't able to provide anything that can refute what was said. Having said that we aren't going to agree. So there is no need to argue with me (the messenger). If you are that upset about it you can by all means take it with the author of the article.
There's no need to argue with him, since none of us knows what happens in the renderer, but, but I do not agree with his
assurement that the surface IS flat. The resulting tesselated scene (at that distance, and LOD) is apparently flat, yes, but that does not mean that it IS flat or that it SHOULD be flat. This is what I mean:
Represented in green the desired geometry after displacement has been applied.
Represented in red is the actual resulting geometry as seen in the screenshot from TR. Red dots represent the vertex.
Even if average of nearby texels had been used the surface would appear flat (but higher), because theres simply not enough vertex to represent the desired surface with such a small number of vertex/tris at that LOD. But as LOD inctreases because the plane is closing the detailed bumps would become more apparent and detailed.
The thing is that there's no way to prevent that kind of thing, except using averages like I said, because that often times solves most of those problems (in a similar way as to how antialiasing gets rid of edges, even though its just a trick to the eye), but if the heigh of the heigh/displacement map is low and there's many bumps per vertex, the average will always be a flat surface, which is not the real surface. If you know of a way to prevent that, or know someone who knows how to create an algorithm intelligent enough to know what should be done in real time, call game developers (anyone, all of them!) ASAP because they will probably thank you a lot.*
Annyway, the key factor here is not if you agree with me, or if I agree with the TR guy. The key, here is that Ubisoft does not agree with you, and has created some mountains that look amazing and put them on a benchmark that runs fluently on nearly any DX11 gaming card. At the same time it exposes the weakness and strenght of certain architectures, where the strong arhitecture runs twice as fast at near 200 fps. Deal with that, is the truth.
* The algorithm that I tink it's used normally, looks at the displacement map for variance in the values of nearby texture pixels, if variance is high, a high ammount of tesselation is used. Because if variance is high (white or very light pixels near very dark ones) it means there's going to be a lot of detain there. This works like a charm in characters up close to the camera because arguably the entire character/object is at the same distance LOD and it's high. But it's dodgy for terrain. How can you prevent triangles from scalating in distant objects? Distance LOD, of course, and that's what HAWX actually uses as can be seen in the screeshot. But that's a problem on it's own too, as distance LOD represents a cap over which the algorithm can not bypass, and in my opinion that is what might be happening there. The algorithm is saying "you need lots of polys, because there's a lot of variance" while LOD is saying "maximum level of tesselation is X" and hence the terrain ends up with X ammount of tesselation which is the highest available to him. And that level happens to be not enough to represent the displacement map, but at the same overkill for the end result: an almost flat surface. How can that be avoided before hand and in real time and without becoming a system hog? That's what I want to know. Because if I knew I may even be rich.
. Nor do you need to tessellate objects are far distances (at what distance is subjective). So again this goes back to the practicality of it all. I think AMD is going to fix issues like that in the drivers. But it's not clear what exactly they plan on doing. As for 16 pixels per polygon vs 18 pixels per polygon goes (as proven with flat surfaces) more doesn't mean better. Unfortunately we don't have a comparison to see if there is any dramatic difference. But I were to guess I would think the differences would be minuscule.
