Quote: " You use the lighting shader but that odd thing using a fur shader ignores all of the lighting, etc. So you can't really get around becoming a Rembrandt with the shader language."
You don't really need to be a Rembrandt or even a wizard (

) - just need the patience to learn how to combine such effects in an orderly manner. Much like programming generally really - you need good documentation and/or people willing to help out. There are quite a few around on this forum thankfully. Good documentation for shaders still seems to be hard to find though, especially for the earlier versions SM1, SM2 and SM3 required by DBPro (I'm not sure about the present status of the DX11 version that Rudolpho was developing a while back which I think supported SM4 and possibly SM5

).
The MS site has all the information you need, but somehow fails to tell you how to use it - and their old demos don't seem to be easily accessible anymore

. Also, the MS docs seem to switch in some confusing way between telling you about HLSL one minute and then ASM the next

- most shader programmers these days, including me, are OK with HLSL but not with ASM code. Same applies to the nVidia site which used to have a collection of shader demos that you could play with and adapt for your own purposes.
Quote: "It would make for a great ocean shader too, with a little bit of animation."
Evolved did that in an early version of Advanced Lighting but I think he's gone down a different route in his more recent versions.
Quote: "Looks good man. I was working on a similar 3x3 grid system years ago with advanced terrain and the vertexdata commands, I was never quite able to get rid of all of the seams and performance wasnt great, I think your approach with vertex shader and matrix1 grid looks a lot more promising."
Thanks. I hope to have some better looking demos available soon. This is a project that I've had on a back-burner for a long time and finally seem able to get it moving along. The basic idea is that the "terrain" is nothing more than a small grid of simple high-poly plains (I've chosen 3x3 for simplicity at this stage - but may need to step up to a larger grid at some stage to get sufficient resolution in the mesh shape). That's all you need - just those few plains. All the work is done by the shader (plus usual "housekeeping" and game logic on the CPU of course) as you move around. For example, starting from an initial grid of 9 plains, the "player" would start in segment 5:
123
4
56
789
The player might then move to an adjacent segment, segment 3 for example. To maintain the visuals of the terrain, the program would need to either rearrange the original grid to something like the following (green indicates the new segments which need heightmaps to be recalculated, red indicates the segment currently occupied by the player)
897
2
31
56
4
or, possibly simply use the original layout with new heightmaps where necessary and the original ones for segments 2,3, 5 and 6, moved around, etc. I haven't decided which route is simpler yet - both would need the new segment images to be computed (but that can be done virtually instantly on modern GPUs). The question really comes down to which leads to simpler housekeeping as you move around the terrain. Watch this space I suppose.