Height field data
EMR
is a pointer to the height data", but not much else. Would I be
correct or incorrect in thinking that the data should be an array of
number values corresponding to a grid of heights? Even if I'm right
there, I still have a question. Lets say I have a map with the
following values:
1 2 3
4 5 6
7 8 9
10 11 12
Would the array that I'd pass be {1,2,3,4,5,6,7,8,9,10,11,12}? Would
width and depth samples be 3 and 4 respectively?
Thanks for the helpful help...
Martijn Buijs
Yes.
The data should stored like a grayscale image (i.e. a 'height map'). Width-samples == the number of
columns (image width), and depth-samples the number of rows (image height). So you really just pass
the image dimensions of the to ODE.
FYI, when I wrote the dHeightfield code functions I avoided the term 'height' for the heightmap
dimensions, replaced with 'depth', to avoid confusion with the heightmap dimensions (2D) and height
dimension (3d).
/Martijn
EMR
How does one get a dHeightfieldDataID from an image file?
I was operating under the assumption that it would take raw arrays, or
possibly arrays of arrays.
Martijn Buijs
Your assumption is correct. But images, especially grayscale images like heightmaps, are just a long
array of values either way. Whether you read the heightmap from image from disk it will either way
be stored in an array in your program.
In any case, ODE does not supply an image file loader for height map data, you will have to do it
yourself (depending on the preferred file format, not very difficult).
Personally, I prefer to store height data as RAW heightmaps, in 16-bit precision. PhotoShop supports
this format, so it is easy to visualize/debug.
As alternative, you can use the "GetHeight" callback mechanism, so you can feed ODE with the height
values (samples) manually, when it needs them to perform collision detection. So you don't _have_ to
store the data in a 1D array, you can store it as 2D array, sample it from a bitmap/image,
decompress, generate it on the fly as you wish.
/Martijn