The technique seemed to fall out of favor for a while due to the polygon GPU boom (I guess I missed Delta Force) until Outcast in 1999. (Back to heightmap terrains.)
https://en.wikipedia.org/wiki/Outcast_(video_game)
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.
> 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... 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.
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!!
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 :)
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?
Reads to me like they used voxels for the grunt work and then painted the result on some otherwise unimpressive polygons at the end (aka voxels plus as they put it themselves).
Speaking of Comanche, there was a discussion on it 6 months ago when I posted the link to "Terrain rendering in fewer than 20 lines of code" https://news.ycombinator.com/item?id=15772065
At the moment, CGI is essentially a craft. You use a set of tricks, illusions, and hacks to deliver an immersive experience. Games like Doom show that when you get all these tricks right, the result is impressive.
Unfortunately, like all hacks, they aren't robust. Most of them work on the assumption that the player won't look to closely at anything, or will only look at certain angles, or move through the game world at regular speeds.
People who do CGI are already well aware that when you go into VR, a lot of the hacks just don't work. Often, to deliver a high-quality experience, you have to throw polygons at the problem.
I'm pretty skeptical of this presentation - talking that much about optimization and performance makes me suspicious that their performance is terrible. However, ultimately, unless better hacks are devised, I think VR will be too much of a robustness test for the current model. In the short term, that will probably just result in some ugly graphics. In the long term, it'll put a lot of weight behind the drive to find better, less hacky solutions - and voxels are kinda first and foremost in that category.
"There are a bunch of techniques people typically consider being voxel-based. The oldest ones used in games were height-map based where the renderer interpreted a 2D map of height values to calculate boundary between the air and the ground in the scene. That‘s not truly a voxel-based approach as there‘s no volumetric data set in use (ie in Delta Force 1, Comanche, Outcast, and others)."
I saw them doing the same pitch for a decade now, can't find old version because I don't remember their original name but I do remember their terrain demo.
The Notch blog post you linked mentions Euclideon’s “Infinite Detail”. I’ve looked into that over the years (but don’t know anything about Atomontage), so will post my thoughts here.
My understanding of Euclideon (based on the snippets of information, interviews and videos they’ve released) is that the primary technology they created is an on disk spatial index and streaming system that allows only the data that is on screen to be streamed from disk, allowing them to have very large and complex datasets on disk while still rendering in real time. The “infinite detail” branding was referring to that the detail possible is only limited by disk space, not by rendering performance.
That sounds pretty cool to me and not a scam as many people think.
However, they’ve never been particularly convincing in the applicability to games or even that the quality gains are as high as they claim. They kept touting how easy it is for artists since they can 3d scan real objects and use that scan data almost directly (but many polygonal models start as scans too, so...), but I’ve never been impressed with the quality of their scans or demos. Their highest quality demos are nice (a lot nicer than their earlier demos which, to me, honestly looked like it was from the 90s) but they still don’t compare to modern games in my opinion. They also have not proven that it works well for animations or dynamic lighting and shadowing. At least, they’ve never demonstrated it.
They did use their tech for their Holoverse[0] games, but, again, the quality of the actual graphics wasn’t particularly impressive in my opinion (certainly the animations seemed stiff and boring) and from reviews I’ve seen on YouTube, VR headsets provide a better experience and superior quality.
So, my verdict is that they do have some novel and interesting tech, but they haven’t been able to get anywhere close to the quality claims that they’ve made and I certainly wouldn’t bet on them over more traditional modern graphics.
Euclideon are scammers not because they have nothing, but because they don't have what they claim they have. They claim to have revolutionary technology; they have something so well-understood that even I, merely an interested layman in the field of graphics, understand what they have just fine, very nearly well enough to just sit down and implement the core data structure right now, with no sign I've ever seen that they have anything beyond that. They claim to be able to animate in realtime, despite the fact that one of the tradeoffs of the tech is that becomes impossible in the sense we mean it. (You can animate much like a cel-based cartoon, but it can't be very interactive except on very restrictive conditions, ones that virtually no modern graphics user could accept.) It's delta between the rather pedestrian tech they have and the wild claims they make that is the scam, not what they do have.
I've heard it claimed that the whole company is basically a Germany-specific tax dodge method. I have no independent verification of this, but it fits the facts I have about their behavior.
> not because they have nothing, but because they don't have what they claim they have
Absolutely.
> animation
Yep, from what I’ve seen of their holoverse ganes, that’s exactly what they’re doing and the results are, predictably, not particularly impressive. When compared to state of the art notion captured animation we have in modern games, it’s really not very good at all.
> data structure
It may be just their hype as opposed to actual facts, but they certainly make it sound a bit more sophisticated than a “traditional” spatial-index tree data structure in the sense that they claim they can stream just the voxels that are on screen at any given moment from a huge on disk dataset. But we both know they’ve been known to exaggerate, so you could very well be correct.
> It's delta between the rather pedestrian tech they have and the wild claims they make that is the scam, not what they do have.
"It may be just their hype as opposed to actual facts, but they certainly make it sound a bit more sophisticated than a “traditional” spatial-index tree data structure in the sense that they claim they can stream just the voxels that are on screen at any given moment from a huge on disk dataset."
To be honest, while I don't have that much difficulty imagining that they can stream voxels off a disk (since it's a straightforward application of the oct-tree structure; you get a good 50% of the way there just by writing a naive octtree larger than memory and letting the OS swap algorithm do its thing, with some slight preloading), none of the demos they've ever showed should require anything to be streamed off the disk. Everything I've seen would firmly fit in memory of very modest desktop systems of the time of the demo. It's possible you can zoom in farther than they demonstrate, but, I mean, it's a demo. I'm allowed to expect they're showing off the best.
This is another one of the reasons people like me call them scammers; the first few graphics demos they put out weren't even that impressive. They were ugly and lacking in detail. They weren't even the kind of ugly you get when you have an impressive graphics tech and the person showing it off has no visual design chops, they were just plain ugly. Had the demos gone around the internet, but stripped of the hype they were accompanied with, nobody would have given them a second look. Any contemporary nVidia demo put out to demonstrate their graphics card look wildly better.
The demos where they scan real scenes and display them work much better. The weirdest thing of all to me is that they don't lean into that and just make that their business, but no, they won't shut up about how awesomesauce their stuff will be for games, even when they have a perfectly sensible application developed. Bizarre stuff.
yeah notch is talking about a different engine with overly bold claims, but given the technological overlap many of the talking point overlaps.
for example, animation and deformation, light mapping and content production are still going to be issues. sure they have a motion captured talking person and it's impressive, but it's still part of a fixed content pipeline, if you require ragdoll animation or an interactive actor it's way harder.
What was/is holding voxel back? the new programming model? computation density?
I guess minecraft is an example of a voxel game (supposed a voxel game written in block style according to a random post on the internet[0]) that became really popular -- so I guess the answer could be "nothing", but it sure seems like voxels are still niche (and don't want to be).
In principle, "voxels" and "polygons" are the same algorithm - you project some points on the surface to the screen and eliminate invisible ones with the z-buffer. Polygons allow to use sparser points and fill space between them with interpolation, voxels rely on the points density or blowing up the point size.
Interpolation is quite complicated and voxels, on the other hand, could be arranged so it would be very easy to draw on a traditional CPU. So one could write a really fast voxel renderer on something like Pentium 200, which would produce better looking graphics than a polygonal renderer at the same speed (it would not be as versatile but when you do a demo you are free to chose scenes where voxels will do the job better).
On GPUs interpolation is not just cheap but it's the only way to exploit massive parallelism since you can draw all interpolated points simultaneously. Drawing points, on the other hand, is sequential (because of z-buffer all primitives have to be drawn in the fixed order) and is already super slow by itself. GPUs are also optimized for drawing triangles so they do a lot of things with them they cannot do for a list of points (which would be the primitive you'd use to draw voxels). Of course you can do your voxels on compute but then you are not using color/depth buffer hardware so either way you are disadvantaged.
It was my understanding that a large reason why early voxel engines had great performance is because you only draw each pixel once (kinda like how deferred lighting only calculates lights for each pixel once) eliminating overdraw and therefore doing work that wasn’t ever going to be visible.
But now GPUs can crunch that data super fast (as you say) and memory bandwidth is often a bigger issue. So while voxels still get used in some places, they’re avoided in favour of more compressed data formats and rendering techniques.
At least, that’s what it sounded like to me, I’m no graphics expert.
It depends on the algorithm, if you did heightfield then yes, you could easily eliminate invisible pixels without testing each of them against z-buffer. However you could not do complex models with heightfields.
A popular general voxel algorithm in 90s was "chains", where an object was represented as a sequence of voxels, where position of each was encoded as an offset from the previous one and voxels were on a regular grid so there were only 26 possible offsets. If you did not do perspective projection then you could have just projected all 26 deltas into the screen space and compute each voxel's position with 3 additions. With the offset taking 5 bits you could fit each voxel in a 16-bit dword together with some ramp-lit material for per-pixel lighting. It was a very fast loop even on a CPU without division. On a modern CPU or GPU, of course, this is painfully slow, since each position depends on the previous one and ensures strict order on the loop. Memory-bandwidth wise this is quite nice because of the very compact input data. E.g. you could put position and texture deltas into 8 bit voxels and had more compact representation for a smaller model than using popular 16/32 byte vertices.
Oh that’s interesting, thanks for the comment! Must read up on it more :)
Do you know how modern voxel algorithms work? Do they just blindly render point clouds to make use of the GPU parallelism and let the z-buffer remove invisible voxels (and a spatial index to render only the ones in view) or is there more sophistication? I assume there’s some clever parallel algorithms available nowadays, or?
I am not closely following voxel developments so I could be wrong, but my impression is that the practical implementations focus on the representation and its compression. They all render with some type of raytracing using compute. There had been approaches to generate a triangle mesh from a voxel representation but I am not sure how far did they get.
The „Voxel Space“ engine from the 90th has only very little to do with what we call voxel today. It it basically a raycasting engine for height maps [0]. It is very limited. You can‘t look up and down more than 20 degrees and you can‘t even render houses, cars or trees.
The fact that the domains they might be used in are also the domains people are guaranteed to have spent a lot of money on specialized polygon-pushing processors. Voxel techniques seemed to peak at about the time of the last hurrah of CPU-based rendering.
The main problem is memory bandwidth at higher resolutions. Minecraft runs at a really low resolution. (Internally.)
Occlusion handling is less efficient too because bounding and occlusion volumes are discrete and either very inaccurate or nearly as slow as rendering the voxels.
Modeling and animation. I'm not even sure what some of these videos are showing, but it doesn't seem like it can be real voxels on a regular grid. Regular grids are hard to create models with, and are essentially impossible to animate in useful ways. I didn't see mention of how the animation in these clips was being done but there were indications that the models started out as polygons.
2D Signed Distance Fields are used for rendering fonts and other shapes defined by a texture whose signed pixels (-128..128) specify how far each is from the border (+ is outside, 0 is on the border, - is inside). They scale beautifully because you can smoothly interpolate between samples.
You can convert them to piecewise outline contours (like an iso-map slicing at many different elevations) with the Marching Squares algorithm, but it's much more efficient to render them directly pixel-by-pixel with a shader.
Signed Distance Fields are excellent for shaders efficiently antialiasing and drawing effects like outlines, drop shadows, embossed and beveled edges, glows, multi texture mapping, bump mapping, etc). The shader can quickly determine exactly how far away each pixel is from the outline, and blend the appropriate effects together for that pixel, so you get precise anti-aliasing, outlines, drop shadows, etc, practically for free! (And literally for free, now that Unity gives TextMesh Pro away for free.)
3D Signed Distance Fields are used for rendering volumes with the Marching Cubes and Tetrahedra algorithms (which are nice for users continuously carving and sculpting with tools, like Astroneer).
That also scales and handles different levels of detail nicely because you can interpolate between samples -- it creates smooth polygon meshes with interpolated normals, not harsh cubes with pointy corners like Minecraft.
Shaders can't render 3D Signed Distance Fields as directly and efficiently as 2D (unless you're rendering to 3D volumetric textures). But you can still implement Marching Cubes on the GPU, using compute shaders (or abusing 2D shaders).
I recall some glorious LAN sessions in the various Delta Force games. Only shooters where to snipe you actually had to account for bullet drop because of the distances involved.
Even older than that, Comanche: Maximum Overkill (1992) was voxel based. Amazing at the time, but I remember it'd fall apart pretty quickly as you got close to objects.
Delta Force:
https://en.wikipedia.org/wiki/Delta_Force_(video_game)
Which used the Voxel Space engine:
https://en.wikipedia.org/wiki/Voxel_Space