

On 2/18/23 14:50, Kenneth wrote:
> So from these stats and results, my*guess* is that there could be a very slight
> 'bias'(?) in the HF creation code or functiontoHF process?  whereby the HF
> is not actually from 01, but (0 minus a small value) to (1 minus the small
> value.) OR, the same with the color_map mechanism. Although, the abrupt 'jumps'
> between .0000152 and .0000153 are puzzling
Interesting results and I think on the right track for some of what is
unique about height_field bounding. What you see with the sudden large
jump on that last subtraction is the out of bounds ramp wave value remap.
For the smaller jumps. Internally, and probably due the original
image_map only usage, the max 3d size we can have is 2^16 a side 
HF_VAL is an unsigned short int. Vertically this means we are working in
a best resolution of 1/2^16 steps = 0.00001525... This lines up with
the values where you see abrupt change in extents and that's kinda cool.
The bounds tracking is done at least in part in terms of doubles during
calculation and where a value of HFIELD_OFFSET (currently 0.001) is
subtracted from the lowest value per side and added to the greatest
value on the top side. After the at double calculation, the result is
converted back to HF_VAL.
Because that 0.001 isn't a multiple of the 16bits of resolution I
believe there must be some value snapping going on during the double to
HF_VAL conversion.
That's as far as I got before bailing out.
In looking at your results I'm not at all sure why the max extent values
for x and z are all zero? The HF max extent should be 1 or larger for x
and z (always I think if not scaled) ?
Bill P.
Post a reply to this message

