Nvidia´s demosIn addition to implementation in games, NVIDIA has given demonstrations since October of three rendering techniques that use vertex texturing.
This first demonstration represents a field deformation thanks to a height map indicating the transformation to apply for each vertex. To provide good quality, the floor has to be made of a significant number of triangles. This technique is only interesting for dynamic transformations because in the case of a static deformation (for example, creating an uneven map that doesn’t change), it’s easier and more efficient to do it at the source.
NVIDIA´s second demonstration is the most interesting and represents an advanced modelling of waves and disturbances on the surface of a small lake. Thanks to vertex texturing, the surface of the water is quite modified. It isn´t just some kind of optic trick like an advanced bump mapping / normal mapping (even if this technique is used to perfect the rendering). To prove this, we displayed the geometry. It’s important to point out that the water’s surface must be made of a large number of triangles.
The last demonstration involves some tissue, blowing about realistically in the wind or affected by the movement of a character, etc., and of course takes into account different physical parameters. This demonstration represents physical effects that will increase the rendering quality of the scene but without changing gameplay. It’s in the same category of effects as Havok FX but it is different than Ageia´s PhysX that can go much further.
How to go without vertex texturing ?
To justify this absence, ATI showed the limitations of current implementations (= NVIDIA) of vertex texturing with no standard filtering support and its very high performance cost. These limitations are true, but they do not prevent its use in certain cases, in some games, for example. ATI also spoke of a different technology that allows going without vertex texturing and still providing more possibilities : rendering to vertex buffer (R2VB). Roughly, this technique makes it possible to directly input pixel shader computed data into the vertex shaders. It mainly relies on the addition of this capability in drivers and is functional for all DX9 graphic cards since the Radeon 9700 (Nvidia apparently could also implement it).
In short, with vertex texturing, data in a texture calculated by pixel shaders is applied on a vertice’s flow. With R2VB, data is transferred (or partly so) to vertices in pixel shaders and it’s via these pixel shaders that data included in a texture that has been previously calculated is applied (the other possibility is to calculate everything simultaneously). Results are then written to a render target ("texture" in which data can be written) that vertex shaders next interpret as the vertice’s flow (or as part of it) in order to pursue a normal rendering. This is all a little complicated and overall quite similar to vertex texturing, which is simpler to use but more restricted. It is obvious that it is easier to process dynamic tessellation with R2VB, for example, to create vertices to increase geometrical details even for objects that can be distorted. You just have to increase the size of the render target to contain more pixels. As they can be then interpreted as vertices, geometry is effectively increased.
Render to texture has been used for a long time and allows the calculation of a texture that will then be used by being reinjected in pixel shaders in another path (for example, a texture that contains a reflection). The render to vertex buffer (R2VB) is similar except that it allows reinjection directly at the base.
The effect on performances is similar. R2VB implies additional operations but partly transfers vertex shader calculations to pixel shaders. This could be of interest when a Radeon X1900 features 48 pixel shader processing units as compared to 8 vertex shaders. By the way, the same is also recommended with vertex texturing, calculating texture operations in a pixel shader and only then using finalised and pre-filtered textures with a single access in the vertex shader. These accesses can indeed require a high number of cycles in vertex shaders as they aren´t optimised to mask latency. But this is not all. Because of the lack of filtering at this level, it has to be emulated via several accesses to a texture (one is already very costly and 4 are required for bilinear filtering) and a filtering in the vertex shader. It’s also important to specify that it’s generally possible to avoid the first problem for textures using one component only (like displacement maps) by using a four components texture that reproduces the same data in each, with a slight shift (1 texel in each direction). In brief, this allows only having one texture access instead of four but requires the access to one texture that is four times bigger (even if its level of detail isn´t higher).