61–70 of 74 posts
Brings back memories. Comanche was incredible when it came out, running on (IIRC) our family’s 386SX-16. I tried to replicate the effect in Visual Basic, albeit with very limited success at the time.
Earlier quoted context omitted.
> 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…
> 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 r…
Technically this is not related to voxels ("volumetric pixels", so to say), which split the 3D space equally along all three axes. This is just a height map, a set of prisms, not entirely unlike a Doom map. Every prism has a regular fixed-size square base. For 1992, this was mind-boggling though.
Playing it on a decent PC in 2992 was mind blowing.
Technically this is not related to voxels ("volumetric pixels", so to say), which split the 3D space equally along all three axes. This is just a height map, a set of prisms, not entirely unlike a Doom map. Every prism has a regular fixed-size square base. For 1992, this was mind-boggling though.
This height map contains vertical elements though.
Previous discussion with plenty of background and links to similar software: https://news.ycombinator.com/item?id=44541662
Earlier quoted context omitted.
No? Each pixel on a height map corresponds to a column of voxels of the specified height. You could represent the same height data with a fully general octree and it would look exactly the same.
It's kind of weird to call them "columns of voxels" when the columns can't have gaps and the "voxels" below the topmost are ignored completely. Which is to say, they're just columns...which is (definitionally) just a height map. 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…
Earlier quoted context omitted.
> 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…
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.
Brings back memories. Comanche was incredible when it came out, running on (IIRC) our family’s 386SX-16. I tried to replicate the effect in Visual Basic, albeit with very limited success at the time.