Jump to content
  • Advertisement
Sign in to follow this  
JackTheRapper

Throwing ideas around for dynamic heightmap storage

This topic is 3580 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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

Share this post


Link to post
Share on other sites
Advertisement
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!