*spin-off* Tessellation
- Thread starter almighty
- Start date
Sigfried1977
Legend
And I'm surprised how much stock some people put into bullet points. Most of the stuff on the next gen systems looked (and this honestly surprised me) amazingly detailed and certainly not at all poly-starved, so what does it really matter?
Ryse looks way too rounded not to be, as do most of the games I've seen footage of. It was mentioned in the CoD tech video, but I'd guess most games are making use of tessellation.
hesido
Regular
I'm expecting full tesselation friendly pipelines where devs do not have to cater to the old-gen consoles.
But I'm surprised, for example, Killzone SF uses 7 lods, for example, it doesn't have to deal with old-gen tech. Why would you need so much LOD if you have tesselation?
Tessellation doesn't solve the LOD problem. For interesting shapes (sharp details / edges), you need LODs. In general triangles are not a good rendering primitive if you want to have perfect LOD (perfectly scaling rendering cost, memory access cost, zero popping and infinite draw distance).
hesido
Regular
Thanks Sebbbi, your posts are always very informative and I'm actually bookmarking some of them.
What I was expecting from this gen was having still a couple of LODs and tesselation in between, but from your remarks I understand the tesselators are not programmable to do something like those Pixar Subdivison surfaces where you can have sharp edges using edge weighting, and doubling an edge loop for sharp creases is not really feasible for a game engine (waste of geometry), and devs have so much RAM that keeping those 7 lods is no longer a problem. If all those LODS have to be tweaked manually, I'm sorry for 3D artists, I was hoping this gen would reduce strain on 3D artists on that front.
GCN isn't the fastest arch to run tesselation on.
I'm extremely interested in games that seem to manage to use tesselation effectively though. For instance GT6, not even next-gen, does seem to have managed lod-less adaptive tesselation this time. I'd love to learn more about it, hope they show it in more detail (there's a tiny bit of example in that trailer, but that's not showing very much just yet)
Rys I didnt know you were a fatty......
DX11 tessellators are programmable, and quite flexible. That's not the problem. The problem is that you practically cannot tessellate down to single pixel triangles ("micropolygons"). GPU pixel shader execution is based on 2x2 quads. If a triangle hits even a single pixel in a quad, the whole quad is processed (and pixels outside the triangle are discarded). Tessellation down to single pixel would waste 75% of the pixel shader resources, in addition to being very heavy to triangle setup engines (and vertex/hull shaders). For good efficiency you want to keep triangles larger than 8 pixels (and preferably even larger).
Simple example:
Imagine a brick wall (a building wall for example). Each brick is 20x10 cm in size. There are deep 2 cm gaps between the bricks. A 10 x 10 meter building wall would have approximately 5000 bricks. When the building is far away we want to draw the wall using a single polygon (view from a city from a nearby hill, and there's hundreds of visible buildings).
When we move closer to the wall, the continuous tessellation starts to add new vertices, by sliding them from existing triangle vertices to their new place. Every time a vertex crosses over the deep gaps between the bricks, it goes rapidly down and then up again. This makes the surface look wobbly and unstable. To fix this problem, you need to add edges to each of the gaps (and in generally over all sharp geometry features). This completely fixes the wobbling issues... however now you have 2*5000 = 10000 fixed edges on the building wall (20000 triangles), and it is no longer efficient for far away rendering. You need LODs to solve this issue.
If you have a continuous smooth surface, you can usually perfectly LOD it by tessellation alone. This is often used for terrain rendering... however a high end terrain might have also sharp features such as cobblestone roads, and the problem arises again. We cannot tessellate the road down to 1 pixel micropolygons, and it looks wobbly if we try to keep the average triangle (screen space) size around 8 pixels. W could add add some geometry (edges) to the road, but then the roads would be expensive to render from further away. So basically our options are to add some geometry LODs, or use per pixel (ray cast) based techniques (such as POM or quadtree displacement mapping). Per pixel techniques have perfect LOD (1:1 screen pixel mapping, and around 1:1 memory access), however many of the currently used techniques are limited to height displacement only (cannot be used to form all kinds of meshes). DX11 conservative depth output improves the performance of per pixel techniques (for silhoutte cases and for real depth output), so we might also see them more in the future games.
hesido
Regular
Thanks Sebbbi, very nice and detailed example.
I remember in one of their GCN slides that there's a performance cliff after 15 levels of tesselation, but I don't think this would be much of problem for character tesselation, given that it seems that they'll probably more likely to use it at higher than the highest lod to increase quality for characters very close to the screen.
I thought they increased the performance in their last generation, but it'd be nice to see some benchmarks.
I remember in one of their GCN slides that there's a performance cliff after 15 levels of tesselation, but I don't think this would be much of problem for character tesselation, given that it seems that they'll probably more likely to use it at higher than the highest lod to increase quality for characters very close to the screen.
Hi sebbbi,
So what do you think GT6 is doing? They call it adaptive tesselation - how is that different from 'standard' tesselation? In the latest video from gamersyde, with the new US track in the desert, I've noticed for the first time that the side of the road seems tesselated too. This is on PS3, so they're obviously not burdened by any tesselation support in hardware and are doing something I suspect using SPE jobs ...
So what do you think GT6 is doing? They call it adaptive tesselation - how is that different from 'standard' tesselation? In the latest video from gamersyde, with the new US track in the desert, I've noticed for the first time that the side of the road seems tesselated too. This is on PS3, so they're obviously not burdened by any tesselation support in hardware and are doing something I suspect using SPE jobs ...
How can you possibly tell without seeing the wireframe ?
I always knew the quad based derivatives were going to be a problem down the line :/ It locks you into a system which just can't efficiently handle small polygons.
On the plus side, the workarounds like silhouette detection offer a lot of fun for the developers.
SedentaryJourney
Regular
Isn't adaptive tessellation supported by the 360's GPU? There's an explanation of it here under adaptive subdivision.
How can you tell if thats tess or lods ?
I imagine it's this. It's going to be so "standard", every game will have it, so there's no real reason to mention it in press releases and such, because it's no longer a big deal.
Well, I couldn't find any good example of the tracks, so I've probably imagined things.
On the cars however, it's definitely visible. Angles in windows and such are visibly stepping in GT5 vids, and not in GT6.
Similar threads
