Loading YouTube Feed...

Saturday, February 21, 2015

The Farm in Voxel Farm

In the past months we have been working on a very cool system. I will describe it briefly for now, but I would really like to hear your opinions on this. We call it "The Farm".

The idea is simple: we are building a cloud service where everyone can contribute to any voxel world or scene they like. Whatever you contribute is remembered, but it is also kept on your own layer. Whatever you do, you cannot overwrite other people's content. And it is really up to others to decide whether they see your work.

When they do decide to see your work, your contributions to the scenery will be merged in real time. This is one of the key advantages of using voxels. So it will look as if everything was created as a hole, in reality what you see is the sum of different content streams which remain isolated from each other at all times.

This is pretty much like Twitter (or Facebook). You can tweet anything you want, if you have no followers, nobody will really see it. Like Twitter, this is real time. If someone is following you and you change a part of a world they happen to be looking at, they will see the changes in right away.

What I find powerful about this idea is creative groups can be assembled ad-hoc. If you and a few friends want to create together, there is no need to setup servers or anything like that. People in the group just need to follow each other.

If someone in the group goes rogue, it only takes people to un-follow that person to make all of his/her changes disappear.

We want your grandma using this so we have made it very simple for people to participate. You just need to say you want to use the Farm service for a particular project (a world) and you are set:

This system is also similar to source control systems like GitHub. At some point someone may decide to merge all contributions from a team of builders into a single "stream". Anyone following that stream will get the changes then. A project manager (or a Guild leader) can decide which team member streams to merge, which ones to reject.

We are using a revolutionary server-side architecture to achieve this based on Dynamo/Reactor patterns. We can guarantee very low latency by design, also to remember all your data, but this will likely require a small monthly fee from everyone involved. Commitment to this level of service has really high requirements.

That's it: Everyone participates, everyone decides what to see and it is very simple to get in.

Oh, and very important: You data is always yours.

Monday, January 5, 2015

Selection Twist

If you played SOE's Landmark during alpha you will remember the first iteration of the Line tool. It had some serious issues as soon as you started shifting the start and end position. We realized then that we needed a more organic approach to the line volumes. We were using flat planes to define the line volume and they were not able to transition smoothly enough from one end to the next.

In order to fix that, we chose to tackle on a bigger feature that had the line tool as a special case. This is usually a bad engineering practice, you just don't make a problem bigger to take care of a smaller one, but it turned out right. The line tool with disjoint ends was a special case of a mesh under a free-form deformation volume (FFD), so we did just that.

As you can see in the previous image, the sides of the line volume gradually curve from the start position to the end.

This has been in use for a while now in the line tool, but we just got time to add control points for the new selection tool. This allows many new cool shapes that were not possible before, like a simple bar that has been twisted:

In general the free-form deformation can produce pretty much anything you want. You can see other applications in this video:

The same operations can be performed over copy/pasted content and even the output of procedural grammars. This is already my favorite tool, if you are into twisting and bending I'm sure you will love it too.

Thursday, December 11, 2014

How the voxel zebra got its stripes

Here is the story behind these two zebras:

The zebra at the left was handcrafted by an artist. It is a traditional polygon mesh where each triangle has UV coordinates. These coordinates are used to wrap a handpainted 2D texture over the triangle mesh.

This is how most 3D objects have been created since the beginning of time. It is a very powerful way to capture rich surfaces in models. It is very efficient, it aligns well with the hardware, allows you to have incredible detail and even animate.

Voxels can also have UV. This allows you to capture more detail at much lower voxel resolution.

The zebra at the right had an interesting life. It went from the artist made polygon into a full voxel representation. Then it went back to triangles just before rendering. UV coordinates were preserved along this trip, but there is a lot of trickery involved. These are different meshes.

Both models use exactly the same texture the artist made. This is the important part. You could draw both in the same draw call.

The voxel version has fewer triangles. This is a 100x100x100 voxelization. To give you an idea of how small that is, here is the equivalent of that in 2D:
If you approached the zebra and looked at its head, at the left is how big these voxels would be:

At the right you see our results. The same amount of voxels can provide a lot more detail if UV coordinates are used.

I am happy with the results. To me this is as important as solving the physics problem. This will take the look of voxel scenes to a whole new level, while allowing you to harvest and destroy these carefully designed things.

This is still experimental and there are tricky issues ahead, like handling topology changes (holes closing.) and dealing with aliasing. For now I got to make a post with images of only zebras in it.

There was an error in this gadget