Have you seen the date of that article ? March 1999. Lots of things have happened since on the 3D sector...

It''s essentially an outdated form of displacement mapping. Doing that in software was a good idea in 1999, but is a very bad idea today. It will break static mesh caching schemes, it will oversaturate the AGP bus, etc. Conclusion: it will be very slow.

The next generation of 3D hardware (GF5, Radeon 9700, Parhelia) will (or does already) include real hardware assisted displacement mapping via textures. The subdivision is done on the 3D card, and is totally transparent to the programmer. The geometry detail is supplied through a heightmap texture.

/ Yann

quote:
Sorry, I should have been more specific what I wanted to know was can you transform the vertices in a 3d mesh by transforming some vertices the normal way then calculate the rest by interpolating the others?

You can''t create new vertices in a vertex shader. You''ll still have to create them on the CPU first. Or if you are really tricky, you could try to use subdivision surfaces (HW accelerated).

About the transformation: You can''t simply interpolate a rotation, since it''s not a linear function. You can create objects by displacement of a heightmap, such as the Flipcode article described. But that''s not possible in a vertex shader, since you don''t have access to a highres displacement map. You need the CPU for that, or dedicated hardware support.

You could try to use some weird tricks to approximate a rotation. But that''s going to be a lot slower than doing the real rotation in the first place. A rotation is a matrix multiply. In a vertex shader, it takes 4 opcodes (DP4) to transform a homogenous point. That includes everything: rotation, scaling, translation, projection.

Actually, today''s microcoded GPUs are ultra-optimized for matrix operations. So a real rotation is probably one of the fastest operations you can get. A lot faster than a 3D interpolation.

/ Yann