Thats a shortsighted view at best. Simple fact of the matter is that no hardware has implemented tesselation close to this functionality before. As I pointed out earlier, the feature is only going to get more exposure in the future, not less.
Xenos tessellation unit - what have we learned?
- Thread starter Dr. Nick
- Start date
PS2 offered topology processing well beyond this level for over 7 years, and we've seen relatively little usage of it(compared to regular, 'static' way of doing things) beyond the obvious low hanging fruits (terrains and what not) - and it wasn't due to performance implications.Dave Baumann said:
As archangelmorph mentions, majority of it comes back to production standards, not what hardware does or doesn't do. And balooning art budgets are only making art pipeline changes getting slower over time.
I second what Faf already wrote and I add that PS3 is more likely to see some decent use of tesselation than any platform around, for a couple of reasons: raw power and flexibiity.
I'd have some interesting tibits to share about 360's style tesselation, unfortunately NDAs kick in at this point
I'd have some interesting tibits to share about 360's style tesselation, unfortunately NDAs kick in at this point
Can you map any HOS algorithm to it?
Yes you can, if you can avoid memory limitations (16kb + 16kb for code and data on Vector Unit 1).
PS2's VUs and PS3's SPUs are particularly good at doing tesselation through direct evaluation of vertices given a set of interpolation coefficients per topology arrangement.
As long as you have enough memory to store your interpolation coefficients you're done, though faster implementations will probably evaluate and tesselate only one topology arrangement at time:
Process all patches with topology A:
-upload evaluation coefficients (for a given tesselation rate)
-send all patches sharing same topology
-tesselate!
-perform post tesselation adjustments
Repeat the previous process for all topologies in this mesh
PS2's VUs and PS3's SPUs are particularly good at doing tesselation through direct evaluation of vertices given a set of interpolation coefficients per topology arrangement.
As long as you have enough memory to store your interpolation coefficients you're done, though faster implementations will probably evaluate and tesselate only one topology arrangement at time:
Process all patches with topology A:
-upload evaluation coefficients (for a given tesselation rate)
-send all patches sharing same topology
-tesselate!
-perform post tesselation adjustments
Repeat the previous process for all topologies in this mesh
I second what Faf already wrote and I add that PS3 is more likely to see some decent use of tesselation than any platform around, for a couple of reasons: raw power and flexibiity.
I'd have some interesting tibits to share about 360's style tesselation, unfortunately NDAs kick in at this point
hmmm multiplatform dev now confirmed?
I second what Faf already wrote and I add that PS3 is more likely to see some decent use of tesselation than any platform around, for a couple of reasons: raw power and flexibiity.
I'd have some interesting tibits to share about 360's style tesselation, unfortunately NDAs kick in at this point
The way things seem it would likely be a first or second party dev to exploit this on that system just like 360 because right now it would be a one box solution but 360 and PCs on the other hand... Whenever introduced as part of DirectX, I would expect there to be a defacto game that uses it kind of like how Crysis is for DirectX10. Does Microsoft provide tools for this in their XNA package?
archangelmorph
Veteran
Not that i'm aware of but I could be wrong..?
(Do MS provide any low level access at all through XNA..?!
)I second what Faf already wrote and I add that PS3 is more likely to see some decent use of tesselation than any platform around, for a couple of reasons: raw power and flexibiity.
I'd have some interesting tibits to share about 360's style tesselation, unfortunately NDAs kick in at this point
Oh yeah any idea who the SPU's would compare to the Geometry Shaders found in the new AMD/Nvidia video cards when it comes to this type of thing? Also I know that animating an organic model is difficult but is it just as difficult to animate cars using this? Would it be considered low hanging fruit?
Last edited by a moderator:
When you say "this" are you talking about the tesselator? Character animation fits within that (look at Natasha's presentation and videos I linked to earlier).
Having messed around with tessalation for while at the start of last gen, the big issues for us were partly on the tool side (although that's largely soluable with time), but mostly it just didn't save very much in the control point count. We needed precise curves that matched model data, and we'd end up with so many control points in a mesh that more often than not we were just end up never tessalating the mesh.
Coupled with the cost of doing it back then it just wasn't worth while, to get rid of some silohette edges in close up replay cams.
I'd look at it again if I were doing a next gen title, and I had the time to experiment, mesh densities are higher now, but I suspect in the cases where your modelling real life objects you'd end up with the same control point density issues.
FWIW I've seen CAD data for a number of cars and they have truly massive numbers of control points.
Coupled with the cost of doing it back then it just wasn't worth while, to get rid of some silohette edges in close up replay cams.
I'd look at it again if I were doing a next gen title, and I had the time to experiment, mesh densities are higher now, but I suspect in the cases where your modelling real life objects you'd end up with the same control point density issues.
FWIW I've seen CAD data for a number of cars and they have truly massive numbers of control points.
Sounds nice on paper, hope you give it a try and share your thoughts on it whenever you start working in a new generation game.
After reading the presentation in the link Dave has provided (thx m8), tessellation does look very, very promising for the future. Specific link here:
http://ati.amd.com/developer/Eurographics/2007/Tatarchuk-Tessellation(EG2007).pdf
Games with a great LOD distance, like Crysis, could be possible on the PS3 and the X360 if Crytek use tessellation, they could even save some memory (a must on the PS3 and since it seems like the SPUs and PS3's power does make it a great machine at tessellation, it's a no-brainer, right?...). I'm not sure if they are lazy developers, though
Platon, I didn't know Viva Pinata does use tessellation until today but it is certainly one of the most clean looking games out there, I'm almost sure it features FSAAx4.
nA0, very interesting stuff, thx for sharing. Aren't the VMX in Xenon like *small* SPUs so they could help the GPU to produce similar results thus also helping the GPU to produce tessellation?
Cheers
Last edited by a moderator:
Though Lair is generally snubbed, from the sounds of it, it is performing a very high degree of applied tessellation. I haven't seen Lair in the flesh though to know if it really works well.
Ironically the only place where I ended up using tesselation was not for graphics at all - but physics. We used N-Patches to smooth out stage collision meshes when testing for contacts with tyres.ERP said:
Without it, smooth roads sometimes need collision mesh density higher then base mesh (or you just need artists that know how to make mostly flat roads
).On hindsight, I would probably want to go with completely HOS(or some other procedural representation) based roads in the future, smoothing I mentioned only works well as long as modeling is reasonably consistent (and in my experience artists find that a very tough demand), not to mention HOS roads map better to streaming levels.
Well most progressive refinement methods use tesselation or some level or another - or is the word reserved for HOS now?nAo said:
Anyway Lair Terrain is handled differently then rest of meshes, it looks/behaves very much like:
http://users.belgacom.net/gc610902/
No idea what progressive refinement exactly was used for other meshes though - maybe you can give us some l33t insider clues
Ironically the only place where I ended up using tesselation was not for graphics at all - but physics. We used N-Patches to smooth out stage collision meshes when testing for contacts with tyres.
Without it, smooth roads sometimes need collision mesh density higher then base mesh (or you just need artists that know how to make mostly flat roads
We did something similar, our physics mesh for roads were Quadratic patches, and in retrospect I'd use a more dense polygon mesh if I were doing it again, the cost for the collsion detection was judt way too high.
No, of courseWell most progressive refinement methods use tesselation or some level or another - or is the word reserved for HOS now?
I might be wrong but I got the impression Lair progressive meshes work at index buffer level, vertices don't change at all.This is certainly an area I've been hoping to see games explore in the future on Xbox 360 (and other platforms for that matter).
Cyan I remember, Remedy saying that they will be using a CPU thread for terrain and tesselation in the large seamless environments of Alan Wake. I would assume the VMX128 capabilities of Xenon would be a good factor in the 360 version, considering they are just using the CPU for tesselation.
Cyan I remember, Remedy saying that they will be using a CPU thread for terrain and tesselation in the large seamless environments of Alan Wake. I would assume the VMX128 capabilities of Xenon would be a good factor in the 360 version, considering they are just using the CPU for tesselation.