Unigine crew

Valley demo preview

2011-10-12T21:44:00.002+07:00

Work in progress, upcoming demo of Unigine engine:

Unigine crew links

2011-09-09T19:14:00.004+07:00

We are still unsure regarding the format of this blog, so you can track some stuff regarding Unigine crew in the following places for now:

Frustum (Alexander Zaprjagaev, CTO and lead developer of Unigine engine): Twitter (zero traffic, sorry - he is busy coding day and night)

Binstream (Denis Shergin, CEO): Twitter (Unigine projects, linux geekness, some management stuff), LiveJournal (in Russian), Facebook

Unigine Engine: Twitter, Facebook, Development log

Oil Rush (our upcoming naval strategy game): Twitter, Facebook, Forum

PS: by the way, check out our new shiny website: unigine.com

Global illumination II

2011-01-03T18:35:00.003+06:00

The previous post about Global Illumination demonstrated a modification of real-time screen space ambient occlusion (SSDO) algorithm. This is a good post-processing effect for modern and powerful hardware. We use this approach in the new version of Heaven benchmark, which will be released soon. But low-level hardware still requires lightmaps...

I have improved lightmap rendering in Unigine by using directional lightmaps. They can be easily calculated by the engine render pipeline (simple ray tracing). Unfortunately the result of directional lightmaps without environment or indirect lighting looks ugly. So I created a tool for indirect lighting calculation. Our approach is very simple: we use built-in LightProb (light source based on spherical harmonics) facilities to grab environment lighting:
* we generate a heap of LightProb objects all across the scene
* each LightProb grabs nearby lighting info
* indirect component from LightProbs is combined with direct one from ray tracing into the lightmap textures

Performance of such global illumination solver is awesome. Calculation time for the shown scene (based on the old "Site" Unigine demo) is only 2-3 minutes on dual core PC. GPU power is also utilised during LightProb generation.

Dynamic forward lights:

Backed lightmaps with direct term:

Backed lightmaps with direct and indirect terms:

Backed lightmaps with indirect term:

Continuous Integration

2010-11-23T20:11:00.002+06:00

We use TeamCity as a continuous integration server to build different configurations of Unigine engine, tools, SDKs and so on. We also use Trac as an issue tracker. The problem was lack of their native integration, but it's solved: Max wrote a TeamcityIntegration plugin, feel free to use it.

BTW, it takes about 5 minutes to make full rebuild of Unigine (engine+tools, both release and debug) on a Linux build node, while the Windows one (which has more powerful hardware) spends 12+ minutes for the same build type. So ccache rules, we do miss it for Visual Studio.

Global illumination

2010-10-21T11:17:00.002+07:00

Vegetation animation

2010-09-30T14:16:00.002+07:00

CUDA vs OpenCL vs SPU Part IV

2010-09-17T16:54:00.005+07:00

Finally I've got radix sort implementation which is working on AMD OpenCL. This is a link on previous sorting algorithms test. And now we have new more interesting results :) Time of GPU sorting includes time of data downloading from video memory. Sorted structure is single uint2 array for bitonic sort, and two int arrays for radix sort.

Elements 64768:

CUDA:

GeForce 9600GT:
CUBitonic Time: 0.007 FPS: 140.5679 Mem: 69.46 Mb/s
CURadix Time: 0.003 FPS: 342.8180 Mem: 169.40 Mb/s

GeForce GTX 260:
CUBitonic Time: 0.002 FPS: 403.5513 Mem: 199.41 Mb/s
CURadix Time: 0.001 FPS: 752.4454 Mem: 371.81 Mb/s

GeForce GTX 480:
CUBitonic Time: 0.001 FPS: 966.1836 Mem: 477.43 Mb/s
CURadix Time: 0.001 FPS: 1398.6014 Mem: 691.11 Mb/s

OpenCL:

GeForce 9600GT:
CLBitonic Time: 0.008 FPS: 126.9519 Mem: 62.73 Mb/s
CLRadix Time: 0.004 FPS: 252.9724 Mem: 125.00 Mb/s

GeForce GTX 260:
CLBitonic Time: 0.004 FPS: 266.7378 Mem: 131.81 Mb/s
CLRadix Time: 0.003 FPS: 368.3241 Mem: 182.00 Mb/s

GeForce GTX 480:
CLBitonic Time: 0.002 FPS: 579.3743 Mem: 286.29 Mb/s
CLRadix Time: 0.002 FPS: 614.2506 Mem: 303.53 Mb/s

Radeon HD5870:
CLRadix Time: 0.003 FPS: 372.9952 Mem: 184.31 Mb/s

Single SPU:

quickSort SPU Time: 0.031 FPS: 32.5298 Mem: 32.15 Mb/s
radixSort SPU Time: 0.004 FPS: 226.9632 Mem: 224.30 Mb/s

Elements 1036288:

CUDA:

GeForce 9600GT:
CURadix Time: 0.036 FPS: 27.8808 Mem: 220.43 Mb/s

GeForce GTX 260:
CURadix Time: 0.013 FPS: 74.1400 Mem: 586.17 Mb/s

GeForce GTX 480:
CURadix Time: 0.006 FPS: 161.9958 Mem: 1280.78 Mb/s

OpenCL:

GeForce 9600GT:
CLRadix Time: 0.034 FPS: 29.8312 Mem: 235.85 Mb/s

GeForce GTX 260:
CLRadix Time: 0.013 FPS: 79.2959 Mem: 626.93 Mb/s

GeForce GTX 480:
CLRadix Time: 0.007 FPS: 136.2955 Mem: 1077.59 Mb/s

Radeon HD5870:
CLRadix Time: 0.020 FPS: 49.9800 Mem: 395.15 Mb/s

Single SPU:

quickSort SPU Time: 0.695 FPS: 1.4381 Mem: 22.74 Mb/s
radixSort SPU Time: 0.070 FPS: 14.3275 Mem: 226.55 Mb/s

BodyRope

2010-09-06T18:57:00.003+07:00

This is a new physics object which can be used for cheap rope simulations.

Terrain occluder

2010-09-03T12:26:00.002+07:00

WorldOccluderTerrain is a new node which can occlude all invisible objects in very efficient way. Heightmap image is used as data source and raycasting operations are performed on CPU. Cone step mapping is used as raycasting optimization. Artistic quality of raycasted image is ugly but number of occluded triangles is very large :)

Terrain editor

2010-08-23T19:05:00.006+07:00

First version of terrian editor. There are some time lags by texture update because video is grabbed in real-time:

Light shafts

2010-06-13T00:34:00.004+07:00

This is a new volume_shaft_base material on ObjectVolumeBox:

PlayStation3 Unigine status X

2010-06-12T19:42:00.003+07:00

Each rendered triangle of static and skinned meshes is culled by view frustum and front/back face tests on SPU. Skinning is performed entirely on SPU with both ordinary and dual quaternion skinning modes available. Vertex buffers for particles are generated on SPU with view frustum culling. Particles can be sorted by depth on SPU. Particles are simulated on SPU with awesome performance.

PlayStation3 Unigine status IX

2010-06-07T21:36:00.002+07:00

Heap of code for view frustum and back face SPU culling, but result is wonderful.

SPU skinning with view frustum and back face culling (30ms per frame)

PlayStation3 Unigine status VIII

2010-06-07T14:54:00.003+07:00

SPU view frustum and back face culling slightly improves performance in Sanctuary and Tropics demo. Difference between forward and pre-pass lighting is removed.

Sanctuary forward lighting:

Sanctuary pre-pass lighting:

Tropics forward lighting:

Tropics pre-pass lighting:

PlayStation3 Unigine status VII

2010-06-01T17:05:00.004+07:00

SPU skinning is ready, SPU triangle culling is coming...

GPU skinning (75ms per frame)

SPU skinning (45ms per frame)

PlayStation3 Unigine status VI

2010-05-29T17:29:00.002+07:00

The first successfully implemented SPU-accelerated thing in Unigine is particle systems render buffer generation. We have wide amount of different particle shapes: billboard, flat, point, length, random. This shapes are generated absolutely asynchronously on all available SPU's with optional depth sorting of particles, which doesn't affect performance a lot. The next target to be boosted is MeshSkinned.

Unigine SPU runtime

2010-05-29T16:56:00.003+07:00

Insomniac papers about their SPU shaders and SPU job management inspired me to implement such system in Unigine. We use raw SPU with SPU-based shader loading scheme. The total amount of code of this system, which parses ELF executable files itself and manages SPU shaders, is just only 1270 lines :) We can run 10000 SPU shaders with up to 8 parameters consuming only 6.7ms of PPU time. Another tasty feature of this system is ability to execute any function from SPU ELF file.

SPU sorting

2010-05-29T16:21:00.004+07:00

As you might know from the public papers, there are only 256 Kb of local memory on SPU, but DMA requests are very fast... quickSort isn't an appropriate algorithm for SPU architecture due to branching and generation of large number of spatially non-coherent memory requests. After several hours of attempts to keep SPU quickSort performance on an acceptable level and writing software implementation of memory cache for SPU, the resulting performance is slightly better than PPU version (on small arrays):

elements: 1012 (16Kb)
quickSort PPU Time: 0.000 FPS: 3717.4719
quickSort SPU Time: 0.000 FPS: 5376.3438

elements: 2024 (32Kb)
quickSort PPU Time: 0.001 FPS: 1923.0769
quickSort SPU Time: 0.000 FPS: 2652.5200

elements: 4048 (64Kb)
quickSort PPU Time: 0.001 FPS: 819.6721
quickSort SPU Time: 0.001 FPS: 908.2652

elements: 8096 (128Kb)
quickSort PPU Time: 0.003 FPS: 398.2477
quickSort SPU Time: 0.002 FPS: 407.3320

elements: 16192 (256Kb)
quickSort PPU Time: 0.005 FPS: 187.7229
quickSort SPU Time: 0.006 FPS: 180.3752

elements: 32384 (512Kb)
quickSort PPU Time: 0.012 FPS: 86.3185
quickSort SPU Time: 0.013 FPS: 78.7030

elements: 64768 (1Mb)
quickSort PPU Time: 0.027 FPS: 37.6322
quickSort SPU Time: 0.029 FPS: 34.2044

elements: 129536 (2Mb)
quickSort PPU Time: 0.056 FPS: 17.8352
quickSort SPU Time: 0.063 FPS: 15.8253

elements: 259072 (4Mb)
quickSort PPU Time: 0.124 FPS: 8.0358
quickSort SPU Time: 0.139 FPS: 7.2073

It was very difficult to sleep after this poor results... I was trying to implement radixSort on the second day in the morning... SPU instruction set fits such algorithms very well. Performance of radixSort on local SPU memory appeared to be very good especially with eliminated branching instructions. Moreover performance of DMA list operations on SPU (surprise!) is great and the resulted version of radixSort demonstrates awesome speedup:

elements: 1012 (16Kb)
radixSort PPU Time: 0.000 FPS: 4081.6326
radixSort SPU Time: 0.000 FPS: 9615.3848

elements: 2024 (32Kb)
radixSort PPU Time: 0.000 FPS: 2617.8010
radixSort SPU Time: 0.000 FPS: 4032.2581

elements: 4048 (64Kb)
radixSort PPU Time: 0.001 FPS: 1333.3334
radixSort SPU Time: 0.000 FPS: 2237.1365

elements: 8096 (128Kb)
radixSort PPU Time: 0.001 FPS: 673.4007
radixSort SPU Time: 0.001 FPS: 1168.2242

elements: 16192 (256Kb)
radixSort PPU Time: 0.003 FPS: 288.8504
radixSort SPU Time: 0.002 FPS: 597.0150

elements: 32384 (512Kb)
radixSort PPU Time: 0.008 FPS: 124.1311
radixSort SPU Time: 0.003 FPS: 298.3294

elements: 64768 (1Mb)
radixSort PPU Time: 0.022 FPS: 45.3700
radixSort SPU Time: 0.007 FPS: 149.8352

elements: 129536 (2Mb)
radixSort PPU Time: 0.049 FPS: 20.5351
radixSort SPU Time: 0.013 FPS: 75.0413

elements: 259072 (4Mb)
radixSort PPU Time: 0.101 FPS: 9.9149
radixSort SPU Time: 0.027 FPS: 37.5587

Intel SSE performance issue

2010-05-29T16:08:00.004+07:00

Particle system render buffer generation has been deeply refactored to obtain better performance. There was a strange performance issue during this process... You can see two versions of the same code bellow. There is no performance difference on AMD CPU between the first and the second rendering code fragments. But on Intel Core i5 the difference is huge. The first version generates only 10M particles per second, while the second one shows 60M particles per second!


/* render vertex format
 */
struct Vertex {
   union {
       struct {
           float xyz[3];
           int parameters;
       };
       __m128 vec;
   };
};
Vertex *v = ...;

/* first version of rendering code
 */
v[0].vec = _mm_add_ps(...);
v[1].vec = _mm_add_ps(...);
v[2].vec = _mm_add_ps(...);
v[3].vec = _mm_add_ps(...);

v[0].parameters = value_0;
v[1].parameters = value_1;
v[2].parameters = value_2;
v[3].parameters = value_3;

/* second version of rendering code
 */
v[0].vec = _mm_add_ps(...);
v[0].parameters = value_0;

v[1].vec = _mm_add_ps(...);
v[1].parameters = value_1;

v[2].vec = _mm_add_ps(...);
v[2].parameters = value_2;

v[3].vec = _mm_add_ps(...);
v[3].parameters = value_3;

PlayStation3 Unigine status V

2010-05-17T13:34:00.003+07:00

PlayStation3 render has been refactored several times:) Now we have stable and fast render pipeline without any CPU/GPU sync points. Render present time is always positive and we can hide update, physics and command buffer generation time when GPU renders previous frame. All Unigine demos work stable and without any rendering artifacts. Main bottleneck is GPU and SPU should helps a lot, especially in geometry culling :)

Sanctuary forward lighting:

Sanctuary pre-pass lighting:

Tropics forward lighting:

Tropics pre-pass lighting:

Heaven forward lighting:

Heaven pre-pass lighting:

Tomsk, May 12

2010-05-12T09:21:00.002+07:00

Late spring at Tomsk.

Updated ObjectWater shading

2010-05-06T12:31:00.003+07:00

New water subsurface shading state has been added. Over/Under water transition artifacts has been removed also.

PlayStation3 Unigine status V

2010-05-01T20:20:00.002+07:00

Direct port to PlayStation3 is complete. Render and physics works properly with expected performance. Time for optimizations is coming...

Unigine Editor on PlayStation3

2010-05-01T18:41:00.003+07:00

PlayStation3, 1920x1080 video mode, loaded Sanctuary and Unigine editor. We can tune art assets on PS3 directly by Unigine editor. But I will append world replication from host PC to PS3 next week...

PlayStation3 Unigine status IV

2010-04-30T22:23:00.003+07:00

And Unigine Heaven running on the PlayStation3, without tessellation of course ;)

PlayStation3 Unigine status III

2010-04-30T22:18:00.002+07:00

Unigine Tropics running on the PlayStation3:

PlayStation3 Unigine status II

2010-04-29T18:06:00.005+07:00

World first PlayStation3 Unigine Sanctuary benchmarking.

PlayStation3 Unigine status

2010-04-26T16:06:00.001+07:00

First launch of Unigine on PlayStation3:

Engine::init(): can't create log file
Xml::load(): can't open "/unigine.cfg" file
Config::load(): can't open "/unigine.cfg" file
Engine::init(): clear video settings for "RSX Reality Synthesizer"
FileSystem::load_dir(): can't open "/data/" directory

Unigine fatal error
Engine::init(): can't create log file
Xml::load(): can't open "/unigine.cfg" file
Config::load(): can't open "/unigine.cfg" file
Engine::init(): clear video settings for "RSX Reality Synthesizer"
FileSystem::load_dir(): can't open "/data/" directory
Engine::init(): can't initialize filesystem

PlayStation3 framework status II

2010-04-25T21:15:00.002+07:00

PlayStation3 framework is ready for Unigine. Tomorrow will be awesome.

PlayStation3 framework status

2010-04-23T20:04:00.006+07:00

Framework for PlayStation3 is almost complete. I should just write several base classes before Unigine PS3 migration.

There are ugly screens from PlayStation3 ;)

PS3Texture, full 2D support, 3D and Cube will be available soon:

PS3Gui, this is a mind-blowing stuff because of full mouse and keyboard support:

PS3Shader, can't say about details, but they work really great ;)

PS3Mesh:

PS3MeshSkinned, vertex shader based skinning for beginning:

PS3MeshDynamic:

PS3Particles, just PPU based simulation:

PS3Grass:

ATI2 to DXT5 conversion

2010-04-21T13:29:00.005+07:00

Unigine uses ATI2 (BC5) texture compression for normal maps. PlayStation3 doesn't support this compression. But after fast bit rearranging we can obtain DXT5 texture with acceptable quality. And it's much better than uncompressed textures :)

2x zoom

PlayStation3 on a way

2010-04-18T11:15:00.000+07:00

Our tessellation talk from GDC

2010-04-16T20:51:00.006+07:00

Practical Use of Tessellation in Unigine Heaven Benchmark
by Denis Shergin, Alexander Zaprjagaev

from NVIDIA Game Technology Theater @ GDC

Massive particle systems

2010-04-14T09:55:00.004+07:00

This explosion effect consists of terrific number of internal particle systems:

Hybrid render

2010-04-07T18:22:00.005+07:00

Unigine render has severely mutated. New render capability of light pre-pass rendering mode is added. Forward and light pre-pass rendering can work at same time. The rendering mode of the lights can be easily switched with the distance, allowing light LOD system of a kind. Light pre-pass rendering mode doesn't multiply the amount of rendered geometry and results in a moderate quality level (because using Phong shading with fixed specular power). At the same time, forward-rendered lights can have all the shading variations, such as Phong-Rim, Anisotropy and Fresnel-based specular component.

Forward rendering:

Light pre-pass rendering:

Forward rendering:

Light pre-pass rendering:

PS: These screenshots are powered by OpenGL 4.0 tessellation.

Fake antialiasing filter

2010-03-25T16:10:00.003+06:00

This is a result of new post_filter_antialiasing material.
This filter can be used on hardware or API which don't has D3D10.1 AA features as cheap AA.

0xAA

0xAA fake antialiasing filter

2xAA

4xAA

8xAA

OpenGL 4.0

2010-03-25T13:10:00.002+06:00

All Direct3D11 features are in OpenGL 4.0 right now.

* hardware tessellation via ARB_tessellation_shader
* supersample antialiasing via ARB_sample_shading
* dual source blending via ARB_blend_func_extended

And we have same rendering quality under Direct3D11 and OpenGL.
Main OpenGL problem is poor performance:)

OpenCL dds compression

2010-02-18T15:46:00.003+06:00

DDS compression it's a complex task for CPU, but it can be accelerated on GPU. We use our internal DDS compressor which produces nice quality image. With small quality degradation we can port this algorithm on GPU and obtain 18x performance gain.

Name: GeForce GTX 260
Vendor: NVIDIA Corporation
Version: OpenCL 1.0 CUDA

RGB8 1024 768
Image Time: 0.338 FPS: 2.9617 RMS: 1.976 SNR: 42.214

CLImage Time: 0.018 FPS: 54.8908 RMS: 2.111 SNR: 41.642

Windows 7 Commemorative Edition

2010-02-09T15:16:00.003+06:00

We have received a while ago this Windows 7 Commemorative Edition box (due to our participation with Heaven DirectX 11 Benchmark in Win7 launch event):

Nice.

Strange moire on HD5850

2010-02-09T11:03:00.004+06:00

Sometime strange moire image happens on HD5850 under Windows7. And it disappears after video mode switching...

Please don't die.

CUDA vs OpenCL vs DirectCompute Part III

2010-02-04T13:49:00.006+06:00

DirectCompute limits GPU abilities... When GPU can write data into several UAV targets physically, Direct3D11 says that GPU can't do that. We can't use DX10 level cards for physics simulation via Direct3D11 API...

This is a small test application which produce simple particles physics. There are 40625 particles on static mesh consisting of 1392 triangles.

GTX260 CUDA (Windows7 11.5ms per frame)

GTX260 CUDA (Linux 13.3ms per frame)

GTX260 OpenCL (Windows7 13.9ms per frame)

GTX260 OpenCL (Linux 15.6ms per frame)

HD5850 Direct3D11 (Windows7 15.6ms per frame)

CUDA vs OpenCL vs DirectCompute Part II

2010-02-04T13:34:00.004+06:00

Interop between compute and graphical API is very important thing. We can render generated geometry directly on GPU without additional data copy through system memory. For example in cloth simulation we can do physics and calculate tangent space entirely on GPU.

There are some tests of interop and compute API performance:

GTX260 OpenGL + CUDA (Windows7 128 FPS)

GTX260 OpenGL + CUDA (Linux 143 FPS)

GTX260 OpenGL + OpenCL (Windows7 151 FPS)

GTX260 OpenGL + OpenCL (Windows7 167 FPS)

GTX260 Direct3D11 (Windows7 100 FPS)

HD5850 Direct3D11 (Windows7 214 FPS)

Same GPU shows 50% difference in performance across different API. That is nightmare.

CUDA vs OpenCL vs DirectCompute

2010-02-02T17:26:00.004+06:00

We have three different GPGPU API nowadays. All of these API's do same job on same hardware, but results which they show are completely different.

I have implemented simple bitonic sort algorithm across these API. And results are terrible.

GeForce GTX 260 CUDA:
quickSort Time: 0.042 FPS: 23.8498
CUBitonic Time: 0.012 FPS: 80.6452

GeForce GTX 260 OpenCL:
quickSort Time: 0.038 FPS: 26.3442
CLBitonic Time: 0.014 FPS: 71.5461

GeForce GTX 260 DirectCompute:
quickSort Time: 0.039 FPS: 25.8766
D3D11Bitonic Time: 0.031 FPS: 31.8350

Radeon HD 5850 DirectCompute:
quickSort Time: 0.036 FPS: 27.8854
D3D11Bitonic Time: 0.017 FPS: 58.3669

Radeon HD 4850 DirectCompute:
quickSort Time: 0.031 FPS: 32.1885
D3D11Bitonic Time: 0.059 FPS: 16.9869

The number of elements are 259072. Sorted structure is uint2.
Timings of quickSort are presented only for CPU comparison.
OpenCL implementation doesn't work on current AMD GPU OpenCL.

BodyFracture

2010-01-11T21:57:00.002+06:00

Another fracture videos:

BodyFracture

2010-01-11T00:27:00.001+06:00

Making of Unigine Heaven Benchmark

2010-01-09T19:41:00.005+06:00

Some photos:

Альбом: Making of Heaven Benchmark

Project team: 5 artists, 3 programmers, 1 producer
Production time: 2,5 months
Release: October, 22 (Windows 7 launch)

Special thanks to AMD guys for pre-production samples of ATI HD 5xxx with support of DirectX 11!

ShapeCylinder

2010-01-04T22:24:00.003+06:00

Cylinder collisions are defeated.

Inverse kinematics with ragdoll

2009-12-23T15:52:00.001+06:00

Funny stuff with ragdolls

2009-12-23T12:19:00.001+06:00

ObjectWaterMesh with BodyWater

2009-12-16T18:08:00.001+06:00

Shading is amazing...

Updated JointPin and new BodyWater

2009-12-15T18:07:00.003+06:00

Updated JointPin allows to directly attach BodyCloth to BodyRigid. This type of joint performs coordinates synchronization between the skinned mesh geometry and the cloth. The attached cloth adheres to the skinned mesh object without any undesired clearance:

New BodyWater physical object provides two-way interaction with BodyRigid. The performance is simply great:

PhysicalWind

2009-12-01T15:07:00.002+06:00

Cloth wind 2

2009-11-17T20:13:00.000+06:00

Cloth wind

2009-11-17T17:00:00.002+06:00

Cloth wearing

2009-11-15T17:37:00.000+06:00

Cloth tearing

2009-11-10T19:32:00.002+06:00

flu

2009-11-07T20:04:00.003+06:00

1/3 of the team have caught flu. It seems that there is a real epidemy in Siberia. I hope we'll recover next week, because there are a lot of interesting things to do!

Physics cloth

2009-11-07T15:45:00.002+06:00

Bunch of new OpenGL extensions.

2009-10-04T16:52:00.004+07:00

We can use signed normalmap textures with ARB_texture_snorm and ARB_texture_compression_rgtc extensions. No more ugly "*2.0-1.0" in shaders for DX10 level cards, but we should do it for legacy cards.

ARB_texture_multisample allows us to implement multisampled deferred effects such as light scattering and SSAO.

ARB_draw_elements_base_vertex great-great-great, but why only now?

inline vs __forceinline

2009-09-30T17:30:00.003+07:00

Don't ask compiler to do something. Force it!

inline:

__forceinline:

DirectX 11 tessellation samples

2009-09-30T13:22:00.004+07:00

In the DirectX 11: Tessellation in Stalker: CoP, Dirt 2, Unigine and Alien vs. Predator article people mentioned that only our art sample really utilizes tessellation capabilities to improve image quality: "Only one that was a visually significant improvement was the displacement mapping on the roof. That should be a nice improvement over the various surface mapping techniques, bump, normal, POM, etc. that don't do nearly as good a job."

All hail our artists, who created that art asset! By the way, stay tuned for much more.

Fried meshes

2009-09-21T13:46:00.010+07:00

* [20090930] Values for HD4870 and Direct3D11 are updated (it was a debug runtime:(

Huge crowd rendering can be accelerated by baking skinned meshes into static meshes in runtime. But there is no easy way to do it because of API and hardware limitations.

The scene consist of 49 characters and each character is rendered 6 times. Tables contain millions of polygons per second. There are no tests for low-level cards. But on such cards performance gain is very substantial. And there are no tests for OpenCL because of incomplete drivers.

The first two rows describe direct rendering of skinned meshes:
"Raw" is a single mesh per draw call.
"Inst" is multiple meshes per draw call.

The other rows describe different backing techniques:
"Raw" corresponds to backing single character per call between characters rendering.
"Inst" corresponds to backing 32 characters per call before characters rendering.

OpenGL:
PBO: works well on all cards but instancing is required.
FeedBack: requires DX10 level card and doesn't work on ATI cards now.
CUDA: requires NVIDIA DX10 level card. Also instancing is very important.

Direct3D9:
R2VB: is ok on ATI and NV40. But we can't use this technique with NVIDIA DX10 cards.
CUDA: same as CUDA under OpenGL.

Direct3D10:
StreamOut: there is absolutely no problem with this technique.
CUDA: same as CUDA under OpenGL.

Direct3D11:
StreamOut: same as StreamOut under Direct3D10.
DirectCompute: instancing is also very important on NVIDIA hardware.

GDC Europe 2009

2009-09-13T22:39:00.007+07:00

Some photos from our trip to GDC Europe 2009 and Gamescom, without lectures shots (clickable):

The route was Tomsk-Novosibirsk-Moscow-Munich-Cologne-Munich-Moscow-Novosibirsk-Tomsk, something about 10000 kilometers.

Ambient occlusion mk2.

2009-09-08T12:07:00.003+07:00

Awesome ambient occlusion mk2.
* Improved emitter/receiver interaction.

HDR pipeline

2009-09-03T15:11:00.002+07:00

New shaft flare post effect.

Middleware in games

2009-08-22T19:59:00.004+07:00

There is a good article in the August issue of Game Developer Magazine about middleware, here is a quote from there:

"It's long been appreciated that using game engines and middleware libraries can get the team up and running more quickly on the target platform during the development process, allowing artists and designers to mock up the game much earlier. Commenters noted, "While middleware is not perfect, it allows us to concentrate on the areas that really make our game different, rather than implement basics. But programmers tend to not like [middleware] because it makes their lives more difficult [and the naive ones think they can do it better]."

CPU Caches 2

2009-08-07T03:57:00.002+07:00

To achieve maximum performance of multi-threaded application you should run same jobs on same threads (CPU's). It's very important for applications based on small thread jobs.

Physics status

2009-08-06T02:20:00.006+07:00

Performance and stability of physics is much improved and it's not a final result:)

State of all physical objects can be stored into the special buffers. In this demos this buffers are used for time wrapping effect:

This is a heap of joints:

And funny stuff with homuncles:)

Homuncle adventures

2009-08-02T08:44:00.002+07:00

Timetable

2009-08-01T00:23:00.002+07:00

Average timetable of last week:

18:00 home power on
19:00 office work on
11:00 office work off
11:30 home power off

Recent photo of the crew

2009-07-28T19:48:00.006+07:00

From left to right:
* Frustum (Alexander Zaprjagaev) // CTO and The Brain
* Andrewko (Andrey Kolchin) // 3D artist
* Silvero (Iliya Abzaev) // developer
* ANet (Anna Ishina) // developer
* FadeToBlack (Alexey Egorov) // developer
* Silen (Vitaliy Sidorov) // game designer
* TmifX (Ivan Gulyaev) // developer
* Binstream (Denis Shergin) // CEO
* Pluton (Andrey Kushner) // lead 3D artist
* Brrrrr (Stanislav Zagniy) // 3D artist
* Manguste (Nadezhda Ovchinnikova) // technical writer

Missing on the photo: Jane (Eugenia Shergina), JL (Eugeniy Logvinov), Paralyzah (Michael Kondratyev).

PS: It was the opening night of "Harry Potter and the Half-Blood Prince" in Tomsk.
PPS: Siberian summer can be hot! but short as well :(

New script feature

2009-07-21T20:58:00.006+07:00

Expression e0 = new Expression("133.0 * 133.0");
printf("%s\n",typeinfo(e0.run()));

Expression e1 = new Expression("{
    int a,b,c,d;
    return a + b + c + d;
}","a,b,c,d");
printf("%s\n",typeinfo(e1.run(1,2,3,4)));

Expression e2 = new Expression("{
    string name;
    File file = new File(name,\"rb\");
    int size = file.getSize();
    file.close();
    delete file;
    return size;
}","name");
printf("%s\n",typeinfo(e2.run("test.cpp")));

float: 17689
int: 10
int: 36339

AMD_vertex_shader_tessellator

2009-07-09T17:02:00.006+07:00

Don't provide tessellation for 3D artists, because the work will stop :)

Normal mapping:

Normal mapping + displacement:

Normal mapping + displacement wireframe:

Here is the video:

PS: The feature will be available in DirectX 11.

Awesome volumetric clouds

2009-07-04T22:06:00.003+07:00

Just images:)

Unigine goes PS3

2009-07-02T17:32:00.003+07:00

We made it, Unigine joined Tools & Middleware License Program for PLAYSTATION®3.

The process took 8 months to complete, it was kinda hard. Now we're going to get devkits and make the porting!

CPU Caches

2009-07-02T15:56:00.008+07:00

Sometimes absolutely correct code can produces huge stalls because of cache misses.
For example if we have two 3D arrays: source ([128][128][16]) and destination ([16][128][128]) and we should copy data from source to destination.
Ordinary copying spends 5.0ms on old Athlon64 X2 3800+ CPU in this case.
But if we create a temporary copy array ([16][129][129]) and perform copying of data two times (from source to copy and from copy to destination), so copying time is only 1.9ms.

Pretty matrix trick

2009-05-14T20:05:00.008+07:00

Floating point numbers are wonderful things.
Let's try to draw a distant mesh by standard approach.

Engine code:
shader_modelviewprojection = player_projection * player_modelview;

Vertex shader:
gl_Position = shader_modelviewprojection * vertex;

The result will be funny:

And it's time to trick now.

Engine code:
shader_offset = player_position;
shader_modelviewprojection = player_projection * player_modelview * translate(shader_offset);

Vertex shader:
gl_Position = shader_modelviewprojection * (vertex - shader_offset);

The result will be absolutely correct:

frustum.org

2009-05-07T10:11:00.000+07:00

frustum.org domain name is officially dead.

Screenshots Buzz

2009-04-29T20:32:00.009+07:00

Recently we have shown a bunch of screenshots from our forthcoming game, which created some buzz. Linux users are especially enthusiastic about the fact that the project will natively support both Windows and Linux (thanks to Michael Larabel for posting news item on Phoronix website).

The bad thing is that we still don't know even a genre of our game %) In fact, we intended to make a large tech-demo, but eventually we came up to the small game idea. According to the first feedback users expect the project to deliver fun, so it's kinda complicated situation for us. Well, it seems that we have no other option than to make a full-featured game =)

PS: Another fun thing is that the news were translated into Russian and copied several times by different sites and blogs, so in the end overall data distortion was so severe that a reader can get to know about "unique feature of the project: unlimited multiplayer!", while there was no single word with "net" in the original entry.

More to come, stay tuned!

stdlib performance

2009-04-26T16:11:00.007+07:00

This is a relative performance of some standard library function.
String::atoi() and String::atof() are Unigine functions.

Windows (Core2 Quad 2400MHz):

atoi	Time: 0.276	FPS: 3.6231
strtol	Time: 0.278	FPS: 3.6001
String::atoi	Time: 0.095	FPS: 10.4853
atof	Time: 2.104	FPS: 0.4752
strtod	Time: 2.127	FPS: 0.4701
String::atof	Time: 0.349	FPS: 2.8644

Linux (Athlon 64 X2 2140MHz):

atoi	Time: 0.271	FPS: 3.6840
strtol	Time: 0.301	FPS: 3.3271
String::atoi	Time: 0.112	FPS: 8.9447
atof	Time: 1.337	FPS: 0.7480
strtod	Time: 1.224	FPS: 0.8168
String::atof	Time: 0.328	FPS: 3.0481

Hall of GPUs killed by Unigine

2009-04-24T10:07:00.003+07:00

NVIDIA 8800GTX is dead because of memory problems
NVIDIA 9800GT is dead because of memory problems

LightProbRoxx

2009-04-17T14:24:00.006+07:00

No comments.

Magic Spring

2009-04-12T23:32:00.006+07:00

Now we have a magic spring in our studio:

Cubemap filtering

2009-04-09T19:21:00.004+07:00

All Direct3D10-compatible cards use linear filtering across cube map faces.
NVIDIA NV50 uses linear filtering across cube map faces under OpenGL for 6-9 months.
ATI R700 uses linear filtering across cube map faces under Direct3D9 since Catalyst 7.1 or 7.2.

Who is next?

Total happiness

2009-03-28T12:25:00.005+06:00

No more gypsum anymore. It was nightmare 20 days without ability to walk, to run, to ride... Right leg is little smaller than left one and it's funny :) I made a crack in splint bone 5 weeks ago by snowboard boot. Doctors said that I had closed wound only. I had been walking with crack in bone for 2 weeks. And after that I broke it totally. Now I can use my leg and it's happiness. Thanks for all Russian doctors :)

Paralyzah: 30 Years

2009-03-23T22:04:00.010+06:00

Yesterday we celebrated 30th anniversary of our musician, Michael "Paralyzah" Kondratyev. At the moment his tracks are released by the following labels: Respect Rec (Russia), Total Advance Music (Russia), KDK Rec (Russia), Gunsta Rec (Russia), MacroVision (Russia), Covert Operations (USA). He creates music mainly in drum'n'bass style, plus he is a DJ and promoter of "Untrace" promo-group. All soundtracks of our demos were written by him, you can check out some other tracks here: http://paralyzah.all.dj/

Happy birthday, man!

frustum.org

2009-03-20T14:30:00.007+06:00

Hi Everyone,

Years ago I had frustum.org website and I frequently posted demos. But years ago I totally switched into Unigine project also. And once I forgot to made payment for the domain name. Currently frustum.org is a dead site, but you can have access to it at frustum.unigine.com address. I hope the situation with domain name will be resolved and frustum.org will be alive as soon as possible.

Three weeks ago I started work on dynamical backed into the vertex buffer skinned meshes to reduce amount of vertex shaders in Unigine. Unfortunately two weeks ago I had broken my leg :) So this interesting task is unfinished now and I will report results when I will work in the office, because at home I have only a Linux based PC.

How can we use uniform scaling with dual quaternions? It's simple. First quaternion in the pair is normalized one and we can scale it on decomposing stage. And on composing we can easily calculate quaternion magnitude and it will be its own scaling.

And now I can't ride snowboard :(

Next Stage

2009-03-16T01:36:00.007+06:00

Suddenly I realized that our company (Unigine Corp.) has passed the startup stage. We are a good team working on the project for years, we have good customers, we have our main product constantly improving on schedule, so things seems to be changed to steady growth. Well, that's all for good, lets keep on moving forward.