Hacker News new | ask | show | jobs
by nine_k 23 days ago
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.

7 comments

Still, it was called voxel rendering back then. Not technically correct, sure, but it sounded as cool as it looked!
Technically you could say that it is volumetric pixels though, no? The height map and prisms are an _implementation detail_. What is being rendered is pixels with volume.
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, because you never look at any other voxels.

> 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.

> 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.

In the present case (Comanche) they clearly do represent integer heights.
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.
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.
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.
Voxel below topmost were not „ignored completely”. They were absolutely rendered in e.g. steep cliffs.
Playing it on a decent PC in 2992 was mind blowing.
In 1992 it was pretty good too!
OMG - you need to write an article on what’s a decent PC nearly a millennium in the future!
LOL
I bet
This height map contains vertical elements though.
This is a vague statement. Are you suggesting each column can can have multiple layers of terrain, air, terrain? IIUC, the article disputes this:

> Such maps limit the terrain to “one height per position on the map” - Complex geometries such as buildings or trees are not possible to represent.

FWIW I'm working on a voxel sandcastle game. People usually seem particularly surprised by this style because they're so used to such games being rendered by height maps which don't allow tunnels or arches or overhangs.

Was the RAM shortage finally over that year?
Louis Castle developed a "voxel plus" software renderer for Westwood Studios' 1997 Blade Runner. It used "voxels" (with scare quotes) for character animation, not just terrain.

https://en.wikipedia.org/wiki/Blade_Runner_(1997_video_game)

https://news.ycombinator.com/item?id=17171287

madmoose on May 28, 2018 | parent | context | favorite | on: How Voxels Became ‘The Next Big Thing’

Blade Runner didn't actually use voxels, they used a rather unique technique that they called "slice animations".

The 3D models were sliced from bottom to top into a couple of hundred slices (depending on desired quality) by intersecting the model with a horizontal plane and storing the resulting polygons.

The engine can only rotate the models around the vertical axis.

I made a hacky javascript version of the renderer a long time ago:

http://thomas.fach-pedersen.net/bladerunner/mccoy_anim_13_fr...

EDIT: Let me also plug our WIP Blade Runner engine for ScummVM:

https://github.com/scummvm/scummvm/tree/master/engines/blade...

digi_owl on May 28, 2018 | prev [–]

https://en.wikipedia.org/wiki/Blade_Runner_%281997_video_gam...

Seems that the people that developed the game considers it voxel based.

madmoose on May 28, 2018 | parent | next [–]

The page you linked quotes Louis Castle:

> What we are using is not voxels, but sort of 'voxels plus.'

So "not voxels". Louis Castle probably called it voxel-like because he didn't want to get too technical in an interview. Their technique has not been described in detail in the press but see http://deadendthrills.com/future-imperfect-the-lost-art-of-w... [Dead URL -- I tried to rewrite it with archive.org but it's down for me and apparently everyone else now -- can anyone else get through? -Don] for an article that calls it a "slice model"-technique.

I'm not an expert on voxels but I've reverse engineered and reimplemented most of the Blade Runner rendering engine and in my opinion it doesn't count as voxels. For one, you're never going to be able to rotate the models around any axis other than the vertical.

LouisCastle on May 28, 2018 | root | parent | next [–]

Fun! Yeah, we stored our data as slices for space and restricted rotation to the Y axis. Both were optimization since each frame of an animation was a full model there was no need to rotate them. The renderer could render them from any angle though so I still consider them voxels. More like voxels lite then voxel plus. We also used a lot of sprite cards with zdepth and a quick normal hack for lighting. You had to cut corners where you could back then!!

madmoose on May 28, 2018 | root | parent | next [–]

Hello Louis!

I've certainly had a lot of fun figuring out how you did what you did, so thank you for that, no matter what you call it :)

You certainly crammed a lot of tech into one engine! Full screen 15 BPP videos with full z-buffer with smaller alpha-channeled videos rendered on top, character models with lighting. Even the UI is looping videos.

Once I get proper path finding working Blade Runner will be a lot more playable in our ScummVM engine.

I've probably rewatched the opening scene of the game a thousand times while working on it...

I only wished that you had used a scripting language for your game code instead of compiling it to DLLs. I know you optimized heavily for speed but it would have made our task a lot easier :)

DonHopkins on May 28, 2018 | root | parent | prev | next [–]

So that's why you didn't include the Deckard -vs- Pris scene where she rotates around the X-axis! ;)

https://youtu.be/e9t5ikxjAQ4?t=1m9s

pjtr on May 28, 2018 | root | parent | prev | next [–]

Fun indeed!

Can you talk about how the artists authored the original models? Was it an automated conversion from a standard polygon model or from a full voxel model? Or was it all drawn in this special slice format directly somehow?

madmoose on May 28, 2018 | root | parent | next [–]

Not Louis, but the article I linked above says they used 3D Studio Max and converted it to the slice model format.

The voxel rendering approach for spatial computing is clever. Curious about the interaction latency compared to standard raster pipelines.