Tessellation; Can someone please clarify something for me...

[spine]

Ok, so we've all heard how wonderful and amazing tessellation is/will be; how it will revolutionise gaming etc, but there's something I'm a little hazy on...


As I understand it tessellation takes a low polygon count object and massively boosts it to create rounded edges. What I don't get is how can you possibly do that unless you have an existing high res model to base the new polygons on?

I just don't see how you can magically take an existing low polygon count model and and make it smoother in all the right places. What if it's a space marine (highly likely) with a gun (highly likely); surely you wouldn't want the gun all smoothed off? I remember seeing the truform patch for Quake and it looked shit for this exact reason.


So basically it seems to me that tessellation is little more than advanced geometric LOD handling. You will always need to draw information from an existing 'full' polygon count model. Is that correct?

If so, why is this so revolutionary? Is it simply a breakthrough via the DX11 API that allows this to be done very efficiently? Is that all it is?

 

[Mr. Pedantic]

As far as I understand it, the edges and other small detail in those instances are filled in by a displacement map, which allows the tessellated surface to show greater detail (by dint of the fact that the triangles are smaller).

 

[kllrnohj]

Take bump mapping but have it actually create polygons rather than faking it, so when you look at it from an angle it will still have depth.

Tessellation in the context of DX11 is:
Lower Poly Model + Displacement map = Higher Poly Model

Displacement maps are already very common, as they are used for bump mapping. So bump mapping and tessellation use the same exact inputs, only tessellation gives you much, much better results.

 

[Valset]

its actually been around for a while so "revolutionary" probably is not an good description. If you don't care about being precise you can think of it as a GPU function that mathematically extrapolates additional polygons on an as needed bases. This allows you have a game that looks better but doesn't necessarily have to have same resources allocated to it that it would need to produce the same effects. You do of course loose something in the process though.

 

[kllrnohj]

its actually been around for a while so "revolutionary" probably is not an good description. If you don't care about being precise you can think of it as a GPU function that mathematically extrapolates additional polygons on an as needed bases. This allows you have a game that looks better but doesn't necessarily have to have same resources allocated to it that it would need to produce the same effects. You do of course loose something in the process though.

Well, tessellation looks like it is poised to really take off now. DX11 adds standard support, the assets are already being created for bump mapping, and we have graphics cards with an abundance of unused power. Tessellation provides a very nice path for developers doing a console -> PC port to give PC players a huge IQ increase while doing almost no development or asset creation work.

 

[ShuttleLuv]

Tessellation adds more geometry. Compare the models of GL quake vs the models of Quake 4. Thats tessellation. It is looking to end the square looking models we have come to know.

 

[Valset]

Well, tessellation looks like it is poised to really take off now. DX11 adds standard support, the assets are already being created for bump mapping, and we have graphics cards with an abundance of unused power. Tessellation provides a very nice path for developers doing a console -> PC port to give PC players a huge IQ increase while doing almost no development or asset creation work.

if they make use of it yes. but I doubt its that simple. look at the heaven demo, simply adding tessellation actually detracts from some of the realism more then it adds. the cobble road for example, that would actually be a hell of a road to travel on. and many of the other functions are overdone. Don't get me wrong, I want to see this. but I think its going to be a while

 

[ShuttleLuv]

^^^ Alien Vs Predator, releasing in a mere few weeks, makes pretty heavy use of tessellation. It's looking amazing too btw.

 

[Ryan45]

if they make use of it yes. but I doubt its that simple. look at the heaven demo, simply adding tessellation actually detracts from some of the realism more then it adds. the cobble road for example, that would actually be a hell of a road to travel on. and many of the other functions are overdone. Don't get me wrong, I want to see this. but I think its going to be a while

I think the whole purpose of that benchmark was to be over the top with tessellation, real games will probably be more subtle.

 

[spine]

Take bump mapping but have it actually create polygons rather than faking it, so when you look at it from an angle it will still have depth.

Tessellation in the context of DX11 is:
Lower Poly Model + Displacement map = Higher Poly Model

Displacement maps are already very common, as they are used for bump mapping. So bump mapping and tessellation use the same exact inputs, only tessellation gives you much, much better results.

Ahhhh, it's much clearer to me now. It's the use of a displacement map that I didn't know about.

So with Fermi having a radically improved geometry engine it is poised to really exploit tessellation which is why it has become synonymous with tessellation.

Excellent, that's exactly what I needed to know, cheers, thanks all!

 

[Valset]

^^^ Alien Vs Predator, releasing in a mere few weeks, makes pretty heavy use of tessellation. It's looking amazing too btw.

PC only title ? or a port? if its a DX11 port I would be very interested to see how it does

 

[kllrnohj]

if they make use of it yes. but I doubt its that simple. look at the heaven demo, simply adding tessellation actually detracts from some of the realism more then it adds. the cobble road for example, that would actually be a hell of a road to travel on. and many of the other functions are overdone. Don't get me wrong, I want to see this. but I think its going to be a while

It actually really is that simple. I have no idea what Unigen was doing with the cobblestone road, but that is the only place in that demo (that I know of/remember) where it looked really bad. Look at other places like the rope on the bridge or the stairs. What might have happened with the road was that they tried to cut back too far on the number of polygons. So DX11's tessellation lets you have some control over how many polygons to generate and whether or not it can try to optimize where to place those extra polygons (as in, should they all be evenly spaced, or add more to areas with more complexity). That isn't something the developer has to code themselves, they just pick the options they want to enable and basically get a slider to control how many polygons to add.

I think the rope in the bridge was a superb example of a perfect application for tessellation.

 

[ShuttleLuv]

^ DX11. The demo just came out on steam, but is only DX9 and is extremely buggy. Wait for the DX11 version. It looks pretty good.

 

[Sly]

First heard about this being described while i was looking up parallax mapping back when F.E.A.R. came out and the site was describing different techniques. Parallax mapping was expensive back then and when i got to the tesselation part i thought "How the heck is a card gonna do that in real time?!"

Well, we got it now

I would imagine it would make for very interesting effects. Bulletholes and craters, i wonder if it can be used to actually make something disappear, like say, dynamically put a hole in something.

 

[trinibwoy]

Nope, tessellation (and geometry shaders) is just eye candy so it can't change the hit-boxes of objects. If you want to make a hole in something it has to be done in the physics engine and/or on the CPU where collision detection takes place.

 

[Sly]

Crap, i was was hoping for the CPU to be updated with the new mesh or something. So i guess we'll still be floating over tesselated bomb craters like we do on parallax craters.

Wait. Does that mean we'll also lose per polygon hit detection? For the FPS guys, every bit of cover counts, and the he could be leaning around a tesselated brick wall only to have the bullets go through the extruded bricks coz the CPU didn't know the cover had extended.

Anybody who's played FEAR Combat would know about the weird bullet holes. When someone tries to shoot at another guy that's behind a concrete pillar, the bullet hole parallax map gets applied on those corners, so you get this nice looking hole that you can see at different angles that suddenly gets clipped when the parallax texture gets mapped past the edge of the wall.

If the tesselation was used instead of parallax, that would mean parts of the wall really would get chipped off and you'd get this jagged edge at the corners. But according to what you said, i still wouldn't be able to shoot through the jagged edges coz the CPU still thinks the wall is still whole. That would suck.

I don't suppose this is where hardware physics come in?

 

[Kaldskryke]

Crap, i was was hoping for the CPU to be updated with the new mesh or something. So i guess we'll still be floating over tesselated bomb craters like we do on parallax craters.

Wait. Does that mean we'll also lose per polygon hit detection? For the FPS guys, every bit of cover counts, and the he could be leaning around a tesselated brick wall only to have the bullets go through the extruded bricks coz the CPU didn't know the cover had extended.

Anybody who's played FEAR Combat would know about the weird bullet holes. When someone tries to shoot at another guy that's behind a concrete pillar, the bullet hole parallax map gets applied on those corners, so you get this nice looking hole that you can see at different angles that suddenly gets clipped when the parallax texture gets mapped past the edge of the wall.

If the tesselation was used instead of parallax, that would mean parts of the wall really would get chipped off and you'd get this jagged edge at the corners. But according to what you said, i still wouldn't be able to shoot through the jagged edges coz the CPU still thinks the wall is still whole. That would suck.

I don't suppose this is where hardware physics come in?

The new verts created by tessellation are pretty much created and placed by the Domain Shader, which then go straight to the rasterizer. I think that means the new verts stay entirely in cache thus never see Vram, let alone go back down the bus to the CPU. I'm not a graphics programmer so maybe there's a way to output all of this data back to the game but I'm pretty sure it would come at a very hefty performance cost.

The game's low-poly control meshes should still be a reasonable facsimile to the final geometry so I don't think there will be too terribly many places where the discrepancy leads to a gameplay issue, but it's an interesting problem none-the-less.

Also it seems that nobody has yet replied that displacement mapping is not the only way to store the additional geometry. The OP must not know about "higher order primitives" - there are ways to define curves mathematically using a set of control points and an equation. If you can feed this equation to the domain shader it can move the new tessellated vertices to their new location along the curve.

 

[Kaldskryke]

It actually really is that simple. I have no idea what Unigen was doing with the cobblestone road, but that is the only place in that demo (that I know of/remember) where it looked really bad.

The Heaven benchmark is a benchmark, with an exaggerated unrealistic art style. Yes the roads could have been smoother, and it would have taken maybe 5 minutes of work to change it... but it wouldn't fit with the style of the scene. The jagged appearance is obvious and draws the eyes to how much additional geometry can be added in DX11 mode. Any developer going for a more realistic implementation would simply use a different displacement map.

 

[Valset]

The new verts created by tessellation are pretty much created and placed by the Domain Shader, which then go straight to the rasterizer. I think that means the new verts stay entirely in cache thus never see Vram, let alone go back down the bus to the CPU. I'm not a graphics programmer so maybe there's a way to output all of this data back to the game but I'm pretty sure it would come at a very hefty performance cost.

The game's low-poly control meshes should still be a reasonable facsimile to the final geometry so I don't think there will be too terribly many places where the discrepancy leads to a gameplay issue, but it's an interesting problem none-the-less.

Also it seems that nobody has yet replied that displacement mapping is not the only way to store the additional geometry. The OP must not know about "higher order primitives" - there are ways to define curves mathematically using a set of control points and an equation. If you can feed this equation to the domain shader it can move the new tessellated vertices to their new location along the curve.

you do realize the OP was asking for it to be simplified?

That is an interesting question though. I wonder if can cause some discrepancies. Their is a way to send it back but your right it would cost a lot (disclaimer, I haven't done any graphics programing sense poly-ray came out, and I was thrilled to be working with a true color pallet)

 

[trinibwoy]

The game's low-poly control meshes should still be a reasonable facsimile to the final geometry so I don't think there will be too terribly many places where the discrepancy leads to a gameplay issue, but it's an interesting problem none-the-less.

Yes, exactly. Tessellation is something that will be used to add fine detail to a low poly mesh where the hitbox isn't going to change significantly. For physical alterations to the environment you would rely on your physics engine, not tessellation.

 

[NaturalViolence]

Tessellation in the context of DX11 is:
Lower Poly Model + Displacement map = Higher Poly Model

Tessellation can be done without a displacement map. Read the GF100 whitepages.

Tessellation and displacement maps are two completely separate things. Tessellation essentially "fills in the gaps" if you will using algorithms that make the models have a very smooth appearance, not always necessarily what the developers want to do depending on the model. I did a screen cap of a section of the gf100 whitepages that I think demonstrates it perfectly.

Also it seems that nobody has yet replied that displacement mapping is not the only way to store the additional geometry. The OP must not know about "higher order primitives" - there are ways to define curves mathematically using a set of control points and an equation. If you can feed this equation to the domain shader it can move the new tessellated vertices to their new location along the curve.

You said it perfectly. Wikipedia used to have a great article on this but it got deleted for some reason.

 

[Eruditass]

Crap, i was was hoping for the CPU to be updated with the new mesh or something. So i guess we'll still be floating over tesselated bomb craters like we do on parallax craters.

Wait. Does that mean we'll also lose per polygon hit detection? For the FPS guys, every bit of cover counts, and the he could be leaning around a tesselated brick wall only to have the bullets go through the extruded bricks coz the CPU didn't know the cover had extended.

I haven't played too many FPS's recently, but what games have per-polygon hit detection? I remember CS had big boxy hitboxes, as does TF2.

 

[kllrnohj]

Tessellation can be done without a displacement map. Read the GF100 whitepages.

Tessellation and displacement maps are two completely separate things. Tessellation essentially "fills in the gaps" if you will using algorithms that make the models have a very smooth appearance, not always necessarily what the developers want to do depending on the model. I did a screen cap of a section of the gf100 whitepages that I think demonstrates it perfectly.

http://i112.photobucket.com/albums/n189/NaturalViolence/Untitled-10.jpg

Yes, I know, but the OP wanted simple and when people talk about DX11's tessellation they almost always mean tessellation + displacement map, as tessellation by itself just subdivides the model (which doesn't do much of anything). Hence why I said "in the context of DX11", because it will almost always mean tessellation + displacement mapping, as things like nurbs aren't used games (I'm not even sure if DX11 allows devs to use nurbs at all), making displacement mapping the only practical use of tessellation in DX11.

So while at a technical level tessellation and displacement mapping are separate things, at a practical level the two are joined at the hip.

 

[PrincessFrosty]

As already mentioend, tessellation can increase the amount of detail on a model by using a heightmap. I think it can interpolate though, which is to dynamically increase/decrease detail in meshes.

I expect it's main use is going to be a sort of high detail up close effect where models get really fine detail heightmaps displaced off them, and also probably used for a smoother more dynamic LOD which doesn't change in steps but rather changes the complexity smoothly over distance.

You see both effects in the Heaven benchmark quite a lot, its tessellation is over the top, but then it's meant to be to make the effect obvious to gamers.

 

[necrophile]

Thinking about LOD like that, oblivion would have been a prime candidate for it.