*spin-off* Tessellation

Creepy.

And strange behaviour.

 

How does tesselation work in that game? The camera is static. Or is it a bug?

 

Whatever they were doing it was mighty impressive for last gen standards




This is from GT6

Some comparisons with Forza 5 i believe

 

Let me correct that, the comparison is with GT5 not Forza.

 

The image above is GT and the one below is Forza 5 I presume? Also from photomode not in game?

 

Tesselation makes so much sense for cars, it's a no brainer. I really like the smooth transition between tesselated geometry in that example, although it seems like a bug of some sort.

 

I think it's fair to expect heavy use of Tessellation in GT7, that is if they iterate on the existing engine instead of building up a new one. We haven't heard a thing from Polyphony Digital in the last few years.

 

Polyphony did tesselation on the Cell (RSX doesn't support hardware tesselation), but I'm wondering if they can provide a solution as beautiful as GT6's through hardware tesselation on the PS4? How programmable is hardware tesselation?

 

It's clearly load-balanced. This is zoomed a bit, but you can see that initially the car is slow or stopped on the grass and then starts driving again onto the road and gain speed, so that would increase the engine load and so tesselation reduces detail dynamically.

Note that SPEs are doing the tesselation here as the GPU doesn't support it yet in the PS3. So the tesselation logic and method may differ a little from what you're used to on GPU (though no idea, I'm not an expert either!)

 

Are they blending between stored LOD's ?

 

As far as I know, they are smoothly transitioning between lower/higher dynamically tesselated geometry. Since it's parametic, the transitions are very smooth, tackling this using stored lods could be a more complex problem to solve (e.g. deciding which vertex to collapse), though I'm talking without much knowledge here.

 

Heard GCN core is weak for tessellation? If So than we may not see a lot of use for it on current consoles.

 

Whenever I hear of dynamic LOD based Tesselation for displacement maps being unusable because of the wobbling and vertex swimming it creates, I assume that has a lot to do with how new created vertices slide into position from the pre-exising ones as most demos usually demonstrate. But can't new vertices "pop" mid quad and have the height displacement be the thing that smoothly goes into place? In other words, new vertices are created already where they are meant to be within the polygon surface (no tangential sliding) but within the average height of its parent vertices (no influence on the geometry shape), and from there it progressively displaces into its actual height as sampled from the appropriate mip-level of the heighmap as the camera gets closer. I guess the artifacts would be much smaller this way. There'd still be visible morphing because of the screen-space size ploys would have to be kept at to maintain performance, but it would be much more stable and consistent wouldn't it? What am I missing?

 

Weak when compared to nvidia, but weak overall I don't know.

I have a few games that use tessellation and i've not noticed that

 

It's not, NV just has a better tesslator, but at the cost of some other weakness...
Problem with tessellation is that it's no silver bullet, you need a fairly tessellated mesh to further tessellate, which crush the initial idea to have low triangle count mesh and use tessellation as LoD. So it is expensive to have a tessellated model even before you tessellate it, making it not so interesting. With time we may get better tools to produce such meshes that would be usable for LoD too, but as of now, it's not really the case. I expect it to be used for main characters, terrain and a few other cases, but we are not at the point it can be used for everything on screen yet.

 

For better tesselation I suppose you'd need graphics tools and formats where you can define arcs and such rather than have models that are triangles already, and then an engine that handles that correctly. I don't have any idea of what the state of the art is in that respect? (but I have my suspicions)

 

A real NURBS setup submits patch-data to the tessellator, not triangles, and it's pretty much standard. The problem is, that it's too slow, even low poly parameterizations need to pass through the tessellator.

 

Could it conceivably be more efficient to do it with custom Tesselation code on CU then? From the sound of things I wouldn't be surprised if that is what GT7 would do ...

 

would be interesting, maybe subdivision surfaces could make a come back that way...

 

@Laa-Yosh has never supported the idea of HOS representations for several reasons. The fundamental problems with the format for representing models are still unchanged even if the hardware to render those surfaces has. For things like pipes and wheels, HOS probably make sense, but not for more varied or curvaceous stuff.