From real experience 8 bits isnt enough range for whole map, so I would
guess
that the extra byte 64+1 is a magnitude ( 0..255) multipleied by 256
and all
the next 64 numbers are added (offset) foo that value.
why the extra row??? 65x65 64+1 64+1 ????
It might be 2 bytes (0..64k-1) for the starting offset 64*2 + 1 (the 1
being
something else.
or there might be other data in a 'struct' (besides the possible offset
values 64*1)
maybe multipliers for the point offsets (so that terrain withing the cell
can shift by more than
1 step for each value in the byte.
Its possible that the extra values might be a lower Level of Detail (LOD)
mapping to use for
a smaller simpler mesh at long distance (like a 8x8 mesh = 64 values
(maybe 2 bytes each)
that are averages (cant rely on just picking every 8th point to use for
this as you might randomly
get a peak or a dip that will distort it too much...)
Or something Ive done for that extra row+column is to have 64x64 tiles
but include
the points to finish the 64th row/ collumn of tiles (requiring 64+1
points each direction = 65x65)
These point values overlap the next cells on 2 side (like right and
bottom if its a 4th quadrant
coord system) so that all the tiles triangles can be drawn without having
to pull other cell's data
into mem (or just complicate the access code -- a client that get sent
cells would have to be sent the
extra cells to do all the tiles properly...)
Kevin Fishburne wrote:
> I am desperate and need help. Whoever can solve this will be rewarded.
> I've been working on this in one way or another for about 6 months.
>
> I'm working on a program to assist me in figuring out the way
> elevation data is stored in a small section of a data file for the
> game Morrowind. I'm going to be creating a mod for it and need to
> create a landscape generation program first. This IS a legal endeavor,
> just a difficult one.
>
> The game map is broken down into 1024 64x64 vertex sections, called
> cells, and stored sequentially in a data file (*.ESM). Although the
> cells' order in the ESM go from left to right, top to bottom, the
> elevation/vertex data is stored in each cell left to right, bottom to
> top due to the game's coordinate system.
>
> Each vertex height is represented by a 1 byte signed integer. This
> value is relative to the height of the vertex before it (-1 means the
> vertex is 1 unit lower than the previous vertex, etc.). However, at
> the end of each row of vertices this value is not carried over to the
> vertex at the beginning of the next row. It resets to something,
> presumably 0. Disturbingly, the string of bytes describing a cell's
> elevation is 4225 bytes long (65x65 bytes), in contrast to the game's
> 64x64 vertex cells. There is an extra row and column for an unknown
> reason. Each cell has it's own global elevation offset as well, which
> is added to each vertex.
>
> I've created several test ESM's using another landscape generation
> program. One has a horizontal gradient of elevation, the other a
> vertical, and another is simply a circular "hill" that overlaps a 3x3
> grid of cells. I included a JPEG for each so you can see what the
> results should look like. Each has mixed results in the program.
>
> My program displays the results of my "formula" for interpreting the
> data graphically and numerically to assist in cracking the format.
> Graphically the elevation is shown as a grayscale. Numerically each
> vertex is shown as either its raw ASCII value (from the ESM, 0-254),
> its relative elevation, or its absolute (final) elevation.
>
> Please contact me in this newsgroup or via email if you are interested
> and I will send you the project and data files (about 1.7 MB). It is
> written in VB6 and contains no additional references or API calls.
>
> Thanks.
>
> Kevin Fishburne
> kfishburne@_NOSPAM_pinestate.com