Blitz terrains are good for crappy video cards, because you can have very few polygons in the mesh and still have some decent detail up close. In the castle demo, the terrain looks kinda smooth, yet is never made of more than 768 polygons.
But that terrain is just rolling hills. If you want an bumps, or hills in the distance you need more polygons.
Blitz terrains start to really cost you framerate when you get up into a few thousand polygons of detail, and that's still not much detail.
If a detailed terrain is what you want, then custom meshes will get you much more detail. But if you want good view distances you'll have to make your terrain out of tiles and have several levels of detail for each tile of terrain.
My terrain system uses that method. Multiple static levels of detail for each tile. I allow one texture per tile, so the texture can be rather varied too, though if you really want high texture detail you'll need to use vertex alpha and multiple surfaces so that you can tile the textures more than once per tile of terrain. The surface count is what limits you to large tiles though, so if you did something with vertex alpha you'd want to limit yourself to no more than 4 textures per terrain tile or less, and you'd have to make the tiles 4x as wide to keep the number of surfaces the same.
"My second question: I want to make a terrain system that calculates terrains given a certain amount of key points (where the terrain smoothly goes through all those height points). I had a go at creating a function for that before and it stumped me. Before I embark on it again, is there an algorithm already documented somewhere?"
There are definitely algoithms to do that, but I don't know a specific good one that can work just with points. A bezier surface for example would require additional control points at each point. Four I think.
There's something called nurbs... dunno how those work.
Tehn there's perlin noise... I have a function for that int he code archives. It occurs to me that you could define the points for one of the lower octaves... and so define only a few points, in a grid, and then allow the perlin noise function to fill in the higher octaves of data based on that. I forget if my function calculates things the right way round for that though. You'd need to divide the height each time and I think I multiply it, so I work from the high octaves of noise to the low octaves.
My perlin noise function also uses a cosine interpolation function for bilinear filtering... You might be able to use cosine interpolation to interpolate between your heigts somehow. Imagine a single wave of a cosine curve. The height of the start of the curve, above 0, is your first point, and the height of the end of the curve, below 0, is the height of your end point. Assuming the second point is lower of course. That gives you a smooth curve, but it wouldn't look very realistic. Neither would any sort of bexier curve or spline surface really. Not noisy enough. That's why I use perlin noise.
But that terrain is just rolling hills. If you want an bumps, or hills in the distance you need more polygons.
Blitz terrains start to really cost you framerate when you get up into a few thousand polygons of detail, and that's still not much detail.
If a detailed terrain is what you want, then custom meshes will get you much more detail. But if you want good view distances you'll have to make your terrain out of tiles and have several levels of detail for each tile of terrain.
My terrain system uses that method. Multiple static levels of detail for each tile. I allow one texture per tile, so the texture can be rather varied too, though if you really want high texture detail you'll need to use vertex alpha and multiple surfaces so that you can tile the textures more than once per tile of terrain. The surface count is what limits you to large tiles though, so if you did something with vertex alpha you'd want to limit yourself to no more than 4 textures per terrain tile or less, and you'd have to make the tiles 4x as wide to keep the number of surfaces the same.
"My second question: I want to make a terrain system that calculates terrains given a certain amount of key points (where the terrain smoothly goes through all those height points). I had a go at creating a function for that before and it stumped me. Before I embark on it again, is there an algorithm already documented somewhere?"
There are definitely algoithms to do that, but I don't know a specific good one that can work just with points. A bezier surface for example would require additional control points at each point. Four I think.
There's something called nurbs... dunno how those work.
Tehn there's perlin noise... I have a function for that int he code archives. It occurs to me that you could define the points for one of the lower octaves... and so define only a few points, in a grid, and then allow the perlin noise function to fill in the higher octaves of data based on that. I forget if my function calculates things the right way round for that though. You'd need to divide the height each time and I think I multiply it, so I work from the high octaves of noise to the low octaves.
My perlin noise function also uses a cosine interpolation function for bilinear filtering... You might be able to use cosine interpolation to interpolate between your heigts somehow. Imagine a single wave of a cosine curve. The height of the start of the curve, above 0, is your first point, and the height of the end of the curve, below 0, is the height of your end point. Assuming the second point is lower of course. That gives you a smooth curve, but it wouldn't look very realistic. Neither would any sort of bexier curve or spline surface really. Not noisy enough. That's why I use perlin noise.