Adaptive Tesselation

This is for the Matrox Parhelia.

Ah. Is it the only card around that supports this? The DX9 docs dedicated a whole page to adaptive tesselation, I thought it might be a more widespread technique...

Irritating. I''m looking at N-Patches as well now - they at least seem to be supported on a few recent cards - but what I''m really looking at is view-dependent LOD, and N-Patches seem more targetted at a single LOD across an entire model. I guess I could break the model into clusters and set different segment values for each piece, but it''d lead to discontinuities at the piece boundaries.

N-patches are loseing suport I hear
but DX10 generation cards are suposed to have a programable geometry thingy

Bobboau, bringing you products that work... in theory

Correct me if I am wrong but I think ATI''s NPatch scheme just teseleltes the whole geometry for the scene and the user has no control over selecting which mesh to tesellate and which ones not to. So therefore,m I do not think you can divide your mesh into smaller pieces and select a different npatch tesellation per piece. (not to mention the cracking problem that would result).

quote:

---

Original post by superpig
Ah. Is it the only card around that supports this? The DX9 docs dedicated a whole page to adaptive tesselation, I thought it might be a more widespread technique...

Irritating. I''m looking at N-Patches as well now - they at least seem to be supported on a few recent cards - but what I''m really looking at is view-dependent LOD, and N-Patches seem more targetted at a single LOD across an entire model. I guess I could break the model into clusters and set different segment values for each piece, but it''d lead to discontinuities at the piece boundaries.

---

Yes, the matrox parhelia is the only card to support this. It uses it as a base for displacement mapping. Adapative tessellation, however isn''t terribly useful because most people are not geometry bound. Which is why most vendors don''t support it - additionally, adapative tesselation tends to introduce vertices at places where they are not efficent. Its just more efficent to throw more static geometry at the problem.

I doubt you will see tessellation become widespread until people are completly data bound (e.g. the size of the geometry is just too big).

D3DX does have an adapative N-Patch tesselator that seemlessly introduces new vertices and blends them in. But its all software.

I see.

What I''m looking at here, btw, is view-dependent LOD. The problem is that vertex hierarchies don''t seem to be hardware-friendly, because you have to make changes to both geometry and topology of the mesh on a frame-to-frame basis (so you''re constantly modifying your vertex and index buffers).

So I''m looking for alternatives - displacement mapping is something I want to use as well, and I thought that maybe by using lower-poly but tesselated meshes, I could achieve a certain degree of LOD (through varying the number of divisions per patch) while not having to modify the vertex/index buffers. But apparently not.

One thing that puzzles me: Progressive Meshes seem to be able to do something very much like this (using a simple chain of operations instead of a tree) with no speed issues. They''re still modifying topology and geometry every time the LOD changes - how are they doing that at a reasonable framerate?

There is >an< example of working around the adaptive tesselation problem that I think is quite ingenius (available with source and technical document). Google the "Xvox" terrain renderer, it does hardware-only terrain LOD with ridiculous processing speed. I''ve been quite impressed. First ran across it on the NVidia site somewhere, they use it to showcase some ooh-aah stuff.

But the real miracle - the technique can already be used by VertexShaders v1.1 onwards.

(PS - howbout some more Engenuity?)

Ah yes, I remember reading about XVox.

I''m explicitly not looking at terrain stuff here, though. I''m looking at very large animated models.

I want to be able to battle Colossuses and Titans in my games.

AQ you''r wrong, you set a render state to tell it how much and in what way to smooth out your geometry, and then you render it, if you want diferent parts of the mesh rendered with diferent levels of smoothness you just change the subdivision level (unless you meant that it applys the same smoothing value to everything within a draw primitive call) craking isn''t that big of an issue realy, it''s just one small complication you have to take care of during model load.

Bobboau, bringing you products that work... in theory

quote:

---

Original post by superpig
One thing that puzzles me: Progressive Meshes seem to be able to do something very much like this (using a simple chain of operations instead of a tree) with no speed issues. They're still modifying topology and geometry every time the LOD changes - how are they doing that at a reasonable framerate?

---

D3DX's progressive meshes are view-independent, no? I think based on the research by Hugues Hoppe. He's got a paper on VIPM's, but I don't think I've read it.

Off the top of my head: With view-independent meshes, I think you can order your mesh so that the least-effective triangles are at the end of the index buffer, and then just don't draw them as the LOD decreases.

---

Muhammad Haggag,
Optimize

[edited by - Coder on June 3, 2004 9:02:13 AM]

I was reading up on this the other day, and although it is a VERY cool technique, just due to the fact that most manufacturers don''t support it most developers are stuck using other methods and not adaptive tesselation.. Which is unfortunate.. However DX Next is supposed to be making a push to bring this back into the limelight, which will be a very very good thing for developers

quote:

---

Original post by Coder

quote:

---

Original post by superpig
One thing that puzzles me: Progressive Meshes seem to be able to do something very much like this (using a simple chain of operations instead of a tree) with no speed issues. They''re still modifying topology and geometry every time the LOD changes - how are they doing that at a reasonable framerate?

---

D3DX''s progressive meshes are view-independent, no? I think based on the research by Hugues Hoppe. He''s got a paper on VIPM''s, but I don''t think I''ve read it.

---

Yup, I''ve been reading those; he''s got a view-dependent one there too. The little VDPM video on that page (with the teapot) is what I''m thinking about, but there''s no detail there as to the framerate that''s running at (or the hardware it''s running on).

quote:

---

Off the top of my head: With view-independent meshes, I think you can order your mesh so that the least-effective triangles are at the end of the index buffer, and then just don''t draw them as the LOD decreases.

---

Ahhh.... mmm, that makes sense. IIRC each step in the view-independent mesh is an edge collapse, which guarantees one or two triangles lost per step (because you can''t have more than two triangles sharing an edge). So all he has to do is decrease the number of triangles rendered by one or two. The actual vertices aren''t being replaced with a single one.. they''re being moved so that all the other indices remain the same. So same number of transforms, but 2 fewer triangles to be rendered...

That seems a bit off, though. The screen space of the result is roughly the same, so the fillrate''s not being fixed up... perhaps I''m right in thinking that a vertex will only be transformed if an index refers to it? (That way, even though the total amount of geometry is the same, the fraction of it being used and thus transformed would be decreasing).

In any case, the problem is that I don''t think that can be used for VDPMs. While a standard VIPM can be modelled as a chain of edge-collapses - with two triangles per node, and thus a nice easy list of triangles, where you work along the chain to increase/decrease the LOD - a VDPM is more like a tree ("vertex hierarchy"). There is no simple way to order the primitives accordingly.

There might be room for compromise, though. What if the model were broken up into polygon clusters, and each cluster treated as a VIPM? Heck, even as discrete LODs with geomorphing? That would turn a single 100,000 tri-list call into one-per-cluster, but it should allow a pretty significant change in detail across the model... there''s also problems with cracking, but perhaps by constraining clusters so that their LOD is +/- 1 all adjacent cluster''s LOD... it may well work.

I think it might lend itself neatly to animation, too. Cool! Has anyone tried this?

quote:

---

Original post by superpig
perhaps I''m right in thinking that a vertex will only be transformed if an index refers to it? (That way, even though the total amount of geometry is the same, the fraction of it being used and thus transformed would be decreasing).

---

That''s the case with hardware vertex transformation. On the other hand, the software pipeline transforms all the vertices in the specified index range (range supplied through DIP).

quote:

---

In any case, the problem is that I don''t think that can be used for VDPMs. While a standard VIPM can be modelled as a chain of edge-collapses - with two triangles per node, and thus a nice easy list of triangles, where you work along the chain to increase/decrease the LOD - a VDPM is more like a tree ("vertex hierarchy"). There is no simple way to order the primitives accordingly.

---

Yes, the problem is that the decrease-number-of-triangles-rendered technique relies on having the least-effective triangles at the end of the index buffer. That is, the determination of those triangles doesn''t depend on the view at all.

quote:

---

There might be room for compromise, though. What if the model were broken up into polygon clusters, and each cluster treated as a VIPM? Heck, even as discrete LODs with geomorphing? That would turn a single 100,000 tri-list call into one-per-cluster, but it should allow a pretty significant change in detail across the model... there''s also problems with cracking, but perhaps by constraining clusters so that their LOD is +/- 1 all adjacent cluster''s LOD... it may well work.

---

I don''t know. I think:
If you divide your model too much, you''ll do a lot of DIPs. If you don''t, the difference between a LOD level and another will be great (in terms of number of edges collapsed), and that''d lead to bad cracks even in the case of constraining a LOD-delta of +/- 1.

quote:

---

I think it might lend itself neatly to animation, too. Cool! Has anyone tried this?

---

Well, if you try it out, fill us on the results


Muhammad Haggag,
Optimize