Unigine Heaven Benchmark with DX11 Tessellation

I'm actually feeling less than impressed with the "dynamic" nature of this. How would a game dev control how dynamic tesselation looks??

Look the the places where I saw large differences between the dx10 and dx11 screenshots:
The road
The roof shingles
The dragon and its spiked scales

The road looks unnaturally uneven. Who would want that particular look? The extra detail seems a good idea, but dynamically decided by the engine? Why not just program in extra polys?

The roof shingles look alot better in the dx11 shot, but this is obviously NOT dynamic tesselation, they have a whole new shape that I really doubt is "dynamic". It's simply extra polys.

The Dragon, same as the roof. That's obviously not dynamic. One has the spikes, one doesn't have them at all. Perhaps I'm not understanding what this dynamic tesselation actually does?

So it appears to me that this demo was made to look purposely better in Dx11. Are these guys trying to sell 3d engines? Everything seen in the dx11 shots that "looks good" could be done just the same in dx10 with some extra polygons...

In any event, it seems no hardware can really run that many polys at 1920x1200 except possibly the top end 5870, and 22 frames is a bit on the low side. Its more likely someone would turn down some graphics options to get better performance.

Maybe in a year we will have powerful enough hardware to see it used more.

Can [H] show some other differences between dx10 and dx11?

that's what makes me skeptical. the huge gap in poly counts for the various comparisons was a bit, shall we say... gratuitous. like extremely low in the befores, and way over the top in the afters. I get that we're trying to highlight a difference in feature here, but it would have seemed much more sincere had it used better examples of dx10, and more practical examples of dx11.

don't get me wrong though, we can definitely see the sheer scale of polys being rendered here, and while of course there's a cost to it, it's clear that this is on a totally different level only possible with obvious advances in efficiency. the only problem, like what's being explained above, is that marketing is so keen on downplaying the old while praising the new. I expect to see how it turns out when you guys get your hands on apps that make real use of this.

Originally Posted by Brent_Justice

Of course, I do not know if this program utilizes CrossFire or SLI well, it may not benefit much from multi-gpu in its current state. I don't really know, so we left out that testing since this is just a benchmark afterall, not a game.

(2) XFX 5870's:

1680x1050
AF:4x
AA: off
Tessellation: on
79.7 fps Scores: 2008

Tessellation: off
134.6 fps Scores:3391

DirectX 10 settings same as above (obviously without Tessellation):
132.9 fps Scores: 3347

At 1920x1200 with 8X AA and 16X AF with Tessellation enabled
40.1 fps, 1010 scores

I did the above tests in the same order as the original article. Let me know if you'd like any customized tests

Originally Posted by sbuckler

Don't think you quite got what I meant?

For example you could achieve the pretty looking rope by:
a) using tessellation so when you get close to it, the graphics card generates a higher detail version.
b) using two versions of the geometry so when you get close to it the programme just switches to the version with lots of polys (identical in every way to the tessellated one).
c) using a displacement map - which done right would also look near identical.

Obviously (a) required DX11, you could do (b) with DX7, and (c) with DX9c. The only reason I can see to use (a) would be if it did it with less of a performance hit then the other ways? Unfortunately the demo doesn't help prove or disprove that.

Working backwards:

c) works and is efficient with modern cards, but limits effects that can be done on the resultant objects (displacement mapping creates a 'fake' surface, rather than a real one). Lighting and collision are the two main culprits here.

b) has the problem of geometry pop-in, and requires you to either have two models resident in memory (one very detailed, so very large), or be constantly loading very large models into memory, and thus running out of memory bandwidth pretty sharpish.

a) allows you to up the detail smoothly (if implemented that way), and allows further effects to be performed on that geometry. The underlying/base geometry is fairly simple, so there is little to no memory penalty. The generated geometry is real polygons, so you could even slap a displacement map atop that for truly ludicrous levels of detail.

Blarg. I'd rather read about OpenGL.

Maybe ATI will implement this in a way similiar to Nvidia and Physx- 1 card (or gpu) for graphics & another card (or gpu) strictly for tessellation?

Originally Posted by GoodBoy

So it appears to me that this demo was made to look purposely better in Dx11. Are these guys trying to sell 3d engines? Everything seen in the dx11 shots that "looks good" could be done just the same in dx10 with some extra polygons...

In any event, it seems no hardware can really run that many polys at 1920x1200 except possibly the top end 5870, and 22 frames is a bit on the low side. Its more likely someone would turn down some graphics options to get better performance.

The way I see it, this demo was made to really showcase what you can do in theory with tesselation - to do this, they needed to exaggerate the effect and use it everywhere, where as e.g. Dirt2 will use use it more sparingly, for slightly more realistic water and more detailed animated cloth and flags for example.

I'm not really sure you could use tesselation for things like staircases and roads anyway - since the extra polygons are just added by the GPU, how would you make AI and physics react? As far as those parts of the engine are concerned, the stair steps are still just a flat ramp. It's probably better used for non-interactive elements like cloth simulation, or water that reacts to the player character or vehicle, but not vice-versa.

Originally Posted by TechloGoblin

(2) XFX 5870's:

1680x1050
AF:4x
AA: off
Tessellation: on
79.7 fps Scores: 2008

Tessellation: off
134.6 fps Scores:3391

DirectX 10 settings same as above (obviously without Tessellation):
132.9 fps Scores: 3347

At 1920x1200 with 8X AA and 16X AF with Tessellation enabled
40.1 fps, 1010 scores

I did the above tests in the same order as the original article. Let me know if you'd like any customized tests

So 2x5870 only got 40 FPS with everything maxed and tesselation on at 1920x1200? Do you think adding a 3rd would get things to run at the 60FPS mark? Are these 5870s at stock speed or heavily overclocked?

This has me pretty excited. I can't wait to see how games will improve over the next few years.

[edit]

nm

Originally Posted by vjcsmoke

So 2x5870 only got 40 FPS with everything maxed and tesselation on at 1920x1200? Do you think adding a 3rd would get things to run at the 60FPS mark? Are these 5870s at stock speed or heavily overclocked?

In the other Heaven benchmark thread I posted earlier here, there is someone who even tested QUAD 5870's with the benchmark. I believe there is also a sep. thread in the forum with youtube videos from this guy.

My 5870's are only running a slight overclock using the stock ATI Catalyst program (900/1300)..I didn't want to risk flashing an Asus 5870 bios on them as there is no real need at this point. They run well as is.

Originally Posted by GoodBoy

I'm actually feeling less than impressed with the "dynamic" nature of this. How would a game dev control how dynamic tesselation looks??

Its dynamic in the sense that the polygons don't exist before the game starts, but not dynamic in that they just show up randomly as the engine sees fit. Tessellation is basically a replacement for bump mapping. Whereas bump mapping fakes a 3d surface for lighting, tessellation actually generates polygons for the surface. Its also faster than parallax mapping, and the number of polygons produced is controllable. The developers still have to create the height maps and things for tessellation to generate polygons from. The point is that it is much, much easier and less time consuming for an artist to create a height map and have the engine generate various LOD models than for the artist to create the models manually.

The road looks unnaturally uneven. Who would want that particular look? The extra detail seems a good idea, but dynamically decided by the engine? Why not just program in extra polys?

My guess is that the road looks like that to really exaggerate that tessellation is in fact generating polygons and not faking it. The sharp and uneven look is NOT a problem or side effect of tessellation, but rather of their height maps (or engine). As for the extra polys, again, it is much easier for an artist to "paint" a road than it is to model a road.

The roof shingles look alot better in the dx11 shot, but this is obviously NOT dynamic tesselation, they have a whole new shape that I really doubt is "dynamic". It's simply extra polys.

The Dragon, same as the roof. That's obviously not dynamic. One has the spikes, one doesn't have them at all. Perhaps I'm not understanding what this dynamic tesselation actually does?

That is exactly what tessellation does - it adds extra polys. I don't see any reason that the dragon isn't a result of tessellation, it is quite possible for that to have been generated from a height map.

So it appears to me that this demo was made to look purposely better in Dx11. Are these guys trying to sell 3d engines? Everything seen in the dx11 shots that "looks good" could be done just the same in dx10 with some extra polygons...

Yes, they are selling an engine. And yes, everything could be done in dx10 with extra polygons. The problem comes in that for an artist to make those extra polygons that would take months and cost far more than letting the engine generate it.

Maybe in a year we will have powerful enough hardware to see it used more.

The number of polygons generated is fully controllable. So you'll probably see sliders in games for the amount of tessellation.

Originally Posted by DorkOff

Maybe ATI will implement this in a way similiar to Nvidia and Physx- 1 card (or gpu) for graphics & another card (or gpu) strictly for tessellation?

Why on earth would they do that and why would anyone want it? You don't have a separate card for, say, dynamic lighting, do you? If you want to use two cards, run CF/SLI

Originally Posted by sbuckler

Don't think you quite got what I meant?

For example you could achieve the pretty looking rope by:
a) using tessellation so when you get close to it, the graphics card generates a higher detail version.
b) using two versions of the geometry so when you get close to it the programme just switches to the version with lots of polys (identical in every way to the tessellated one).
c) using a displacement map - which done right would also look near identical.

Obviously (a) required DX11, you could do (b) with DX7, and (c) with DX9c. The only reason I can see to use (a) would be if it did it with less of a performance hit then the other ways? Unfortunately the demo doesn't help prove or disprove that.

Which way is easier to program?

I see a lot of strangeness floating about in this thread regarding what "hardware tessellation" and it's implementation here actually are.

I'm not sure this is about the engine "generating" extra polygons to save your artists work. Yes, tessellation "adds" polys by increasing the number of subdivisions on the model, but if you want your model to look a certain way with those extra polys you'd better model the high-poly version and use tessellation to lower the polys. Perhaps you even need two targets? A low and high-poly model, and the dynamic tessellation takes you anywhere in-between. The reason I say that I don't think this will save artists time is that if it did, anyone could load up any low-poly model into Maya or 3DStudio Max and just tessellate it. If you do that, all you'll get is extra polys, not extra detail. The surfaces that are flat will stay flat, and the curved blocky surfaces will stay blocky, they'll just have extra polys on the blocky faces. You can improve the roundness of a primitive sphere, for example, by simply increasing the # of subdivisions(which tessellates the sphere). The reason your 3d-suite can continue to make the sphere rounder is because it knows, based on an equation, what a "perfect" sphere would be. There is no equation that defines what a perfect dragon looks like, and if there is one for *that* dragon then that means an artist had to come up with it.

Speaking more plainly, if that's how tessellation worked there would be no reason to spend extra time on very high-poly models, you'd just do everything low poly and move the "subdivisions" slider up at the end. Tessellation isn't going to be able to say, intelligently split a block-hand into fingers(and then go on to wrap the texture properly as well!), or turn a flat Half-Life face into a fully-featured(and animated) Half-Life 2 face. Not without the high-poly models also being there as a reference. Tessellation just gives you the stuff in-between.

Comparing this to LOD makes a bit of sense, but I think the point of this is that it can be done dynamically. My understanding of LOD is that the game actually loads a different higher/lower poly model based on distance to the camera. Dynamic Tessellation, as the name suggests, should be able to get you every step in-between.

Regarding more polys vs lighting, I have to both agree and disagree. If you're talking about lighting a 2002 character model with some kind of ultra-realistic lighting engine vs using one of Crysis' character models(face and all, of course), my money goes on the Crysis models looking better every time. If you're talking about lighting say, a street-lamp, or a park-bench or the interior of a hallway, I'd say lighting probably matters more. You can give plenty of depth to a wall or a floor with displacement mapping, but it's tough to make a face look as good that way.

Edit: Just so we're clear, I like what's being shown and what seems to be possible with Dynamic Tessellation. I just want to try and clear up some details about it

Originally Posted by wolfman3k5

Wasn't tessellation available in ATI video careds since the HD2000 series came out? The HD2900 had a Programmable tessellation unit. What I'm wondering now is how where developers supposed to take advantage of it, because at that time, the HD2000 series was, DirectX 10, and tessellation has only now been implemented in DirectX 11. Also, why did ATI put effort and resources back then into implementing a technology at a hardware level, that almost no one could take advantage of. I'm not saying it as a bad thing, but gamers that still own a HD2900 won't be able to take advantage of it, because their cards don't support DirectX 11. It's kind of a bummer. It seems to me that NVidia is only implementing as much as necessary with every graphics card generation, and doesn't bother with point releases of DirectX either, and as a result, their cards seem to be more focused on what matters. I'm only saying this in reference to the HD2900 card, not to the current generation of ATI cards. The HD2900 had amazing specs on paper, but it was a crappy performer because it lacked in other areas like anti aliasing. Anyway, my whole point is that this technology has been available since the HD2000 series cards (in ATI cards), and I don't think anyone that owns a HD2000, HD3000 or HD4000 series card can take advantage of it, just folks with HD5000 cards. So what was the point of implementing it way back then?

Several reasons why this happened:

Tessellation was to be a standard in DX10. It was included in the spec while it was in development several years ago.

GPU development takes several years. ATI had already implemented a proprietary version of tessellation as far back as 2001 (8500 series) called TruForm. At that time, they didn't have a dedicated piece of hardware on the chip for it. Matrox had also implemented it, but the gpu itself was piss poor and soon fell out of gaming gpu market. When Microsoft announced the specs for DX10, ATI was already ahead of the game. ATI then implemented it in further gpu's, dedicated hardware to it, and made it adhere to DX10 standards for the HD 2xxx series.

ATI has for the most part has worked with Microsoft closely at adhering to the DX spec (atleast since x1xxx gen). They had to, especially since they haven't always had the majority marketshare. Nvidia had not implemented tessellation for the 8800 series, and was able to influence Microsoft into dropping Tessellation as a mandatory spec in DX10. It still remained an optional spec (instanced tessallation?), but few if any developers implemented it.

Originally Posted by sbuckler

Don't think you quite got what I meant?

For example you could achieve the pretty looking rope by:
a) using tessellation so when you get close to it, the graphics card generates a higher detail version.
b) using two versions of the geometry so when you get close to it the programme just switches to the version with lots of polys (identical in every way to the tessellated one).
c) using a displacement map - which done right would also look near identical.

Obviously (a) required DX11, you could do (b) with DX7, and (c) with DX9c. The only reason I can see to use (a) would be if it did it with less of a performance hit then the other ways? Unfortunately the demo doesn't help prove or disprove that.

But with b) and c) you cannot perform smooth gemometry transitions that are seamless the way you can with a). I don't know about you, but detail pop-in drives me insane...

9.10 WHQL, HD5870 in DX11 it just hangs. Runs fine in DX10 mode though. Anyone else have that issue?

The problem this should solve via using displacement mapping is how much vertex information you have to send to the card.

To do proper displacement mapping you need enough vertices so that they can be displaced via your texture map. If you don't want to send so many vertices down the pipe, bump mapping would allow you to achieve a similar effect at less cost (but problematic around silhouette edges). What the tessellation shader can do that is new is to generate new triangles and vertices ON THE CARD. This way, you get nice displacements and don't have to send any extra vertices to the card from the CPU.

Tessellation also allows for faster animation since you only have to animate a low-rez version of the model, send the low-rez animated mesh to the card, and the card will up the resolution. Although, as someone previously posted, only having data in the middle of the pipeline might make physics harder.

The difference between what should be stairs, but are instead a ramp, and what actually are stairs after tessellation bothers me somewhat. Its like they went out of their way to make it look fake, or to say 'look what tessellation can do!' when more than likely 10 times as much time was spent on creating the tessellated stairs, than was spent on the flat ramp 'stairs'

Also, the roof shingles; its somewhat unbelievable that tessellation can turn that model into fairly realistic shingles, i just dont buy it. Either a different base model was used and then further tessellated, or some serious programming went into telling the tessellated object's geometry how to behave which just does not seem likely or possible.

The images for the most part look good, but that quality isnt free to the user, or the programmers, and using it as a demonstration of 'look what tessellation can do to your image quality' in this case feels like an attempt to be misleading. Could be wrong about it, but if i had to make an educated guess, id say that the tessellation isnt using the original geometry to work off of.

In this case, i think that the tessellation might be being used to add some dynamic feel to the models, such as making the stones look more worn and pitted, but ultimately it only works because of the extra programming and higher quality base model. If i had to guess.

Originally Posted by Spewn

I see a lot of strangeness floating about in this thread regarding what "hardware tessellation" and it's implementation here actually are.

I'm not sure this is about the engine "generating" extra polygons to save your artists work. Yes, tessellation "adds" polys by increasing the number of subdivisions on the model, but if you want your model to look a certain way with those extra polys you'd better model the high-poly version and use tessellation to lower the polys. Perhaps you even need two targets? A low and high-poly model, and the dynamic tessellation takes you anywhere in-between. The reason I say that I don't think this will save artists time is that if it did, anyone could load up any low-poly model into Maya or 3DStudio Max and just tessellate it. If you do that, all you'll get is extra polys, not extra detail. The surfaces that are flat will stay flat, and the curved blocky surfaces will stay blocky, they'll just have extra polys on the blocky faces. You can improve the roundness of a primitive sphere, for example, by simply increasing the # of subdivisions(which tessellates the sphere). The reason your 3d-suite can continue to make the sphere rounder is because it knows, based on an equation, what a "perfect" sphere would be. There is no equation that defines what a perfect dragon looks like, and if there is one for *that* dragon then that means an artist had to come up with it.

Speaking more plainly, if that's how tessellation worked there would be no reason to spend extra time on very high-poly models, you'd just do everything low poly and move the "subdivisions" slider up at the end. Tessellation isn't going to be able to say, intelligently split a block-hand into fingers(and then go on to wrap the texture properly as well!), or turn a flat Half-Life face into a fully-featured(and animated) Half-Life 2 face. Not without the high-poly models also being there as a reference. Tessellation just gives you the stuff in-between.

Comparing this to LOD makes a bit of sense, but I think the point of this is that it can be done dynamically. My understanding of LOD is that the game actually loads a different higher/lower poly model based on distance to the camera. Dynamic Tessellation, as the name suggests, should be able to get you every step in-between.

Regarding more polys vs lighting, I have to both agree and disagree. If you're talking about lighting a 2002 character model with some kind of ultra-realistic lighting engine vs using one of Crysis' character models(face and all, of course), my money goes on the Crysis models looking better every time. If you're talking about lighting say, a street-lamp, or a park-bench or the interior of a hallway, I'd say lighting probably matters more. You can give plenty of depth to a wall or a floor with displacement mapping, but it's tough to make a face look as good that way.

Edit: Just so we're clear, I like what's being shown and what seems to be possible with Dynamic Tessellation. I just want to try and clear up some details about it

If all you have to tessellate is a model, then you are correct, but DX11's tessellation allows more than that. It does actually allow for details to be added. It just isn't automagicly added, it does require input (very similar to bump mapping)

So DX11's tessellation DOES allow for details that don't exist in the source models to be added, so long as there is a height map for those details (see below).

Originally Posted by Ratha

The difference between what should be stairs, but are instead a ramp, and what actually are stairs after tessellation bothers me somewhat. Its like they went out of their way to make it look fake, or to say 'look what tessellation can do!' when more than likely 10 times as much time was spent on creating the tessellated stairs, than was spent on the flat ramp 'stairs'

Also, the roof shingles; its somewhat unbelievable that tessellation can turn that model into fairly realistic shingles, i just dont buy it. Either a different base model was used and then further tessellated, or some serious programming went into telling the tessellated object's geometry how to behave which just does not seem likely or possible.

The images for the most part look good, but that quality isnt free to the user, or the programmers, and using it as a demonstration of 'look what tessellation can do to your image quality' in this case feels like an attempt to be misleading. Could be wrong about it, but if i had to make an educated guess, id say that the tessellation isnt using the original geometry to work off of.

In this case, i think that the tessellation might be being used to add some dynamic feel to the models, such as making the stones look more worn and pitted, but ultimately it only works because of the extra programming and higher quality base model. If i had to guess.

I highly recommend you look at the DX11 tessellation demo from the DX11 SDK.

Here are some shots I grabbed from the demo. Note, there are *no* models involved whatsoever! Not a single 3d model exists in the source. All that is used to create the tessellated image is the same height map used in bump mapping. This is why tessellation is so cool. Also note the sliders, the number of resulting polygons is highly configurable. It is not just a fixed penalty.