Outerra

Basic environment sounds

2011-10-12T15:24:00.001+02:00

We have added sound system (based on OpenAL), and provided aircraft with engine sounds using preliminary sound samples. Once the sound system was working, I went to add some basic environmental sounds so that the world feels more alive.

The whole system works by sampling coarse level environment data points surrounding the camera, using a 5x5 cornerless grid. Sound emitters are then set up at the places of the points, and each emitter is assigned a sound buffer corresponding to the type of environment.

To hide the grid layout, the emitters are set up to start attenuating the sound only from a distance that is larger than half the grid step. This works almost alright, except that the unattenuated zone also spans upwards, which doesn't feel natural. Later we'll have to implement a custom attenuation function that will handle it.

At the moment there are just 4 environment types - grass, open sea, shoreline and forest. Each emitter of given type can use only one of two sound samples (for now), that are pseudorandomly picked for given location. Locations are identified using a global unique identifier; this identifier is also used to manage the reuse of sound emitters.

Apart from these ground sources there is also another layer of emitters that are used to provide sounds of wind and rustling of tree leaves. They are positioned higher above the ground.

Following video shows it in action. The sound of wind in the last part of the video (in forest) is too loud, especially when the leaves and branches aren't moving yet.

***

In other news, we have started a closed beta testing of our alpha demo (yea, beta of alpha ). Here's the announcement and some info from it.

It goes pretty well, meaning we are getting lots of crash and bug reports and unexpected behavior reports on various combinations of hardware, OS versions and internet settings.
It's keeping us quite busy at the moment.

***

There's also a new truck model with digital camouflage texture, that we want to use for our demo game:

The camouflage is a modern type that is apparently not so well-known, and from the initial reactions it seems that Minecraft has spoiled it for people who didn't know about it before :-)

White balance

2011-07-29T00:24:00.001+02:00

When implementing the fog mentioned in the previous post, I observed a weird thing happening: the fog wasn't white, as I expected, but it had a dirty Beige tint making it look a bit like a smog or something. But since the implementation didn't use different absorption and scattering coefficients for RGB components, and thus the color of the sun light shouldn't have been modified, I thought it was a bug, and neglected it until most of other issues were solved.
But then, after inspecting all the code paths, I came to the only conclusion that the computation is right and the problem must be in the interpretation. So I tried to convince myself that the fog must be white, and the tint actually isn't there. Almost made it, too.

But the machine coldly asserted that the color wasn't white as well. Didn't bother with any hinting as to why, though.
Apparently the incoming light that was scattering on fog particles was already this color, even though the sun color was not modified in any way, unlike in the previous experiments.

Interpretation?

The thing is that sunlight really gets modified a bit until it arrives to the planet surface. The same thing that is responsible for blue sky causes this: a small part of the blue light (and a smaller part of the green light too) gets scattered away from the sun ray. What comes down here has a slightly shifted spectrum.
But how come we see the fog white in real life?
Turns out, everything is fake.

The way we perceive colors is purely subjective interpretation of a part of the electromagnetic spectrum.
And as it is easier for the brain to orient in the environment when the sensors don't move, it is also simpler to stick with constant properties on objects. Our brain "knows" that a sheet of paper is white, and so it will make it appear white in wildly varying lighting conditions. This becomes apparent when you use a digital camera without adjusting for the white color - the results will be ugly.

So basically that's why we have to implement an automatic white balancing, at least until we all have full surround displays and our brains magically adapt by themselves. By the way, playing in fullscreen in the dark room with uncorrected colors slowly makes it adapt too.

Implementation

Our implementation tries to mimic what the perception actually does. By definition, a white sheet appears to be white under a wide range of lighting conditions. So we are running a quick computation that uses the existing atmospheric code on GPU, that computes what light reflects off a white horizontal surface. The light has two components - sun light that reflects at an angle and its illuminative power diminishes as the sun recedes from zenith, and the second one is the aggregated light from the sky. Once this compound color is known, we could perform the color correction as a post-process, but there's another way - adjusting the color of sun so that the resulting surface color is white. This has an advantage of not affecting the performance at all, since the sun color is already taken into equation.

While this algorithm doesn't mimic the human perception precisely, i.e. the actual process is more complex and depends on other things, it seems to be pretty satisfactory, though I expect further tuning.

Some of the properties: it extends the period of day that seems to have a "normal" lighting, and removes the unnatural greenish tint on the sky:

During the day it compensates for the brownish light color by making the blue things bluer. Can't say the old colors were entirely bad though.

So long, and thanks for all the fish

Fog and dust

2011-07-21T22:53:00.001+02:00

In addition to the existing atmospheric model that already accounts for aerosol particles in air, we have been working also on incorporating ground fog and dust. It's defined by several parameters that determine its density, light scattering properties and boundary altitude. Shaders then compute resulting attenuation and scattering of sun light for terrain and objects. The code is similar to the code computing optical properties of water, using different values and omitting the upper reflective layer.

Viewing valleys of fog from a greater distance, illuminated by evening sun.

When the amount of scattering is lowered, one gets appearance of dust. Also, thicker layers of dust/mist can cast the terrain down below into darkness

There are several things that need to be done yet - currently the fog settings act globally, covering the whole planet in a veil of mist. There's no modulation that would give the fog a nicer, non-uniform look.

Ultimately, fog (or dust) should appear dynamically according to a probabilistic model that would describe chances of it forming at a given place (climate, precipitation) on the planet in given time of day/year. Or using a real time weather report feed.

Alien planet Earth

2011-07-13T09:45:00.000+02:00

Rendering our planet "alienized", using a different set of basic materials for fractal mixer, with changed parameters of atmosphere, sun and water.

Scattering of light in the atmosphere determines both the color of sky and sunsets. We can see a blue sky because the blue light is more likely to bounce off the air molecules than the green and even more than the red components of sun light. As the light from sun travels through the atmosphere above us, some of it gets scattered away from the ray and towards our eyes. The same effect is responsible for red sunsets - as the sun sets, light from it has to travel a longer way through a denser layers of atmosphere. By the time it reaches us, most of the blue and green light gets scattered away from the ray, leaving only the most persistent red component.

This effect is simulated in Outerra, and so we are able to play with it. What if the atmosphere consisted of different gases and the scattering characteristic was different?

In the following video we are showing planet Earth that was "alienized". The atmosphere in it scatters the green light best, which you can see not only on the sky itself but also on the shaded parts that are not lighted by sun but only by a portion of the sky.
The sun has got an orange shade, which you can see mainly on the horizon (the sun itself is too bright so looking at it directly saturates the color to white).

The absorption of light in the water has been altered as well - normally, the red light gets only so far in the water, when it almost entirely disappears. Here, the medium absorbs the green and blue light instead, letting the red one to penetrate into depths. Of course, since the water surface largely reflects the sky at an angle, the ocean appears to be green in the distance.

At the end there's also a short sequence with a red-orange atmosphere.

Here are some screens showing it under various settings:

Milk water & yellow skies:

Violet atmosphere:

No atmosphere (or no atmospheric scattering). This is what you'd get for example on the Moon:

Book: 3D Engine Design for Virtual Globes

2011-07-03T11:21:00.000+02:00

3D Engine Design for Virtual Globes is a book by Patrick Cozzi and Kevin Ring describing the essential techniques and algorithms used for the design of planetary scale 3D engines. It's interesting to note that even though virtual globes gained the popularity a long time ago with software like Google Earth or NASA World Wind, there wasn't any book dealing with this topic until now.

As the topic of the book is relevant also for planetary engines like Outerra, I would like to do a short review here.
I have been initially contacted by Patrick to review the chapter about the depth precision, and later he also asked for a permission to include some images from Outerra there. You can check out the sample chapters, for example the Level of Detail.

Behind the simple title you'll find almost surprisingly in-depth analysis of techniques essential for the design of virtual globe and planetary-scale 3D engines. After the intro, the book starts with the fundamentals: the basic math apparatus, and the basic building blocks of a modern, hardware friendly 3D renderer. The fundamentals conclude with a chapter about globe rendering, on the ways of tesselating the globe in order to be able to feed it to the renderer, together with appropriate globe texturing and lighting.

Part II of the book guides you to the area that you cannot afford to neglect if you don't want to hit the wall further along in your design - precision. Regardless of what spatial units you are using, it's the range of detail expressible in floating point values supported by 3D hardware that is limiting you. If you want to achieve both global view on a planet from space, and a ground-level view on it's surface, without handling the precision you'll get jitter as you zoom in and it soon becomes unusable. The book introduces several approaches used to solve these vertex precision issues, each possibly suited for different areas.

Another precision issue that affects the rendering of large areas is the precision of depth buffer. Because of an old non-ideal hardware design that reuses values from perspective division also for the depth values it writes, depth buffer issues show up even in games with larger outdoor levels. In planetary engines that also want a human scale detail this problem grows beyond the bounds. The chapter on depth buffer precision compares several algorithms that more or less solve this problem, including the algorithm we use in Outerra - logarithmic depth buffer. Who knows, maybe one day we'll get a direct hardware support for it, as per Thatcher Ulrich's suggestion, and it becomes a thing of the past.

Third part of the book concerns with the rendering of vector data in virtual globes, used to render things like country boundaries or rivers, or polygon overlays to highlight areas of interest. It also deals with the rendering of billboards (marks) on terrain, and rendering of text labels on virtual globes.

The last chapter in this part, Exploiting Parallelism in Resource Preparation, deals with an important issue popping up in virtual globes: utilizing parallelism in the management of content and resources. Being able to load data on the background, not interfering with the main rendering is one of the crucial requirements here.

The last part of the book talks about the rendering of massive terrains in hardware friendly manner: about the representation of terrain, preprocessing, level of detail. Two major rendering approaches have their dedicated chapters in the book: geometry clipmapping and chunked LOD, together with a comparison. Of course, the book also comes with a comprehensive list of external resources in each chapter.

We've received many questions from several people that wanted to know how we started programming our engine and what problems we have encountered, or how did we solve this or that. Many of them I can now direct to this book, which really covers the essential stuff one needs to know here.

Podcast about Outerra

2011-06-07T20:35:00.001+02:00

I've never been much of a speaker, not in my native language and even less so in English. When Markus Völter, the man behind SE Radio and omega tau podcasts, contacted me to make a podcast about Outerra and some of the technology behind it, I initially hesitated. But then I decided that it cannot hurt, and that I must force myself to train my tongue a bit.

So, after some time we recorded a hour long interview and you can listen to it here:

omegataupodcast.net/2011/06/67-rendering-the-world-with-outerra

Beware that I'm really slow speaker with pretty monotonous voice, and together with the technical nature it's probably not consumable for everyone. Enjoy if you can :-)

Bumpy grass effect

2011-05-09T21:24:00.000+02:00

Some time ago when I was modifying how dirt roads are being generated, to achieve their better integration into the terrain, I noticed that after one operation the grass close to the dirt tracks got a bumpy look, that had a potential in it to produce a better looking low grass fields.

Recently I have got to those code corners again and decided to play with it more. It's using fractal channels to generate the bumps, subjecting it to several treatments - the effect being smaller on some types of grass, and also changing together with modulating colors.
Here's the result:

For comparison, here's how the same scene looked until recently:

The effect is most visible when the sun is lower, it's achieved just by normal lighting. It should be probably combined with another effect that will make it more attractive during noons - shades from grass blades, visible from the side.

Of course, an important thing will be to combine it with real 3D blades smoothly appearing up close, and to apply the effect on other types of vegetation visible at distance.

A short video showing the thing in motion:

A comparison of the old and new datasets

2011-04-14T09:56:00.003+02:00

Here's the promised comparison between the old and new data. Despite the base terrain resolution being the same in both cases (3" or roughly 90m spacing), the new dataset comes with much better erosion shapes that were previously rather washed out.

The new data come from multiple sources, mainly the original SRTM data and data from Viewfinder Panoramas that provide enhanced data for Eurasia. It appears that the old data were somehow blurred, and fractal algorithms that refine the terrain down didn't like it.

The difference shows best in Himalayas - the screens below are from there, starting with Mt.Everest.

old | new

There are also finer, 1" (~30m) resolution data for some mountainous areas of the world, and we plan to test these too - interested to see how it affects the size and changes the look.

→ forum link

A new terrain mapper tool

2011-04-13T18:57:00.001+02:00

Our old terrain mapping and compression tool has been recently replaced by a new one, developed from scratch. The old tool has been the only piece that was not done completely by us (core Outerra people), and as the result it felt somewhat "detached" and not entirely designed in line with our concepts. It was quite slow and contained several bugs that caused artifacts mainly in coastal regions.

What's going on with the tool? Its purpose is to convert terrain data from usual WGS84 projection into a variant of quadrilateralized spherical cube projection we are using, along with wavelet-based compression of the data during the process. It takes ~70GB of raw data and processes them into a 14GB datased usable in Outerra, endowing it with ability to be streamed effectively and to provide the needed level of detail.

With the aforementioned defects in mind, and with the need to compile a new dataset with a better detail for northern regions above 60° latitude, we've decided to rework the tool, in order to speed it up and to extend the functionality as well.

I originally planned to implement it using CUDA or OpenCL, but after analyzing it deeper I decided to make it a part of the engine, using OpenGL 3.x shaders for the processing. This will allow for creating an integrated and interactive planet or terrain creator tool later, which is worth it in itself.

The results are surprisingly good. For comparison: to process the data for whole Earth, the old CPU-only tool needed to run continuously for one week (!) on a 4-core processor. The same thing now takes just one hour, using a single CPU core for preparing the data and running bitplane compressor, and a GTX 460 GPU for mapping and computation of wavelet coefficients. In fact the new tool is processing more data, as there are also the northern parts of Scandinavia, Russia and more included in the new dataset.

All in all it represents roughly a 200X speedup, which is way more than we expected and hoped for. Although GPU processing plays a significant role in it, without the other improvements it would show much less. The old tool was often bound on I/O transfers - it synchronously processed and streamed the data. The new one does things asynchronously, additionally it now reads the source data directly in packed form, saving the disk I/O bandwidth - it can do the unpacking without losing time because the main load has been moved from CPU to GPU. Another thing that attributed to the speedup is a much better caching mechanism that plays nicely with the GPU job.

There's another interesting piece used in the new tool - unlike the old one, this traverses the terrain using adaptive Hilbert curves.

Hilbert curve is a continuous fractal space-filling curve that has an interesting property - despite being just a line, it can fill a whole enclosed 2D area. Space-filling curves were discovered after mathematician Georg Cantor found out that an infinite number of points in a unit interval has the same cardinality as infinite number of points in a any finitely dimensional enclosed surface (manifold). In other words that there is a 1:1 mapping from points on a line segment into the points of a 2D rectangle.
These functions belong to our beloved family of functions - fractals.

In the mapping tool it's being used in the form of a hierarchical recursive & adaptive Hilbert curve. While any recursive quad-tree traversal method would work effectively, Hilbert curve was used because it preserves locality better (which has a positive effect on cache management), and because it is cool :)
Here is a video showing it in action - the tool shows the progress of data processing on the map:

Apart from the speedup, the new dataset compiled with the tool is also smaller - the size fell down by 2GB to ~12GB, despite containing more detailed terrain for all parts of the world.

I'm not complaining, but I'm not entirely sure why is that. There was one minor optimization in wavelet encoding that can't explain it. The main suspect is that the old tool was encoding wide coastal areas with higher resolution than actually needed.

***

Coming next - a comparison of new and old datasets. Apart from providing a more consistent terrain detail for whole world, the new dataset also comes with enhanced mountain shapes in several places.

Ocean Rendering

2011-02-18T14:19:00.003+01:00

Let me first say that I'm often visiting my own blog to read how I did certain things. This is mostly true for some of the older, more technical posts. I decided to blog about recent water rendering development in a way that will be helpful for me in time when my brain niftily sends all the crucial bits to desert. I apologize in advance if some pieces seem incoherent.

Now for the rendering of water in Outerra.

There are two types of waves mixed - open sea waves with the direction of wind (fixed for now), and shore waves (the surf) that orient themselves perpendicularly to the shore, appearing as the result of oscillating water volume that gets compressed with rising underwater terrain.

Open sea waves are simulated in a usual way by summing a bunch of trochoidal (Gerstner) waves with various frequencies over a 2D texture that is then tiled over the sea surface. Obviously, the texture should be seamlessly tileable, and that puts some constraints on possible frequencies of the waves. Basically, the wave should peak on each point of the grid. This can be satisfied by guaranteeing that the wave has an integral number of peaks in both u,v texture directions. Resulting wave frequency is then

Other wave parameters depend on the frequency (or its reciprocal, the wavelength). Generally, wave amplitude should be kept below 1/20th of wave length, as larger ones would break.
Wave speed for deep waves can be computed using the wavelength λ as:

Direction of waves can be determined by manipulating the amplitudes of generated wave, for example the directions that lie closer to the direction of wind can have larger amplitudes than the ones flowing in opposite direction. The opposite wave directions can be even suppressed completely, which may be usable e.g. for rivers.

Shore waves form as the terrain rises and water slows down, while the wave amplitude rises. These waves tend to be perpendicular to shore lines.

In order to make the beach waves we need to know the distance from particular point in water to shore. Additionally, a direction vector is needed to animate the foam.

Distance from shore is used as an argument to wave shape function, stored in a texture. This shape is again trochoidal, but to simulate a breaking wave the equation has been extended to a skewed trochodial wave by adding another parameter determining the skew. Here's how it affects the wave shape:

The equation for skewed trochoidal wave is:

Skew γ=1 gives a normal Gerstner wave.
Several differently skewed waves are precomputed in a small helper texture, and the algorithm chooses the right one depending on water depth.

Distance map is computed for terrain tiles that contain a shore, i.e. those with maximum elevation above sea level and minimum elevation below it. Shader finds the nearest point of opposite type (above or below sea level) and outputs the distance. Resulting distance map is filtered to smooth it out.
Gradient vectors are computed by applying Sobel filter on the distance map.

Gradient field created from Gaussian filtered distance map

Both wave types are then added together. The beach waves are conditioned using another texture with mask changing in time so that they aren't continual all around the shore.

Water color is determined by several indirect parameters, most importantly by the absorption of color components under the water. For most of the screen shots shown here it was set to values of 7/30/70m for RGB colors, respectively. These values specify the distances at which the respective light components get reduced to approximately one third of their original value.


Red: 7m, Green: 30m, Blue: 70m, Scattering coefficient: 0.005	Red: 70m, Green: 30m, Blue: 7m

Another parameter is a reflectivity coefficient that tells how much light is scattered towards the viewer. Interestingly, scattering effect in pure water is negligible in comparison with the effect of light absorption. Main contributor to the observed scattering effect is dissolved organic matter, followed by inorganic compounds. This also gives seas slightly different colors.


Scattering coefficient: 0.000	Scattering coefficient: 0.020

Here's a short video showing it all in motion.

An earlier video that was posted on the forums with underwater scenes:

TODO
Water rendering is not yet finished, this should be considered a first version. Here's a list of things that will be enhanced:

Better effect for wave breaking. This will probably require additional geometry, maybe a tesselation shader could be used for that.
Animated foam
Enhanced wave spectrum - currently the spectrum is flat, which doesn't correspond to reality. Wave frequencies could be even generated adaptively, reflecting the detail needed for the viewer.
Fixing various errors - underwater lighting, waves against the horizon, lighting of objects on and under the water, LOD level switching ...
Support for other types of wave breaking
Integrating climate type support to the engine, that will allow different sea parameters across the world
UI for setting water parameters
Reflect the waves in physics for boats

A few of ocean sunset and underwater screenshots that were posted on the forums during the development.

Outerra on Twitter Outerra on Facebook

Outerra Year 2010 Retrospective

2010-12-26T20:35:00.001+01:00

Our friend from Texas, artist and science-fiction writer born under nickname of C. Shawn Smith, made this nice compilation from pieces of our published and some unpublished videos created during the year 2010.

Outerra 2010 Retrospective

Thanks Shawn, and happy New Year to all our fans and supporters all around the world!

Outerra on Twitter Outerra on Facebook

Aeroworks and Outerra

2010-12-15T17:40:00.001+01:00

This blog post will be about our recent visit of AeroWorks team at Brno University of Technology in Brno, Czech Republic. These guys are working on SimStar project, a light aircraft simulator based on the cockpit section of Evektor SportStar aircraft.

Presentation photo, the space is actually jammed with stuff as anyone would expect

They were interested to use Outerra as one of the image generators that could be plugged in. We liked that idea as well, so ultimately we packed our stuff and went on a trip to Brno, which is just some 125km from our HQ in Bratislava.

The project is being led by Peter Chudy who is coaching a few enthusiastic students working on related diploma theses with goal of enhancing the simulator. He is also ensuring that everything in this unique academic project goes right, undertaking all the necessary chores and dealing with all companies that might help to advance it. Peter is quite dedicated kind of guy who constantly fires jokes intermixed with questions caring whether we like the project. Nevertheless, or maybe thanks to that, he was nicknamed "Mr.Horrible", not just for forcing people to take off their shoes

Mr.Horrible ready to take off in Outerra

Approaching Airport2. Displays are not yet interconnected with Outerra, but otherwise they function just fine.

There were some issues with joystick detection and behavior, and we had to fix the blocking ones directly in place to be able to test the simulator. We still have to adjust the profiles for individual axes to get a more realistic behavior.

The canvas has resolution of 1024x768 pixels which is quite low, the overall feeling will be even better when the projector is upgraded.

Here's also a video montage of initial testing with Outerra as a visualizer. Because of the joystick issues the aircraft control was very clunky. But as a first test it was overall success, all the issues will be dealt with in coming time.

For further steps we'll need to design a protocol for interconnecting all the components of the simulation, or to find a standard one that will suit our respective needs. One of the possibilities is CIGI from Boeing, but its design is somewhat old and doesn't entirely fit our architecture. If anyone knows about other possible standards that we might consider for the job, please let us know.

Forum topic for discussion.

Outerra on Twitter Outerra on Facebook

IITSEC, ISS and DDG-96

2010-12-08T21:02:00.001+01:00

I/ITSEC, the world's largest modeling, simulation and training conference this year took place in Orlando. Although we weren't exhibiting, we still had a representation there. Packed with Alienware M11 notebook and a bunch of brochures, our friend and US partner Robert Francis was having several meetings with the attending companies, teasing everybody in range with images and videos.

He was showing some of our older videos, as well as some newer ones with ISS space station and alpha version of ocean rendering. Even though the ISS model was using only default materials and wasn't quite finished, it's been a great hit - together with descending to earth surface it showed the scale of the world nicely. After showing the videos he ran the demo version on the laptop to prove the thing's real.

Robert is saying: The reaction received was extremely positive. Many times when demoing to one person they would call their team members over excitedly so they could see the demo. Several groups said that they would meet as a team to discuss options with us and would be contacting us soon.

Here's one of the videos with ISS, descending down to a bay with docked USS Bainbridge ship. Don't mind the bugs visible on the water - they have been fixed already for the presentation.
A blog about the new features in engine will be coming soon.

We've also modernized our communication channels, creating a Facebook page. Now you can also follow us on Twitter.

Outerra on Twitter

Speed of Light

2010-10-31T21:48:00.001+01:00

We've had this idea some time ago - to experience how fast the speed of light actually is by flying away from the planet in Outerra at that speed. Now I've made a short video showing exactly that - flying away from the surface to space, and then returning back (but overshooting past it).

And while the speed is indeed great, one can feel that's also terribly slow when considering the extents of space ..

Apache helicopter

2010-10-30T19:54:00.003+02:00

Here comes another video, this time with Apache AH-64 helicopter or two in it.We went to add a helicopter after the support for them has been recently added to JSBSim library. There still seem to be some bugs and our parameters for the model aren't entirely right either, so the behavior might not be absolutely correct.

Still, flying the helicopter is a great fun. I wasn't able to fly helicopter in a simulator before, probably just because I never tried hard enough. But flying it here - over the forests and through the canyons and close to the rocky walls - that gives it a completely different feeling and experience, so even the types of me can get easily lost in time while wandering over the unknown lands here.

In case you are wondering, the camera comes out from the Hydra rocket launcher at the beginning of the video, made possible thanks to the use of logarithmic depth buffer.

In order to make this video we added support for "translucent" shadows so that the shadows from rotor blades look more natural, the hard shadows were quite disturbing.

Since the last blog update a number of things has been worked on - an updated atmospheric rendering code resulting in nicer and faster atmosphere rendering, while being also more consistent in various settings. There should be a separate and more technically oriented post about that for people who are fighting with atmospheric scattering which is quite hard to get right. And of course I need to write something about it so I can find how it works later when it drops off of my brain completely again.

As a part of the atmospheric code also the ambient light has been tweaked so the shaded and shadowed terrain is now looking better; this shows best on the features of rocks - previously it didn't have the right amount of contrast and looked quite bland.

Another batch of work done concentrated on GPU memory consumption optimizations; large terrains are quite demanding in this regard so an effective management of it is essential. We managed to save bits of memory here and there by employing various hacks and different formats, which totaled to hundreds of megabytes in the end. But while someone had to effort and tweak the system to save the megabytes, someone else just had to delete that dummy 80MB buffer that was sitting there :-)

Lastly, here are some screenshots with the helicopters:

Forum topic - Apache helicopter.

Asynchronous Job Scheduler

2010-09-26T19:31:00.000+02:00

Today's blog will be again more technical, speaking about some of the internal engine components.

One of the essential components is an asynchronous job scheduler, named simply jobmaster in the engine. Its task is to execute jobs that have to be carried out asynchronously because they contain code that usually blocks while waiting for disk I/O or network operations to complete. This code has to run decoupled from the main application and the renderer threads as it would introduce stuttering.

However, programming asynchronous routines is not that straightforward as it is with the synchronous ones. Previously we used special job processors that used a fixed number of threads to process jobs, that explicitly handled their state and issued respins to allow running other jobs while waiting for their asynchronous operations to complete.
This was cumbersome to use and consequently we often coded some things as synchronous routines, pushing it to a queue of things to be done "later". As you can guess, many things queued there and we had to think how to make this simpler and more enjoyable.

Jobmaster came as a solution to this, because it allowed us to write a simple synchronous code to handle things like texture and terrain data loading and downloading terrain data over bittorrent, while still effectively handling multiple jobs in parallel. Another important property is that one can set the number of threads that will run concurrently, adjustable to the number of processor cores available on the system and thus not fighting for the resources unnecessarily.

Jobmaster keeps a pool of threads that it uses to handle jobs. A thread can be in one of three states - either sleeping when no job is assigned to it, running a job code, or sleeping while waiting for a blocking operation to complete. At any time only the designated maximum number of threads can be running. Other jobs will have to wait until the active jobs terminate or hit a block. In that case the thread looks if there is another job that can continue because its blocking operation completed already, or if there's a free thread that can run another queued job. In any case, the current thread suspends itself afterward, keeping the context of the job's routine.

A blocker can be also an explicit wait operation for completion of other jobs, usually of the children ones that were spawned from the job previously. Consequently it has to prioritize jobs that are likely to progress because all jobs they are waiting for were completed already.

The jobmaster is programmed using lock-free queues and pools to maintain its state.

So far the testing shows this system is much more convenient to use than the previous one, what is probably also its major advantage.

***

Another component worth mentioning is the logger/grapher used to identify performance problems and timing issues in jobs and the main threads. The graphs can be fed from custom timers used to measure time durations or amount of resources. They are resizing dynamically to cover the actual range of values.

Graphs are used to point to the problematic component during a particular activity and as such are mainly complementing the log system, so there are means of identifying the frame numbers that showed some erroneous behavior, that are then used to locate more detailed information in the logs.

Himalayas - unused footage and failed attempts

2010-09-21T08:15:00.002+02:00

As we are currently in the midst of reworking and updating several key components of the engine, which is taking time, I pieced this video from unused footage made for the Himalayas trip video.

Shows mainly the failed attempts to land at Lukla and some other sequences. The problem with Lukla runway is that the engine of that particular Cessna has vastly reduced power at that altitude, and cannot propel itself up the slope. One has to touch down at a higher point, using the momentum to overcome it. Which of course usually didn't work as imagined

The second half contains many attempts at getting the flyover right; we managed to meet at designated point on like 10th try.

The video ends with one preserved recording of how we always rushed back to the starting positions to make another attempt in a row of several needed for each scene.

Himalayas trip

2010-08-18T14:41:00.002+02:00

Finally here comes the video we promised some time ago, with Lukla airport and more.
The video is quite long, over 13 minutes and that's after some heavy trimming.

For those not interested in the flying parts, here's just the last part with Tatra trucks:

Making of video

It consumed three music tracks, and it consists of three main parts as well:
- landing at Lukla, a short fly over and then a take off with mountain scenery views
- approaching and landing at a fictional airport built at the edge of Lesser Himalayas
- driving Tatra truck to a log cabin in woods on a nearby hill

A simple LAN networking was added to make the scenes where two vehicles can be seen moving: two Cessna planes in Lukla, a Cessna flying over the truck in the second part and finally two trucks in the last part.
The network connects up automatically whenever the other machine is reachable. It led to several surprising encounters when we were each just debugging and tuning our code, suddenly seeing the other one go by, like when one was working on the pavements in Lukla and while the other suddenly showed up, training the landing at the airport. It was quite a refreshment during the development.

Otherwise the making of the video resembled real movie making - each scene was taken several times from various angles, capturing two video streams in each run. There was probably 20 times more material taken than used for the final scene. Not counting those shots where we forgot to adjust sun position chosen for given location.

The video shows the current state of engine, and given that it's still in an alpha stage there are some noticeable bugs. Bear in mind that we aren't scenery designers so basically everything you see there is programmers art.

Here are also some images from used locations.

Lukla

Fictional airport & city

Roads & Woods

Woods & Mountains

Used music:
Fresh Air / Airports and Hotels / Great Outdoors by ibaudio.com
Meadow ambient sound by eric5335

Earth Fly-by

2010-08-09T22:43:00.001+02:00

A video of Earth fly-by, with head-up display showing altitude, ground distance, speed, heading and current latitude/longitude.

A collection of screenshots from the development 2

2010-07-20T22:48:00.000+02:00

Another collection of screen shots from the recent development.

Stars rendering was added to make the background more interesting. It uses a real star database of more than 100k stars. It will need some additional effects to make it nicer, like a halo around bright stars etc. There should be also an adaptive HDR to manage the large differences in luminance.

The terrain is quite dark at night even when sky is still lit, it doesn't take secondary scattering into account yet.

Something from another corner - the following image shows fractal blending of two materials and how it looks like from up close and from a distance. A similar approach will be used to blend land classes.

A quick hack of the terrain material system to make it like there is a snow on the mountains. The snow covers the surface if it is flatter than a critical slope, whereas the critical slope depends also on the elevation. This way the transition to lower altitudes looks better, although it still needs some tuning.

At the moment snow doesn't have any thickness, but later a build up of snow will be possible along with temporary tracks behind vehicles.

Last images, showing distant marked peaks and how they are visible against the background, viewed from altitude 7000m (~23,000ft):

The same view from 20,000m (65,617ft):

Cessna in Mountains

2010-07-05T12:29:00.001+02:00

A short video of Cessna flying high over mountains. Angrypig took it somewhere in Lesser Himalayas, mixed in some music, and here's the result.

A collection of screenshots from the development

2010-06-29T11:29:00.000+02:00

Here are some screen shots from the development, that we collected during the past week.

Cab view is working, speed indicator in Tatra works as well. Also the basics of scene editing are there so we could create this small airfield with some hangars and scattered containers. Somewhere in Nepal, I think.

Inside the hangar.

Indicators in Cessna are now working too.

The same cockpit now in the evening.

And a couple of outdoor evening shots ..

Development screen shots and videos

2010-06-19T09:38:00.002+02:00

I have decided to create a forum section where we could post various development screen shots and videos of stuff we are just working on, with only a short description. It should be updated more often. Some of the videos may be occasionally posted here as well.

Here is the link to the development screen shots and videos forum.

Tatra T813 Cab View Video

Dirt Roads

2010-06-09T07:25:00.003+02:00

In the previous post about roads in Outerra I mentioned that different road types can be created by using road profiles. Here comes one example.

Dirt roads are using the very same mechanism as normal roads, in fact the only difference is that road nodes here contain a different road type identifier. That is used to look up the corresponding road profile in shaders that generate the roads, and it determines other things as well - the pavement and border materials, for example.

Road profile specifies "exactness" values across the road width, in range from 0 to 1. Normal roads have value 1 across the whole road width, meaning that the elevation given by the road spline interpolation is exact and the resulting surface will be smooth and level. Values less than 1 will cause that the computed surface elevation is blended with the actual underlying terrain elevation with given blending coefficient. Additionally, the less exact the road surface elevation is, the more it is randomized by fractal to make it rougher.

The roughness created by the fractal noise can vary with the road type. The depth of the furrows can be determined by setting road surface under the terrain by a specific amount, and it can change node by node. On the sample road above it creates deeper or shallower parts. Or even a ridge when the way points are not set densely enough to follow the terrain accurately.

Here is a road that was created from way points lying 0.4m (on average) below the terrain surface with high roughness:

Another one that was put only slightly under the terrain and the roughness is low:

Lastly, few screen shots how it all looks in the terrain.

In order to utilize the generated detail we also set a finer level to be used for vehicle physics. In the previous video with Tatra truck the resolution for physics was around 1.2m, and it was quite visible. In the following video the resolution for physics is around 0.15m, 8 times better. The wheels are simulated as simple ray casts so it may be occasionally visible. Also, Angrypig toyed with the suspension and I left it in for the video; Tatra truck now sways way too much, but at least it serves to show the response to the terrain shape.

Forum topic here.

Integrating Vector Data - Roads

2010-05-25T11:02:00.011+02:00

You may remember an earlier blog about roads where the approach and algorithms for creating spline based roads were outlined. At that time it was just a concept of how it may work, with many unresolved issues.

In the past weeks I occupied myself with integrating the road system into the engine, making it more robust and powerful on the way. The road way points now contain additional information such as road type, width, marking style and more that will allow to make a variety of road types, also including forest roads with ruts, for example.

As you can see on the following screenshots, the roads are completely integrated into the terrain - no terrain poking through the road surface ever. The integration also modifies the surrounding terrain to make the embedment natural. Side of the road is initially smooth up to a specified border width (can be specified per road spline node), and after that the fractal roughness gradually takes on.

Depressions are filled and an embankment is created.

Routing the road through a rock or hill makes rocky slopes with defined steepness on the side(s).

More screenshots showing the creation process and the results, with varying level of detail.

The trees are automatically removed from the road surface and its border area, although sometimes you can see branches hanging over the road.

Splines allow for some mad road shapes but it still fits into the terrain :)

Terrain under the road is initially roughly prepared - gaps are filled and excess volume is cut out. This is being done at tile with resolution ~10m, so that fractal algorithm can refine it down naturally. Previously, when the road cut into a hill, the cut was unnaturally smooth. Now only the road border is smooth, gradually transitioning into a rougher fractal structure.

In the following screenshots you can see the process documented:

I. Placing the waypoints - this is currently being done as you move over the terrain pressing a build-road key, later a built-in editor will allow for better editing modes and options.

II. Rough terrain treatment - note this is actually hidden within the process, I've visualized it here just to show what effect it has on the terrain.

III. Finalizing the road

The engine has no problems with terrain resolution (as is apparently the case with many planetary engines), to the extent that asphalt can have actual thickness - I think it's 3cm now (~1.2inch).

Other notable features are

vector data are automatically partitioned and indexed in quad-tree managing the terrain
overlay dirt textures per road type
roads can connect, additional helper code will be needed to adjust the spline points and their attributes so that the connection is smoother
the same system is also used for terrain leveling, with or without pavement placing or with gravel surface etc.

Finally the process can be seen on the YouTube video. Original uploaded video was 500MB with good quality, but the recompression step on YouTube reduced it considerably.

The same system is used also for runways, here's a teaser screenshot for upcoming video where Angrypig tries to properly land at .. you can guess where this is from :-)

The corresponding discussion topic on Outerra Forums can be found here
See also the dirt roads

In-Game HD Video Capture using Real-Time YUYV-DXT Compression

2010-03-28T16:40:00.003+02:00

This article describes a method of recording in-game HD videos without the large impact on frame rate as with an external video capture software.

The method used in this approach was inspired by an article about Real-Time YCoCg-DXT Compression which presented a real-time GPU compression algorithm to DXT formats.
Standard DXT texture formats aren't very suitable for compression of general images like the game frames, the higher contrast results in artifacts like color bleeding and color blocking. The article introduced YCoCg-DXT format that encodes colors to YCoCg color space (intensity and orange and green chrominance). It also contains the source code for real-time GPU compression and comparison of achieved results.

The YCoCg format is suitable for decompression on GPU, because decoding YCoCg values back to RGB only takes a few shader instructions. However, for the purpose of decoding the frame data in a video codec, a better format is a YUV-based one that allows to decode the data directly to the video surface without additional conversions. The best format for this seemed to be YUYV with 16 bits per sample, which means there's one U and V value per 2 horizontal samples.
The compression algorithm differs from the YCoCg-DXT one in the initial color space conversion to YUYV and in that it encodes 4x4 YY, U and V blocks in the way alpha component is encoded in DXT5 format.

The algorithm is as follows:

Video frames are compressed with fragment shader to YUYV-DXT format by render to texture technique, reducing the data to 1/3 of its original size
The compressed textures are asynchronously read back to CPU
The data are continuously written to disk

The compression on GPU reduces the bandwidth needed between CPU and GPU, but more importantly also the bandwidth needed for disk writes. Sustainable write speed of a SATA drives is somewhere around 55MB/s, transferring a raw 1280x720/30fps video takes 79.1MB/s, while the DXT compressed video only takes 26.4MB/s. A Full-HD video stream is 59.3MB/s.

To capture the frame buffer data the application first renders to an intermediate target. The compression shader uses this as the input texture, rendering to a uint4 target with one quarter width and height of the original resolution, that is then read back to CPU memory.

The next step is decoding the captured video. To make this easy I've written a custom video codec and video format plugin for ffmpeg library. The format was named Yog (from YCoCg) as the encoding was originally in YCoCg format, changed only later to YUYV.
The game produces *.yog video files that can be directly replayed by ffplay or converted to another video format with the ffmpeg utility. They are also recognized by any video processing software that uses ffmpeg or ffplay executables or uses the avcodec and avformat dlls from the suite, such as WinFF or FFe or many others.

Results

After starting the video recording in our game the frame rate drops only by a few fps, and it's still playable normally, unlike when recording for example with Fraps. Disadvantage is that this has to be integrated into the renderer path.
Quality wise the results are quite good, as it can be seen on the following screen shots:

Original

YUYV compressed, note this is slightly lighter because of an issue in ffmpeg that has to be solved yet.

The difference, 4X amplified

The source code and further implementation details can be found at outerra.com/video/index.html

Tatra T813 Video

2010-02-09T08:59:00.000+01:00

Previous video with Cessna test flight apparently made some good (for most) waves in the flight sim scene. Here comes another video, this time with the Tatra T813 truck, focused on its independent swing suspension exercising on bumpy slopes somewhere in High Tatras mountains (it's not a coincidence, the truck got its name after the mountain range).

Suspension limits and parameters were set only approximately so the behavior may not be precise. But it's normal that an unloaded Tatra truck has its hind wheels in V shape.
Also the dynamically refined terrain has a higher resolution than the mesh used for physics, that may be slightly visible in closeups.

As a technical note, both videos were captured using GPU-based compression of video frames to reduce the bandwidth needed for sustained disk writes, while not imposing a noticeable performance penalty. Since the video frames are being compressed on GPU, GPU->CPU transfers are also smaller what is a good thing as well.
I also made a custom video codec for ffmpeg that can decode these videos so one can recompress the video directly with ffmpeg or any other tool that uses the libavcodec dll. There will be a separate blog entry with more technical description and the code to be usable for others.

Cessna Test Flight

2010-02-05T10:19:00.001+01:00

Angrypig finally managed to implement collision detection for JSBSim planes along with the joystick support, so we created a short test flight video with Cessna plane.

Here it comes.

Outerra Engine Progress

2010-01-27T19:44:00.002+01:00

It's been some time since I blogged about the Outerra engine, so here comes the latest info about what we've been doing.

Lots of stuff has been done on the visuals - shadows are finally in, and even though they are not finished yet the output is much nicer with them. It uses a randomized lookup into the shadow map but the blurring pass is not present yet, so the closeups show noisy shadow edges. This will go away with the blurring pass on the shadow map.

The ugly patterns on the ground visible in older screen shots, resulting from tiled textures have been suppressed by more fractal magic - a free fractal channel has been used to mix three textures (daisies, grass and a lighter grass) together and the pattern is almost completely gone.

Another thing that helped a lot was the color transformation to linear space. This included both the input (loading the textures in sRGB format and also correctly computing the mipmaps) and setting the render target. The fix is most obvious on the atmosphere that now looks more natural.

The trees are also slightly randomly colorized to break the monotonicity.

The material system has progressed as well, as it can be seen on the new truck model here.

Also new is the support for dirty windows.

A gun is mounted on the roof, with a separate controller. It should be also functional soon, along with some flying prey to ground

The new model appearing in the shots is the Tatra T813 8x8 heavy all-terrain truck with unique independent swing half axles. I wrote specialized code to handle its physics, and it works quite nicely. It is much better visible in motion, a video will be coming soon.

Floating Point Depth Buffer

2009-12-31T11:08:00.002+01:00

I had always thought that using a floating point depth buffer on modern hardware would solve all the depth buffer problems, in a similar way than the logarithmic depth buffer but without requiring any changes in the shader code, and having no artifacts and potential performance losses in their workarounds. So I was quite surprised when swiftcoder mentioned in this thread that he had found that the floating point depth buffer had insufficient resolution for a planetary renderer.

The value that gets written into the Z-buffer is value of z/w after projection, and it has an unfortunate shape that gives enormous precision to a very narrow part close to the near plane. In fact, almost half of the possible values lie within two times the distance of the near plane. In the picture below it's the red "curve". The logarithmic distribution (blue curve), on the other hand, is optimal with regards to object sizes that can be visible at given distance.

Floating point depth buffer should be able to handle the original z/w curve because the exponent part corresponds to the logarithm of the number.

However, here's the catch. Depth buffer values converge towards value of 1.0, or in fact most of the depth range gives values very close to it. The resolution of floating point around 1.0 is entirely given by the mantissa, and it's approximately 1e-7. That is not enough for planetary rendering, given the ugly shape of z/w.

However, the solution is quite easy. Swapping the values of far and near plane and changing the depth function to "greater" inverts the z/w shape so that it iterates towards zero with rising distance, where there is a plenty of resolution in the floating point.

I've also found an earlier post by Humus where he says the same thing, and also gives more insight into the old W-buffers and various Z-buffer properties and optimizations.

Update

I tried to compute the depth resolution of various Z-buffers for whole range from 0 to 10,000 kilometers. Here's the result (if I didn't make a mistake), showing the resolution at given distance (lower is better):

The red curve shows resolution of the logarithmic Z-buffer. It scales linearly with distance, what means that in the screen space it's constant. That's also an ideal behavior.

The blue curve shows the resolution of 32 bit floating point depth buffer with swapped far and near plane. The spikes are formed with each decrement of the exponent. Floating point depth buffer has worse resolution than the logarithmic one, but it should be still sufficient. The green line is for an ideal Z-buffer that has depth resolution of 0.12 millimeters at one kilometer. It also happens to be the worst case bound for the floating point depth buffer.

Early vehicle physics test

2009-12-10T09:06:00.000+01:00

First test of vehicle physics in the engine. Camera isn't yet attached to the vehicle so I had to chase it, without much success I admit
Also it's really easy to lose sight of the truck in the big world.

Collada Importer

2009-11-26T12:00:00.000+01:00

Angrypig managed to get Collada importer into beta stage, so here are some first screens with new Cessna model and Gaz 66 truck. Too bad neither AO nor shadows are ready yet, the screens would be much nicer with it.

Cessna cockpit has quite a high resolution; the indicators should become alive soon.

Views from the outside. Propeller is already turning, but there's no motion blur on it yet. Transparency works too but there's a bug in the model. The windows ask for bit of dirt here and there, too.

Approximately 3,900 feet above the ground.

Mount Etna in the background.

Gaz 66 truck ..

.. and a fleet of them.

Horizontal displacement

2009-11-12T09:40:00.002+01:00

Recently I've been working on the code that computes fractal data - a bit of reorganization to be able to have more independent fractal channels that are used everywhere in the engine, as I was running short of them already. Previously we had one channel where the terrain elevation fractal was computed, another channel with low-pass filtered terrain slope and 2 independent fractal channels. After the redesign we have 4 independent fractal channels, but additionally the filtered slope is computed independently for u,v terrain directions.

The two-dimensional slope values allow for better horizontal displacement effect on the generated terrain, because now it's possible to make the rock bulge from the hill slope in the right direction. In the previous version only the absolute slope value was known, and the fractals extruded the mesh independently in two orthogonal directions, and of course that did not always look good.

The equation for the displacement was in addition parametrized, to be able to get more effects out of it. Currently it's possible to vary the dominant wavelength, bias and amplitude of the used fractal.

Here is a quick comparison of what the parameters do.

Bias +0.5 (bulging outwards from the slope), wavelength 19m

Wavelength 38m

Wavelength 76m

In the last screenshot the fractal used for the displacement is already only slightly visible and the bulbous shape of purely slope-dependent displacement shows up.
Here's how the displacement looks like when the bias is even larger, i.e. when the sloped parts are pushed even more outwards (bias +1.5):

It's also possible to use a negative bias values, that make the sloped parts carved into the hill (bias -1.0):

On the other hand, amplitude boost can emphasize the effect of the fractal, creating more visible overhangs here and there:

For comparison, here's how the same terrain looks like without any horizontal fractal effect at all:

... and without the vertical fractal, only a bicubic subdivision of original 76m terrain grid:

Next thing to try could be using a texture containing rough shape of specific type of erosion one would like to achieve. Current technique still cannot generate proper cliff and canyon walls, but combining it with the shape map lookup should theoretically do the job.

There's also an interactive comparison

Web Site Update

2009-10-02T18:43:00.004+02:00

Some time ago I had an idea to make the web site with white background. That idea was inspired by a bug in early atmosphere rendering that made Earth as if submerged in watery milk. I remembered it and managed to reproduce the bug in RenderMonkey, tuned it and here's how it looks:

The whole new look built around that idea can be seen here: outerra.com

Chromium & Google Maps

2009-09-02T10:12:00.001+02:00

Another short video showing the embedded Chromium browser and Google Maps that is synchronized to engine camera.

Short flight sim video

2009-08-31T13:50:00.002+02:00

It's been one year since we released the first videos from Outerra engine. So it's about time to release another short one featuring a lifeless Jalapeno and a pilotless Cessna plane with broken propeller

Flight sim?

2009-08-17T08:45:00.003+02:00

Two guys I'm working with on the engine, Laco 'angrypig' Hrabcak and Tomas 'jonsky' Mihalovic have some time ago worked on FNPT II MCC trainer with Boeing 737-800 cockpit replica (Laco has got some photos in his history page)
They are still being quite drawn to simulators, so when we got positive reception from flight sim community with the engine we decided to lean the development slightly more that way.

Recently, Laco got preliminary Collada loader working, loading a Cessna model. He is also incorporating JSBSim Flight Dynamics Model library into the engine, while Tomas works on the cockpit.

Here are some first screens.

Here are some screens with (now featureless) cockpit, recent Z-buffer development allows to handle the cockpit and terrain without problems.

A look below while grounded.

And some screens from outside.

Logarithmic Depth Buffer

2009-08-12T17:33:00.016+02:00

I assume pretty much every 3D programmer runs into Z-buffer issues sooner or later. Especially when doing planetary rendering; the distant stuff can be a thousand kilometers away but you still would like to see fine details right in front of the camera.

Previously I have dealt with the problem by splitting the depth range in two and using the first part for near stuff and another for distant stuff. The boundary was floating, somewhere around 5km - quad-tree tiles up to certain level were using the distant part, and the more detailed tiles that by law of LOD are occurring nearer the camera used the other part.
Most of the time this worked. But in one case it failed miserably - when a more detailed tile appeared behind a less detailed one.
I was thinking about the ways to fix it, grumbling why we can't have a Z-buffer with better distribution, when it occurred to me that maybe we can.

Steve Baker's document explains common problems with Z-buffer. In short, the depth values are proportional to the reciprocal of Z. This gives amounts of precision near the camera but little off in the distance. Common method is then to move your near clip plane further away, which helps but also brings its own problems, mainly that .. the near clip plane is too far

A much better Z-value distribution is a logarithmic one. It also plays nicely with LOD used in large scale terrain rendering.
Using the following equation to modify depth value after it's been transformed by the projection matrix:

    z = log(C*z + 1) / log(C*Far + 1) * w      //DirectX with depth range 0..1

or

    z = (2*log(C*z + 1) / log(C*Far + 1) - 1) * w   //OpenGL, depth range -1..1

Where C is constant that determines the resolution near the camera, and the multiplication by w undoes in advance the implicit division by w later in the pipeline.
Resolution at distance x, for given C and n bits of Z-buffer resolution can be computed as

    Res = log(C*Far + 1) / ((2^n - 1) * C/(C*x+1))

So for example for a far plane at 10,000 km and 24-bit Z-buffer this gives the following resolutions:

            1m      10m     100m    1km     10km    100km   1Mm     10Mm
------------------------------------------------------------------------
C=1         1.9e-6  1.1e-5  9.7e-5  0.001   0.01    0.096   0.96    9.6     [m]
C=0.001     0.0005  0.0005  0.0006  0.001   0.006   0.055   0.549   5.49    [m]

Along with the better utilization of z-value space it also (almost) gets us rid of the near clip plane.

And here comes the result.

Looking into the nose while keeping eye on distant mountains ..

10 thousand kilometers, no near Z clipping and no Z-fighting! HOORAY!

More details

The C basically changes the resolution near the camera; I used C=1 for the screenshots, having theoretical resolution 1.9e-6m. However, the resolution near the camera cannot be utilized fully as long as the geometry isn't finely tessellated too, because the depth is interpolated linearly and not logarithmically. On models such as the guy on the screenshots it is perfectly fine to put camera on his nose, but with models with long stripes with vertices few meters apart the bugs from the interpolation can be visible. We will be dealing with it by requiring certain minimum tessellation.

Also I think I've read somewhere that some forthcoming generation of hardware will support different modes of interpolation too.

So yes, modifying C changes the resolution near the camera, setting it to a value that gives the largest acceptable resolution may be desirable to achieve more linear distribution in the near range and thus minimizing the interpolation problem.

Near clip plane can be put arbitrarily 'near' but not zero because of the 1/w division. I have put it to 0.0001m. This is using standard perspective projection setup.

Negative Z artifact fix

Ysaneya suggested a fix for the artifacts occurring with thin or huge triangles when Z goes behind the camera, by writing the correct Z-value at the pixel shader level. This disables fast-Z mode but he found the performance hit to be negligible.

See also: floating point depth buffer

Roads

2009-06-25T15:46:00.006+02:00

Added support for vector data which is currently used for simple roads, later it will be used also for rivers and similar stuff.
The points are interpolated using Catmull-Rom spline, and the generated path is baked into tile's material map with specific artifical material. Tile height map is modified too by setting the elevation from the path but gradually blending the borders to terrain.
The roads can also be slanted.

The actual algorithm runs in shader, finding the distance to spline from each point and outputs a blending coefficient and elevation. Asphalt material id is generated where the coefficient is one, otherwise only the height map is modified by blending.
Once the map is created it incurs no additional performance penalty - it's just another set of materials used.

While the algorithm can also generate the road surface markings as specific materials, the resolution of the material map for the tile isn't sufficient for such highly contrasting stuff. This will have to be drawn separately as an overlay on the tile, possibly using the same algorithm but when drawing to the screen.

The algorithm

I'm drawing quads with road segments into an intermediate texture that contains elevation (as interpolated by the spline) and blending coefficient which is 1 for road surface and slowly falling to 0 on road borders.
To get the distance to spline for particular pixel I had to transform world coordinates to road segment's lengthwise and crosswise coordinates.

The final solution got somewhat more complicated, though.

Since the linear interpolation on quads is ambiguous, I had to treat the segment as a bilinear surface and compute the inverse of it so as to get these lengthwise/crosswise coordinates. See http://stackoverflow.com/questions/808441/inverse-bilinear-interpolation for explanation.

But as it turned out this wasn't sufficient enough, because of course the spline road segment isn't a bilinear surface. It led to roads that narrowed in sharper turns or disappeared.
Actual road segment surface equation could be:

    p = q(s) + t*n(s)

where q(s) is the spline equation, n(s) is 2D normal to the spline, s is the lengthwise coordinate and finally t is the crosswise coordinate. However, this would lead to solving 5th degree polynomial and one would have to pick the correct root too ...

But ultimately I used this equation to take one step of Newton-Raphson approximation, seeding it with value of s computed by the inverse bilinear transform. The approximation converges rapidly so one step was enough.
The equation for one step of Newton-Raphson is:

    s1 = s0 - f(s0)/f'(s0)

with

    f(s) = (px - qx(s)) * qx'(s) + (py - qy(s)) * qy'(s)
  f'(s) = (px - qx(s)) * qx"(s) - qx'(s) * qx'(s)
        + (py - qy(s)) * qy"(s) - qy'(s) * qy'(s)

So you need the first and second derivative of the spline equation to compute it.

Horizontal displacement

2009-05-29T11:44:00.005+02:00

As always I do not keep strictly to the plan, and decided to try one of things I wanted to do someday - horizontal displacement of terrain.

The fractal map computed for quadtree node already contains 3 independent fractal noise channels. The first one computes elevation and is seeded from heightmap data. Other two are used for detail material mixing and other things. There is also a fourth channel containing global slope.
I modified the shader that computes vertex positions to displace also in horizontal directions, using one of the two independent fractal channels. Amount of displacement also varies with global slope - areas in flat regions are shifted minimally, but sloped parts that are also treated as rock are displaced a lot. This makes rocky parts much more interesting. For the record, the actual equation used for displacing point on a sphere in tangent space is this:

Next thing that had to be done was to compute the normals of such deformed surface. Article in GPU Gems about deformers provides nice info about Jacobian matrix that can be used for the job. After some pounding to my math circuits I managed to produce the following Jacobian of the above equation (in tangent space):

Normal is then computed as cross product between the second and third column, since the tangent and binormal are {0,1,0} and {0,0,1} respectively.

Finally, here is the result - left side original with only the vertical displacement, on the right side vertical&horizontal displacement:

There are still some issues but the overall effect is quite nice. Of course, collisions with sloped parts are no longer accurate and I'll have to do something with it later.

Outerra planetary engine

Progressive download

2009-05-22T17:54:00.003+02:00

Complete dataset for Earth with 76m sampling is 192GB, after wavelet compression it is roughly 14GB. That is still too much for direct download, and it will be even slightly larger after more detailed data are used for some parts at higher latitudes that are currently only coarsely defined. Possible solution could be to use a coarser sampling, but this rapidly washes out nice terrain features that the fractal cannot supersede easily.
Fortunately it seems we will be able to use the 76m dataset since progressive download works quite nicely.
Wavelet compression of elevation data helps here because it not only nicely compresses the data but perhaps more significantly it arranges the data in layers by level of detail. Particular level of detail for quad-tree nodes can be then downloaded when needed.

Results are that landing on the ground in a mountainous area (where the data are largest) requires around 30-40MB of compressed data to be downloaded progressively and cached. Further data (3-8MB) are needed again only after traveling some 300km from the spot. So it seems that even camera following a cruise missile can be handled too, though possibly it could skip the most detailed data at that speed anyway.

Lastly, the downloader uses libtorrent library so the data can be downloaded using p2p, initially from http seed.

Using finer sampling manifests itself mainly in mountainous areas where high frequency features occur most.
Here's comparison of High Tatras as rendered by the engine and by the nature.

Currently we are working on material mixer that will allow us to assign different materials to different climatic bands, so the peaks here will not be covered by grass and mountain pine will grow at higher elevations too.

Outerra planetary engine

chromium

2009-03-06T08:28:00.002+01:00

Angrypig experimented with chromium code and ultimately managed to integrate the browser into our engine. Works fairly well, with mouse and keyboard too. It's still just a prototype, though; the integration with the engine will be reworked and optimized for example to have to update only the changed parts in the web page and to make the whole thing asynchronous.

Also, we are going to hook into V8 engine to handle javascript events in Google Maps, so that the camera moves to the selected location in the maps, and vice versa.

Outerra planetary engine

Procedural terrain algorithm visualization

2009-02-26T06:32:00.002+01:00

When I tried to visualize resolution of elevation dataset we are currently using, it occurred to me it would be a good idea to visualize also the various steps and enhancements to the procedural refinement algorithm. These more or less show also how the algorithm evolved.

First, the terrain rendered with bilinear subdivision just to show the resolution of elevation data. We currently use ~150m dataset for whole Earth. All detail below 150m is generated procedurally.
To have a completely procedural planet, another algorithm would generate rough map with continental plates and mountain ranges, that will be then used as the basis for further procedural refinement.

The same terrain now with bicubic subdivision of tiles producing molten ice cream hills. The terrain is textured mostly according to the slope, with slight perturbation with another fractal.

Adding homogeneous wavelet noise to the bicubically subdivided terrain. Doesn't look right, though - no erosion except for the glacial one, that is visible even in the original data.
Shows symptoms of simple fractal terrains - different parts look similar.

To fix the erosion, the amplitude of noise is modulated by slope - flat areas have less noise, while the steeper get more.
This starts to get right, at least for the valleys, but the slopes are still too monotonous.

The idea for the next step is that anything below the angle of repose is subject to excessive sediment deposition, and is then more even and less noisy.
This creates larger continuous grass surfaces on moderate slopes, with rocks here and there.

One problem with slope-dependent noise is that the mountaintops tend to be smooth because the slope is low there.
The subdivision also distributes the flatness to wider area.
The solution is to make the amplitude of noise rise with positive values of curvature too, depending also on elevation.

Also an interactive comparison here.

Playing with detail texturing

2009-01-29T23:25:00.001+01:00

Playing with detail texturing.

First creating detail material map for each tile, computed from terrain data - elevation, slope and curvature, using two additional fractal channels for mixing.
The algorithm first computes slope, if it's steeper than some defined angle of repose it's considered to be a rock.
I'm not using slope directly here though - a positive (convex) curvature is used to boost the slope slightly to make rocks more protruding at the top.

Gradual slopes and flat parts can use one of three textures. The mixing is done using one fractal channel. The first texture is default, the two other textures have some coherent probability of occurrence, that is additionally altered so they are more likely to occur on gradual slopes (dryer grass) or flat parts, respectively.

Yet another fractal channel is used for coloring - slight modification of texture colors to break the monotonous pattern on large flat areas.

The textures didn't come from an artist so all the patterns are my fault.
Also, due to this bug I can't have anisotropic filtering on atlas textures yet.

vimeo

2008-12-03T05:55:00.000+01:00

We tried Vimeo's HD videos and the result is here, with music giving it somewhat different mood

Only afterwards I noticed that the function computing the tree distribution stopped working correctly after some variables (namely the local terrain curvature) changed in magnitude as they are computed slightly differently. So the trees now grow on much steeper slopes than they should. I won't deal with it now, it has to be reworked into a generic vegetation placement module anyway, when climate info becomes available.

Just now I have to optimize tile manager and generator because it not very efficiently handles GPU memory.

Flying above forest

2008-11-22T06:24:00.000+01:00

Managed to finish some other tasks before the shadows and detail ground textures.

First was placing objects on terrain, with persistence to cache. Later the local cache will be synced with a server, which will be also used to retrieve objects existing anywhere in the world, placed there by other users. We plan a multiplayer demo where users could build their own cities or settlements, and also visit other people scattered on Earth. Still a long way there, though.

Also modified tree rendering so that the boundaries between trees and more distant areas where trees are rendered as solid color are almost invisible. There is a better tree model used too. Now I should focus on the ground texture generation because its the ugliest part there.

Here is video with the new stuff:

Collisions - terrain vs. Jose

2008-11-07T07:41:00.000+01:00

I am now reading the generated terrain tile data back from GPU and doing basic collision testing (ray vs. terrain). We test it with one model of man we call Jose Jalapeno, because of the lacking animation.

The yellow lines that are visible somewhere mark the boundaries of the tile where Jose currently resides - without this we cannot possibly find him in the world, ever.

We are currently working also on several other things too:

Finally adding the shadows. We waited with these until quad-tree traversal would be right

Detailed ground textures, selected by several parameters: climate, bedrock or soil type, terrain slope and curvature etc.

Elevation datasets with better detail - 30m resolution for many mountain ranges, along with additional datasets for whole world with climate data. These will be used to select the ground material sets and to condition various other subsystems, like vegetation probabilities or modification of fractal algorithm parameters by bedrock type or other local terrain attributes.

xnview plugin

2008-10-20T00:17:00.001+02:00

We created XnView plugin for viewing terrain elevation maps (raw or srtm files) to help us visualize input heightfield data in any combination of format (8-, 16- or 32-bit depth, signed or unsigned, integer or floating point, endianness etc.).

The plugin also autodetects image dimensions by computing row correlation coefficient for all possible image dimensions (i.e. the dimensions that give the correct file size for specified image options)

Find it here.

Tree placement

2008-08-29T23:13:00.000+02:00

In addition to the elevations that are read from wavelet-compressed dataset and then refined by fractal algorithm, the engine computes 3 other fractal channels in parallel. These contain 'normal' fractals that will be used as source for coherent random values for various engine parts.

First of these channels was used to enhance the tree placement algorithm. The algorithm in fragment shader first computes the probability of tree being there, according to elevation, slope and terrain curvature. If the actual tree occurrence is determined by comparing the probability against a fixed threshold, it results in large continuous forest areas. The fractal channel provides threshold value that changes continuously and modifies the probability threshold, that results in clearings and woods, but an occasional lonely tree too.

Here is a short video, flying from somewhere in Europe to Africa:

An earlier video without the trees, where angrypig madly flies and turns around

Atmospheric scattering

2008-08-22T09:37:00.001+02:00

I've implemented atmospheric scattering as described by Sean O'Neil, with some modifications and endless tweaking. I'm still not quite satisfied, though, but I'll return to it later.

Meanwhile the other two lethargic programmers are presently awakened too.
Angrypig is working on tree generator that will produce all levels of detail needed for tree&forest rendering, from detailed models through continuously simplified and increasingly unified models down to billboards.

Jonsky is modifying the toolchain used to process heightfield maps for the engine (currently used to process earth's elevation data - remapping and wavelet compression). This can be then used to create custom planets; in fact he is currently testing it with the heightfield map of Tolkien's Middle-earth. When we release a demo you will be able to fly over that fantasy planet, or land in Mordor

So if people are interested, we could release some flyable demo sometime in the near future, with the possibility to define your own world using the heightfield map patches, specifying elevations in some rougher resolution. Fractal algorithm computes the details, vegetation is placed by algorithm taking terrain properties into account. One thing still missing are the climatic maps so we could generate deserts and steppes and so on; but this one still requires some thinking.

Lots of trees

2008-08-03T07:34:00.000+02:00

We've added some simple, crude billboard trees into the terrain. These are generated in fragment shader after the tile elevation map is computed. There can be one tree in roughly each 2x2 meter square; whether there actually is one is determined by an ecotype probability equation that takes into account elevation, slope and curvature of the terrain. There's currently just a testing one, producing a single type of tree. Everything is computed in shaders, billboards are created using render-to-vbo technique.

Now there are more than 500 000 trees rendered as billboards, but the furthermost ones are just a pixel high. Even more distant tiles, that have texels covering larger area than 2x2 meters have the trees just baked in as colors (in a marketing-speak it would read as hundreds of millions trees rendered, but if you get to that parts you'd really see the trees there, so .. ). I shall use a different approach for the far billboards though - the frame rate dropped considerably, from 350-600 to about 60-100 with the trees (on 8800GT), and it chokes ati x1600 mobility on my nb to ~12 fps.

Nevertheless the trees nicely show the scale of the world and the ranges of detail that is generated by the fractal algorithm.

Replying to the comments in the previous entry - we should soon produce some videos too. That is, if the other two lethargic programmers here manage to create something during my one week offline vacation (going to forests ~~to observe tree distribution patterns~~ ~~to think about optimizing the forest rendering~~ .. to rest )

Intro

2008-07-31T08:14:00.000+02:00

Hi everybody.
I'd like to introduce our project - a planetary engine.

Features:

Planetary engine that can be used with an elevation dataset, enhancing its resolution using fractal algorithms. Resolution of the elevation data is arbitrary, fractal algorithms further refine the detail down to under-foot resolution. It's possible to have a completely random fractal terrain too, or to sketch the terrain in rough resolution and have the fractal to generate the details.

Level of detail ranging from thousands of kilometers down to centimeters.

Currently working with earth elevation data (3arc sec dataset remapped to cube faces with roughly 150m resolution).

Elevation data are packed using a modifed wavelet compression, the required level of detail can be extracted effectively on the fly. Decompression done on GPU.

Finer resolution tiles are generated by fractal algorithm entirely on the GPU.

Textures are generated on the GPU from the fractal data using per-pixel computed elevation, slope and terrain curvature; later a material mapper would also utilize climatic data, bedrock maps etc. to more accurately texture the world.

Fully asynchronous engine using OpenGL, majority of the algorithms running on the GPU

There are many things to do, though - the material mapper, detail textures, atmospheric model, rendering rivers and water bodies, vegetation etc.

Now some pixel food.

Approaching earth. Until we implement the atmosphere, space is full of air :-)

Heading towards High Tatras in central europe.

Fractal refinement starts to show up. Original elevation data have resolution ~152 meters.

That rock over there ..

.. is roughly 4 meters wide, completely fractal generated.