Show HN: My Isometric GPU-Powered Voxel Engine | Hacker News Reader

Show HN: My Isometric GPU-Powered Voxel Engine

voxelquest.com

203 pointsgavanwoolery76 comments

This is a cool project, but something here sounds familiar a) doesn't use a known algorithm like sparse tress or b) a million GB of memory.

...wait a second. I swear I've heard this before.

Why does everyone who works with voxels act so secretive about how their rendering works?

No one cares.

No one. Cares.

Really. No one is going to steal your clever memory optimizations. They don't care.

If you've done something clever, explain it. Maybe you'll get a hi-5 from someone. Being all, coy about it is just irritating.

Hi - I kind of have explained it a little bit in previous comments here - I was going to go more in depth on my website but last night I was running on very little sleep. Sorry! :) The tricks are actually not that interesting but I guarantee I'm not like the Infinite Detail / Euclideon guys. :) It generates the voxels in GPU memory (About 128 MB of memory is used per chunk) - but once it renders the chunk it immediately dumps the non-critical data and reuses that rendering page. It can still access any visible voxel in the 2D rendering (even the various chunk layers), but to access the internal voxels it has to regenerate the chunk or use the procedural generation algorithm to determine what a given point would be like. Collision detection can still be handled pretty well via the larger chunk properties and the depth properties of the rendered chunk. So the real trick lies in procedural generation and the ability to rapidly recreate chunks as needed. It uses ray-casting on a hexagon shaped like an isometric cube, which is nothing very advanced or new. Let me know if I can answer in more detail - I may do a writeup on the techniques time willing. :)

Sounds interesting, definitely be interested in a blog post with some details, for example, how it compares to the normal way of doing this sort of stuff (eg. http://www.seas.upenn.edu/~pcozzi/OpenGLInsights/OpenGLInsig...)

Thanks for posting this. I've had a few toes (ok maybe a foot) in the indie game development world for quite a few years now, and they're definitely amongst the group of developers who are the most averse to putting their shit on github and open sourcing their libraries etc.

The game dev community has a love/hate relationship with open source: on one hand a lot of widely used tools are under open source/free software licenses (box2d, SDL, etc.), but on the other hand you'd be hard pressed to find an indie willing to release his source code (Jason Rohrer I love you).

There's definitely a technical reason for it (game code is often hacky and not that reusable), but I've observed that it has to do more with the sense of pride of the developers ("my code is too ugly people are going to think I am a bad developer").

> definitely amongst the group of developers who are the most averse to putting their shit on github and open sourcing their libraries etc

Yep. I'm sure the majority of them are also GPL violators.

They love to take but never give back.

Well that's a rather harsh accusation. Do you have any evidence to back that up?

Since when has "it's nice to share code" turned into "you're probably a criminal if you don't share code".

That's a funny question. The plethora of open source code available and the miniscule number of open source 'indie' games suggests something is askew.

But one look at today's 'app store' ecosystems and current game dev culture is all the evidence I need. It's a profiteer's paradise.

Your comment is appalling. I wish there were less people like you in the world :)

You appear to have some gripe that goes beyond your ridiculous accusation. It sounds like you're bitter against closed-source in general, but just won't come out and say it.

Yeah I would like to eventually open source my code (at the very least, the javascript portion which is used to mod/script/edit the engine will DEFINITELY be open source). Not all decisions are mine to make (I have to generate a monetary return as I have a small investment, then we will see how things go from there). :)

>There's definitely a technical reason for it (game code is often hacky and not that reusable), but I've observed that it has to do more with the sense of pride of the developers ("my code is too ugly people are going to think I am a bad developer").

Or maybe that they just don't want to compete with people building on --or even outright cloning-- their products. Of course, they're perfectly happy building on others' work.

This isn't entirely true. There are indie games that are open source or have publicly available easily accessible source code.

LD48 requires that you open source games in the jam, so that's 1000s of games with available source code, even if most of them don't live on Github. Quite a few Humble Bundle games are open source as a result of the bundle (http://indiegamebundle.wikia.com/wiki/List_of_Humble_Bundle_...) I can think of other indie games that are open source, Stephen Lavelle's games (http://www.increpare.com/), Game Maker Spelunky, Mari0, Infinite Super Mario Bros. Roguelikes are also usually open source.

Libraries or contributions to frameworks that have come from indie game developers include MojoShader (http://icculus.org/cgi-bin/finger/finger.pl?user=icculus&dat...), MonoGame for Mac OS X, Linux and NaCL, (http://supergiantgames.com/index.php/2012/08/bastions-open-s...), Flashpunk and Flixel.

I also think it's unfair to knock game developers for not open sourcing their games. Last time I checked, many startups open source libraries and helper code, but very few of them open source their product code. The indie game community is also much smaller than the startup community and also less technical on average.

Thanks for your thoughtful reply!

It's definitely getting much much better, as you described it - but it still has a long way to go. I do tend to hang out more in very FOSS-centric circles, so maybe my perspective is a bit skewed by this.

(and I do agree with you re:startups - I wish we saw more open source product code. Gittip is doing a great job with that: https://github.com/gittip/www.gittip.com/ )

I have an idea, could you load a basic map into this, the map would contain a rough idea what the roads, trees, buildings look like. But then use algorithms to add generated details to those objects. So it would be a way to define the rough idea what a map would be like, except all the nitty gritty is generated.

Yeah, you will actually be able to do something like that fairly "easily" (at least, relative to how complex it might be in other engines) -- the engine is scriptable via a javascript client (demoed in another post), so you could pull data from Google Maps or something.

Yeah would make a pretty cool openstreetmap tile generator

Sounds really cool! :)

Forget maps, this would be the ultimate Dwarf Fortress visualization engine!

This was my first thought too, except for rogue/nethack/other ascii-based roguelikes.

I'm actually working on something like that, where instead of using a map, I'm making a small DSL that's a bit prolog like for creating the rules about how things should be placed. It will be open sourced but I do have to write it first.

I'm basing a lot of my work on things like this: http://www-cs-students.stanford.edu/~amitp/game-programming/...

I'm sorry you couldn't live in your parents' house forever. :)

I remember reading about the Genesis Engine in college. For what it's worth, I think it's awesome how you've worked your way to Voxel Quest. Good luck.

Thanks! I am amazed that people still remember it. It has been a decade long battle to fight my way back into doing game development full time, and even though I am working like a dog I couldn't be happier right now.

Genesis3D? I contributed a little to that back in '98! There were big plans at the time, though they didn't come to anything of course. I remember working on the collision code late at night.

Those were the days :-)

Maybe that was a different Genesis Project? I released the Genesis Engine in 2006. :)

Oh wow, let me add to the group and say thanks. Teenaged mr_luc turned into a programmer mostly because of late-90's game engines, and I'm probably not alone. Everyone who wanted to be a programmer and was interested in game development probably remembers Genesis3d.

There's something magical, as a young programmer, about compiling an open-source 3d engine and walking around in the demo.

Although in my case I never did more than compile Genesis and tweak a few variables in the physics code before recompiling. (I ended up learning from the Torque Game Engine and its forebears, because they had a scripting language and sprawling outdoor terrains with multiplayer).

Awesome! :)

This is really awesome, considering my current (first ever) graphics engine which just uses standard polygon rasterization can't even render a few rotating cubes without starting to break a sweat. And you've got billions of everything! You say the grass is green-space. Do you mean that you just generate the grass as a texture and blit it to a framebuffer or something equivalent? (i.e.: it's never "real" geometry on the GPU).

Do you generate your visuals by rendering a fullscreen quad and having shaders do all the work is there actual polygon work involved?

Just curious, nice work!

EDIT: drat, it seems I missed a few comments, you already answered most of my questions. So feel free to disregard them. I'm leaving the comment to show that I really like the things you've done with the engine, it looks fantastic (and $deity knows how much fun it can be to work on something like that)

Thanks! Everyone has to start somewhere (if you saw my earliest work, you'd probably laugh). :) Good polygon rasterization can be a project in itself.

It seems that he is using marching cubes [http://http.developer.nvidia.com/GPUGems3/gpugems3_ch01.html]

Nope - good guess though. :) Funny story about marching cubes: in 2004, when I was creating my first major game engine, I "invented" the marching cubes algorithm without knowing that it already existed (and at that time, was patented) - a testament to how stubborn I am about learning on my own.

I am actually using ray-cast volumes, rendered to a hexagon (6 tris). Each vertex in the hexagon contains two points, a front and back location of the equivalent cube. (If you look a a cube in isometric perspective, it looks just like a hexagon which is why I used this technique -- another thing I'm sure that has been done before me). :) Another optimization over a standard cube is that a cube contains 12 triangles, and would have double redundancy on fill time.

> and at that time, was patented

Is it no longer patented today? Who held the patent and was it released or did it just expire?

The patent expired in 2005.

you wouldn't have a link to the actual patent do you?

https://www.google.com/patents/US4710876

Looks like a bullshit patent to me, anyway. Isn't it an obvious procedure to go from voxel to voxel in order to create a mesh from a 3D texture?

@sspiff (can't reply because it is nested too deep I guess?) -- I think it expired in 2005 or 2006 if I remember correctly.

(The reply link doesn't show up until a few minutes after a comment is posted.)

But can we have a more in-depth post about how you do do it? Are you tessellating on the CPU? When you say "on the GPU", do you mean you have a geometry shader? What platform are you using? I mean, I'm hoping for a lovely technical blog post with a few illustrations ;)

Excellent work, keep it up! Gorgeous :)

Thanks! The only thing that uses triangles directly is the grass (I could do some shader magic and perhaps render all the grass on a single quad, but it probably would not be worth it in terms of performance or visual results). Everything else is ray cast. It renders voxel data to a 2D render target, and does path tracing on that target to get the results. It more or less all happens in texture memory/FBOs with shaders. :) I will try to provide more details time willing! (Not much free time these days obviously :D)

ray casting or ray marching?

I ask as I've done a bit of fractal rendering using distance-estimators before.

I hate to say it but I always misuse the terms. It uses marching.

The Feynman approach. Nice :)

Could you elaborate or link to the relevant paper? Feynman did so many things that looking for the particular thing you have in mind probably is like looking for a needle in a needlestack.

It's not a paper, just an anecdote - in one of the many stories about him he mentions that he liked to independently solve problems that other people had already solved in order to learn the subject in question better, and to advance his problem solving skills. Sorry for lack of source, I'm quite tired... if you can't find it let me know and I'll try to dig it up tomorrow.

Oh, in that sense! I thought you implied he had solved some math problem that happened to be useful in voxel engines or something.

I actually went through the same thing! I was also working on a voxel engine a good few years ago and when going through all the ways of turning voxels into meshes I invented my own version of marching cubes as well.

When I finally found the right search terms to Google on the issues I ran into I came across the real marching cubes algorithm and was actually happy I figured out most of it on my own. A good boost for my self-confidence. The fact that the patent just had ran out was nice as well.

If you scroll to the end of this page you can see some screenshots: http://github.com/aerique/okra

I'm sure many people have done this, which is why John Carmack's quote on patents is so relevant.

I have a funny story also. I "invented" mmx, and markov chains. Well, MMX didn't exist when I envisioned it, it came 10 years later. Markov chains, I have no idea how long they've been around, but I'd had the idea about 6 years ago. If only once I can generate a new idea, I'd be happy.

:) I invented the Hadamard transform once. Only later realized it had been invented couple of decades earlier.

Quite likely.

Is there any way for a hobbyist game dev to try out the engine in a game? say, for the next ludum dare or some such competition.

I think real feed back comes from people using it, and can't be given by only viewing screenshots or video demos. I m assuming you are going to license the engine out of course.

Hi - I am going to avoid releases until I am in beta. The reasons being: I don't want to preemptively disappoint people with bugs/issues, and as a one man team I simply can't keep up with the support work (its hard enough doing a public release and trying to respond to many comments/emails). I would like to open source the engine in the future if it is possible (the decision is not entirely up to me).

I was expecting another minecraft clone but it looks awesome.

Looks good but the images on the page are actually larger images scaled down with css. This is a bit pointless as the images always show the same size regardless of how large my resolution is (They're shown in a small column in the middle anyway). This is just a pet peeve of mine as I dislike seeing the images loading slowly and knowing there's no real reason for them to do so. Also Firefox has a tendency to resize is a really ugly way when width/height is set on an image. Finally it's going to eat through all your bandwidth as you're featured on Hacker News. :P (You might even want to consider replacing them with small jpegs if you're worried about your bandwidth but this would be lower quality.)

Congratulations and the engine really does look great. :)

Thanks! My host is Weebly (I believe a YCominator graduate, IIRC). I am not a huge fan of their image gallery either. :(

You made an amazing job here.

It would be great if you find a way to sustain your development using this system.

Does having a fixed isometric perspective give any benefits to performance or code quality?

My guess: Because there is no perspective or camera rotation, changes in the appearance of the voxels are limited to screen-aligned translation, zooming and changes in lighting. Relighting is easy assuming he's using standard deferred rendering techniques. Zooming can be clamped to a certain range. If the voxels are rendered off-screen at maximum zoom, that just leaves panning the render around on the screen. In other words, he can render each tile once and cache them as 2D images to reuse in later frames. Each frame he only needs to render new tiles that have not been seen before. Unless you are panning really fast, that's a small amount of work compared to re-rendering the whole screen every frame like most 3D engines do.

That's pretty much exactly whats going on. It renders it to a frame and then uses deferred rendering for the lighting. Static objects (i.e. terrain) are not re-rendered until the camera moves, but dynamic objects (like the grass) are rendered in realtime (unless the grass animation is turned off, which I have included for weaker machines).

Yes! With a dynamic (traditional) perspective, you must obviously render every time the camera moves. Since the camera never changes angle, I can render once and be done with it until something is changed or the memory pool cycles back to the start (i.e. a chunk falls out of rendering distance).

In terms of code quality, it is actually far more difficult (IMO) to do isometric projection with a 0.5 slope (not true isometric with 120 degrees between axes). You can build a projection matrix to handle it but I actually just worked out the math by hand to handle the projections and inverse projections. So, for a while this really put a dent in how clean my code was until I refactored everything several times.

Great work, wonderful to see voxel engines becoming more popular and feasible. Also check out http://procworld.blogspot.ca/ great technical write-ups on the engine chosen by Sony for EQ2.

Everquest II was released in 2004, I believe you mean Everquest Next. The voxel engine in the game looks very exciting. Modifying individual blocks after they're placed blew my mind.

Yes - I have been following Miguel's work for some time (and apparently he checks out my work sometimes too) :)

Please change the seizure-inducing flickering background, thanks.

noted :)

There was once a Japanese cartoon show that was said to have actually induced seizures among susceptible viewers:

http://www.cnn.com/WORLD/9712/17/video.seizures.update/

So it's not mere hyperbole to say "seizure-inducing."

And more recently the unveiling of the 2012 Summer Olympics logo: http://news.bbc.co.uk/2/hi/6724245.stm

Great work, kudos!

Can you increase the contrast of the font? I can barely read gray-on-slightly-darker-gray, particularly at that size.

Good suggestion, I'll do that (its a prefab theme). I have noticed that issue myself.

Mmmmmmmm.... Voxely!

I haven't touched video games in years, but I did spend time playing Delta Force in the 90s. Voxels were a perfect fit for the 300+ meter military engagements DF1 was attempting to model. I tried one of the latter entries in the series after they "upgraded" to a standard 3D engine and the sense of space was lost.

I can recall when Ultima 9 was originally conceived it was anticipated to be isometric 3D RPG. Here is a screenshot http://i.imgur.com/MGDSXYP.jp . Voxels would seem to be a great fit for such an engine.

fixed url http://i.imgur.com/MGDSXYP.jpg

using game data from older games sounds like a great idea (if any of those licenses allowed it)

The exult project (http://exult.sourceforge.net/) has done much of the hard work in terms of making game data available. It would be neat to see a voxel engine transplanted into the old game.

I remember as a teenager I had the first issue of PC Gamer that talked about Ultima 9 and Ultima Online - I must have read it 1000 times. It was a shame U9 never lived up to its plans (I blame EA! :), hopefully Garriott has better luck with his current venture.

Same here. I was hoping Origin would redeem itself after U8.

Hopefully in the afterlife I'll be able to play U7 again for the first time. What a great game and a hard act to follow.

Reply on news.ycombinator.com