"Yes, but how many polygons?" An artist blog entry with interesting numbers

[Laa-Yosh]

Pixar has originally developed Catmull-Clark in order to get the best of both worlds from B-patch surfaces and polygons. They get the arbitrary mesh construction and the ability to treat the subdivided surface as patches and use their pre-existing approaches with it.
The key thing here is that PRMan dices up everything into micropolygons for shading and rendering. So they don't have to deal with tesselation because they already have something better.

There are other ways to render C-C subdivs, for example the pretty much #2 renderer Mental Ray has various tesselation options that can take view-dependency into account. It's not as memory and speed efficient as micropolygons, though.

Browsing through the recent Nvidia and AMD presentations has given me the same impression that you got, by the way - their approach is based on what's easier and more efficient to implement. They work with triangles and they need a continous tesselation method... so they have their reasons. Also, PRMan doesn't have to care about stuff like switching between resolutions because they sample the hell out of any pixel so they never get any popping. But in real-time engines this is still a luxury.

But the content creator side doesn't want to walk down this path of adding a new approach and having to re-develop and re-learn a lot of tools and tech and such. We'll see if anyone's willing to jump the gun but I really doubt it. We'll get the occasional sponsored game with support, just as with Truform and the rest, and then the rest will keep on waiting for Catmull-Clark stuff. Maybe Larrabee will help, I recall perhaps Tim Sweeney talking about such stuff at an Intel presentation?...

 

[Dr. Nick]

It is just speculations from my part. Atleast I think so! :smile:

And it really is a shame that Radeon 3xxx/4xxx having tesselation support for all these years without being used. Well I suppose we all should "thank" Nvidia and the TWMBMP program.

Without tesselation being part of DirectX they were never going to be used in a PC game. The same thing happened with N-patches. I was hoping that the 360 would push it's use into PC games but it looks the other way around now. DirectX 11 games may help push more 360 games into using the tesselator.

Edit:Sorry I didn't see Laa Yosh's post.

 

[Arwin]

Well, maybe it's still possible to use the Catmull-Clark parameters to feed the tesselation routines in some form or other. We'll see what happens, but considering the pay-off it has on modern hardware, I think that we'll start to see things moving pretty soon regardless.

 

[Dr. Nick]

I think the closest Microsoft has gotten to it is a presentation on approximating Catmull-Clark but that was years ago and I'm guessing it is not a good enough solution.

 

[Laa-Yosh]

There were some links to presentations on this topic recently, when I get home I'll try to dig them up...

 

[liolio]

Wasn't it a Rein presentation about the end of the GPU road map?
EDIT more specifically this

 

[joker454]

Well tesselation on SPU is clearly possible and even most likely more flexible than what GPU provide but then comes the issue to send that many vertices to the GPU, I don't Know more insights would be welcome but I can clearly see an advantage on keeping stuff on the GPU.

Generally speaking, you do not want to do spu tesselation on PS3 because there is no way to bypass the vertex shading step. That step is one of the big bottlenecks in the machine, so even if you have written the worlds greatest spu tesselator you won't be able to use it, because all those massively increased vert count meshes still have to make their way through rsx's vertex stage. If there was a way to bypass the vert shader process, and say spu tesselate meshes and send them straight to the pixel shader for shading then I would agree that it would be beneficial. But you can't. That's why most of the spu work on PS3 regarding verts has been aimed at removing them, not adding more.

Likewise, when I was experimenting with tesselation on PS3 I ultimately went with a de-tesselator, the idea being to remove vert load in a smooth fashion as meshes move away. That showed good performance gains since it could be done on all shadow passes and render passes.

 

[Dr. Nick]

Likewise, when I was experimenting with tesselation on PS3 I ultimately went with a de-tesselator, the idea being to remove vert load in a smooth fashion as meshes move away. That showed good performance gains since it could be done on all shadow passes and render passes.

That actually sounds kind of cool. Was there smooth level of detail or was there a bit of pop in?

 

[COPS N RAPPERS]

Likewise, when I was experimenting with tesselation on PS3 I ultimately went with a de-tesselator, the idea being to remove vert load in a smooth fashion as meshes move away. That showed good performance gains since it could be done on all shadow passes and render passes.

whoa, now that's a interesting idea, a lot games would need that if they're to achieve 60 fps.

game developers these days are having problems making games run at a solid 30 fps a lone, (i mean take a look at http://media.ps3.ign.com/media/800/800208/imgs_1.htmlInfamous, that game would have benefited from a de-tesselator, for smooth performance in it's huge environments)

 

[joker454]

That actually sounds kind of cool. Was there smooth level of detail or was there a bit of pop in?

It was configurable from "I can't see pop", to "oh my god I can't stand the pop", and everything in between. It was just an aggressiveness scale that could be set on a per mesh basis.

 

[liolio]

Generally speaking, you do not want to do spu tesselation on PS3 because there is no way to bypass the vertex shading step. That step is one of the big bottlenecks in the machine, so even if you have written the worlds greatest spu tesselator you won't be able to use it, because all those massively increased vert count meshes still have to make their way through rsx's vertex stage. If there was a way to bypass the vert shader process, and say spu tesselate meshes and send them straight to the pixel shader for shading then I would agree that it would be beneficial. But you can't. That's why most of the spu work on PS3 regarding verts has been aimed at removing them, not adding more.

Likewise, when I was experimenting with tesselation on PS3 I ultimately went with a de-tesselator, the idea being to remove vert load in a smooth fashion as meshes move away. That showed good performance gains since it could be done on all shadow passes and render passes.

Thanks for the insights.
De-tesselator... That sounds like a pretty neat idea. I'm waiting to see this in effect

By the way it sounds like Groo/Charlie Demerjian made some investigations about the tesselator in the 360 and the one in last ATI card. The news is here
I hope he is right and that tesselator will be finaly put to good use. The option being available for both PC and 360 may be we can hope the content tools to evolve to support this tech.

 

[COPS N RAPPERS]

By the way it sounds like Groo/Charlie Demerjian made some investigations about the tesselator in the 360 and the one in last ATI card. The news is here
I hope he is right and that tesselator will be finaly put to good use. The option being available for both PC and 360 may be we can hope the content tools to evolve to support this tech.

nice find,

god i hope that we start seeing this from here on out, starting with this new alien vs predator game.

 

[Nesh]

Based on what I read do we conclude that Tessalation on the PS3 is a no go because of performance hit?

Also to Joker, can you explain a bit more what the "de-tesselator" does? Is the aim supposed to produce similar results to tesselation? Is it supposed to remove vertices to objects moving away and add them to objects near the camera to smooth out the surfaces (to objects near the camera)? In other words reduce vert load to some objects to give room to others and smooth em out? If not can this be done?

 

[liolio]

Also to Joker, can you explain a bit more what the "de-tesselator" does? Is the aim supposed to produce similar results to tesselation? Is it supposed to remove vertices to objects moving away and add them to objects near the camera to smooth out the surfaces (to objects near the camera)? In other words reduce vert load to some objects to give room to others and smooth em out? If not can this be done?

I think his goal is prevent brutal change of the level of detail of a character/object. As a nice effect it saves memory I guess you only have to keep in RAM what would be otherwise the highest LOD for a mesh, everything else is generated on the fly. I don't think it adds details, it cuts them smoothly without memory overhead.
From my understanding it's different than tesselation as tesselation can go both ways.

 

[ultragpu]

I think his goal is prevent brutal change of the level of detail of a character/object. As a nice effect it saves memory I guess you only have to keep in RAM what would be otherwise the highest LOD for a mesh, everything else is generated on the fly. I don't think it adds details, it cuts them smoothly without memory overhead.
From my understanding it's different than tesselation as tesselation can go both ways.

So with the performance saved by the De tessellator, wouldn't that leave room for further polygon increase one way or another? I wonder if the result would resemble the one with tessellation implemented?

 

[Nesh]

So with the performance saved by the De tessellator, wouldn't that leave room for further polygon increase one way or another? I wonder if the result would resemble the one with tessellation implemented?

Yeah thats what I wondered too

 

[Shifty Geezer]

So with the performance saved by the De tessellator, wouldn't that leave room for further polygon increase one way or another? I wonder if the result would resemble the one with tessellation implemented?

Yes. That'd actually be a smart move for other platforms too. The iedal would be to make the hardware work smarter, not harder. We already have more than enough vertex power to render one vertex for every pixel, so in an indeal scene, we ought to be able to elliminate jaggies completely! If you can put vertices where they're need and remove them where they're not, you'd have a better model-handling system. Of course this would be loads easier with unified shaders shifting jobs dynamically.

 

[Arwin]

Yes. That'd actually be a smart move for other platforms too. The iedal would be to make the hardware work smarter, not harder. We already have more than enough vertex power to render one vertex for every pixel, so in an indeal scene, we ought to be able to elliminate jaggies completely! If you can put vertices where they're need and remove them where they're not, you'd have a better model-handling system. Of course this would be loads easier with unified shaders shifting jobs dynamically.

Heh, we think alike -

In theory I have a feeling that if on a 1280x720p screen you have just under 1 million pixels, then under the most optimised circumstances you would never need more than 1 million vertices either, and you can create a near perfect looking scene as long as you don't need it to move / zoom in, right?

So much more than being able to deal with 30 million vertices to make sure that when you zoom in the detail is still there, engines should work to optimise themselves so that they can keep showing the optimum detail for the specified resolution.

http://forum.beyond3d.com/showpost.php?p=1335885&postcount=8

 

[joker454]

Based on what I read do we conclude that Tessalation on the PS3 is a no go because of performance hit?

Well, one clarification there. If the vert load isn't increased then it's no problem. So on stuff like terrain it's still good because you can distribute the vert load better without increasing vert count, and terrain doesn't move so the load always remains predictable. But in cases where overall vert load is increased, then it does become a performance problem because of the way the gpu hardware is setup.

Also to Joker, can you explain a bit more what the "de-tesselator" does? Is the aim supposed to produce similar results to tesselation? Is it supposed to remove vertices to objects moving away and add them to objects near the camera to smooth out the surfaces (to objects near the camera)? In other words reduce vert load to some objects to give room to others and smooth em out? If not can this be done?

The basic goal was to smooth out lod pop and improve the overall vertex look in an automatic manner, without messing with the artists existing work flow. Because the de-tesselator dynamically removes verts, it means the overall scene has slightly less verts than before, and that saved vert count can be spent by the artists to improve important stuff, like to make heads rounder, etc.

The result is 'similar' to tesselation in that some stuff does look better up close because the art guys had more verts to spend, and lod pop is reduced. But it's not as effective as true tesselation. With tesselation, the art guys make a nice model and the hardware makes it much nicer. With de-tesselation, the art guys make a slightly nicer model than they would have previously, and the software will degrade it with distance. So at it's best, the tesselator wins.

The big advantage though is that the de-tesselator doesn't affect anyone. Art guys work the same as always and the tool chain doesn't change, so no one really notices that anything has changed on the art side. There's no learning curve basically.

I think his goal is prevent brutal change of the level of detail of a character/object. As a nice effect it saves memory I guess you only have to keep in RAM what would be otherwise the highest LOD for a mesh, everything else is generated on the fly. I don't think it adds details, it cuts them smoothly without memory overhead.
From my understanding it's different than tesselation as tesselation can go both ways.

Yup, it mostly cuts detail (albeit, smoothly), although some detail is added because the overall scene vert budget goes down so the artists can add some more faces here and there. Definitely not as much as a tesselator would. It can save memory if you ditch lod's entirely and let the de-tesselator do it's thing, but realistically you probably still want to have two lod's, one best one and one crappy one.

So with the performance saved by the De tessellator, wouldn't that leave room for further polygon increase one way or another? I wonder if the result would resemble the one with tessellation implemented?

The savings do allow the poly budget to be increased a bit which is nice, but definitely not to the extent of a proper tesselator. Realistically, a tesselator is the way to go, it will give better results. The de-tesselator was just an intermediary step that has some immediate benefits, most notably being not messing with artist work flow while at the same time improving the scene.

 

[Acert93]

Yes. That'd actually be a smart move for other platforms too. The iedal would be to make the hardware work smarter, not harder. We already have more than enough vertex power to render one vertex for every pixel, so in an indeal scene, we ought to be able to elliminate jaggies completely! If you can put vertices where they're need and remove them where they're not, you'd have a better model-handling system. Of course this would be loads easier with unified shaders shifting jobs dynamically.

While a nice idea in general, per the aliasing I don't think it would completely remove jaggies of straight objects (fences, buildings, gun barrels, swords, etc) seen at diagonal angles, espeically with high contrast backgrounds. Isn't the theory behind sampling that you are averaging around the pixel edges to smooth the the transition (especially objects that may only occupy 3/4th of a pixel or whatnot). Not sure how vertex-per-pixel solves the issue, but I may misunderstand the problem.