Video Update for May 2013

This update sums up a few nice additions done over the last month: the ability to use meshes as brushes for creation and how you can go off-grid.

Euclideon Geoverse 2013

Euclideon is back. Here is their latest video:


It seems they put their tech to good use. Their island demo was very nice, and now this is one of the best point cloud visualization I have seen so far. Is it groundbreaking or revolutionary? No. There is plenty of this going around. But this is good stuff.

This announcement may be very disappointing to some people who may have taken their past claims literally. Two years ago they said they had made computer game graphics 100,000 better. They would show you screenshots from Crysis and explain how bad all this was compared to their new thing. Panties were thrown all over the internet.

The reality is today this still ranks below the latest iterations of CryEngine, Unreal Engine and id's Tech 5. It even ranks below previous versions of those engines. Actually I do not think you can make a game with this at all. If you want to have the texture density you have on screen in most games, you would need to store far more information than what they have in the demos shown here. It is a perfect match for the state of laser scanning, where you do not have much detail to begin with. They are not showing grains of dirt anymore, that is for sure.

The real improvement in the last two years? The hype levels are a lot lower.

Going off-grid

Here is a teaser of a series of screenshots and videos to come very soon:

This is not Minecraft on LSD.

Once you have a voxel system that is capable of representing surfaces in any direction and curvature, the real challenge becomes UI mechanics. Creating content has to be simple and rewarding. It has to feel like a game. You cannot expect players to pickup a manual or become experts in full voxel edition systems like Z-brush or 3D Coat.

But the potential is definitively there. Going off-grid allows for more interesting creations. If the system is intelligent enough to adapt to whatever is already there, you could be creating all sort of angled and curved content without busting any veins in your forehead.

What is even more interesting: there is no reason why you would limit this only to cubes. These elements you place could be anything: column disks, rocks, crystal shards, archways, statues. They could be even portions of stuff you or someone else has done before.

I'll leave it there for now. Hopefully you will be intrigued enough to come back later checking for more.

Covering the Sun with a finger

The oldest optimization in real-time graphics is to avoid rendering what you don't see. When you explain this to people who are not in the field, they usually shrug and say something in the line of "Duh, Sherlock".

It is easier said that done. Well, actually a big part of it is quite easy. The first trick you see in all graphics books is to render only what's inside the field of view. While the scene surrounds entirely the camera, the camera only captures a narrower slice of it. Anything outside this slice, which is usually 90 degrees along the horizontal, does not need to render. For a mostly horizontal scene, only 90 degrees out of 360 need to be rendered. This simple optimization reduces scene complexity four times. Another way to put it is, now you can have four times more detail without a performance drop. This technique is called Frustum Culling.

Frustum Culling is a no-brainer for small objects that are scattered around the scene. As scene complexity rises you must batch as many objects together as possible. The need for aggressive batching apparently has relaxed a bit recently, but there is no question that batching is still necessary. This goes against Frustum culling. What if there is an entire batch that is only partially in the field of view? You would still need to render it all. So, the more you batch, the more you can loose from the frustum culling optimization... unless your batches are somehow compatible with the scene slices you need to render. More to that later.

Even if you were able to perfectly cull all the information outside the field of view, there is usually a lot of polygons being rendered in a scene that never make it to the screen as pixels. This is because they become hidden later by a closer polygon.

Imagine a huge mountain with a valley behind it. If the mountain was not there you would see the valley. With the mountain in front of you, all the efforts rendering this valley go to waste. If we could somehow detect we can skip this valley, we would save a lot of rendering. We could have a much nicer mountain.

This technique is called Occlusion Culling. It is in principle a difficult problem, as the final rendering is the ultimate test of what is really visible and what not. Obviously some sort of approximation or model has to be used. A simpler model of the scene allows to estimate what portions of the final rendering will become hidden so it is safe to skip them.

And then again, if you had the occlusion problem perfectly solved, you would still have the issue with batching. It is not that different than with frustum culling. Maybe just a small clip of a large batch is visible, still that would require the entire batch to render... unless your batches are somehow compatible with the scene volumes being occluded.

I wondered that maybe there was a single approach that would help with all these issues at once. Yes, some sort of silver bullet. I set out to look for one, and did find something. Well maybe it is not a silver bullet, but it is quite shinny.

It is about the geometry clipmaps. I have covered them many times in the past. The idea is somewhat simple: if your world can be represented as an octree, you can compute any scene from this world as as series of concentric square rings. Each ring is made of cubic cells. The size of these cells grow exponentially as the rings are farther from the viewer.

The image above shows a projection of a clipmap in 2D.

You can see right away how this helps with batching and frustum culling. Each cell is an individual batch, which can contain a few thousand polygons. It is quite simple to determine whether a cell is inside the field of view. Also, cells go out of the field of view quite efficiently as their size is constrained by their very definition.

The clipmap turned to be very friendly for occlusion testing as well. Imagine you could identify some cells as occluders in one specific direction of the clipmap. It becomes fairly simple to test if more distant cells are occluded or not.

The following image shows how this principle works:

Here four cells have been identified as occluders. They show as vertical red lines. Thanks to them, we can safely assume all the cells painted in dark red can be discarded. These batches are never sent to the graphics card.

In my case I am performing the tests doing software rasterization. It is very fast because the actual cell geometry is not rendered, only cell aligned planes. So far a depth buffer of 64x64 provides sufficient resolution.

Not bad!