Wunderwerk Engine Development Blog

Material system

2012-01-23T10:59:00.000+01:00

I've been working on the material system lately. A material handles the textures and shaders used when rendering a mesh. Every material has its own shading program, which consists of a vertex shader, a fragment shader and an optional geometry shader. Some of the material's properties, like its number of texture layers, are compiled directly into the shaders, while others, like material colors, can be updated at run-time using uniform variables.

Materials can be made up of several layers which are blended on top of each other with a variety of blend modes, very similar to Photoshop. A texture layer can contain a diffuse texture with an optional alpha channel (for transparency effects), a normal map with a height component stored in the alpha channel (for parallax mapping and similar effects) and a specular map. Internally, texture layers are represented by array textures. This brings the advantage that only one texture object has to be bound per layer, effectively reducing the number of texture binds by two thirds (diffuse, normal and specular maps are all adressed by the same sampler in the shader).

In addition, texture layers can be scrolled, stretched or rotated for effects like animated computer screens etc. This was heavily used in Quake 3, for example. I'll show an example of that later (if I don't forget as usual).

The wall on the screenshot is composed of four images (as seen on the left). You can see the material definition in the upper left corner.

Level export and portal rendering

2012-01-09T16:24:00.005+01:00

I've been a busy bee these past months even though I failed, as usual, to report on my progress.. so here's a short recap.

I designed the engine's level format and wrote a Blender script which creates levels from prepared .blend files. Levels use portals and bounding volume hierarchies for fast visibility detection. This way, both indoor and outdoor scenes can be rendered reasonably fast and, most importantly, mixed. For now, portals have to be set manually in Blender. It works like this:

The artist creates an indoor level as a series of connected rooms. Every room must be a separate object.
Portal polygons are created for every door, window, etc. which connects two rooms or a room with the outside. Every portal polygon must be kept as a separate object, its name must begin with "p_" to tell the export script it's a portal.
The export script creates a list of rooms and portals and their connections. In addition, a bounding volume hierarchy is created from the rooms and free objects (landscapes, detail meshes, etc.)

This way, portals are merely an optional optimization; if the scene you're working with it rather simple or you simply want to preview a complex level and don't care to much about speed, you can simply skip portal creation; potential rooms will then be placed in the bounding volume hierarchy.

A portal's definition in the level file may look like this:

 portal02                       // portal's name
 room02                         // target room's name  
 4                              // number of vertices
 -2.947355 0.001296 -4.529554   // vertex #1   
 -2.947347 3.001296 -4.529551   // vertex #2    
 -4.947346 3.001301 -4.529550   // vertex #3    
 -4.947354 0.001301 -4.529554   // vertex #4

The next step was to put the new information to use. When a camera's render routine is called, it first determines the smallest sector it is in. Then it traverses the portals connected with this sector and recursively performs the following steps:

If it is not completely visible, the portal is clipped to the screen.
If the clipped portal has more or less than four vertices, it is replaced by its projected bounding rectangle.
A new view frustum is computed from the clipped portal, using the portal's plane as the new near clipping plane.
The sector is rendered using the new frustum.
The entity components (meshes, sprites, etc.) contained in the sector are rendered.
Sub-sectors are rendered.

Here's a screenshot with debug visualizations of the portals created during the recursive process:

The player's camera sees what is displayed in the top-right viewport. It is positioned in the first room. The doorway acts as a portal to the adjacent corridor, which in turn acts as a portal to the next room, and so on. This means that only parts of all rooms following the first are visible from the camera's current position, and only these parts and the entities they contain have to be rendered.The white frustum visualizes the camera's perspective from the first room, the turquoise frustum its perspective from the adjacent corridor, etc.

AABB vs. OBB

2011-10-12T22:20:00.003+02:00

The lack of posts in the last weeks was not due to a lack of progress on the engine.. what I've been working on is just not very interesting: I've ported the frustum culling and collision detection code from the old framework into the new engine and it's finally all working as it should.

I've been struggling to implement culling and intersection tests for oriented bounding boxes (OBB) and discarded them eventually; instead, I simply rotate the eight corner points of an entity's axis-alinged bounding box to dynamically compute a larger AABB which encompasses the rotated entity. This is still pretty fast and works just as well.

Next task: Bullet integration.

Just a small update

2011-09-06T14:03:00.002+02:00

I've added project serialization using boost::serialization; although it was rather easy to implement, it took some time until I fully understood how to serialize classes which inherit from one or several base classes. For example, all entity components inherit from a base class EntityComponent which among others serializes the component's parent transform. Similarily, all resources inherit from a common base class Resource, which stores the resource's file path. In order to make sure that the desired inherited class members are serialized properly as well, one should use the BOOST_CLASS_EXPORT_GUID macro, which has to be defined for every class at the top of each source file from which these classes are serialized:

 BOOST_CLASS_EXPORT_GUID( EntityComponent, "EntityComponent" )  
 BOOST_CLASS_EXPORT_GUID( ModelController, "ModelController" )  
 BOOST_CLASS_EXPORT_GUID( CameraController, "CameraController" )  
 BOOST_CLASS_EXPORT_GUID( SkeletonController, "SkeletonController" )

If not used, your program may simply crash without telling you where and why. At least that's what happened to me, ruining an otherwise perfectly fine Saturday afternoon :/

Also, it's now possible to create and attach cameras to entities through the editor. In addition to their primary free-fly camera, all 3D viewport can then select and preview all available cameras. This is useful to set up and test in-game cameras. The screenshot illustrates how a third person camera may be set up for a mech game:

A Transform class

2011-09-02T13:09:00.001+02:00

When listing all the third party libraries I'm using for the new framework, I forgot to mention one library that has become indispensable in development: GLM, a mathematics library for graphics software based on the OpenGL Shading Language (GLSL) specification, written and maintained by Christophe Riccio.

Despite its excellent design it may be tricky to use sometimes, so I've decided to post my Transform class which is the engine's base class for all translation, rotation and scaling transformations and also computes a view matrix to be used in vertex shaders. Complex hierachies can be created by providing the view matrix of a superordinate Transform's view matrix to the update() routine. The m_timePassed variable may prove useful for physics simulation.

Transform.h

 class Transform  
 {  
      public:  
   
           Transform();  
   
           Transform( const quat &rotation );  
           Transform( const vec3 &translation );  
   
           Transform( const quat &rotation, const vec3 &translation );  
   
      public:  
   
           const vec3 &getScaling() const;  
           const quat &getRotation() const;  
           const vec3 &getTranslation() const;  
   
           void setScaling( const vec3 &scaling );  
           void setRotation( const quat &rotation );  
           void setTranslation( const vec3 &translation );  
   
           void scale( const vec3 &scaling );  
           void rotate( const quat &rotation );  
           void translate( const vec3 &translation, bool global = false );  
   
           void setScaling( const float &scaling )  
           {  
                setScaling( vec3(scaling) );  
           }  
   
           void scale( const float &scaling )  
           {  
                scale( vec3(scaling) );  
           }  
   
      public:  
   
           const mat4 &getModelMatrix() const;  
   
           virtual void update( double deltaTime, const mat4 &modelMatrix = mat4(), bool force = false );  
   
      private:  
   
           vec3 m_scaling;  
           quat m_rotation;  
           vec3 m_translation;  
             
           bool m_needUpdate;  
           long m_timePassed;  
           long m_lastUpdate;  
   
           mat4 m_modelMatrix;  
 };

Transform.cpp

 #include "Transform.h"  
   
 Transform::Transform()  
 {  
      setScaling( vec3(1.0f) );  
 }  
   
 Transform::Transform( const quat &rotation )  
 {  
      setScaling( vec3(1.0f) );  
   
      setRotation( rotation );  
 }  
   
 Transform::Transform( const vec3 &translation )  
 {  
      setScaling( vec3(1.0f) );  
   
      setTranslation( translation );  
 }  
   
 Transform::Transform( const quat &rotation, const vec3 &translation )  
 {  
      setScaling( vec3(1.0f) );  
   
      setRotation( rotation );  
      setTranslation( translation );  
 }  
   
 const mat4 &Transform::getModelMatrix() const 
 {  
      return m_modelMatrix;  
 }  
   
 const vec3 &Transform::getScaling() const 
 {  
      return m_scaling;  
 }  
   
 const quat &Transform::getRotation() const 
 {  
      return m_rotation;  
 }  
   
 const vec3 &Transform::getTranslation() const 
 {  
      return m_translation;  
 }  
   
 void Transform::setScaling( const vec3 &scaling )  
 {  
      m_scaling = scaling;  
      m_needUpdate = true;  
 }  
   
 void Transform::setRotation( const quat &rotation )  
 {  
      m_rotation = rotation;  
      m_needUpdate = true;  
 }  
   
 void Transform::setTranslation( const vec3 &translation )  
 {  
      m_translation = translation;  
      m_needUpdate = true;  
 }  
   
 void Transform::scale( const vec3 &scaling )  
 {  
      setScaling( m_scaling*scaling );  
 }  
   
 void Transform::rotate( const quat &rotation )  
 {  
      setRotation( glm::cross(m_rotation, rotation) );  
 }  
   
 void Transform::translate( const vec3 &translation, bool global )  
 {  
      if( global )  
      {  
           setTranslation( m_translation+translation );  
      }  
      else  
      {  
           setTranslation( m_translation+(m_rotation*translation) );  
      }  
 }  
   
 void Transform::update( double deltaTime, const mat4 &modelMatrix, bool force )  
 {  
      long thisUpdate = clock();  
      m_timePassed = thisUpdate-m_lastUpdate;  
   
      const bool performUpdate = force || m_needUpdate;  
   
      if( performUpdate )  
      {  
           mat4 rotationMatrix = glm::mat4_cast( glm::normalize(m_rotation) );  
           mat4 translationMatrix = glm::translate( mat4(), m_translation );  
             
           m_modelMatrix = translationMatrix*rotationMatrix;  
           m_modelMatrix = glm::scale( m_modelMatrix, m_scaling );  
   
           m_modelMatrix = modelMatrix*m_modelMatrix;  
   
           m_needUpdate = false;  
      }  
        
      m_lastUpdate = clock();  
 }

Happy coding!

I have to be the worst blogger ever.. (also, a video!)

2011-08-31T14:53:00.001+02:00

Despite the usual sparsity of blog updates I've been working a lot on the engine and the editor over the course of this summer and I'm proud to say that I've made quite some progress! Considering that I haven't been writing anything in months and that noone probably remembers what this is all about anyway, I feel like I should give a quick recap.

My motivation (or justification)
Some of you may remember RealityFactory, a gameshell based on the then popular open source game engine Genesis3D. The idea behind RealityFactory was (and apparently still is - there still seem to be some people around from back then!) to allow non-programmers to create computer games, merely relying on a set of level and game editors and some scripting. Frustrated by my own puny attempts at writing games using Genesis3D by essentially hacking the included (and horribly written) game shell I became a huge fan of the RealityFactory project and stayed active for several years. That was around 2003 and 2005. Time went by and eventually, people started asking for a replacement of the outdated Genesis3D engine. I raised my hand and teamed up with an American guy who at some point lost interest but the idea of creating a piece of software that would give people the chance to realize their games and learn as much I had with RealityFactory kept me going.

Looking for a suitable graphics engine to base my RF2 candidate on, I stumbled upon NeoEngine. The project was ultimately abandoned by its founder; while trying (and for the most part failing) to add new features myself I realized that graphics engine programming didn't seem to be all that hard after all, and after I had taken a look at some other open source engines and decided I didn't like any of them (basically because I hadn't written them - of course most of these were and still are great pieces of software) I decided to write my own graphics engine which would later develop into a full-blown game engine.

That, of course, never happened. I got so tangled up in improving graphics that I forgot about my original intention of creating a game engine. The result was a decent but utterly slow graphics engine with support for some basic physics. And, of course, I learned a lot about how NOT to plan a project. You can still find screenshots and videos of this project in previous blog posts. So in the summer of 2009, I started from scratch. I built up a stable foundation first, utilizing all the knowledge I gained in the process of building the previous engine and considered such (basic) concepts like interfaces for sub-systems like graphics, audio, physics and scripting and the integration of more third party libraries, first and foremost boost. Since then, I've been working on and off. This summer has been very productive - I've been on semester break, my part-time job is pretty relaxed, the girlfriend visting her parents, and so I've been working eight to ten hours a day for the last few weeks.

Wunderwerk Engine ("the engine")
The engine's core consists of four sub-systems: graphics, sound, physics and scripting. All but one (physics) are functioning and more or less complete. The graphics engine currently uses OpenGL 3.3 in the core profile. A switch to OpenGL 4.x would exclude many and gain little, so I'll wait. Right now, only a very basic rendering pipeline is implemented, allowing for simple per-pixel shading. I'm planning to implement and extend the old engine's deferred shading pipeline and post-processing framework soon. Have a look at older posts for some screenshots and videos. The sound engine uses OpenAL and is more or less finished. It features playback and mixing of positioned 3D sound and music. Not much to say here, really. The old engine's physics engine was powered by Bullet Dynamics and will be incorporated as soon as the octree implementation is finished. Scripting is realized using the Lua scripting language, which I've grown quite fond of. The entity system exposes most of its functionality through a simple, C-style scripting API.

Here is an example of a (very, very) simple AI script; a zombie approaches and reaches for the player depending on their distance to each other (read bottom to top):

 function idle( deltaTime )  
      -- blend idle animation  
      stopCycle( "Zombie", "Skeleton", "Walk", 0.5 )  
      playCycle( "Zombie", "Skeleton", "Idle", 1.0, 0.5 )  
 end  
   
 function attack( deltaTime )  
      speed = 0.6  
      rotSpeed = 4.0  
   
      -- fade idle animation  
      stopCycle( "Zombie", "Skeleton", "Idle", 0.5 )  
        
      -- query zombie's health  
      health = getAttribute("Zombie", "Health")  
        
      if health > 50 then  
           -- blend walk animation  
           stopCycle( "Zombie", "Skeleton", "Limp", 0.5 )  
           playCycle( "Zombie", "Skeleton", "Walk", 1.0, 0.5 )  
      else  
           speed = 0.25  
           rotSpeed = 1.5  
   
           -- blend limp animation  
           stopCycle( "Zombie", "Skeleton", "Walk", 0.5 )  
           playCycle( "Zombie", "Skeleton", "Limp", 1.0, 0.5 )  
      end  
        
      -- get position vectors  
      eyePos = getTranslation("Zombie")  
      targetPos = getTranslation("Player")  
      targetPos = vec3( targetPos.x, eyePos.y, targetPos.z )  
        
      -- compute look at matrix  
      lookAtMatrix = lookAt( eyePos, targetPos, vec3(0, 1, 0) )  
        
      eyeRot = getRotation( "Zombie")  
      targetRot = inverse(quat(lookAtMatrix))  
      rotation = shortMix( eyeRot, targetRot, rotSpeed*deltaTime )  
        
      -- make zombie look at player  
      setRotation( "Zombie", rotation );  
        
      -- move towards player  
      translate( "Zombie", vec3(0, 0, -speed*deltaTime) )  
 end  
   
 function slam( deltaTime )  
      -- is slam animation already playing?  
      if isActionPlaying("Zombie", "Skeleton", "Slam") == false then  
           -- stop animation cycles  
           stopCycle( "Zombie", "Skeleton", "Walk", 0.25 )  
           stopCycle( "Zombie", "Skeleton", "Idle", 0.25 )  
             
           -- blend slam animation  
           playAction( "Zombie", "Skeleton", "Slam", 0.15, 0.0 )  
      end  
 end  
   
 function update( deltaTime )  
      -- get position vectors  
      pos = getTranslation( "Zombie" )  
      target = getTranslation( "Player" )  
        
      -- calculate distance from player  
      distanceFromPlayer = distance( pos, target )  
        
      -- slam if very close  
      if distanceFromPlayer < 1 then  
           slam( deltaTime )  
      -- walk towards if close  
      elseif distanceFromPlayer < 5 then  
           attack( deltaTime )  
      else  
      -- ignore if far  
           idle( deltaTime )  
      end  
 end

Resource managment is finished and the entity system is basically complete. Static and animated models can be exported from Blender, which is actively developed and most importantly, free. Textures have to be provided in .dds format; there's exporters for both Gimp and Photoshop. The sound engine expects files stored in the OggVorbis format, which provides quality similar to MP3 without the competitor's license restrictions.

The entity system uses a component-based approach in place of the classical inheritance-based one, which means that there is e.g. an entity class Model which derives from a base class RenderEntity which in turn derives from an abstract base class Entity. Instead, an entity is merely a container for an arbitrary number of entity components such as models, sounds, cameras, decals etc. All these components have in common are a spatial or logical connection. There's numerous threads on gamedev.net dealing with the pros and cons to both approaches, in case you're interested. What was important to me is that the entity components themselves and the camera rendering them are ignorant of the entities these components have been attached to. Instead, whenever an entity component is added to an entity, it is added to a pool of like components and merely keeps a reference to the transform part (i.e. translation, rotation, scaling) of its parent entity. During rendering, a camera then fetches relevant components from these pools and renders them accordingly.

Composing e.g. a player entity which contains an animated model, the corresponding skeleton and a camera could look like this:

 shared_ptr<Entity> setupPlayer( shared_ptr<ResourceManager> resourceManager )  
 {       
      // load resources  
      auto model = resourceManager->loadResourceAs<Model>( "ak-47.model" );  
      auto skeleton = resourceManager->loadResourceAs<Skeleton>( "ak-47.skeleton" );  

      // setup camera  
      auto camera = shared_ptr<Camera>( new Camera(60.0f, vec2(1.0f, 1000.0f)) );  
   
      // setup mesh controller  
      auto modelController = shared_ptr<ModelController>( new ModelController(model) );  
   
      // setup skeleton controller  
      auto skeletonController = shared_ptr<SkeletonController>( new SkeletonController(skeleton) );  
   
      // add skeleton as modifier  
      modelController->addModifier( L"SkeletonModifier", skeletonController );  
   
      // setup new entity  
      auto entity = shared_ptr<Entity>( new Entity() );  
   
      // add mesh controller to entity  
      entity->addComponent( L"WeaponMesh", modelController );  
   
      // add skeleton controller to entity  
      entity->addComponent( L"Skeleton", skeletonController );  
   
      // add camera to entity  
      entity->addComponent( L"Camera", shared_ptr<CameraController>(new CameraController(camera)) );  
   
      return entity;  
 }

This is tedious and we don't want users to have to deal with writing code anyway, so that's where the editor comes in.

Weltwunder Editor ("the editor")
The editor's task will be to populate the game world with static geometry (the "level") and entities and to attach the appropiate scripts to them. The game world you create is the starting point of the simulation when the game is started. The player's interaction with the world and its entities is then controlled by scripts. Scripts can either be executed once each frame or started from other scripts, e.g. when the player enters a specific area or presses a button.
The editor uses the wxWidgets framework and would so - theoretically - run on multiple platforms. Right now, I'm developing on and for Windows only, though. It also has, just like the engine, full support for Unicode and is currently available in English, German and French.

The following short video shows how to create an entity representing an animated mesh model. It could be extended by adding headlights, muzzle flashes, sound effects, etc. Using the entity's name, all components can then be controlled in scripts.

Over the past week, I was racking my brains over the degree of asset customization that should be available to the user from within the editor. Usually, assets exported from Blender are perfectly fine and ready to use, but the engine supports some advanced material settings such as several texture layers each with different blend modes, texture coordinate generators, etc. which cannot be customized from within Blender. The problem is - how would I save such customizations? Should I overwrite the original files? What if the user re-imports his assets? In the end I decided to either write a small Blender plug-in or a stand-alone material editor.

The game shell
The game shell loads a world created by the editor and handles script execution to simulate a game. It works.

What lies ahead?
Right now, my focus is on the editor, even though I'm tempted to finally add some pretty graphics. I hope to finish entity management within the next four weeks, and then start on static, i.e. "level" geometry

I'm writing all this because everybody keeps asking me what the hell I'm doing all day and whether I'm still working on "that game of yours that you never finish" and also because I'm tired of always working for myself when I should share my experiences with others. So if you've got any questions, comments or need help with your own little renderer slash game engine, leave a comment or write me a message. Also, I'll try to write some lines about my progress on the engine at least once a week. But then again, that's what I always say.

Update: Editor development

2011-03-26T19:45:00.006+01:00

Wow, my last post has been over a year ago.. well, I've been working nonetheless, here's a quick update on the editor. Hope to update more regularily from now on.

New demo online

2010-03-10T11:52:00.020+01:00

I completed a small demo of my game engine for a school application. The demo shows dynamic lighting and shadows, the physics system and some post-processing effects including light bloom, depth of field and dynamic reflections. It uses my old framework from 2008, though. I did not have the time to adapt it for my new framework. Also, as there is no height imformation encoded in the normal maps, there is no parallax mapping. Don't worry about the low framerates on the screenshots, the demo actually runs pretty decent with most effects enabled. I just turned it all up to the maximum for the screenshots :) Have fun!

Controls:
- Control the camera with the cursor keys and by moving your mouse
- Press 1 to 6 to switch light sources on and off
- Press the left mouse button to push an object
- Hold the right mouse button to grab an object
- Press the space bar to pause the physics simulation
- Press F1 to F10 to toggle effects and debug options on and off

The program does not check your system for compatibility - if your graphics card does not meet the requirements, the demo will simply crash. Use at your own risk! Also, make sure you have the latest drivers for your graphics card installed. I developed and tested the demo on a GeForce GTX 260 with the 196.75 drivers.

Download: ~~Backyard Demo~~ (outdated and not compatible with latest AMD and NVidia drivers - new demos using the updated framework will follow soon!)

Some screenshots:

Hello, World!

2009-07-12T23:11:00.008+02:00

I have returned from a one-year stay in Norway and finally find the time to program again! I got a new graphics card to be able to fully use the power of Direct3D 10 and OpenGL 3.1 and installed the latest Windows 7 RC, and I love it!

But I had to admit that the engine, with its current design, is a dead end. So I started from scratch. I've been building up a stable foundation first, utilizing all the knowledge I gained in the process of building the previous one. Now I'm re-implementing all the features from the old project. The most important changes in design are:

- game state managment
- serialization
- use of interfaces for sub-systems like graphics, audio and scripting
- integration of more third party libraries, first and foremost boost

The renderer is still using OpenGL, but I'm slowly switching over to Direct3D 10. I might keep the OpenGL renderer for compitability reasons, though. After all, it's the API I know best. Font loading and rendering is realized with the Freetype library.
Sound output is powered by OpenAL, which is really easy to use if you're familiar with OpenGL syntax, and I've added LUA scripting. Initially, I wanted to expose most engine functionality to scripting and use it as the primary way to work with the engine, but I soon realized that it's not a good idea. I will limit its use to in-game events (HL² style) and material definitions, I guess.

For the new renderer, I want to use a deferred rendering approach to keep the rendering pipeline clean and simple. For shadows I'll stick to variance shadow mapping I guess, using a geometry shader to render shadow cubes (for omni-directional lights) in one pass. But there are still a lot of questions: Should I use one shadow map per light? Or one per mesh? Or just one global shadow map that is being re-rendered before every lighting pass? How to do particle effects? On the CPU alone? With a CPU/pixel shader combination? Or purely on the GPU? We'll see.

And yes, I know what they say: Make games, not engines. But I'm finishing my bachelor's degree in winter, so I have to start applying for master courses soon.. and for this, I'll need something to present my skills. So maybe, just maybe, I will be able to provide an interactive demo or at least a high quality video around October :)

Stay tuned!

Sign of life

2009-02-19T23:08:00.004+01:00

Whoever's been wondering why there heven't been any updates in months: I have been and still are in Norway for one year as an exchange student. All I have here is a cheap notebook with integrated graphics, so I haven't been able to work on the engine (I wouldn't have much time for that anyway). But my girlfriend is on a concert tonight, so I took the chance and bagged her vista notebook to finally check out Direct3D 10. So far I'm pretty impressed and being utterly disappointed with OpenGl 3.0, I might well consider switching to D3D when I finally find some time again to work on the engine. I miss it.

If you're interested what I'm doing all the time instead of programming, visit my (German) blog: www.norwegenjuhu.wordpress.com

I'm still alive..

2008-04-03T19:04:00.006+02:00

Damn, it's been more than three months since I've posted the last update. I've been very busy lately with university and two jobs, and I just haven't found the time to work on the engine. This week, I could finally dedicate some time to programming again.

I've completed the character controller and the terrain renderer, added support for sky boxes and improved the water shader. In addition to the usual reflection/refraction stuff, it eliminates hard edges where water and terrain meet: i render the distance between the water surface and the ground into a texture and then use this to mix the distorted refraction/reflection with the undistorted refraction.

Reflections

2007-12-18T02:21:00.000+01:00

The engine can now render reflections about arbitrary planes. Before, I had to setup the reflection matrix, the clip planes etc manually. Now all I have to provide is a plane equation, and everything is handled internally.

One item less on my todo list :)

Stencil light volumes

2007-12-13T21:54:00.001+01:00

I abandoned deferred shading after all and returned to classic multi-pass shading.. its limitations still outweigh its advantages. It's a shame, I had finally found a robust way to handle transparent geometry.

But there's also positive news: I'm going work with the guys from Panic on their project, semester break is close, and I've added stencil light volumes. The idea is the same as with stencil shadow volumes, but instead of extruded geometry, I render a cone (or a sphere respectively) to the stencil buffer. The result is a mask containing all the pixels that might be lit by the given light source. The performance boost is not as high as I expected, but it's still a somehow more elegant solution than scissor regions. I highlighted the masked areas on the screenshot.

Relief Mapping

2007-11-13T15:17:00.003+01:00

I've just added relief mapping using code from the ShaderDesigner example. Framerate loss is ~10% compared to simple parallax mapping. SM 3.0 only, of course :)

Variance shadow mapping & Bullet physics

2007-11-12T15:00:00.014+01:00

I've implemented variance shadow mapping, a simple modification to the standard algorithm that allows shadow maps to be filtered. I use bilinear filtering (mip maps are too slow), 8x anisotropic filtering and apply a gaussian blur and still get ~80fps with two light sources. I had to add a little hack to the lighting shader to get rid of artifacts, though.

The other two screenshots show simple bilinear filtered VSM and VSM with a gaussian blur applied and parallax mapping enabled:

I've dropped ODE and implemented Bullet instead. It's faster, more stable and its C++ interface integrates nicely with my code. I've also added decals using code from Eric Lengyel's article in GPG2, but I still have to find a way to blend them onto world geometry. The same is true for billboards. I might abandon deferred shading and switch back to multi-pass if I can't find a decent solution.

So what's left to do?
Omnidirectional shadow mapping - cube maps were to slow with the standard algorithm, they might work with VSM, but I can't use cube maps with deferred shading; I got it working with an unwrapped cube map, though. Still have to decide what's best.
Particle systems - should be possible to use Bullet for that.
Arbitrary reflections - and a way to render reflective surfaces with deferred shading.
Sky dome/box - should be easy :)

Deferred shading - does it pay off?

2007-10-19T21:30:00.000+02:00

Playing Stalker I asked myself how they managed to simulate so many light sources casting soft shadows at a decent framerate. I then read their article on deferred shading in GPU Gems 2 and thought, I can do that, too. Implementation was surprisingly easy, but the results were rather disillusioning - it ran about 5% faster than the classic multi-pass algorithm i was using before.

I soon realized that the problem was the g-buffer's setup. My naive approach was this:
3 half-float RGBA textures, storing diffuse color & specular intensity, normal & height and worldspace position, resulting in 16bit x 4 channels x 3 = 192bpp.

I could omit height as it's only needed in the initial pass (parallax mapping etc). I then read that it was possible to restore worldspace position from depth only, using the pixel's screen position and viewport information. This would not only mean that I could omit two more scalars; I could use a depth buffer to save it, so the other components of the g-buffer could be saved in fixed-point 8bit textures. Unfortunately, no paper explained this in detail :/ In the end, a professor from Erlangen University told me how to do it using a scalar saved in a floating-point texture. I modified it to work with a depth buffer, but that resulted in poor accuracy. On top of that, normals lose accuracy when saved in 8bit textures and reconstructing their z component from x/y proved to be unreliable, so I decided to stick to floating-point textures *sigh*

My current setup: 2 half-float RGBA textures, storing diffuse color & specular intensity, normal & worldspace position z, resulting in 16bit x 4 channels x 2 = 128bpp.

The performance boost is huge. But what I actually wanted to achieve is this:
2 fixed-point RGB textures, storing diffuse color, normal xy & specular intensity and 1 24bit depth buffer to reconstruct worldspace position, resulting in 8bit x 3 channels x 2 + 24bit = 72bpp!

While still far from perfect, the results are satisfying.
Aside from higher framerates, hardware skinning and effects like parallax mapping only have to be computed once per frame and my rendering pipeline is much cleaner.

Any suggestions how to improve my setup would be highly appreciated :)

No tech demo yet - but good progress and a first video

2007-09-03T14:40:00.000+02:00

Just when I had almost finished the level for the tech demo, I realized that some new bugs have crept in. Shadow maps were corrupted, frustum culling returned false positives etc. While fixing those bugs, I came to the brilliant conclusion that the demo would be much more impressive if it featured physics. So I implemented ODE, realized that it won't run properly before I've got some decent space partitioning working, started over, implemented octrees and then ODE again.

I did not want to be left empty-handed, so I've thrown together this short, low-quality presentation of the engine's most prominent features:

Upcoming tech demo

2007-07-28T01:02:00.000+02:00

I've started working on a tech demo to show off the engine's capabilities. I'm going to upload a video of it asap. I won't be able to provide a binary though, as it's using copyrighted material.

Stay tuned!

Wunderwerk Development Blog online

2007-07-24T13:42:00.000+02:00

I've finally brought myself to setup this development blog. I've been working on this engine for almost a year now, and graphics are almost complete.

For those of you who care: The engine is written in C/C++ using OpenGL for graphics. I have no plans to support DirectX, especially now that version 10 is Vista only. All shaders are written in GLSL, no fixed functionality is being used. What's still missing graphics-wise are particle systems, sky, cubic reflections and support for more image and model formats. So far the engine supports .tga and .dds image files and Doom 3 and Milkshape3D models including animation.

I've setup this blog because I'm often asked how this project is coming along and all I can do then is promise to send them some screenshots eventually. Also, i'd love to get into contact with other programmers who are interested in this project or who develop something similar. And last - but not least - there is nothing more motivating than a compliment. Still, don't hesitate to critize!

Finally, here are two screenshots of the latest features I've implemented: the left one shows two post processing effects, depth of field and bloom; the right one shows reflective/refractive water.