Jump to content
  • Advertisement

Archived

This topic is now archived and is closed to further replies.

superpig

Adaptive Tesselation

This topic is 5284 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Is anyone here using - or does anyone know of - a device which supports adaptive tesselation, and thus the D3DDEVCAPS2_ADAPTIVETESSRTPATCH and D3DDEVCAPS2_ADAPTIVETESSNPATCH device caps? I''ve tried looking in a couple of devcaps databases but I''m not finding anything.

Share this post


Link to post
Share on other sites
Advertisement
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.

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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).

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites
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?)

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!