Loading YouTube Feed...

Saturday, November 15, 2014

Cantor City

The Cantor set (or how you obtain it) is probably one of the simplest fractals out there. It was one of the first examples I encountered and it helped me greatly understanding whatever came after. Here is how I like to explain it:

1. We start with a horizontal segment.
2. We divide the segment into three equally sized segments.
3. We remove the segment in the middle
4. Repeat from step (2) for the two remaining segments

This produces a set of segments that puzzled mathematicians for a while. I am more interested in the fractal properties of the whole construct. It shows how a simple rule operating at multiple scales can generate complex structures. This set is too primitive to be used for realistic content, but it is the seed of many techniques you will require to achieve that.

This is how you would code the Cantor set using our grammars:

This is the real world so we need to make sure it stops. An easy way would be to add another definition of "cantordust" for when the size is small enough. This definition would do nothing, thus stopping any further subdivision:

Here you can see the output:

Let's make it more interesting. First let's add depth to it. Instead of segments we will use 3D boxes:

This already looks like we were growing little towers. We can make the towers taller if there is enough room:

Let's add a random element. We will not split into three equal spaces anymore, instead we will pick a random value for each iteration:

For a microsecond this image can fool you into thinking you have seen a city. I think that is pretty cool if you consider it is only a few lines of grammar code.

Of course this is not a replacement for a city or buildings. The cantor grammars are probably the simplest you can have. You will need a lot of more code to produce somethings that can pass as a city. But odds are it will be mostly variations of the Cantor dust.

Sunday, November 9, 2014

Life without a debugger

Some programmers love the more literary aspects of coding. They enjoy learning new languages and the new structures of thought they bring. You will often hear words like "terse" and "art" from them. Some programmers like learning different frameworks, while others die by the not-invented-here rule. Some see themselves more like civil engineers: they have little regard for the nuances of coding, frameworks are just bureaucracy to them, whatever they build must stand on its own merits.

I have been a member of all these camps in one moment or another, so really no judgment here. But what probably unites all coders is that if you write a program, you will likely have to debug it.

If you have not stepped through your code at least once, you probably do not know what it is doing. Yes you can unit test all you want, but even then you should also step through your test code.

Karma dictates if you put a new language out there, you must also give a way for people to trace and debug it. That is what we just did with our LSystem and grammar language:

It turned to be quite surprising. We are very used to tracing imperative languages like C++ and Java, but tracing the execution of a L-System is unlike anything I had tried before.

I get the power of L-Systems and context sensitive grammars better now. This system feels like it had the ability to foresee, to plan features ahead. You see it happening in the video: often empty boxes appear in many different spots, like if the program was testing for different alternatives. That is in fact what it is happening.

It looks amazing that end features like the tip of a tower may appear even before than the base. In reality the program has already decided there will be a base, but its specific details are still a bit fuzzy so they come up much later. But then once they do appear, everything connects as it should, all predictions line up properly.

All that did not require planning from the programmer. In this case the code is not a series of instructions, it is more like a declaration of what the structure should be. The blocks fall into their pieces, the debugger just shows how.

It reminds me of another type of code at work: DNA. Now that would be one really cool debugger.

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:

There was an error in this gadget