Is tesselation possible on the PS3?

[E2K]

slightly offtopic but: Why is it so important on PS3?
Is 360 doing it or something? (Comparing games tailored for each system, either 360 is not doing it, or tesselation is a bit overrated.)

edit: nevermind:
http://www.technology.scee.net/files/presentations/cedec2008/PhyreEngine_CEDEC2008Speech_e.pdf Looks like they can already do it, plus it's possible on SPU.
http://forum.beyond3d.com/showpost.php?p=1335488&postcount=567 < but here someone is claiming it would be too slow. Then again, he is stating he is developing ps3 software so maybe PhyreEngine is lying and he is telling the truth.
There was some fud/misinformation spread around. And I believe that is why this topic started

ANyway, while reading the article, it became more obvious that cell was really meant as a GPU companion, seeing what it can do to help rendering and all that.

So do we know who is telling the truth? Joker or Phyre-engine?

 

[Arwin]

It's important for two basic reasons.

1. Tesselation is an interesting technology that at least in theory could greatly improve image quality. However, when DX11 hits the market, the PS3 will be the only console that does not have dedicated tesselation hardware. So it's interesting to know if tesselation is possible through another means, like for instance using SPEs.

2. Insofar as if you're going to do a multi-platform game and you want to make use of tesselation on all platforms, then the relevance of this question is obvious.

 

[rekator]

slightly offtopic but: Why is it so important on PS3?
Is 360 doing it or something? (Comparing games tailored for each system, either 360 is not doing it, or tesselation is a bit overrated.)

edit: nevermind:
http://www.technology.scee.net/files/presentations/cedec2008/PhyreEngine_CEDEC2008Speech_e.pdf Looks like they can already do it, plus it's possible on SPU.
http://forum.beyond3d.com/showpost.php?p=1335488&postcount=567 < but here someone is claiming it would be too slow. Then again, he is stating he is developing ps3 software so maybe PhyreEngine is lying and he is telling the truth.
There was some fud/misinformation spread around. And I believe that is why this topic started

ANyway, while reading the article, it became more obvious that cell was really meant as a GPU companion, seeing what it can do to help rendering and all that.

So do we know who is telling the truth? Joker or Phyre-engine?

The both?

Phyre engine presentation speaks about terrain tessellation and Joker about "character" tessellation.

 

[E2K]

The both?

Phyre engine presentation speaks about terrain tessellation and Joker about "character" tessellation.

As far as I know 3d models are 3d models.

 

[Laa-Yosh]

Cool. How would you deal with hair?...or is that a dumb question.

In offline rendering hair is procedurally 'grown' - each main renderer has some sort of tube primitive that can be generated along a spline. The renderer can always ensure that it won't get faceted edges and can also deal with proper antialiasing (hair is usually less then 1 pixel thick).
You can then randomize it a bit to have 10-100-1000 tubes generated from a single spline, so you can use just 100-1000 control splines for the entire hair mass (10 to 100 thousand strands altogether). No geometry is stored in the scene, so you pass additional data like shaders to the renderer using other (pretty standard) means. We use the splines for dynamics simulations and styling.

Some studios have somewhat different methods to control the hair, for example Dreamworks has 0.5-1.5 inch thick tubes that also define volume and can use some sort of softbody dymanics. Hair is then generated within the tube volumes.

Shadows are usually deep shadow maps, independent from the rest of the scene shadow method (we use raytraced area shadows with Mental Ray, most PRMan renders still rely on standard shadow maps).

 

[Laa-Yosh]

Just curious, I thought normal maps are supposed to replace some of the polygon detail in order to produce a high detailed model without the use of complex geometry that will take too much performance otherwise (ie in Gears the models in game are feasible by the hardware, yet the source model would have been impossible to run in real time without killing performance). Tessellation seems to do the opposite. Its as if it is adding polygons to increase detail. Doesmt this mean that we need much more powerful hardware to do that?

Normal maps can't help the silhouette of the model which remains lowpoly; they also don't properly self-shadow.
In fact sometimes we get shadow artifacts too, from raytraced area shadows, when we're using normal maps without enough underlying geometry (and we're talking about models tesselated to at least several hundreds of thousands of triangles).

Today's PC hardware can already deal with such high number of vertices. Although getting too small polygons (less then 4 pixels) kinda ruins the efficiency of the fragment shading part as it still works in quads.

Consoles are a different matter, even with adaptive tesselation...

 

[Dr. Nick]

Thanks for the reply Laa Yosh. I guess we are several generations away from seeing CG movie quality hair in a game...if we ever see it used in a game.

Do any of you who are in the know, used ATI hardware in the recent past or present, think with ATI or DirectX 11 method we will see characters models with polys in the hundred or several hundred thousand range(67,000 has to be the highest for a character model so far, I don't think there are many games on the market that push more than Crysis). I know ATI was trying to push into the million range with there demo's but that seems kind of too much to ask for even with Direct 11. Fighting game character tessellated to that range seems like a cool idea...or pipedream.

 

[Shifty Geezer]

As far as I know 3d models are 3d models.

Then you know wrong. The nature of terrain is very different to the nature of a face. You are oversimplifying the idea of tesselation into a black and white 'either you can or can't in all cases' scenario.

 

[E2K]

Then you know wrong. The nature of terrain is very different to the nature of a face. You are oversimplifying the idea of tesselation into a black and white 'either you can or can't in all cases' scenario.

We have a documented case of an engine being able to do it on spu.
We also know what tessellation is.
The surface of a terrain, or the surface of a characters face (as seen in many tesselation-demo's) are both 3d models.

You could argue that "spu accelerated tesselation" is less effective than 'x1900' and "dx11-type" (notice " ") tesselation, and that terrain consists of less detail than character faces, and therefor performance wise spu accelerated character model tesselation is not possible, but you are not arguing that.

I would suggest everyone to go to, so we will know what we are talking about:
http://developer.amd.com/gpu/radeon/Tessellation/Pages/default.aspx#d3d9

 

[Dr. Nick]

I think from now on we should state what type tesselation we are talking about to avoid confusion. We should just say DirectX 11 or ATI like tesselation. I think Jokers point is that it's not a good idea to try what ATI is trying to do on the PS3 because all of the extra polygons are going to have to go through the vertex shaders and that is where the problem lies. The SPU might be capable of sub-dividing a mesh it add geometry to it but the RSX is the bottle neck at least if you are trying to do what ATI/DirectX 11 is doing.

 

[Shifty Geezer]

Terrain is very predictable. You can easily budget vertices based on distance, giving a mostly uniform vertex throughput no matter where you're looking. Tesselation of characters and objects can change dramatically - what if 5 people move up close to you? That's where you now have high quality assets all demanding vertex processing.

The point here is, contrary to your inflammatory remark, neither SCEE nor Joker are lying. They're just presenting different cases. Rather than try to dismiss one or other out of hand to simplify the universe, you should take it all on board and form a more rounded view.

 

[Mastperf]

Well said, Shifty.

 

[Fafalada]

That's where you now have high quality assets all demanding vertex processing.

The amount of relevant detail on screen is finite - if you have adaptive heuristics that can deal with it, there's not much difference really - ie. see my first post.

 

[joker454]

The amount of relevant detail on screen is finite - if you have adaptive heuristics that can deal with it, there's not much difference really - ie. see my first post.

That finite amount of vert detail though varies from machine to machine. So even though some hardware handle more than others, they usually all get saddled with the same models for development & time simplicity. With tessellation support though, you now get the added option of being able to bump up said detail on machines that support it, even though you may be still stuck with the same base assets as the other platforms.

Or worded another way, if machine 'A' can handle 10k verts, and machine 'B' can handle 15k verts, more often than not all models will currently be designed with 'finite == 10k verts' in mind, thereby not leveraging machine 'B'. But add tessellation support to the mix, and now you can both still start with the same base assets on all platforms, but improve them on screen on machines that can handle it by adding lots more verts until each platforms specific 'finite' limit is hit.

I guess in an ideal world, both for dev and the players, would be to still start with a common base set of assets, and let the hardware tessellate them up to a given machines limits. So that way the hardware that can't support more verts will stick with the base assets, and the PC guys with their shiny new 5870 gpu's can crank the vert limit way up.

 

[Shifty Geezer]

The amount of relevant detail on screen is finite - if you have adaptive heuristics that can deal with it, there's not much difference really - ie. see my first post.

That is of course true. And as mentioned elsewhere, if we had ideal heuristics and vertex distribution, we already have enough vertex processing power to have 'perfect' models. My real point was just that E2K's attitude sucks.

Having said that though, there's clearly a chasm between theoretical adaptive technologies and what can be achieved in game, as evidenced by the fact we have in-game terrain and scenery tesselation, but we don't have complete adaptive models! Approaches like Digital Molecular Matter have promised this yet haven't delivered. I don't know what the state of current-gen console tesselation is, but the software certainly isn't at the point of being able to implement robust, per-model tesselation LOD, and all we actually get are the occassional white papers presenting specific examples.

 

[ihamoitc2005]

GT4

Hello my friend, didn't PS2's GT4 have tesselation? I remember some video with up close view of the moving car where you can see placement of polygon edges changing. Because camera is always close I did not feel that this was LOD but rather tesselation to have maximum polys close to camera. Also Yamauchi says GT4 has very efficient model data mechanism.

What do you think?

 

[Gitaroo]

nurbs in action?

 

[Shifty Geezer]

PSP supports NURBS in hardware, according to release reports. But at the time we (okay, Laa-Yosh!) discussed the limits of this tech. For a road it makes sense. For a car, it'd be surprising. I certainly don't recall seeing shifting polygon edges in GT4, but then I haven't seen much of that game anyhow.

 

[Laa-Yosh]

Actually, I also recall ERP talking about why it doesn't make sense to tesselate a car using any kind of HOS. The thread is probably still available somewhere around here.

 

[Fafalada]

Having said that though, there's clearly a chasm between theoretical adaptive technologies and what can be achieved in game

It's more a case of having to put down significant long-term resources and risk with going into direction that mainstream industry doesn't follow(from tech to art/tool pipelines), with unproven returns. Companies don't like throwing money into things like that.
And technical-people in this industry that have the kind of power to force the issue are very rare - I can only think of one guy that actually did something like that to date.

At any rate IMO HW evolution is already past the point where this would make a dramatic visual difference. It'll probably happen for efficiency reasons one day though.



About GT4, with car polybudget in 2k-4k range at highest LOD, it's hard to imagine tesselation making much sense. And IIRC there are discrete LOD changes visible in race-starting flyby.
Actually on PS2 I investigated this a bit (tesselating on VUs was just too cool not to try) but for a racing game it was hard to justify a bit slower rendering as tradeoff for a minor-memory saving and smoother car-closeups that you basically never see anyway. We did end up using N-Patch subdivision for physics/tire collision tests though.