Fr0stbyte Shares His Gamedev Man-Crushes

[fr0stbyte124]

Some of you may have seen this already, but for those who haven't, take a look.


More videos and descriptions can be found here.
http://procworld.blogspot.com/search/label/VoxelFarm%20Realtime

I haven't seen a ton of detail on how it works, so most of my understanding comes from what I've seen in the videos and even more helpful, what happens when things don't work correctly.
Voxel Farm is a true voxel engine, and its terrain data is stored to a sparse oct-tree structure. As you move around, the world is dynamically redrawn from this structure in a big way. Details become finer, lighting is affected (though I think that aspect is realtime), and stuff moves around a little bit with the increased resolution. In earlier builds, the grass on the ground would move around, implying that they are procedurally generated from a noise function rather than stored in the oct-tree.
This change in detail is either it's strong point or its weak point, depending on your priorities. On the one hand, it lets you keep only scale-relevant data resident in memory, but on the other, you can see detail constantly popping into place as you approach.

Though there is a growing body or research into rendering voxels completely on the GPU, Voxel Farm takes a more traditional approach by turning the voxel surfaces into a mesh (from the looks of it, with the ever-popular marching cubes algorithm). The weak point of marching cubes is that it can't do right-angles. At most it can do 45 degree transitions. You can see this in the video above. Those not-quite-square edges around the blocks gives an indication of the resolution it is sampling over. There are two exceptions, though. First is those stair steps when they were converted to a smooth incline. That is almost definitely taking manual control over the mesh. I suspect the underlying voxel structure is unchanged. The other exception is the trees, which don't appear to be voxels at all, but instead additional procedurally generated assets.

The texturing is kind of odd, and I'm not 100% positive how it is handled. It is clearly material based, but I suspect it isn't UV mapped to the surface. If I didn't' know better, I would swear it was a 3D texture, but that would be hugely memory expensive and I've not seen any evidence to support it. The blending between bordering block materials is always smooth, too. I bet it's the same for all blocks, and we simply can't see it when they have the same material.

---------------

Most of the specifics of the procedural generation are impossible to know with the hints provided, and there is so much about it I simply don't understand, though I hope its creator will shed more light on it in the future.
Overall, this engine is quite amazing to me. I've been focusing so much on strictly emulating Minecraft's terrain lately that it's been easy to forget just how powerful a full voxel engine can be.

If there were ever a Minecraft 2, in which the goal was maximum realism, but which still has the same cube manipulation we've come to expect from the genre, Voxel Farm would be my #1 candidate.

RATING:
10/10
MAD RESPECT

*edit*
I said meshing was done with marching cubes, but it would appear that is not case. It is actually using a related technique called [url=http://procworld.blogspot.ca/2010/11/from-voxels-to-polygons.html]dual contouring[/url], which is capable of producing square edges.

[Iv121]

Respected by frost -respected by me, though this thing will REALLY need a copy button because making each thing from scratch will take ages.

[fr0stbyte124]

Changing the topic to be more general, since I don't want to make a new thread for all of them. But here is another amazing voxel engine, by the name of Atomontage.


I can't say a whole lot about it. Normally, there are hints as to the inner workings of an engine you can use to work out what is going on behind the scenes, but for once, I've got nothing. All I know is that it is doing something truly amazing behind the scenes. The creator says the engine was running well on his old laptop with an NVIDIA 130M gpu. For those who don't know, that is a DX10 mobile gpu with enough processing power to handle HD movies and not much else (I'd estimate it's roughly comparable to a gaming rig from 2005-2006). The fact that the engine performs with that much detail, and from all accounts it can handle much more, means that there is not nearly as much data processing on the GPU as there ought to be, nor does it appear to suffer from bandwidth artifacts normally associated with streaming data structures. The drawing method itself is almost certainly raycasting, but beyond that, I can't make heads or tails of how that data is represented or accessed.

Atomontage is a project which has been in the works for 10 years now, and is finally starting to shape up as a legitimate game engine. There is no dynamic lighting in the video, but it would not be difficult to add into the pipeline. The one limitation, if you consider it such, is that none of the individual voxels are textured which make it non-ideal as a Minecraft engine. However, our heightmaps most don't either, so it would work just fine in a hybrid setup like ours.

If you recall that King's Landing render I posted the other day, Atomontage could undoubtedly fly around it from any angle, and the surrounding countryside, all without resorting to quality reducing shortcuts. I really wish I knew how.

RATING:
10/10
MAD JEALOUS

[blockman42]

maybe if he puts it up on a website for open-sourcing we could use some of the code?

[fr0stbyte124]

@blockman
That would be cool, but for the time being, he doesn't seem to have any solid plans yet for how it will be distributed or liscensed. Ultimately, it is supposed to become a full-scale physics engine, so there is lots left to be done.

-----------------------
I did some more hunting around to see if I could find anything about how it actually works, only to end up with even more uncertainty than when I started. As far as I can tell, Atomontage has a very flexible compression system, which can compress voxel data up to a single bit per voxel, with the compression rate changing with the level of entropy (measurement of orderliness). I assume this is specifically meant for reading from a disk and not on the GPU, but I'm not positive. It does refactor the data into a variety of formats for consumption on the GPU, and has a simple AI routine working out how best to format each piece. This is the same strategy we use, with the two flavors of heightmap, plus the polygon model, though I highly doubt this guy is using the same system.

Some people have said that the data structure is a sparse voxel oct-tree, in which each of 8 voxels points to a self-similar table of 8 more voxels, and you make each branch go only as deep as there is unique data to fil it. I don't think that is the whole story. The problem with SVO in a raytracer is that each ray ends up hitting a ton of texture lookups, which reduces the performance. With that much data on-screen on that hardware, it doesn't add up. There has to be something else speeding things up. We get around navigating the datastructure by baking the direct lookups into traditional rasterized bounding boxes, but there is no evidence to suggest AE relies on rasterization for any part of its pipeline.

Basically, I don't think anyone knows how Atomontage really works but its creator. But the fact that it exists and works is encouraging for our own system, even though we don't share the same techniques.

[fr0stbyte124]

If anyone is wondering about Euclideon's Unlimited Detail engine, it's based in the same theory as Atomontage. A while back, though, Notch rather publicly called them out as being a scam, which caused a lot of controversy. While I think it was a bit on the hyperbole side, I agree with him on this. Euclideon misrepresented their engine and what it was capable of. In its demos, it would show scenes with a ton of repeated geometry, which indicates that, although you can represent extreme ranges of detail, they still suffer from getting unique data into the GPU.

For a game engine hosting entire maps, this is a serious flaw. And rather than acknowledging the flaw and discussing how they will attempt to address it, they pretended like it didn't exist, and that the artist would have unrestricted control over the level. That's not longer stretching the truth or wishful thinking. In my mind, that is a serious breach of ethics for a developer, and a company-level deal breaker even if the engine was practical.

Atomontage, though the developer never gets into implementation-level specifics, has always been honest and upfront about the state of the engine, it's strengths and weaknesses, and his plans for future development. While proprietary game makers can get away with being tight-lipped, engine developers needs to be as transparent as possible in order to build trust in their product. Many developers, like Id and Crytek, even hold presentations at conferences like SIGGRAPH to share not only how their own engines work, but how other developers can implement the innovative parts of it. This in turn, accelerates the rate of advancement in the field and everyone benefits.

The community as a whole is shockingly transparent considering everyone involved is a competitor, and I'm quite proud of that. But Euclideon makes a mockery of that good will. and gets zero points in my book.

[Iv121]

You are one of those guys who will open the car lid and pat the engine - just computer wise .

[Keon]

Seen the first one, haven't seen the second one.

[fr0stbyte124]

Found something I was looking for while going through some old assets:

Spoiler:

Did you see it?

About a third of the way from the top, in the pale part of the rock. There is a faint horizontal band which doesn't follow the natural grain of the rock. That's a boundary between two heightmaps, laying perpendicular to one another. How that edge was determined and how they are stored in graphical memory remains to be seen, but this cinches the idea that Atomontage isn't pure SVO as some have suggested.

As for the structure, I'm willing to bet that the interior colors are the same as the surface, so each voxel column only has to store a single color (though I would still like to find a sample of one which has been cut open). I would also guess that the limited color range isn't going to waste. Most likely each column is at the very least indexing a color from a predefined palette, and more than likely there is some additional level of local compression which takes advantage of the localized color sets, like the DXTC textures, perhaps pointing to a coordinate on another texture serving as the world palette. I can't imagine it being too much more sophisticated than that without hurting performance.

But this is interesting now. If heightmaps are one of the terrain representations, then how are they referenced? If it's not done with rasterized bounding boxes (and the author has never even hinted at using them), then I would bet the structure is once again sparse voxel oct-trees. That structure could provide a primary accelleration system for raymarching, and it may also provide implementation details for that heightmap, or even the surrounding area (like the palette, heightmap offsets, etc.) And based off a line the author mentioned about it running on OpenGL 1.4 hardware, it is very unlikely that anything but the fragment shader is involved in traversing the structure.

It's also difficult to see the seam between heightmaps in the other asset images, which is worth noting. Since having a complex border definition doesn't seem terribly reasonable, it may very well be that each heightmap extends the entire length of the asset, and all 3 planes are raymarched simultaneously. This would actually be quite a good technique for mapping minor concavities which show up on other axes. This trick is something we can probably use ourselves to represent more complicated geometry without requiring numerous layers.

When major changes happen, the engine probably pumps out a raw SVO representation initially, and then the CPU works out how to replace it with a more compressed representation once things stop moving. And as far as compressed representations go, there are probably more than just SVO and heightmaps, though I don't know what else yet. I'll keep my eye out for any additional hints.

[fr0stbyte124]

Found one already.

Spoiler:

This is an example of a voxelized mesh of a model. There were some flaws in the geometry which confused the representation, leaving some vertical 3D artifacts. That's kind of neat in itself, but note the color of the artifacts. In areas where there is a lot of open air (so probably undefined during the voxelization stage) the artifacts are black. But then in the grill and next to the ground, they have color. On the ground, the colors start at the same level, making me think that the oct-tree region is what is storing the color values. Additionally, the artifacts on the grill might have more than one color, though it is hard to say for sure.

Spoiler:

This is a lower res model with the same artifacts. Every artifact has a voxel, and the ones which were black before are also black here. Undoubtedly, this resolution is entirely SVO. While it may be possible to have heightmaps on layers other than the highest resolution, it is probably more expensive to nest them if my thoery that the SVO holds the color information is correct, so only the leaf nodes of the SVO would ever hold them.

I don't think we've solved it yet. Just eyeballing the numbers, this is still too expensive assuming arbitrary color values, though I think color stored in the SVO is an important clue.

*EDIT*

Found another image from even earlier.

Spoiler:

According to the caption, 96 configurations were tested, and about 20 of them turned out like this, while the other 76 were passing quality. This is significant. This means that there are a finite number of heightmap configurations, and that it is actually a pretty small number. As for what exactly is going on here, I am not sure yet.

*EDIT*

No. AE uses something like ray casting but it is currently not a per-pixel method and doesn't serve to calculate or plot particular pixels. Lighting is calculated using a primitive implementation of a rather complex technique that has something to do with photon mapping. The last step is implemented using older OpenGL functionality and can be considered as 'traditional'.

Details about the AE renderer are not yet publicly available. I believe that it is a new technique and that it deserves a dedicated paper.

Well, I give up on this one. This would imply that most of the work is done on the CPU with other methods, rather than traversed on the GPU. If that is the case, I have no idea what is going on.

[blockman42]

I have no idea what most of that means, but looks pretty cool from what I can decifer.

[fr0stbyte124]

TL:DR, this guy is to me what I probably look like to you.

[Keon]

Which guy? Atomontage?

[Chairman_Tiel]

TL:DR, this guy is to me what I probably look like to you.

So when do you intend to start a cult honoring him like we - oh, pretend you didn't hear that

[Keon]

So does that mean we need to get one of them in here to dev our mod?