Voxel Engines

First off, a Voxel Engine is a game engine that uses voxels, and voxels are simply 3d pixels. One of the most popular games that runs on a voxel engine is Minecraft.

A landscape from Minecraft

If you don't know, (how could you not know?!), Minecraft uses massive blocks (voxels) to form a highly sandboxed universe where players work together to build their own virtual worlds. To me, Minecraft seems to be just a demonstration of the incredible potential behind voxel-based sandbox games. I was enthralled in the game throughout high school. It was another world. A world where I was completely free to build whatever wherever and with whoever. I met people from all over the world and worked together to create complicated logistics systems and redstone circuitry, as well as beautiful mansions and cabins. All this, with voxels that are actually half the height of the characters!

Nowadays, voxel engines are getting much more complex and much more refined. These engines are able to achieve much more complicated worlds with more optimized algorithms written in higher performing programming languages than Java, which is the language Minecraft is written in. I believe that if voxel engines can continue to get more and more powerful, while remaining entirely customizable and modular, that they could soon become the future of virtual reality and video gaming in general.

A landscape from Voxel Farm

I recently stumbled upon the incredibly impressive voxel engine called Voxel Farm. Voxel Farm is written in C and C++ and is a highly advanced engine that allows relatively intuitive world building in a much more continuous sandbox world than Minecraft. As you can see from the image on the left, Voxel Farm looks just like a typical gaming engine. In many ways, Voxel Farm is a typical gaming engine. For example, it can output meshes in real time and work in tangent with many popular game engines like Unity or Cryengine, however in its backend, it is still a fully voxelized world.

Voxel Farm is being developed as a game engine and not as a game. While this is an obvious point, it definitely makes a huge difference. The developers are targeting other developers with much of their programming time, which will have some interesting effects. Now, I'm sure you might say, well how come someone couldn't simply use this game engine to build the next Minecraft? While I agree that this is a distinct possibility, it simply doesn't offer the huge potential that you get when you are in control of absolutely everything about a game. It is a freedom that cannot be matched, and it is one of the main reasons why Minecraft was such a success. Also, it is worth mentioning that the Pro package distributes the full source code to the buyer, so it is technically possible to change the inner workings of the game engine, however I have doubts that even this will be enough.

Despite my doubts, I really hope we get to see some great games come out of this project. And either way, I think the work that is being put into Voxel Farm is an excellent investment. It is pushing the limits of what voxels are capable of, and because of this, I believe it has some incredible potential! So look out for the future of Voxel Farm because it could be making some waves in the world of gaming in the next couple years.

More Cellular Automata

I'm back after a little more developing on my CA program, (see my previous post entitled 'Cellular Automata'), and a very educational conversation with reddit user /u/slackermanz, someone with much more experience making cellular automata that me. (Seriously, look at /r/cellular_automata, they have some very impressive patterns on there, and most of them are made by /u/slackermanz).

The modifications I have made to my program are making it such that each cell will not move, but will be able to eat cells in its near vicinity, and reproduce in a random direction. As mentioned previously, I implemented an energy value, which each cell starts out with, and if they run out of energy, they become food for other cells. If the cell has an excess of energy, they will reproduce. This produces the following pattern.

As you can see, there is an exponential expansion, and I am working to minimize this, since I think there will be more interesting patterns in an energy starved environment.

Another problem I am working to fix is an over-lapping of cells. Somehow in my code, multiple cells are able to occupy the same space, which is causing an over-creation of cells and lagging my program. I believe to make this more efficient, I will initially spawn cells for all spaces, then have my program set the cells in a state of dead, alive, or food, that way the number of cells is constant.

As always my code is on my github. Stay tuned for these modifications and optimizations in the near future, until then, thanks for reading.

What I did over winter break, and why it was a massive waste of time.

I want to talk about the myriad of obstacles that I encountered over winter break (2014 - 2015). Ever since the end of my senior year of high school, after writing a pretty dinky little 2D physics simulator, I had been really wanting to give it another dimension, but held back by the complexity of it. 3D graphics and physics gets quite complex, so simplify the enormous task, there are a host of tools that one could use, ranging from closed source production-quality game engines like CryEngine or Unity to the free and open-source tools that I chose to use, Ogre3D and Open Dynamics Engine. I chose the open sourced libraries because, (a) I exclusively use Linux, and Unity isn't available for Linux and (b) I am a Linux SysAdmin, what do you expect?.

An image of what some of the starter code rendered
This Ogre is a pain in my ass!

So at the beginning of my sophomore year, I decided upon Ogre3D after learning Cinder was unfortunately Windows and OSX only. So I tried to start working through the beginner tutorials but the provided starter code wouldn't even compile. The starter code's Makefile was just broken, with about four lines of options needing to be added to the autotools makefile.am and configure.ac. After getting in touch with a developer, who kept insisting I use CodeBlocks, a graphical IDE (ew gooey), I noticed that there were some very helpful comments on one of the autotools configuration pages that included exactly what I needed to get the starter code compiling. My question is, why hadn't these changes been made to the code? Finding this and getting it to work took up most of the first half of my semester, just to get the starter code compiling!

So I went into winter break hoping that my experience would smooth out, or that I would get over some threshold and finally understand how to make Ogre do exactly what I want in an intuitive way. After all it is object based, why shouldn't it be intuitive? Well, long story short: I was wrong. Ogre's syntax is incredibly verbose and complex. It's objects are not used in an intuitive way--it's data structures are sort of hybrids between self contained objects and nested-scoped static methods. For example, I struggled to be able to simply print to the program log, and that is because printing requires the following line of code in Ogre:

    Ogre::LogManager::getSingletonPtr()->logMessage("### Error parsing config file ###");

 "Ogre::LogManager::getSingletonPtr()" is a call to a static method within the LogManager scope, which is itself within the Ogre scope. That method will return a pointer to the Ogre::LogManager object, which can only be initialized once in the program. Then you can use that pointer to call logMessage(), which will add your message to the log. Here is the initialization of the LogManager object:

    Ogre::LogManager* logMgr = new Ogre::LogManager();
    Ogre::Log* myLog = Ogre::LogManager::getSingleton().createLog("myLog.log", true, true, false);

Honestly, I don't even have a complete understanding of what this code is really doing, I mean is logMgr a deferenced LogManager pointer to a pointer to the new LogManager object? What? After that line, we can completely ignore the existence of the logMgr object, because of course we will just use getSingleton() whenever we need to log. (what was the point of even making us write that line then?) But initializing the LogManager wasn't enough, because we need to create the log file, and put it into myLog, which we will never use again. If the logManager object was only meant to be initialized once, and used through getSingleton(), then why even make us be so verbose about it. These kinds of options should not need to be written explicitly. I mean, if I wanted to rename my log's filename, or specify whether to add debugger output to it, then I should be able to via these complicated ways. However, if I just want to print some message and don't really care, I am forced to add these highly complicated lines of code to my file just to do that. 

My entire winter break went like this. There was no way I had the time to fully understand all of the highly complicated syntax of Ogre, while also trying to tie in Open Dynamics Engine.

Open Dynamics Engine (ODE) is a rigid body physics engine, written in C. Naturally, it's interface was  incredibly different than Ogre's. While it was much less complicated and slightly much more straightforward, I ran into serious difficulties when trying to get it to play nice with the big bad Ogre. For example, all the calculations ODE ran would be returned to my program in the ODE-defined 3d coordinate object const dReal* and I was tasked with the requirement to decompose that object and turn it into what Ogre wants, Ogre::Vector3 s, in order for the object to be re-rendered in the corrected location. It was a constant battle trying to make the two get along, and even today they still don't behave. 

Well that got long and complex... In summary, I dove head first into the deep end of two very complicated and very different C and C++ libraries, and I emerged with a buggy hunk of code, from which I understand <60% and have written <40% myself. I previously thought that if I forced myself to use C++ then I would be a better programmer than all those cheaters using the easy languages like Python. I even started the break off with a few OpenGL tutorials before realizing that it was far too low level for the kind of things I wanted to do. Clearly, the same was true for Ogre and ODE. I learned C++ and C are production-level languages and programs that are even mildly complicated are usually written by many people over the course of many months, not by a hobbyist experimenting with 3D programming with a low work ethic (winter break is a break after all). 

All of this is ironic, of course, because the reason this blog exists is because of my research at ASU. At ASU, I was researching the differences between Java and C++ and concluded that C++ was more geared towards businesses with more value in their software and many more programmer (wo)man-hours to devote to it, NOT lazy CS majors trying to have some fun making a realistic 3D world. I guess this whole experience was a lesson in believing the results of actual research... 

Well, thanks for reading, and if you have any questions feel free to comment and I will try to answer them if I can. 

-Jeff