Outerra Year 2010 Retrospective

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

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

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

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

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

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

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

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

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

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

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

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

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

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.