Loading YouTube Feed...

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.

Sunday, September 7, 2014

Voxel Studio Revisited

We are working to make Voxel Farm accessible for a bigger crowd. Among other things we are easing Unity integration and improving our tools. Here is a teaser of the new Voxel Studio application, showing some terrain building:


We removed a lot of the complexity from the old Voxel Studio. No need to set up or connect to a render Voxel Farm anymore for instance.

The tool allows you to work on the macro features of your world like terrain, lakes, caves, architecture, then to jump in and edit the voxels directly. We will be showing more of that in the future.



Friday, August 22, 2014

Eureka!

Tired of running and swimming in virtual worlds? I see people wanting to build their own vehicles in order to get around. When the time comes, their imagination should be free to create ships and airships in any form they like.

Voxels are a good help here. They are volumetric by nature, and we can always know what kind of material is there. Each material then can have its own specific weight. So wood is lighter than stone, and stone may be lighter than raw iron. These properties have a great deal of influence one how things interact with each other, also how they rotate, how their center of mass is computed.

Air is no different. It is meant to weight something. So what happens if you have a material lighter than air? Check out the following video:



Here the balloons are just regular voxels. They could be any shape. The trick is they have a material that is much lighter than air. As soon as they become free standing objects, they raise. This is because the air they displace weights more than themselves and this force may be big enough to overcome gravity.

We will be looking at the same principle for water in a next iteration.

Tuesday, August 19, 2014

Dynamic Fluids

You may have caught some of this if you attended SOE Live or if you watched some of the audience videos from the panels.

We have been working for a while on a cellular automata system. The following video shows some early results:



As you can see the automata is producing something that resembles flowing water. I guess with different rules we could represent other phenomena, like smoke, clouds, slime and lava. Water in particular is a tough system because it likes to flow pretty fast.

This system is already able to schedule simulation so areas near the player (or players) get more simulation ticks. Simulation frequency is also affected by how much the system "wants" to change in a given area. For instance a stable puddle of water will get far less ticks than water falling from a cliff.

This makes the solution manageable from a computational point. This approach does create its own set of problems. For instance if nobody is there to experience the water, it does not really change. As someone approaches, the simulation frequency will increase gradually. This is enough to deceive players I hope, the player influence area is large enough to mask the fact that distant water does not update as frequently.

There are a few significant challenges ahead. We need to make sure this scales when we have hundreds of players. Also not everything in a game world is made out of voxels, eventually we would need to make props block and modify the flow of water.
There was an error in this gadget