Throwing ideas around for dynamic heightmap storage

Started by
-1 comments, last by JackTheRapper 15 years, 2 months ago
Hi, just throwing out some ideas for a splatted heightmap I shall be working on over the next few months. The idea is to build an application that can generate and texture a heightmap from a given image file/noise function/combo and display it in realtime. Furthermore, the heightmap will be editable in realtime, as described below. Here's what I'm thinking: * Array of vertices divided up into tiles say, 32x32 or 64x64 for splatting and quad/octree purposes * An array of colours for each vertex, generated offline by a position/directional lighting algorithm. each lit, greyscale colour will be further coloured depending on the vertex height/angle * An array of indices for each vertex in order to render the tile as a triangle strip So, with just the above, I have a lit, coloured heightmap stored in tiles for culling/picking/splatting. Now, splat texture-wise, I'm thinking the following: * Tex stage 0: all splat tile types (base/dirt, grass, rock, sand, etc.) stored in one lo-res texture (say, each tex is 32x32 so 5 tex would be 160x32) using 1 set of texture coordinates (0,0 -> 1,1) to access each splat texture (tex coords are split to select the correct texture, e.g. 0,0 -> 0.25,1 = base/dirt tile etc.) * Tex stage 1: high-resolution detail texture (say, 512x512) with a grayscale texture stored in each colour channel (r = grass, g = rock, b = sand, a = dirt, etc.). Each of these hi-res textures share the same tex coords as the 1st tex stage (0,0 ->1,1) BUT the tex coords for this stage actually store the blend amounts for each splat tex in stage 0 (glTexCoord4f(0,0,0,1) = vertex has 100% rock texture) The hi-res textures will be blended on top of the low-res textures depending on the fragment distance from the viewer. This will be calculated in the vertex shader and stored in tex unit 3's texture coordinates as a single value to be interpolated for each fragment. Too far away, the texture won't be drawn. and so on

Stage | Tex Image       | Tex Coords
---------------------------------------------------------------------
  0   | splat textures  | base coords for all textures (2 components)
---------------------------------------------------------------------
  1   | hi-res textures | splat blend amounts (4 componenets)
---------------------------------------------------------------------
  2   | none            | frag position calculated in vertex shader (1 component)
---------------------------------------------------------------------

So far, so good. Problem is, I'm trying to figure out the most optimum way to store this data. I'm gonna chuck it into a VBO, but what type of VBO and how is my struggling point. Some data is dynamic, some is static: Dynamic ------- * Vert colours * Splat blend amounts (stage 2 tex coords) * Vert Y component Static ------ * Vert X/Z components * Texture coordinates (stage 1 tex coords) Would it be best to make each terrain tile (32x32/64x64) one big dynamic VBO? Or can I put the static contents in one and the dynamic in another? is it possible to put the x/z vertex data in a static vbo and the y component in a dymamic one? Any thoughts (including on the general heightmap design) much appreciated :D

This topic is closed to new replies.

Advertisement