Comment by anfilt | Hacker News Reader

Comment by anfilt | Hacker News Reader

Parent Full thread

Well demo video's don't tell you a lot. They claim to have some secret sauce.

However, the demo video's makes you even question that they have a secret sauce at all. When you see them delete parts of the game world you see how thin the ground layer is when part of it is deleted.

The are big problems with voxels. The simplest being space as the game world increases in size the amount vowels grows with the 3rd power.

My big problem is no technical details have been published. They claim to have a pending patent on their site. However, that may not really tell us much.

I have played with voxels myself and oct-trees and other algorithms related to voxels. The only real use voxels have seen is medical imaging. If they have figured something out they should be having a paper in a math journal. I doubt it though mainly since it would involve pushing thing to the limit or beyond the limits of information theory. The only other option for such small voxels is massive amount data storage or object with relative homogeneous structure at which point it's not much better than hollow polygons.

Not only the main memory is limited, and while SSDs are getting better when playing with high density voxels with a pretty how amount entropy you can quickly exist main memory. So what I did instead was just request exposed/surface voxels and arrange the octree data structure to be linear from outside in to help with memory caches. Still all the really mattered was the exposed voxels, and that's not much different from a hollow polygon. Honestly, after having played with voxels myself I would say they are cool, but you not making a whole game out of them. If anything it's just tool to be used in some parts of a game.

I will add an other thing that gives me doubt they have anything really new is the fact when they start destroying their models you see the same color in side the model for the most part. Even the brick wall that got destroyed is pretty homogeneous.

Looks like they just formed a real company https://www.atomontage.com/blog/2018/4/5/atomontage-inc-laun....

One of their investors is an MD specializing in imaging. https://www.atomontage.com/#team-section That'll be their bread and butter.

I always wondering if the community picked up VoxelQuest https://www.voxelquest.com/ and ran with it, but last I looked that wasn't the case.

I'm too old to do serious graphics programming, but might be interested in a voxel engine written in C# with a good community.

> I'm too old to do serious graphics programming

Too old? Maybe too busy, but never too old.

The issue with VoxelQuest is that, while it was an astonishing piece of technology, it wasn't documented in any way a normal human can understand. I spent several hours trying to read it, and while I'm impressed with the results, the lack of design patterns and structured code (the code is separated in just about 10 files, and it is almost 50k lines long, if not more) makes it really difficult to work with.

I dabbled in voxels myself, even wrote a Minecraft clone and all that, but VoxelQuest was the first real voxel engine I saw working in a really nice way. It had proper lighting, shadows and even nice effects such as reflections. It is kind of a bummer that the dev quit the project, so much potential wasted :(

I agree with you on the poor documentation - that stemmed from me almost never working with others professionally and either doing a lot of solo contract work or work where my code was mostly isolated from other systems. I've gotten a little bit better about standard practices after working for a company that uses them and team work is super-critical as small changes can potentially cost $10k+ in damage per hour, so understanding the code and making it testable is more important than producing new code.

Over the past year I have been working on Voxel Quest silently, because progress is so incredibly slow that I still do not have much interesting to show (and I dove to the deepest depths of feature creep and tried to build a compiler/transpiler to address a lot of problems I was having with c++ and slow turnaround times).

To be honest, over the past month or so I got frustrated with my slow progress and took a break to work on a simple 2D game, just to see if I had any ability to control what I consider my greatest weakness: failure to prioritize. So far that experiment is successful but now I'm asking myself if making a 2D game is a waste of my knowledge - maybe that is true or maybe its just shiny object syndrome. >_<

Overall the biggest problem is my past two years have been almost entirely consumed by my work, renovating my house, raising a kid, and other stuff. I typically have less than 10 hours per week to concentrate on projects (more often 5), so I am working about 1/8 to 1/16 as fast as I was when working on VQ full time.

Anyhow, it would be nice to work on it in greater capacity, or at least something similar, I just dont know where that money would come from. I am very hesitant to ask people for money at this point, given my track record, so I feel like my next thing has to be self-funded or funded by someone who can truly afford to lose the money. I could easily find people who would throw more money at VQ but I dont think that it would be a sufficient amount to survive off of, so it would be effectively wasted.

Not sure what to do in the short term, to be honest, other than work at my current pace. :/ I'll share my current progress publicly once there is something interesting to show.

> The simplest being space as the game world increases in size the amount vowels grows with the 3rd power.

Not quite. Not unless you store the voxels in a three dimensional grid structure, which you wouldn't do for anything but the most simple applications.

If your game world is anything like the real world, most of it is empty space. Additionally, you usually don't have to store realistic data for the interior of the models.

You'll use a datastructure that exploits this. The most common and simple one for voxels would be sparse voxel octrees.

In addition to this, you can use compression techniques for both texture data and geometry. Most of this data will be relatively predictable.

I'd wager that the data for a modern efficient voxel implementation grows at roughly the same rate as a modern polygon based implementation. Most models these days have a quite high density of polygons after all. No surface in the real world is completely flat. As the article mentions, when you have a high density of polygons, you're using a lot of data to store the positions of each vertex, while in a voxel datastructure that data is implicit.

I think the only real problem with voxels when competing with modern polygon engines, is animation. Polygon models have a huge benefit there. Like you said though, you might want to use voxels for part of the game. I know that John Carmack was interested in using it for static landscape and buildings, and saw it as a natural extension of the megatexture technology.

If this is a destructible environment, they would need to store interior details to render exposure in any real application.

Animation is very hard. Mathematics can help here, but the results look unnatural and fairly shoddy (see the building doing a simple sinusoidal based sway in their video). The problem is essentially one of scale. With polygons, we only need to animate the vertices. With this, we need to animate every voxel. This presents massive opportunities, however also massive challenges both for the machine performing the computations and also the software engineers trying to get realistic animations.

It should be possible with enough elbow grease to build an engine based off voxels imo, seems like some combination of lazily generating voxels based off simple primitives and being able to generate what the "inside" of something looks like on the fly gets you most of the way there through the rendering problems at least, right?

Now whether that's worth it or not is an open problem.

And for that, you could again look at what Minecraft-like games have come up with.

Minetest, for example, groups its "voxels" into cubic chunks, which are then loaded depending on a max distance and presumably some sort of a ray tracing approach to figure out, if the "voxels" in such a chunk are visible.

Minecraft itself throws a chunk at a time (a horizontal 16x16 section of the world) at it's rendered, which then spits out an OpenGL model for the rendering. (iirc). This is the, or one of the, reason(s) why clipping through one block gives the ability to see through all those in the middle, instead of 'just' seeing the next block adjacent to the one you are clipping into. The ray tracing is just that only faces of voxels that touch air or another non-solid block (fencepost,liquid,torch,etc) are included into the OpenGL model, along with their texture. The raytracing is done by the GPU, and handled via the depth buffer.

For something like Minecraft where the voxels are comparatively huge they’re probably using something like Marching Cubes to extract a poly mesh from the voxel chunks rather than ray tracing. You can actually get pretty far with surface extraction techniques see for example the VoxelFarm engine.

I probably should have highlighted this better, but I was not talking about Minecraft in the second part of my comment. I was talking about Minetest:

https://www.minetest.net/

Which is essentially a game engine for creating Minecraft-like games. Minecraft itself grew historically and is not state of the art anymore.

Which especially shows in the pillar chunks that you mention. Their size is 16 x 16 x world-height, meaning that the world height can only be so big (256 blocks in the case of Minecraft).

Minetest has cubic chunks, 16x16x16, which allows for virtually infinite world height, but also for loading those chunks in a much smarter way than Minecraft has it (which basically just loads chunks in a circle around the player).

When you're in a cave, for example, you don't need 400 blocks in all directions to be loaded, you just need to see the next wall. Whereas when you're standing on a mountain, you do need to be able to see all of the chunks that make up the surface of the surrounding terrain, but you again don't need any blocks to be loaded below the surface.

And for that, I assume they use a raytracing approach. Periodically check what chunks are in line of sight for the player and make sure those are loaded. When on a mountain, that's a lot of chunks, when in a cave, it'll only be a few.

So, I'm not talking about whether they are rendered or not, I'm talking about them being loaded into RAM or not (which obviously does also result in them not being rendered when they're not loaded).

Reply on news.ycombinator.com