Terrain with height values stored in 4 bytes
Terrain with height values stored in 1 byte and modified with Erosion Filter of Box Size 3 and 1 IterationAs you can see, running the Erosion Filter on the terrain greatly improves the quality of the 1 byte height field. (When I say 1 byte height field I mean that the data in the .raw file was stored in bytes. The height field is still stored in 4 bytes (float) within Decade). There is a little loss of detail compared to the 4 byte terrain however depending on the game and environment this may be acceptable.
Terrain with height values stored in 1 byte and modified with Erosion Filter of Box Size 11 and 5 IterationCare has to be taken when using the Erosion Filter. As you can see above running with too large a box size over many iterations starts to remove allot of the detail from the terrain resulting in a flowing rolling landscape. Again, this may be desirable in certain instances and not in others.
What this has thought me is that there is no right answer to the question I am asking. It all depends on personal preference and the requirements of the game at that time. To accommodate this I am going to allow a broad range of options. My custom height map file will be modified to allow the user specify how the data is stored.
Currently the simple file type is
Width (2 Bytes)
Length (2 Bytes)
Data (Width * Length * 4 Bytes)
so by adding in a type field the user can save and load as they desire
Width (2 Bytes)
Length ( 2 Bytes)
Type (1 Byte)
Data( Width * Length * Type Bytes)
I hope that this,along with the box and any other Erosion Filters added later, will allow Decade deal with a large variety of requirements when rendering/storing its terrain.
No comments:
Post a Comment