I moved this blog to www.glow3d.com/blog. New blog is built on Wordpress and hosted on the same site as www.glow3d.com. I think Wordpress is more convenient and  if you interested, please subscribe to www.glow3d.com/blog.

SSAO: First steps

Today's results - fancy Screen Space Ambient Occlusion!
It searches pixel's surroundings to check pixel's occlusion, after
that blurs results and blends with the screen.

Video with a water:


Some additional effects like Light Scattering (God rays ) remains to implement
and I can finally start work on the game!

Finally water!

First stage of water with reflection and refraction in Glow engine. Plus HDR, Antialiasing, Color Corrections and Gamma Corrected (Linear) Rendering.

New day - new picture with house )

Playing with combination of atmospheric scattering, light
intensity, dynamic sun and time of day.

Atmospheric Scattering

Atmospheric Scattering was added (restored) today. It's dynamic and renders beautiful sunsets and dawns. Special values added to Scene properties - Time of the Day (0..24, in hours), Length of the day ( in hours ).

HDR finally done

fuuuf .. 4 months without updates.

I returned to HDR, finally cracked it. It's probably
not so very efficient now, and I will return to it later.
It uses 64bit float render targets, bloom, all standard.

Current state of editor.. several tasks to finish alpha version..

Color transformations

Color transformations as Post-Process is added into Glow engine.

Currently supported transformations are contrast, brightness, black and white, red, green, blue shifts, saturation will be added later. All transformations work in a same step, so adding, for example contrast to brightness will not slow down it in 2 times.

Transformations added as scene property, and can be accessed from script.

Image:


Adjusted brightness:


Blue and Green shifted, to create Matrix movie look


Black and white:

Antialiasing

Antialiasing is finally implemented in Glow engine.

It's implemented by Directionally Localized AA algorithm,implemented in The Force Unleashed 2. It's operates in image space and works as post-process, finding edges by High-Pass filter and blur it with 5x5 (and 16x16 for long edges) kernel.

Looks cool .. my images long time suffered from jaggies .. not now)

Antialiasing is off:

Antialiasing is on:

NPC with several lights

More pictures from Sponza model

Lion by Glow engine

Just screen

Little by little engine becomes usable after various changes (as usual it need to be completely rewritten after reading about some interesting idea :)). Last ideas were concurrency, memory debugging,fragmentation and reference counting. Anyway, it improves engine, makes it safer and usable.

Screen from "Deadly light" demo:

Debugging in Glow Engine

It's very important to display debugging information about your level or models during developing game level. Previously, I used 3ds max to place all objects, including lights and it was not easy task. Tweak lighting in 3ds max, switch to engine, check lighting etc...

Now several debugging modes are supported in Glow engine - wire-frame mode, displaying normals in world space, depth of pixel, lights, physics, AI (triggers), navigation meshes.

All modes can be used same time (except normals, depth and diffuse color), button "layers" should be pressed and mode selected.

Room from "Deadly Light" demo, lighted with 6 lights:

Same room in wire-frame debug mode:

Normals mode:

Lights debugger:

Physics:

Depth:

Site is updated

www.glow3d.com is updated to reflect all recent changes.

TBB adopted

Embedding of Intel Threading Building Blocks is finished, really good library with many abilities.

Development of a concurrent scene graph is started, scene graph (sectors - portals) was made templated, to hold different types of objects and it supports now read-only access from several threads (or tasks). Also several modules of engine have copy of the scene graph - renderer holds scene graph with visible objects, physics - with physical to optimize simulation.

moving to Intel Threading Blocks

deeper and deeper into concurrency and multi threading...

I have decision to use Intel Threading Building Blocks instead of experimental boost::thread_pool. All computations in the Glow engine are organized into tasks and theoretically would scale well when number of hardware threads (CPU cores) will be increased.

Previously, I used boost::thread_pool for task execution. Now, when I returned to concurrency, I realized that usage of boost::thread_pool is not scalable, because it heavily uses mutexes (spin-based). Later I will launch tests to measure scalability of both methods and post results here.

I am thinking about concurrent scene graph.

The are several modules in the engine, which needs queries to the scene graph, like Physics, Audio, Render. Moreover, in the future, several threads (tasks) inside of module will need concurrent access to the scene graph.

There several options how to do it:

1) copies of scene graph in every module (used also in OpenSceneGraph engine)- needs more memory, but should hold different types of objects - Physics module will hold only physics objects etc. Still it does not resolve problem with concurrent access in the future

2) concurrent containers in the scene graph - maybe the best solution, but currently I can not find best fit for it. Also looks like it hardware dependent and not robust enought. There is Intel Thread Building Blocks library with concurrent containers, but it's not perfect and doesn't support Android and iOS.

3) mutexes to isolate queries. Usage of mutex is not good thing for scalable multi threading, but maybe for some usage patterns it's ok. In my case it's SINGLE PRODUCER MULTIPLY CONSUMERS model.

Can anyone suggest robust cross platform concurrent containers (hash_map or vector at least) ?

excellent blog http://www.1024cores.net about concurrency and scalability.

UPD: I was wrong about Intel TBB, it's cool and powerful library. It's not clear now for me, how to use it under iOS or Android, but it's Open Source and ports are available for different platforms.

High Dynamic Range lighting with eye adaptation is implemented in the Glow engine. Plus gamma-correct rendering. Plus Color Transformations (hue, saturation, brightness etc) were started.

Memory Management in the Glow engine

Memory management is very important thing in a console world. We can forget about it on a PC (at least for several hours without leaks, but consoles are restricted, so we should consider that after some time, allocation of memory will return NULL (or exception, depending on compiler). Also fragmentation is serious problem after allocation of many small objects. So with the plans to move on mobile devices, we decided to develop system for memory management.

New memory manager is implemented for Glow engine. Separate optimized singlethreaded heaps with pools for small objects for every module of the engine (physics, ai, navigation, sounds etc) are added instead of the single common C++ heap.

Special heap for transferring messages between modules, memory leak debugging, shared pointers (boost c++ library) for memory arrays.

Allocator for STL containers was implemented, so every memory allocation in the specific module goes from the module heap. STL containers and strings are evil force of a memory fragmentation, so process for removing every STL container from code is started. Some vectors are replaced by special Stack vector container, based on boost::array with restricted dynamic grow. Also major part of constant std::string was replaced with const char* equivalent (with memory allocated from constant string pool) and "copy on create if exists" usage.

Memory debugger UI, with rendering of memory fragmentation, information about allocated blocks - count, amount, overhead.

Remaining part for the memory manager implementation - garbage collector for Geometry.

January release date was very optimistic, so we moved release of alpha version to Spring, 2011. Major parts are ready, but there are many small task to polish editor and engine.