Head over to VoxelQuest.com for the first sneak peak (it will be live in about an hour)!
First of all, I am happy to introduce my new investor: Tristan van Essen, who is making all of this possible. He is a great guy, and I'm not just saying that because he is giving me money. :) It takes either a very smart person or an insane person to see potential in my work, so I'm glad that Tristan is both. ;) I hope that I can reward his good faith with success for both of us. So I am working on Voxel Quest full time now, which means this website will definitely be seeing a lot more updates.
That said, a screenshot:
And a video (sorry its a bit choppy, I had to capture in software this time vs using a hardware recorder):
I have put a lot of work into the GUI (probably too much), but thankfully I am done with it although I will add in features here and there as I have time (namely, make it more user-friendly). However, building out the GUI has allowed me to rapidly implement many other things that will be used in the engine such as fast AO, materials, shadows, and so forth. It's nice to be able to preview exactly how materials will look within the editor itself. I did some major overhauls on the performance side of things, and it performs quite well even on the Intel 4000 chip pictured here (as noted, the video is a software capture; normally it is much more smooth). I am relieved this worked out well because there is a lot of dynamic updating going on for mesh and buffer data. Aside from that, it is not resource intensive at all since it only updates when you move the mouse or click a button (and only uses 40 mb of texture memory, which could be far less if optimized).
The GUI is extremely flexible, much more so than what is demoed here. It can support any layout, and the layouts are liquid/fluid/elastic/choose your term -- meaning that I just drop in components and it autosizes them correctly and intelligently. It will even minimize container widths and heights to their smallest children, meaning you don't have to tweak column widths to see everything at once -- it all just fits.
You can additionally take any JSON data and it will build a GUI for you to edit it -- which is what's being done here. Not only that, but it can spit back out an updated JSON across a websocket or to a file, which means real-time editing of any of your game data (as I mentioned, my editor hooks up to a C++ server that hosts the game, or can be directly embedded in the game). One needed improvement is nesting the data more to take up vertical space - every node opens up a new horizontal container right now.
One thing that you may have noticed is the color, which is more vivid than your typical game engine (IMO). It uses the LAB color space. You are probably familiar with the RGB (Red, Green, Blue) and HSL (Hue, Saturation, Luminance) color spaces already. The LAB color space (and its variants) are generally considered to be the most perceptually uniform color spaces. Picking out a single color, this really makes little difference. The LAB color space really shines on interpolation. If you want to blend color A to color B using RGB, it will often turn grey between the two. LAB avoids this by keeping saturation and lightness more or less constant between two points, at least perceptually speaking. If you want to learn more about this, here is a good link. The easiest way to understand the difference between the two is probably a visual comparison of their linear spaces. Take a look at a LAB color ramp (top, mirrored) vs a HSL ramp (bottom):
Doing LAB interpolations in realtime would be way too expensive. So I precompute it. I use gradients to build a lighting ramp, which might seem like a naive approach but in my experience it is far superior to tweaking things like specular, ambient, and diffuse lighting. Even to experts, the mind cannot fully grasp how such colors are added together to form the result. A gradient is great because you know exactly how each color is going to act. If this lighting is too simplistic you can always add additional rules. It produces far from realistic lighting, but I am much more interested in style than I am realism. All of the chrome-ish textures you see above are achieved solely with gradient lighting - no reflection maps (although I will probably use reflection maps eventually since they provide better looking results).
Eventually I may use this GUI to power the Voxel Quest website (since it runs in a browser, obviously), but its other uses are:
Now that I'm finally done with this aspect (at least, past the worst of it) I am going to focus on getting the interesting stuff going for Voxel Quest, namely finishing up the terrain generation.
First, obligatory screenshot:
And a video:
This is a quick rundown on the text rendering and layout of my engine. The above demo is running on an Intel 4000 chip (a relatively weak, nondiscrete GPU) and never drops below 60 fps after initial startup / loading lag.
Because the browser side is used to modify many of the resources like materials and shaders, it is best to be able to preview that stuff in the same screen. It might seem a bit crazy to create a text renderer from scratch in a web browser, but I wanted it to look good an be responsive. Right now it still needs optimization (just in one area mostly, the ambient occlusion).
Why voxels, why not polygons? After all, three.js has a built-in example for polygon text. Well, polygon text does not scale very well - after a few hundred characters your system will not respond well...its also a lot of geometry to handle. My text is just a single quad for each letter, with some shader magic (although it does do a real rendering of volumetric data, nothing is "faked"). It does not matter how many characters you have on the screen, the only thing that effects performance is the size of the buffer the text is rendered to. It does not use any dirty tricks like rendering to a canvas, this text is all laid out in code with bitmap fonts (surprisingly fast, although like I said the AO shader is causing some lag right now). There is of course some sacrifice between "looking cool" and legibility but the engine is flexible and can render fonts in pretty much any style, even plain looking text. It supports all fonts, left/center/right alignment, text wrapping (with word breaking for continuations), any font size or scale, different styles of beveling, per-letter materials, etc. It also uses ray-cast shadows. The text is genuinely 3D, although many optimization tricks are used in light of the orthographic, fixed perspective (I figure most users wont care to rotate the text around).
From a technical standpoint, this is how the engine works:
Anyway, I am traveling to Germany and Switzerland in a few hours, so I may not be able to answer questions right away. I will write more when I get time. :)
One last screenshot, just messing around with the voxels and using a sin wav on the background height:
As of (roughly) today, I am now working fulltime on VoxelQuest (prior, I had almost no time due to a job that often required +80/hours a week). Expect updates more than once a year now! :)
The Voxel Quest website is slowly coming to life, give it a look. I have posted a fair amount of info about the game in the "about" section. I have also attached a screenshot of the current hex layout and perspective below:
I've updated my site a little bit with a screenshots and videos section, containing most of my (game-related) work over the past decade from various projects and clients. I've added some screenshots from my engine from a few months ago. I have added in isometric rendering and now all generation is done on the GPU, meaning it goes way faster (can generate billions of voxels in a few seconds) -- screenshot below. Also, I'm building up a site for my new game, appropriately called Voxel Quest. More details to come when I get a break from work! Not the "really cool" update I was hoping to provide (which is not really that cool, just some stuff I was hoping to get out for the new terrain engine).
That's all I'll say for now. :D
Just a quick update, I know I have not posted for a while - I have been pretty hammered at my "day job" but I am continuing to work on the engine as I get time - right now it is a lot of "non-visual" progress, as in backend, resource management, saving/loading data, and UI layout.
Added in some volumetric water. The water is not simply a plane (as is typical in many games) - it consists of a full set of voxels (you can kind of see this in the cutaway view shown below). Right now, the water is also shaded differently based on how close it is to an object, but I want to make it a bit more dramatic. I also need to add some depth to the water so that it is more occluded as it gets deeper. Additionally, I want to add refraction and probably animated waves - so as you can tell, this is still far from complete.
Just a quick update...mostly have been busy with work but in the free hours I've managed to get a lot done, even though visually it may not seem like it.
I rebuilt almost the entire engine. It is much cleaner, less code, better organized. No copy-paste code. The same routine handles all chunk generation and scheduling. Multithreading works a lot better now - rather than redundantly processing chunk edges, it synchronizes the chunk processing. Noncoindentially, I seemed to have completely eliminated the crashes I encountered every so often. (Word to the wise: do not try and use C++ vectors inside a thread, even if each one is exclusive to its own thread.) I also implemented better mipmap generation and handling. Overall, rendering performance is up 2-10 times faster depending on settings, and chunk generation is (as promised!) over 100 times faster, although there is still much room for improvement (particularly in terms of choosing visible chunks to render). But for now, I am very happy with performance and probably won't optimize it much more for the time being.
I wrote my own GUI and text-render from the ground up. It can render without shader state changes, meaning it can all be compiled into a single display list. It is generated almost entirely on the GPU (text is read from a bitmap though). It uses uniform spacing and character widths, intentionally (all part of the old-school look :D). Still in the early stages but here is a screen shot (characters have backgrounds just for the hell of it, but can easily be disabled).
Overall, I am very happy with the progress made, the engine feels much cleaner, faster, and stable.