[Squilliam]

Save memory, produce more detailed models and speed up processing all at the same time. It sounds too good to be true, and yet thats what being promised with direct 3d 11. They went on to say that the Xbox 360 is compatible with this implementation but im not sure how far the compatibility goes.

The documents I saw from AMD and Microsoft seem promising, and yet I still have to question (and hopefully recieve answers) on how we might take one underused tessellation engine on the Xbox 360 and put it to use.

So yea, I have some questions perhaps someone whos knowledgeable could please answer them so I can put this confusing matter to rest.

1. How far apart are the promises in the documentation and the reality we might see in the field? Whats the reality of tessellation as of today?

2. Are there other benifits to Tessellation to the Xbox 360 beyond the models themselves such as "Easier development of models?" and perhaps reduced disk space usage. From my laymans perspective it does seem like a form of procedural generation.

3. If you implement tessellation on the Xbox 360, what does it mean from the perspective of crossplatform equality with the PS3? From this, is it worth it for a Xbox 360/PS3 cross platform title?

[Shifty Geezer]

Originally Posted by Squilliam

2. Are there other benifits to Tessellation to the Xbox 360 beyond the models themselves such as "Easier development of models?" and perhaps reduced disk space usage. From my laymans perspective it does seem like a form of procedural generation.

It's more a form of LOD, only it's additive rather than subtractive, and you can add detail to models by subdividing them further, instead of typical LOD that removes triangles as needed. The big plus is for 'deformation' - you can have a root model, apply a 'tesselation map' like a normal map but which actually builds geometry rather than adjusts the light to look like geometry, and end up with a different model. An obvious application off the top of my head would be close-ups for cutscenes. You could have a lower detail model for gameplay, but on the closeups, tesselate it into a finer model to better show subtle changes. I don't know the difficulties of managing tesselation though, what artistic impacts there are and how they can limit usefulness.

It's something SPU's are well suited to, so it probably wouldn't impact cross-platform in a huge hardware dependent, feature-missing way. However it'd be dependent on developers being able to code the engine on PS3 where DX handles it for them, and balancing Cell's workload with everything else it's doing compared with XB360 where the tesselator is otherwise twiddling its thumbs..

[orangpelupa]

1. Whats the reality of tessellation as of today?

its on MASS EFFECT xbox 360.

you can see the textures look better than the PC version.
X360 = tesselation ON
PC = Tesselation OFF

you can see on cutscene, see the face of the first lizard-like alien (cant remember the name)

thanks

[Neb]

Originally Posted by orangpelupa

its on MASS EFFECT xbox 360.

you can see the textures look better than the PC version.
X360 = tesselation ON
PC = Tesselation OFF

you can see on cutscene, see the face of the first lizard-like alien (cant remember the name)

thanks

Gotta be a joke post right?

It looks noticably better on PC, devs have said they uppgraded textures for PC version... they did it.

[NRP]

If I remember correctly, the few devs on B3D who have commented on the 360's tesselator sort of implied that its inflexibility reduces its usefulness.

[kyleb]

Originally Posted by orangpelupa

its on MASS EFFECT xbox 360.

you can see the textures look better than the PC version.
X360 = tesselation ON
PC = Tesselation OFF

you can see on cutscene, see the face of the first lizard-like alien (cant remember the name)

thanks

Even if the 360 version did have beter looking textures, that wouldn't have anything to do with tessellation. Tessellation improves geometry, not textureing.

[Squilliam]

Originally Posted by Shifty Geezer

It's more a form of LOD, only it's additive rather than subtractive, and you can add detail to models by subdividing them further, instead of typical LOD that removes triangles as needed. The big plus is for 'deformation' - you can have a root model, apply a 'tesselation map' like a normal map but which actually builds geometry rather than adjusts the light to look like geometry, and end up with a different model. An obvious application off the top of my head would be close-ups for cutscenes. You could have a lower detail model for gameplay, but on the closeups, tesselate it into a finer model to better show subtle changes. I don't know the difficulties of managing tesselation though, what artistic impacts there are and how they can limit usefulness.

It's something SPU's are well suited to, so it probably wouldn't impact cross-platform in a huge hardware dependent, feature-missing way. However it'd be dependent on developers being able to code the engine on PS3 where DX handles it for them, and balancing Cell's workload with everything else it's doing compared with XB360 where the tesselator is otherwise twiddling its thumbs..

Thanks! It sounds like a useful piece of technology then!

So really its applications are limited to certain areas? Its not something useful to apply wholesale to an engine?

[Shifty Geezer]

Originally Posted by Squilliam

So really its applications are limited to certain areas? Its not something useful to apply wholesale to an engine?

I don't know! It depends on hardware implementation, and how much effort devs want to go to, plus all the fine details. In theory, you could have RAM saving, higher quality High Order Surfaces defined as curves instead of meshes and have them tesselated in realtime to the LOD required, but Laa-Yosh has pointed out lots of artistic troubles with that. At the moment I can't see it being more of a subtle technique used on occasion.

[eastmen]

Doesn't ati have this in the r600 and above gpus for the pc also ?

[corysama]

Originally Posted by Squilliam

So really its applications are limited to certain areas? Its not something useful to apply wholesale to an engine?

Tesselation is only a win for models that are well suited for it. Tessellating a 1000 poly mesh to 16,000 polys is faster than drawing a 16,000 poly untessellated mesh. But, you can do a lot with 16,000 arbitrary polys that you can't do with 1000 polys that are going to be tessellated.

If you want models that are smooth, round and evenly dense, then tessellation can help a lot. If you want flat surfaces, hard edges, uneven density or lots of small details than tessellation won't fit. Displacement mapping helps add some kinds of small details, but it also pushes up the break-even point vs arbitrary polygons.

So, no. It's not useful to apply wholesale. It's getting a lot easier and more usefull --the recent papers that map catmull-clark subdvision to bezier patches is a big step forward in artist-friendliness. But, there really wouldn't be much point to tessellating the buildings in Half-Life 2 for example. You would just end up with a slower scene that looks almost exactly the same.

[Jawed]

My understanding is that D3D11 provides a one-pass tessellation pipeline, but XB360/R6xx/RV7xx tessellation requires multiple passes and requires the use of VS and PS programs to take the place of Hull Shader and Domain Shader programs in D3D11.

These multiple passes in pre-D3D11 hardware consume memory bandwidth since "vertex buffers" have to be created to hold the intermediate data, for consumption by the next pass.

It's kind of similar to the use of render to vertex buffer in DX9 GPUs which was used to provide a preview of Geometry Shader functionality before D3D10 arrived.

Mathematically the XB360 tessellation calculations should be the same as the D3D11 calculations. It's just that the data formats in D3D11 are a better match for the process, and the inter-stage data doesn't have to take a trip off-chip. So it's prolly notably simpler in D3D11, overall.

AMD provides some kind of SDK that exposes some internals of the PC GPUs to better support tessellation (may be only RV7xx though - I get the feeling that there have been revisions with each generation of this hardware).

Overall, tessellation is a proper brainache, e.g. dealing with holes that form where there should be a continuous surface.

The major artwork problem is that it requires a different process and data-structures to implement models, e.g. for characters and their animations.

Jawed

[Kaotik]

Originally Posted by eastmen

Doesn't ati have this in the r600 and above gpus for the pc also ?

Basicly the same yes, exactly, no.

[joker454]

Originally Posted by corysama

If you want models that are smooth, round and evenly dense, then tessellation can help a lot. If you want flat surfaces, hard edges, uneven density or lots of small details than tessellation won't fit.

Yeah that's a problem with the 'add polys' method, it just doesn't work quite right with all meshes. If the hardware solution fits the mesh then cool, but in the end it's easier to just roll your own solution that gives you total control. I've been working on something similar lately on the PS3 that creates unlimited lod's in realtime with no artist support, and it works on all types of meshes. It just seemed like the better route to take, this way the artists don't have to do anything special, they just create a single 'best' lod and I'll take over from there, and the contours of the mesh get preserved automatically on the lods. Very important to keep the artists happy

[proffesso]

Originally Posted by joker454

Yeah that's a problem with the 'add polys' method, it just doesn't work quite right with all meshes. If the hardware solution fits the mesh then cool, but in the end it's easier to just roll your own solution that gives you total control. I've been working on something similar lately on the PS3 that creates unlimited lod's in realtime with no artist support, and it works on all types of meshes. It just seemed like the better route to take, this way the artists don't have to do anything special, they just create a single 'best' lod and I'll take over from there, and the contours of the mesh get preserved automatically on the lods. Very important to keep the artists happy

but to make sure the tessaltion doesnt smooth out innappropriate areas the artists still have to put in extra geometry to "hold" the shape (think small bevels on a car bonnet etc)

and for somthing like a car, its extremely hard to justify the base mesh needed, because A. its unusable as a low end LOD, and B. the same reason..the polycount has to be high enough to hold the shape perfectly, that you might only be getting a 20% reduction in overall base polygons.

now, once polycounts and hardware get fast enough, this will be extremely viable..where you can sub`d a 100k mesh into a 400k mesh for example...then it works wonders...just like the offline render world.

[Squilliam]

So has anyone played with the new direct3d 11? I saw from the Microsoft developers conference they were about to send out the first direct 3d stuff to developers.

[Shifty Geezer]

Originally Posted by joker454

It just seemed like the better route to take, this way the artists don't have to do anything special, they just create a single 'best' lod and I'll take over from there, and the contours of the mesh get preserved automatically on the lods.

Is that any different to existing LOD, such as DX7's progressive meshes? These start with the highest qulaity, a big model, and shrink it to screen. Activae tesselation offers the option of starting with a lower quality model and increasing quality. eg. Think a wheel, which can be subdivided as smooth as needed to keep it round dependent on screen size. LBP would benefit from this, as the circles are clearly polygons. It also has some very destructive LOD on small shapes.

Regards adding small details, can't these be added by adjusting the created vertices according to a displacement map? The normal map of a car could be used as a template to align and tune vertices, so they don't just sit in the middle between other vertices. i can see then processing overhead being prohibitive, but it doesn't seem to me like there's no work around for the loss of detail from tesselated objects.

[FirewalkR]

Possibly naïf post warning!

Isn't it possible to tag certain parts of the geometry, like hard edges and small-detail sections so they won't be modified by the tesselation process?

Shifty's post has an interesting idea (i guess): define models with relatively simple shapes, prone to tesselation, and add all detail through displacement mapping...

Hmmm, so much to learn about this, I wonder if reading helps.

[joker454]

Originally Posted by proffesso

but to make sure the tessaltion doesnt smooth out innappropriate areas the artists still have to put in extra geometry to "hold" the shape (think small bevels on a car bonnet etc)

There's algorithms that deal with that, so that important features/contours get preserved with no artist involvement.

Originally Posted by Shifty Geezer

Is that any different to existing LOD, such as DX7's progressive meshes? These start with the highest qulaity, a big model, and shrink it to screen.

Well I wanted something that game me 100% control, and something that I could run on spu's. I also wanted to preserve the main contours of the mesh, and be able to have certain edge geometry never be touched because some meshes needs to interlock with others. I also wanted it to be 100% code controlled, the artists are swamped enough already, and so I can customize it. I ended up "more or less" implementing this method:

http://faculty.ksu.edu.sa/mhussain/P...s/IJMS2005.pdf

Before doing that, I process all the verts in a mesh and mark the edge verts as 'untouchable'. Then I perform edge collapses as described in that doc. Their idea is incredibly simple but works very nicely. Long story short, it takes a vert and moves it over to an adjacent vert position. It then takes all the triangles connected to the vert that moved, takes their normals before and after the edge collapse, and calculates error as the sum of 1 - dot ( original normal, new normal ) for each triangle. After it does that for every vert in the mesh, the 'lowest error' vert is flagged as the best one to be removed. Rinse and repeat. It works very nice, and mesh edges/contours are maintained. Plus, I can tweak the algorithm any way I like, for example I can set an 'error max' where a vert never gets removed no matter what if it exceeds a certain error threshold. The hardware or directx solutions are a bit too generic for what I was looking for, so going the custom route has worked out nice so far.

Originally Posted by Shifty Geezer

Regards adding small details, can't these be added by adjusting the created vertices according to a displacement map? The normal map of a car could be used as a template to align and tune vertices, so they don't just sit in the middle between other vertices. i can see then processing overhead being prohibitive, but it doesn't seem to me like there's no work around for the loss of detail from tesselated objects.

The beauty of their method is that it doesn't need normal maps or anything esoteric. The bulk of the processing can be done offline in the art export tool. I tweaked it to just write out 'hint data' that is very small. Runtime side, this hint data, which is just well packed/optimized edge collapse data, can be ripped thru realtime very fast to lod the mesh anyway I want.

[Laa-Yosh]

Originally Posted by corysama

If you want flat surfaces, hard edges, uneven density or lots of small details than tessellation won't fit.

That is not correct; proper modeling techniques can guarantee flat surfaces and nice edges (nothing's 100% sharp in reality, most man-made objects have rounded corners so that we won't hurt our hands using them).

However, keeping an edge hard requires considerably more geometry, which is why racing games for example prefer to use simple poly models and distribute the detail more efficiently.

[Laa-Yosh]

Originally Posted by FirewalkR

Isn't it possible to tag certain parts of the geometry, like hard edges and small-detail sections so they won't be modified by the tesselation process?

It is an exisiting solution, but it makes asset creation a nightmare...

[3dcgi]

Originally Posted by Kaotik

Basicly the same yes, exactly, no.

The tessellation algorithm is identical for Xenos, R600, and RV770. RV770 has additional functionality such that the tessellator can feed the Geometry Shader.

Originally Posted by FirewalkR

Isn't it possible to tag certain parts of the geometry, like hard edges and small-detail sections so they won't be modified by the tesselation process?

With adaptive tessellation the first pass calculates tessellation factors. If the factor is 1 for an edge it won't be tessellated. I've never implemented this, but presumably you could set the tessellation factor to 1 if the angle between normals is greater than a threshold.

[corysama]

Originally Posted by Laa-Yosh

That is not correct; proper modeling techniques can guarantee flat surfaces and nice edges

I wasn't clear: I meant that tessellation is not a good fit for flat surfaces when there is no point to tessellating them into visually identical flat surfaces. For example, the ceiling in my room can be adequately represented by 2 triangles and a normal map for fine detail. If it were tessellated, there would be no gain.

[catisfit]

Originally Posted by corysama

I wasn't clear: I meant that tessellation is not a good fit for flat surfaces when there is no point to tessellating them into visually identical flat surfaces. For example, the ceiling in my room can be adequately represented by 2 triangles and a normal map for fine detail. If it were tessellated, there would be no gain.

Well, viewing such a flat surface at an acute angle would show a difference in the silhouette - probably not likely for ceilings, but could for a rough brick wall for example.

[Crossbar]

Originally Posted by joker454

There's algorithms that deal with that, so that important features/contours get preserved with no artist involvement.
..
stuff
...
The beauty of their method is that it doesn't need normal maps or anything esoteric. The bulk of the processing can be done offline in the art export tool. I tweaked it to just write out 'hint data' that is very small. Runtime side, this hint data, which is just well packed/optimized edge collapse data, can be ripped thru realtime very fast to lod the mesh anyway I want.

Impressive work!

I remember this post by you.

Originally Posted by joker454

Fair enough, I'd agree with that. But...until someone has figured out a way to adjust polygon distribution in realtime that is suitable for games, then we're kind of stuck using the more tried and true methods. Maybe you're ahead of us in that regard, as we don't have any such system in house. Progressive mesh, as described at PS3Devcon, isn't a solution for us either, partly because it doesn't really redistribute polys from where they aren't needed, and party because it's a nightmare to setup/maintain. So for now for us that means using polygons, and lots of them. We have no choice in this, and I don't really see that changing much in the next couple of years, for us anyways. I'd wager that many other studios are in the same predicament though as I can still spot polygons in just about every title out there, even the uber ones.

I guess my point is that while the argument of poor poly distribution is noble and correct, it just doesn't matter much in the current reality of the situation. And hence we are still stuck with 4+ million triangle counts (in replay mode, 30fps but still 4xmsaa) because our silhouettes must look perfect for the replay camera which inevitably gets zoomed in close enough to see if a superstar players shoes are accurate.

Now, if you have already built a realtime polygon distribution system that works on PS3 then message me. Our parent company has deep pockets, they would be interested in buying and/or licensing it. No joke, just let me know and I'll get you in touch with the big wigs here that make these choices, then you guys can sort out the legal details. Just make the interface easy, since I'll probably be the one implementing it

I guess you did it all by yourself in the end.

[joker454]

Originally Posted by Crossbar

I guess you did it all by yourself in the end.

Well...the brainiacs that originally wrote that paper did most of the work, I just implemented and tweaked it But yeah it's something I've been wanting to try for a while now.