Unigine Heaven Benchmark with DX11 Tessellation

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.
 
Brent_Justice said:
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.
Click to expand...

(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
 
sbuckler said:
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.
Click to expand...
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.
 
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?
 
GoodBoy said:
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.
Click to expand...

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.
 
TechloGoblin said:
(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
Click to expand...

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.
 
vjcsmoke said:
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?
Click to expand...

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.
 
GoodBoy said:
I'm actually feeling less than impressed with the "dynamic" nature of this. How would a game dev control how dynamic tesselation looks??
Click to expand...

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?
Click to expand...

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?
Click to expand...

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...
Click to expand...

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.
Click to expand...

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

DorkOff said:
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?
Click to expand...

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 :p
 
sbuckler said:
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.
Click to expand...

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 :D
 
wolfman3k5 said:
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?
Click to expand...
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.
 
Last edited:
sbuckler said:
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.
Click to expand...

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.
 
Spewn said:
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 :D
Click to expand...

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).

Ratha said:
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.
Click to expand...

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.








 
JMke said:
do keep in mind that in the comparison shots, in DX10 they could have added instanced tessellation which is supported by the older ATI/NVIDIA hardware; but they did not, making the on/off comparison a bit exaggerated.

Instanced Tessellation in DirectX10

if they'd added some instanced tessellation to the DX10 path the difference would be noticeably less stellar!
Click to expand...

if I remember correct, Tessellation does work in DirectX 10, but does not work correctly..

I tried the tessellation demo provided by ATI (The frog one), it doesnt work on nVidia card (GTX 295) for me while it works on ATI 4800 series....

so I guess nVidia hardware isn't fully support it..... but that just my test...... or its a different tessellation that implement by ATI.. I dont know....
 
I'm not one for canned benchmarks, but this is just gorgeous! The tessellation has a profound effect on the visuals, kind of like BumpMapping ala DX8 gone wild. Funny thing is I remember this feature being hyped on my ATi-8500 back in the day. Glad to see it finally matured and hope it becomes a standard programing practice. In Nvidia doesn't support it though, it could become another unused "BumpMapping" of today.
 
i got the same results with a phenom2x2 unlocked to quad, this benchmark is 100% GPU intensive. Lets just wait to see how the new games run, because with the 5770 testelation comes at a big price, and in the dragon scene it is very hard to get more than 25fps at low resolutions!!! at 1680x1050 i get like 16-18 and that is the minimum fps. I hope games have a slider like other ones have suggested to prevent that high performance hit.
 
Something about the Tesselation in this benchmark seems fishy. If the Tesselation feature is dynamically generating new polys for increased detail, how exactly do the program know how to shape those polys into the right shape for a particular bit of detail? I know you can use displacement and bump maps, but I don't see how the program can shows stairs as a perfectly flat angled surface without tesselation, and then as physical 3D steps in the next. Bump and displacement maps don't really provide enough info to make a complex compound shape like steps just out of texture detail. The roof tiles seem odd as well, being perfectly flat in one shot and then as perfectly formed, rounded spanish-style tiles with tesselation enabled. The fact that the dragon mesh becomes so detailed that you can't even see the mesh detail is weird as well, as you could create the tesselation-quality dragon with far, far fewer polys if done by a competent 3D modeler. Seems like a waste of processing power right there.

Kudos to the benchmark's developers and tesselation tech in general if this is all on the level, but my gut just tells me something odd is going on here.
 
Spankbot, what seems fishy to you is how overexaggerated they made the non-tesselated version look. What tesselation does is it subdivides (that is makes a surface four times as detailed) and then redistributes the new vertices based on a heightmap. In other words, tesselation behaves exactly like a normal map, but for the silhouette as well. Another benefits is that this means the new detailed model can self-shadow.

I would have personally made the stairs and roof more detailed in the base mesh. Nonetheless, that is exactly the kind of effect tesselation could and should have. The reason why tesselation is preferred over raw detail is that the new vertices aren't actually held in memory, if I recall, they're actually simply handled by the tesselator units on the card. In other words, not free detail, but detail and reasonable price.
 
Spankbot-5000 said:
Bump and displacement maps don't really provide enough info to make a complex compound shape like steps just out of texture detail.
Click to expand...

Ah, but they do provide enough info. A heightmap is all that is needed for both the stairs and the roof tiles. If you look carefully you can see that the tessellated polygons only vary in height from the base. There isn't any shady trickery or model swaps (at least none are necessary, anyway), just clever use of heightmaps.

as you could create the tesselation-quality dragon with far, far fewer polys if done by a competent 3D modeler. Seems like a waste of processing power right there.
Click to expand...

Oh, absolutely, but the point is that we have plenty of processing power to waste, whereas games are getting exceedingly more expensive to create.

Kudos to the benchmark's developers and tesselation tech in general if this is all on the level, but my gut just tells me something odd is going on here.
Click to expand...

Look at the screenshots from the tessellation demo I posted last page. It is very possible for this to be completely legit, tessellation does some really cool things with heightmaps.
 
Brent_Justice said:
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.
Click to expand...


take a look at the other Heaven thread.. theres a few guys that ran it with quad crossfire and were getting 300+ fps with the default settings in Dx11.. which tells me it scales excellent in multi-gpu.. also Bodar did a video review of quad crossfire in some games and on the Heaven demo which were getting insanely high numbers with everything maxed out at 1680x1050..
 
kllrnohj said:
Oh, absolutely, but the point is that we have plenty of processing power to waste, whereas games are getting exceedingly more expensive to create.
Click to expand...
This is the big thing. Anything that will make development cheaper or not add a lot of cost is going to be huge in the next few years. Game budgets are now at the point of being quite insane. Just a few days ago there was an article that Gran Turismo 5's budget was $60 million. Remember, hardware has been following Moore's law. This has led to game development costs also rising exponentially. If Tessellation can make games look much better without extra cost, most games will be implementing it.
 
I have a GTX 295 and using the Hard settings I got 75.3 which is well over what the GTX 285 single card was getting. I am running a very lightly overclocked 920.
 
Spankbot-5000 said:
Something about the Tesselation in this benchmark seems fishy. If the Tesselation feature is dynamically generating new polys for increased detail, how exactly do the program know how to shape those polys into the right shape for a particular bit of detail? I know you can use displacement and bump maps, but I don't see how the program can shows stairs as a perfectly flat angled surface without tesselation, and then as physical 3D steps in the next. Bump and displacement maps don't really provide enough info to make a complex compound shape like steps just out of texture detail. The roof tiles seem odd as well, being perfectly flat in one shot and then as perfectly formed, rounded spanish-style tiles with tesselation enabled. The fact that the dragon mesh becomes so detailed that you can't even see the mesh detail is weird as well, as you could create the tesselation-quality dragon with far, far fewer polys if done by a competent 3D modeler. Seems like a waste of processing power right there.

Kudos to the benchmark's developers and tesselation tech in general if this is all on the level, but my gut just tells me something odd is going on here.
Click to expand...

There is nothing odd about it.

It is specified probably per object. with different settings per object. Yes you can make certain features look very good during benchmark setup :)

Then again an average programmer would know that theoretical performance differs from what they are using or want to use in scene/envoirement.
 
i agree, particularly the stairs look fake. at least make some basic stairs in the dx10 screenshot and not just a ramp. and like it was said before, i'd rather have improved lighting technology and higher detail textures than higher polygon count. it totally kills immersion if you have fairly detailled textures and then there's some blurry posters on a wall or other low res textures. or unrealistic shadows. give me realistic light refraction. that would impres me. there's already enough polygons in current games imo.
 
The thing that bothers me is, the 5870 gets sluggish dealing with tessellation. That means I have to buy another video next year to make it better, sigh. :)
 
bitgod said:
The thing that bothers me is, the 5870 gets sluggish dealing with tessellation. That means I have to buy another video next year to make it better, sigh. :)
Click to expand...

Keep in mind that an actual game might not have such extensive use of tessellation. We'll have to see when the new STALKER comes out..
 
This is not displacement maps! That's old tech.

Displacement maps is just a texture rendering trick to make it appear it has depth, when it in fact does not. You can't get extreme displacement without it looking wrong.

This however is completely different. It actually modifies the vertices in the model outwards to create real displacement.

What is awesome is the fact that the this tessellation with displacement takes the same input as displacement maps!! Meaning with small tweaks you can make old games have real displacement!!!

What I wonder is how do you generate the low polygon model + displacement map? It is automatically done by the modeling program from a super high res model? If so, that's a neat trick.
 
My poor old quadro got 19 FPS :) but it still folds faster than any ATI :)

By the way Roger Dean (artist who worked on album art for Yes etc) called from 1970, he wants his anti gravity islands back
 
Last edited:
shansoft said:
if I remember correct, Tessellation does work in DirectX 10, but does not work correctly..

I tried the tessellation demo provided by ATI (The frog one), it doesnt work on nVidia card (GTX 295) for me while it works on ATI 4800 series....

so I guess nVidia hardware isn't fully support it..... but that just my test...... or its a different tessellation that implement by ATI.. I dont know....
Click to expand...

I think that's a bit of a hack implementation just for experimentation. DX10 doesn't really support it.
 
bitgod said:
The thing that bothers me is, the 5870 gets sluggish dealing with tessellation. That means I have to buy another video next year to make it better, sigh. :)
Click to expand...


Thats the thing , you dont ;) , the sluggish part of the benchmark means there are choke points with an excessive amount of tessellation to be done. That gives you an idea on how well things scale but in general no game will purposely kill itself with to many choke points so it would become unplayable and end-up as a tech demo.
 
Pyrolistical said:
This is not displacement maps! That's old tech.

Displacement maps is just a texture rendering trick to make it appear it has depth, when it in fact does not. You can't get extreme displacement without it looking wrong.

This however is completely different. It actually modifies the vertices in the model outwards to create real displacement.

What is awesome is the fact that the this tessellation with displacement takes the same input as displacement maps!! Meaning with small tweaks you can make old games have real displacement!!!

What I wonder is how do you generate the low polygon model + displacement map? It is automatically done by the modeling program from a super high res model? If so, that's a neat trick.
Click to expand...

No, you're thinking of bump-maps. Bump-mapping is a texture trick to make it look like there's depth. Dsiplacement maps are textures that actually modify vertices in 3-dimensions to achieve depth.
 
You must log in or register to reply here.
Back
Top