I remember when Voxels were the "Next Big Thing", 20 years ago.
Delta Force:
https://en.wikipedia.org/wiki/Delta_Force_(video_game)
Which used the Voxel Space engine:
Delta Force:
https://en.wikipedia.org/wiki/Delta_Force_(video_game)
Which used the Voxel Space engine:
There used to be quite a few Turbo Pascal "voxel"-heightmap demos floating around.
Blade Runner was surprising: It used voxels for characters. https://en.wikipedia.org/wiki/Blade_Runner_(1997_video_game)
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)
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...
Seems that the people that developed the game considers it voxel based.
> 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.
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?
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)."
https://www.youtube.com/watch?v=Gshc8GMTa1Y
it was quite impressive 8 years ago as it is today, but 10 years of demo without applications are weird.
here's a 2011 critique from notch of this very technology https://notch.tumblr.com/post/8386977075/its-a-scam - I don't think things have changed much
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.
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.
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.
That’s a very good point and I certainly agree.
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.
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.
That's practically Molyneuxesque!
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).
[0]: https://forum.unity.com/threads/voxel-games-vs-block-games.2...
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.
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.
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.
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?
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.
Signed Distance Function: https://en.wikipedia.org/wiki/Signed_distance_function
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.
Drawing Text with Signed Distance Fields in Mapbox GL: https://blog.mapbox.com/drawing-text-with-signed-distance-fi...
TextMesh Pro - Font Asset Creation Process: https://www.youtube.com/watch?v=eXhfygRgIVY
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.
Marching Squares: https://en.wikipedia.org/wiki/Marching_squares
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.)
TextMesh Pro - Unite 14 Demo: https://www.youtube.com/watch?v=q3ROZmdu65o
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).
Astroneer: https://astroneer.space/
Astroneer - Digging to the Center of the Planet: https://www.youtube.com/watch?v=C3zxBhPzxYU
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.
Marching Cubes: https://en.wikipedia.org/wiki/Marching_cubes
Marching Tetrahedra: https://en.wikipedia.org/wiki/Marching_tetrahedra
Fast Marching Method: https://en.wikipedia.org/wiki/Fast_marching_method
Fast Sweeping Method: https://en.wikipedia.org/wiki/Fast_sweeping_method
Level-Set Method: https://en.wikipedia.org/wiki/Level-set_method
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).
Marching Cubes on the GPU for Unity3D: https://github.com/Scrawk/Marching-Cubes-On-The-GPU