The new DirectX 11 features in Crysis 2 were documented quite nicely by Crytek in this document: http://www.mycrysis.com/sites/default/files/support/download/c2_dx11_ultra_upgrade.pdf
It sounds good: they use tessellation only where required, and tessellation uses an adaptive approach. They use Parallax Occlusion Mapping (POM) for other areas, such as floors, like in the earlier Crysis.
But then I found this interesting article on Tech Report, about Crysis 2’s tessellation: http://techreport.com/articles.x/21404
As you can see here, Crytek was right about using tessellation only on selected objects. The non-tessellated/POM surfaces don’t turn up in their highlighted views. Then again, although they use the Ultra setting, there seem to be a LOT of triangles on those objects.
I am not too surprised, I believe I already said earlier that nVidia would ‘make sure’ that Crysis 2 would run better on their hardware, given that it’s a The Way It’s Meant To Be Played title. nVidia has tessellation and DirectCompute as two effective weapons to bend DX11 performance to their advantage. It turns out that I could be right.
There are a few thoughts that came to mind though:
- This is only the Ultra setting, so very high/overkill graphics settings are expected (basically the “you asked for it”-setting… the original Crysis was notorious for having way over the top detail settings as well…). What does tessellation look like with lower settings? Because these high polycounts could either mean that their adaptive algorithm just takes a very high upper limit at the ultra setting, in which case lower settings will look considerably less high-poly, even though they still use tessellation. Then again, if the source geometry is already very highpoly, then there really is not much choice. Tessellation cannot remove polygons, it can only add them to the source mesh. So what are we looking at here? Is it the artist’s fault or the fault of whoever picked the upper limits for tessellation?
- The fact that the water mesh is rendered underneath the entire scene may look a bit sloppy at first, but is understandable, depending on how the effect works. So I wonder, what does the water effect look like in DX9? Does it still run under the entire level? It could be that they use a screen-space approach, so that it doesn’t really matter, it doesn’t try to do water for the ‘entire level’, just for whatever is in view. And in that case, it would be quite difficult to solve the visibility more accurately in screenspace. It may be faster just not to do it. So I’m not sure if the water-thing is something DX11-specific, let alone that it is deliberately trying to increase the tessellation workload that way.
- Apparently, despite the very high polycounts, nVidia cards don’t get much of a performance hit from it. You wouldn’t be able to tell by looking at the differences between DX9 and DX11 performance. Aside from tessellation, DX11 also has more detailed water, more advanced shading, shadowing and better post-processing, which would also lower the framerates.
It is a problem for AMD though. AMD added an ‘optimized’ setting to their driver. One user has created some screenshots showing the difference in detail with AMD’s default ‘optimized’ setting, compared to ’64x’, effectively disabling AMD’s optimization and rendering the game as-is (just as nVidia cards render it): http://forums.anandtech.com/showpost.php?p=31992121&postcount=89
From these screenshots it is quite obvious that there is an impact in visual detail. The whole point of tessellating the brick walls is lost, as AMD’s chosen ‘default’ tessellation level is too low to make the triangles follow the contours of the bricks accurately. The resulting effect is severe aliasing, that I would consider to look worse than just non-tessellated wall.
This is partly because AMD only applies an upper limit, as I mentioned before… The highly tessellated objects mean that the workload is quite high everywhere in the scene. S0 when AMD’s limit kicks in, it limits the tessellation detail at the most detailed objects first, which cuts into the visible detail directly. A lot of the scene may be ‘just under’ the limit, but still very high workload… So you push the limit further and further down, totally destroying the detail. As I said before, AMD would have done better to scale down the tesesllation factor first. That way you reduce the detail over the entire scene, which means more performance gain with less direct impact to visual quality (lowering detail on far-away objects is less obvious… you can spend that saved performance on more detail at the nearby objects).
I have to say though, as a developer I am quite happy with this tessellation, and the fact that at least nVidia’s cards seem to be able to handle it. I have said it before: the whole point of tessellation is to be able to generate as much detail as possible. Pixar’s REYES rendering technique depends on it, and they subdivide every mesh down to subpixel-level. So what I want to see is hardware that is capable of delivering such incredible polygon counts, and we are clearly on that road now.