[cubefox]

> It's kind of weird to call them "columns of voxels" when the columns can't have gaps

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.

[jere]

> A height map is representing voxel data without overhangs.

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.

[cubefox]

In the present case (Comanche) they clearly do represent integer heights.

[jere]

I still think this is a weird framing overall, but yes I see your quoted line "a height map is" was applying to this article and not generally.

[bastawhiz]

Your argument comes down to the meaning of "voxel", then. Voxels have volume, and they are represented with polygon faces. If you think that applies here, I guess more power to you.

[cubefox]

They don't necessarily need to have polygon faces when you zoom in, they can just be rendered as dots with a single color, as long as adjacent voxels don't show gaps (unlike point clouds). Similar to how there are different methods of zooming into 2D pixel images.