spherical terrain node or height mapping a sphere?

[Anthony]

Maybe cosin does work as easy like my way too, don't know. There are always more ways to achieve the same. I came to this solution due to I don't use a mesh to draw but instead I use drawIndexedTriangleList (thus far, will deepen out the strip/fans). This saves a lot of data being in memory. It's not the fastest thing to draw a mesh however a terrain will always hit the FPS. We have even created a camera to fight the render costs .

My philosofy about it being 'better' is due to the fact you would need a normal anyway and it should be calculated.

And as I am fairly new to this, never ever take my word as I can say the biggest nonsense (well, it's no nonsense but can be)

For the cosin it's propably possible too to adjust the longitudes pitch so you keep squares rather then rectangles. That would have my preference then due to the least distorted quads.

[Anthony]

With a TriTreeNode system you don't save positions only pointers to nodes that are neightbours and children. Then when doing the actual rendering you plot in the potitions.

If you need a higher detail you just divide the triangle. This needs only the first to coordinates to keep stored in a patch, so called topleft and bottomleft corner.

First I set up a big array of TriTreeNodes and keep track of how many are actually used. This saves creation of structs wich is time consuming and as it is used often the array is a member of the terrain class. The array is big but only stores pointers to other indices of the tritreenodes. Than I create an array for the patches wich holds the position and the opposite corner (x and z, y isn't needed here). Before rendering I call a recursive function to split the tritreenodes. In the rendering process I call a recursive function wich gets the two corners passed in. There you could use any calculation you desire.

When that's implemented the way I like it I will try to skip TriTreeNodes that will stay the same without recreating the whole tree.

Perlin Noise doesn't suite me I think as it won't save terrain changes. However it does have some attraction as (not sure here) you can 'zoom in at the detail'. With this TriTreeNode system you have a variation tree too - haven't dived into that yet - wich is a tree that will smooth heights for the details that hasn't been stored. That tree is being recreated when set dirty, it should be updated after modifying the terrain.

Creating a game is a game itself
EDIT: Real-Time Dynamic Level of Detail Terrain Rendering with ROAM by Bryan Turner has three pages of explanation and a source that hits the core of this system.

[Granyte]

i got the vertice figured out

and i would have the indice to but so far irrlicht refuse to take them from an array or w/e and i reallly dont like the idea of writing every single indice one by one

[Anthony]

it depends on how you have the vertices.

for instance if you have a linear array of vertices resambling a 3x6 grid.

Code: Select all

S3DVector vertices[ 12 ] =
{
  v, v, v, // v = a vertex obviously
  v, v, v, // but for simplicity it's a v
  v, v, v,
  v, v, v,
  v, v, v,
  v, v, v,
}

then you have

Code: Select all

s32 w = 3;
s32 h = 6;

to loop for the indices

Code: Select all

s32 index = 0;
for( s32 z = 0; y < h - 1; y++ ) // loop rows <-- EDITTED
for( s32 x = 0; x < w; x++ ) // loop cols
{
  
  s32 vertexIndex = z * w + x; // in a loop like this the value always incr with 1 (0, 1, 2)(3, 4, 5)(6, 7 etc...

  indices[ index++ ] = vertexIndex;
  indices[ index++ ] = vertexIndex + 1;
  indices[ index++ ] = vertexIndex + w; // vertex is in the next row

  indices[ index++ ] = vertexIndex + 1;
  indices[ index++ ] = vertexIndex + w + 1; // vertex is in the next row
  indices[ index++ ] = vertexIndex + w; // vertex is in the next row

}

EDIT: Removed a little bugger there