Thats exactly what i meant with my post, i wrote that post just to share the implementation experience with other members of the community so that they can have a much clearer image of implementation on their mind.sinbad wrote: The reason I went for raw floats for the heights is that I didn't want to limit the core to a set precision (like 8- or 16-bit). This way, the min/max of the terrain is unbounded (well, within reason), meaning it's a lot more flexible - it can accurately represent terrains that would be impossible to store in even a 16-bit PNG without data loss. I allowed for importing from lower-precision sources but when saving, the full float data is the only lossless way - even exporting to 16-bit PNG will lose some precision. If people want to process the data in external tools then you can provide export functions in your editor, but you'd have to accept that precision loss unless you use a float format. I didn't include an export to PNG or similar because I didn't really want to encourage this, preferring to advocate a 1-way conversion from these 'lesser' formats.
- In my implementation i use float arrays so height data doesnt loose precision (which is very important especially when you start placing objects on the terrain, you wouldnt want the terrain to erode due to lossy conversion ) and most of the professional apps can read from a float array.
- Since the blend maps have an internal format of UINT8, L8 PNG files are perfect candidates for saving them, although saving them individually creates an assets mess, its much more compatible for editing in other editing programs...
- And of course when it comes to exporting, options can be supplied to export in:
* Native StreamSerializer based packed format
* 16 bit PNG files for heightmap
* 3 or 4 channel packed PNG files for layers...
ismail,