Loading YouTube Feed...

Saturday, October 25, 2014

Unboxing Oculus DK2

It felt like Christmas yesterday when FedEx dropped our first Oculus development kit.

I had tried Oculus before at GDC this year. I was not particularly impressed, which was expected for an early prototype. I did get a very positive feeling about the potential of the VR medium.

It was the Couch Knights demo back then. While I was "inside" the demo I wondered why I would spend time in such a place. But it did take me to another place. This was a big deal for me, I do not remember any other device or medium getting close to that.

A few months later I had it in a box right in front of me. (I made sure it would be delivered to my home address instead of the company's so it could be just mine, at least for a few days.)


I was immediately impressed with the quality of the hardware. It was light and solid. You would get a distinct feeling this thing was properly built. The SDK was alright too.

It did not work at all in the first machine I tried. I blame Windows 8.1 and its new ability to use either integrated graphics or the standalone GPU. I see a lot of applications getting confused by that. As soon as I switched to a machine with just a GPU it began to work properly.

Then the sickness began. It was not a subtle discomfort, it made me so sick I could not function properly for the rest of the day. I am not astronaut material, but I have never been troubled by motion sickness in my life. I was aware the Oculus was making a lot of people sick, and was convinced I was not part of that population.

That experience was so bad it got me thinking. I felt poisoned. Poisons and our ability to survive them are masterpieces of evolution. So, in some sense, it is like I had evolved against VR.

What if no matter how much we improve displays, cut latency, etc. we will still be hitting biological triggers that tell your body something is wrong and it must puke its guts out?

I want to go back to working with the device. If the content is appealing  people won't mind the discomfort and will spend time to build tolerance. A lot of people do sickening drugs like alcohol.

Wednesday, October 8, 2014

3ds max

We have a 3ds max plugin in the works. Here is a quick screenshot:


We want people to use Voxel Farm to create scenarios for their video projects. But this may also help for the content you create and experience in real time. For instance: any content from your game world, procedural or hand-made, could now appear rendered in very high detail. Since this does not need to run realtime anymore we have time to crank up the voxel resolution. Exporting to max and creating a high quality rendering can be a very effective way to showcase your work.

3ds max is where this project started. Before writing a single line of code, I used 3ds max for a while to prototype geometry and texturing. It is good to be back.

Friday, October 3, 2014

Desktops, Tablets and Phones

One of my goals starting this project was to have relatively simple client applications exposing rich and complex worlds. While we later worked on generating as much as possible in the client-side, there will always be a case where you want access from power-challenged devices. Phones, tablets and even desktop web browsers do not necessarily have the power to generate everything you would like to have in your virtual world, but are still ideal mediums for people to experience it.

The good news is that generation can be offloaded to the cloud. Check out the following video. This is me at my home running several of these simple clients. The content they display is generated by servers running in Amazon's cloud:



Sunday, September 21, 2014

Your Euclideon Yearly Fix

Like every year or so, comet Euclideon comes close to us and we get to see what they have been working on. Here is a video they posted a couple of days ago:


As usual, the technology is brilliant and quite interesting. It is still similar to what Nvidia and Olick were able to show a long time ago, but nevertheless a significant feat of engineering. I am just having trouble reconciling the narrator's discourse with what we see on screen.

I was hoping they would tone down the hype in the future. They however named this video "The World's Most Realistic Graphics". I wonder which World they are talking about. In planet Earth, 2014, pretty much any AAA game looks better and runs faster than this.

I'm not sure why they would go and compare themselves to engines like UE4 when everybody knows UE4 will produce far better looking graphics. Same for CryENGINE and even Unity. It is not enough you say it looks better, it has to look better. Jedi tricks do not work over YouTube.

The "conspiracy of fools" aspect is also interesting. The true sign of genius is to see all fools conspiring against you. Somewhere in this video the narrator points that many experts around the web were very critical of the tech. These are the fools. That they got so many fools to speak against them must surely mean they are geniuses.

Well we know it does not work like that. Sometimes the fools just go against other fools. Being criticized does not make you right. Now in this video they claim they have proven all the fools wrong. That has yet to happen. The burden of proof is on them.

I had some secret hopes for this tech to be applied to games, but the tech gap is growing every year. Let's see what happens next year, when the comet approaches us again.

Tuesday, September 16, 2014

Runtime Extensions

We recently developed an extension model for Voxel Studio and Voxel Farm in general. The idea is you should be able to come up with entirely custom procedural content without having to recompile any of the tools, and even your final EXE if you like.

You can achieve this by wrapping your custom code inside an extension. During world design time, Voxel Studio is able to load your extension and allows you to input whatever configuration parameters you have chosen for it. Then, during runtime, the same extension code runs thus guaranteeing you get the same results you saw inside Voxel Studio.

Let's follow a quick example. Imagine we have developed a small scene in Voxel Studio using the default terrain component. At this point we have interacted only with the vanilla settings, so our scene looks like this:


Note this is only terrain, it does not contain other layers like rock and tree instancing, but it should be enough for this example.

Now let's say we want to add a massive sphere somewhere in the image. While we could go in edit mode and add a sphere using a voxel brush, this would set a lot of voxels. Since we know this will be a perfect sphere we can save a lot of data if we just store the center and radius and produce the voxels on the fly. Voxel Studio does not include a layer like that out of the box, but we can create it ourselves. Here is how:

Voxel Studio in Windows OS can load extension DLLs at runtime. You can develop the DLL in any form you like as long as the few required entry-points are found. The first few are functions so Voxel Studio and Voxel Farm in general can ask the extension what parameters it wants to capture. And then there is one function that will return the voxel data for a given chunk of space.

So we create a new DLL project. Just by dumping the binary DLL in the extension folder, Voxel Studio should be able to find it and allow us to use it for a new voxel layer:


Here our extension has identified itself as "Mega Sphere". Clicking on it will add it to the list of voxel layers in the tree.

We then define four properties for the sphere: origin x, origin y, origin z and radius. Exposing property metadata is what allows Voxel Studio to create editors for the extension without really knowing what they are and how they will be used:


Now comes the real work. So far it was mostly about metadata, let's see how we get actual voxels out of the extension. It comes down to implementing a function that looks like this:

        bool getVoxels(
                char* object,
                VoxelFarm::CellId cell,
                double cellOrigin[3],
                double cellSize,
                double voxelSize,
                int blockSize,
                VoxelFarm::VoxelType* changeFlags,
                VoxelFarm::MaterialId* materials,
                VoxelFarm::Algebra::Vector* vectors,
                bool& empty)


I will not go into the implementation this time, but the overall idea is this function is expected to fill the material, vector and flag 3D buffers with voxel data. The requested region of space is defined by cellOrigin and cellSize.

Once we code this to output a sphere, we are finally able to refresh our render view and see the results:



Here you can see some spheres. The one in the last image has a 10 km radius. Naturally we could have developed a more interesting layer, for instance a meteorite impact zone or ore veins, but hopefully you get the idea.

One last thing: Using native code for extensions always brings up the issue of security. We debated this for a while when designing the system. We finally chose to use DLLs just because they allow  to run native code without penalty. You can get really close to the metal. The security aspect can be managed by certification, also by running the DLL in a lower OS integrity mode, thus restricting the kind of access it would have over the system. And of course you can always have a DLL extension you trust that acts as a wrapper for code you do not trust, but runs in Lua or some other form of application language where you are certain it can be contained.

There was an error in this gadget