Brano Kemen
a.k.a. cameni
outerra.com
| Tuesday, February 9, 2010 |
  Tatra T813 Video | 
Posted - 2/9/2010 2:54:56 AM | 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 | |
Posted - 2/5/2010 3:57:14 AM | 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.
| |
| Wednesday, January 27, 2010 |
| Outerra Engine Progress | |
Posted - 1/27/2010 11:53:22 AM | 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 glass 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.
| |
| Thursday, December 31, 2009 |
| Floating point depth buffers | |
Posted - 12/31/2009 4:45:32 AM | 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 the 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.
| |
| Thursday, December 10, 2009 |
| Early vehicle physics test | |
Posted - 12/10/2009 12:59:33 AM | 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.
Click on the image below to see the video of Gaz-66 truck skidding down the bumpy slopes.
| |
| Thursday, November 26, 2009 |
| Collada Importer | |
Posted - 11/26/2009 5:39:52 AM | 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.
| |
| Wednesday, November 11, 2009 |
| Horizontal displacement 2 | |
Posted - 11/11/2009 5:48:59 PM | 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
| |
|
| S | M | T | W | T | F | S | | 1 | 2 | 3 | 4 | | 6 | 7 | 8 | | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | | | | | | |
OPTIONS
Track this Journal
ARCHIVES
February, 2010
January, 2010
December, 2009
November, 2009
October, 2009
September, 2009
August, 2009
June, 2009
May, 2009
March, 2009
February, 2009
January, 2009
December, 2008
November, 2008
October, 2008
August, 2008
July, 2008
|
