In fact, an octree for this approach would be _meaningfully worse_ because finding "the topmost voxel" in each column is O(logn)—or maybe worse?—versus O(1) for a height map. With no benefits, because you never look at any other voxels.
In fact, an octree for this approach would be _meaningfully worse_ because finding "the topmost voxel" in each column is O(logn)—or maybe worse?—versus O(1) for a height map. With no benefits, because you never look at any other voxels.
No, it's not weird. The columns don't have gaps because they are columns represented by a height map, which can't display arbitrary voxel geometry (unlike octrees), but that doesn't mean they can't display voxel geometry at all.
> Which is to say, they're just columns...which is (definitionally) just a height map.
Yes. A height map is representing voxel data without overhangs.
> In fact, an octree for this approach would be _meaningfully worse_
That's irrelevant. The fact remains that rendering the same height data using an octree would look exactly the same. If the latter displays voxel geometry, the former does too.
A height map can represent voxel data if the columns are integer heights, in the same way an integer can "represent" an infinite number of countable things. It's like saying the number 7 is "related" to a group of 7 ducks. The relationship is kind of meaningless.
But more importantly height maps can use also floating point heights in which case there's no reasonable mapping between the two. So your statement isn't generally true.