Closed RAMilewski closed 6 months ago
This probably argues for deprecating heightfield() and replacing it with the textured cuboid top described in the comments in #1346
It does pass however if you set bottom < 0. ...even by as little as -1e-12.
After some testing it appears that the resulting heighfield is invalid if any data point exactly matches the bottom argument.
include <BOSL2/std.scad>
bottom =9;
maxz = 10;
data = [
[ 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, ],
[ 8, 12, 12, 12, 12, 12, 12, 12, 12, 8, ],
[ 8, 12, 8, 8, 8, 8, 8, 8, 12, 8, ],
[ 8, 12, 8, 8, 8, 8, 8, 8, 12, 8, ],
[ 8, 12, 8, 8, 8, 9, 8, 8, 12, 8, ],
[ 8, 12, 8, 8, 8, 8, 8, 8, 12, 8, ],
[ 8, 12, 8, 8, 8, 8, 8, 8, 12, 8, ],
[ 8, 12, 8, 8, 8, 8, 8, 8, 12, 8, ],
[ 8, 12, 12, 12, 12, 12, 12, 12, 12, 8, ],
[ 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, ],
];
vnf = heightfield(data, size = [10,10], bottom = bottom, maxz = maxz);
vnf_validate(vnf);
First, giving a size=0.1 argument to vnf_validate()
will make much smaller purple balls in that rendering.
Second, if you view that in Thrown Together mode, you'll see that way more than the one point at z==9 is bad. You have the bottom set higher than the lowest datums, which makes a bad polyhedron. This admittedly should assert an error. But basically this is an issue of Garbage-In, Garbage Out.
Mind you, if I were to rewrite this now, I'd have the bottom always at 0, and have two arguments that would define the minimum and maximum expected input values, and two more to define the high and low heights those would map to.
Something like:
heightfield(data/fn, minval=0, maxval=255, minz=1, maxz=10, size=[100,100]);
Running the 20x20 pixel png above through img2scad.py generates this file:
20x20S.txt (I changed the extension from .scad to .txt because GitHub refuses to load .scad files here.)
...results in: ...and the following console messages: validate_messages.txt
It also appears that the rendering attempt is not symmetrical while the input png is.