just wondering if it is posiable using vs 1.0 to parse a small height map to the shader to set the height of the verteces. Doing it this way would mean you would only need to store 1 patch of the terrain. and could save a heaps of memory

For this you need support for "vertex-textures" and it is only in VS3...

Chances are that even with support for this you would have a lot of problems using it for terrain -- specifically, you'll hit a lot of issues with collision detection.

You could use 1 stream as a X/Z for a patch. A second stream that changes per patch that holds just Y.

You could use 1 stream as a X/Z for a patch. A second stream that changes per patch that holds just Y.

Sounds interesting how would you do this?

Create 2 vertex buffers. One for XZ data and one for Y data. As a first step, we won't worry about space.

Create a VB to hold a vertex that just has two floats.

Create a VB to hold a vertex that just has one float. You'll create this one per tile.

Create a vertex declaration that indicates position is float2, at offset 0 of stream 0, and, lets say texcoord0 is a float1 at offset 0 of stream 1.

Lock and copy the data into the VBs.

SetStreamSource(0, xzvb)
SetStreamSource(1, yvb)

In the shader, build your position from

pos.x = IN.Pos.x;
pos.z = IN.Pos.y;
pos.y = IN.TexCoord0.x;

then perform world transforms, etc. as usual.

In reality you'll probably want at least one actual uv set in there... or you may generate it based on world position. If you need normals, they'd probably go into the VB holding Y values.

Depending on what you need, you could pack the XZ data into two bytes of a D3DCOLOR, and multiply it back up in the shader... Same deal with the Y. If you need 16-bit x,z, or y, you can use short2, or combine two parts of a D3DCOLOR.

You could possibly make your Y vertex buffer dynamic and fill it as needed with the appropriate values for the section of land that's visible.

Then again, if you compress your vertex data down to 8-bit x,y,z, and vertex data needs to be 32 bit aligned anyway, there's no advantage to using the second stream. Just use one stream, at 4 bytes per vertex. We use 16-bit Y values, and pack that into a D3DCOLOR as X,Z,YLow,YHigh.

Depending on your game's needs, and how much possibly redundant vertex data you might have, there are many different ways you might want to go... consider the above as just a push to get you to think about all your available choices.