Following one man's task of building a virtual world from the comfort of his pajamas. Discusses Procedural Terrain, Vegetation and Architecture generation. Also OpenCL, Voxels and Computer Graphics in general.

Monday, April 30, 2012

Finally, some leaves. In this image you can see how trees look once the crown blobs have been seeded with branch instances. It is a very early test, but I thought it may help you see beyond the green blobs in all my previous tree screenshots.

This renders in realtime. I took the screenshot from my experimental HTTP streamer Sputnik. The lighting is very primitive. This will improve a lot with the radiosity solution.

I have been playing under this forest for a while now. I will post a video when I get some time.

As usual I look forward to your suggestions and ideas. I want to thank Robin Green for pointing a nice method to smooth normals. I'm already using portions of that.

Monday, April 23, 2012

One recurring question about the trees and forests I am doing is how they will show in the distance, from how far you could see them. It is a real issue.

I chose a different approach for trees than most engines I know. In traditional engines, trees are done by instancing the same tree models many times over the landscape. Each tree instance is known by the scene management and rendering engine. If a tree is sufficiently distant it can be represented by a simpler instance. This works nicely even for distant forests, but it imposes a very homogeneous look for your trees. If you want very large trees with unique branches this becomes a problem. At some level of detail the unique tree needs to be replaced by an instance. The more unique the tree, the bigger the visual jump will be.

I wanted to take a different approach to instancing. I still use it, but for much smaller elements like grass, flowers, tree leaves and small branches. This means each tree has unique geometry. Trees are fairly complex objects, a distant forest could have thousands of them. How to overcome this?

Many years ago I was flying over the Amazon rain-forest. I could see a thick layer of tree canopies below and a thick layer of clouds above me. I was amused by how similar they were. I began wondering if a forest could be rendered as a volumetric object, more like clouds.

I also wondered if I could make tree canopies opaque. After all they are often so dense you cannot really see inside them. It would really cut the number of polygons. All the branches inside the canopy could be removed, only the larger branches supporting the canopy puffs would remain. Here is one example taken form a Voxel Studio mesh render preview:

When looking at this, keep in mind there is a missing layer of instancing that goes on the crown volumes. This is rendered pretty much like grass and flowers over the ground (which you also won't see in this picture). You will be able to see a lot of detail coming out of the tree crowns. The green blobs in the picture before are the base for this instancing. This basic geometry is from where leaves and small branches get their position and -very important- their illumination.

I liked the fact that tree identities would be lost in this gigantic cloud. The geometry of several trees could be merged and simplified together, there was no need to think of tree instances beyond the generation stage. Also it would be rather easy to perform light scattering in the canopy cloud. To me proper lighting was essential to convey the scale of the trees and how it feels to be under them.

This approach had some big issues too. It does not work very well unless trees have fairly thick crowns. You can have a lot of small crown puffs to represent sparse crowns, but this could hurt your polygon budgets.

Now comes the initial question: How does it look when trees are far away? This is where this approach can shine. Since there are no individual tree instances anymore, the volume can be simplified down to the levels we know will look fine on screen. Then the instancing of leaves and branches continues to provide detail on top of the simplified clouds.

The following images show how much the trees can be simplified. You need to remember that each consecutive level appears further away. When these meshes are rendered in their proper positions, you cannot really tell the coarse level is just a weird soup of polygons.

This is LOD 1, which is shown pretty close to the camera:

This is LOD 6, which shows a few hundred meters away from the camera:

And this is LOD 10, which appears at more than one kilometer away. As you can see, the forest has entirely blended with the terrain. This means the grown polygons are not rendered anymore, only the canopy layer remains visible:

Here you can see the same progression from a different point of view. The LOD levels are the same: 1, 6 and 10.

Hopefully I have answered that forest-in-the-distance question. This looks really nice when properly illuminated and adorned with instances. In the short future I will post about that.

Tuesday, April 10, 2012

It was a nice quiet long weekend. I had some spare time to sink into this project. While it has nothing to do with procedural generation, I was always bothered by the plain generic look of my Voxel Studio application. So I decided to give it a new look.

This is really a waste of time. Only one person in the entire planet is using this program (you guessed who), but hopefully this may change in the future. For us who spend so much of our lives looking a computer screens I think we should make our software pretty and fun to use.

Here are some screenshots:

The biggest change was I moved all the commands into a single "ribbon" interface. I was never a fan of the ribbon when it was introduced by Microsoft. Now I see it does make the UI simpler, especially for a program you never used before. I like the fact there are no modal dialogs anymore. It also creates more space if you want it. The ribbon can collapse, then it behaves similar to a traditional menu.

Something the screenshots don't show is the docking system for all the views allows to extend your workspace across different monitors. This is how I normally use this program.

Wednesday, April 4, 2012

This is a continuation of the previous post. Like the one before, it is mostly about occlusion tests and snap planes in architecture generation systems.

It is possible to create richer architectural volumes by combining several simple volumes like boxes. The resulting volumes can be quite complex, which is in part what we wanted but it also brings some complications.

In the following image you can see the result of three boxes intersecting each other:

If you concentrate on the walls going out you will see they would make an interesting building. At the same time there is a lot of nastiness in the inside. There are several triangular spaces and at least one non-convex polygonal space. Those would not translate well into rooms. Ideally we would like to keep the outer walls and remove all the nonsense spaces. This can be done with occlusion tests and snap planes.

To show this I will use the same grammar language as in the earlier post. If you feel lost in the code there are some comments in that post that may help.

This is the code that produced these three boxes. It will be our starting point:

The module "angletest" is the one that produces the three rotated box volumes. Each box has its sides covered by wall panels.

The first half of the trick is to hide those panels that appear inside a volume. The occlusion query can do that. It would take only a few lines to add it:

The "volume" module now occludes. Also there is a new definition for the "panel" module that should be picked when the panel is occluded. Just to visualize which ones should be hidden I chose to render them as lines on the floor. You can see the results here:

This is already better, but there are stillsome holes in the corners. This is because an entire panel is hidden even if only one part of it is occluded.

Snap planes can help with this. If each volume defines a set of planes, the intersecting panels will match their size to the near volume. This is how you would write it:

Now each wall introduces a snap plane, then the panel repetition is snapped to those planes. Panels are aligned to wall intersections. They can be entirely removed and no holes will appear:

It wasn't so bad. Again, this alone won't be enough to create interesting buildings, but it is a technique you may want to remember.

Here is how it would look if you replaced the panels by windows. I also added some random rotation to the three boxes.