Anything related to game development (design, techniques, middlewares, libs, etc)

The Animago Award is a German CGI Award which has become more and more international in the past years. This time it took place in Potsdam, near Berlin at the Babelsberg Studio. This year there was also a conference which was mostly organized by the reseller Lichtblick.

I've to say that I was very positively surprised by the conference, I enjoyed it a lot – therefore thumbs up! It also allowed me to see some people again. For example Hanno who now works for Naughty Dog and previously at CryTek. He did a talk about Uncharted 2, I've a few notes maybe I can remember something from it … hm… I can barely read 'em 😐 … sorry will be rough!

Creating a Character Driven Game – Hanno Hagedorn, Naughty Dog

  • 8000 triangles per hero head
  • no manual low-res creation, reduction automated for faster iteration
  • Mudbox and Photoshop used (for texturing?)
  • I think he sad something about how to have a better look for the skin. I think they controlled the red tones via an extra channel that did the masking. Maybe that was mixing insidea shader via a Fresnel term or so.
  • extra ambient lightmap butthat maybe not used in close-up shots (cinematics)
  • they used 2 normal maps
    • one rough
    • one for the skin shader to produce specular highlights

  • texture variations for wet/snowy cloths and skin that got blended in dynamically
  • dynamic wrinkles using ambient occlusion and normal maps that got dynamically blended in
  • hair had around 4000 polygons (i guess triangles)
  • per frame light baking for the skin,
    • (maybe at 256er resolution)
    • which got blurred 
    • my notes say "red blur edge", not sure what it means πŸ™
  • faces were hand modelled
  • audio  (voice) and body motion-cap was done at the same time
    • better quality of voice acting and sync
    • extra cameras to record facial expressions
    • facial animation was manually animated using the reference material from the mo-cap sessions
  • all deformations with bones no blend shapes (no morphing)
  • 76 bones per face

Some more general infos

  • level editor and cut scenes inside maya
  • pre-process/-production 6 months
  • production 1,5 years
  • no producers due very experienced and skilled team = flat hierarchy
  • PS3 only game
  • access to Sony's PS3 expert team

Crowd Simulation – Paul Kanyuk, Pixar

Another interesting talk was from Paul, TD at Pixar. He explained various crowd simulations done for films like Ratatouille, wall•e and Up.

  • Secondary animations via signal processing
    • creating secondary animations procedurally can become quite processing intensive
    • using signal processing on various inputs (transformation, animation etc) creates nice effects at much lesser costs
    • example Robots stopping suddenly with spring-like overcompensations
    • but phases (i.e sinus phases) should not shift
  • massive was used with Maya and Marionette
    • flow-fields on terrain to help brains via color maps
    • 6 short animation clips
    • data transport between different tools (massive, marionette etc) via invisible bones
  • different rules combined via weighting
    • avoidance
    • leader follow
    • helps to tweak, fine tune behavior
    • 200 to 1000 rules for foreground actors (? hm not sure about my notes here!)

Well, so far for now. These were the highlights. As said a bit rough but maybe you got one or another thing for you out of it.

Wow, what an exciting time for real-time 3D enthusiasts!


Epic released the UDK for PC: the Unreal Development Kit based on the famous Unreal 3 Engine! For non-commercial/Edu use it's totally free. And for commercial use there is a very reasonable and transparent pricing:

  • Internal Use: 2.500 US $ per developer seat per year
  • Publishing: 25% royalties for revenues above 5000 US $
  • Internal Use may stack with publishing thus: per seat per year plus royalties

You can read it directly on their site. Checkout the features, here some highlights:

  • SpeedTree included – with editor
  • global illumination solver
  • Bink Video Codec
  • Animation is driven by an AnimTree
  • animated Facial normal maps using a visual scripting system
  • slicing of objects for physics-based destructions
  • distributed assets processing
  • automated creation of navigation meshes for pathfinding
  • visual shader creation system
  • and much more of the "usual" Unreal Engine stuff πŸ˜‰

Another YAY πŸ˜€

One important note though: this is basically the modding access. No source code access. So this may mean that if you can't script what you need, you won't be able to implement it.

Guys, not only the next free update just got release. It's also that the formerly "Indie" version is now available for free !!!!! !!!! !!!!

Go download it NOW


It's so intensively refreshing to see a company of enthusiasts doing all the stuff I was hoping for Virtools over so many years. When I read their interviews I sometimes I get the feeling that they read my mind! But moreover they go even further with it!!!!

Thank you!

Background details in this Gamasutra interview and in in their 2.6 press release. And look at the Unity 2.6 release notes or have at glance at this extract:

  • streamed loading in the background
  • new profiler
  • animation curves
  • possibility to use any version-control system
  • new audio backend
  • better integration for Visual Studio
  • Render Target AA (nice !!)
  • Floating Point Render Target
  • Snapping
  • Terrain Brush size Preview
  • New hotkeys for Terrain editing
  • Debug Releases of the Standalone player
  • direct import of Cinema4D files on Windows
  • fixed rendering artifacts for intersecting geometries on windows
  • etc

Before opening your projects with 2.6, backup! 2.6 does a reimport and break backwards compatibility!

Interactive 3D for all – especially for casual games – is now !!!

YAY ! πŸ˜€

GarageGames has released it's new product Torque3D last week. Time to have a look at it! πŸ™‚

I've to say, that I never used GaragesGames products before. Correct me, if my first impressions are wrong.

Installation and Startup

Let' begin with the first step: installing: went smooth except it defaults to a target directory right under C: instead under program files. Moreover it doesn't prompt for the start menu location. Things that a modern installer shouldn't do anymore.

GarageGames kinda remained to it's used scheme: a start dialog, called Torque Toolbox, allows to select the project and then what editor to launch. It's not a all-in-one editor approach but world-editor and GUI editor are separate. What I like is the list of all available projects, as it allows to switch between different projects quickly.

Torque3D Toolbox

Instead of starting with the demo project, I start with a blank one as it forces me more to explore and trying out things – and thus might to things that are unexpected. Creating a new project shows a confirmation dialog that is unfortunately not big enough to display the whole message (target path).

Editor GUI

The world editor consists of one window with a custom GUI inside of it. It's not possible to tear off GUI elements for a secondary display. On XP machines this is bad for dual-monitor setups in non span-modes. On Vista the 3d acceleration works a little better on the secondary screen thus it might be less a problem in future.

Using the Function-Keys one can toggle between different editing modes: terrain sculpting, terrain painting, material editing, world editing etc. Depending on the editing-mode an "inspector"-like dialog on the right side adapts it's content. Unfortunately that inspector-window doesn't snap to the right side – it's aligned and sized correctly for the startup window size, but upon resizing the main-window it doesn't adjust automatically. This is not so good.

Torque3D Editor

As I said, the GUI system is custom (except the main menu bar). It can be scripted and therefore the editor itself can be extended via scripting, which is a very nice thing. The GUI itself looks quite good and comes with resize-able panes and collapsible panels. Also the color dialog is good. Windows or panes also snap in range of each other but as said, there are no real docking areas. Editing values like vectors in the inspector is not so good. It's merely a text field with all values listed and separated by a space/blanc character. It seems that there is no way to "slide" values using a separate-gui-handle or a right-click drag operation. This makes tweaking very ineffective.

Moreover the keyboard shortcuts do not take localization into account: undo is on the German keyboard not CTRL+Z but CTRL+Y. But the good news is, there is UNDO ! πŸ™‚ 

Scene Navigation and Object Transformation

Navigating the scene is easy with the WASD controls and the mouse. Unfortunately there is no speed modification by holding the shift key while flying but there is a slider in the GUI that allows to adjust the speed, … good! Besides the fly-mode there is also an orbit mode. Sometimes the camera does reset it's position and orientation to suboptimal distances when switching between the modes – this gets annoying pretty fast. It is possible to define "view bookmarks" which is nice and not often seen in 3d authoring tools. Using the 'F' key, you can focus the view to the selected object – like in Unity.

Very nice is the 3D transformation handle/gizmo/manipulator. It also includes handles for translating on a plane – like in 3ds max. But it requires to pick it up quite at the corner, which is not so optimal. There are also snapping tools and a mode to snap the object to the terrain surface, very cool! You can also toggle between the object's bounding-box center and the object center, which should be the pivot point. Holding shift while dragging and object, creates a clone – nice! Switching between transformation modes is fast with the key 1 to 4.


Materials seems to be based on a uber-shader. Therefore is quite easy to tweak materials – unlike in Unity which has a powerful shader-system but when one is wanting a material-variation where it's double-sided or using vertex-colors, it requires to copy the shader and modify the shader code of the copy manually for the desired effect. A couple of features like glow, specular, detail map, normal maps etc. are just check boxes thus very easy to enable/disable for a selected material. Torque3D offers max.  4 layers / 4 passes per material. It's maybe not that customizable, but really easy to setup. Moreover it already includes frequent aspects like specular or normal maps, emissive color and transparency.

Torque3D Material

Creating new materials seems to be not very intuitive with the material editor. I often tried to create a new material but somehow it was never stored properly. Better is to tweak an existing material, but even with this I had problems. I wanted to modify or change the material of an imported object and switch to the object-editing mode, called Shape Editor. But even there I had not much luck. It's a bit confusing as the GUI obviously allows actions that are not valid. Also terrain materials can't be created in the Material Editor Mode but have to be created via a separate terrain operation that is listed in the main menu – i.e. via "import height map". So let's go with terrain creation and modification.


When you import a height map, you have access to the dialog where you create material layers and their textures. Unfortunately it's a bit buggy as it allows tweaking of the texture slots without creating a layer and sometimes material names are not saved back into the channel list. Deleting a material there seems not to be possible. Some text labels are not very well named: "texture maps" would be more descriptive when called "masking textures" or something like that. Luckily the documentation is already quite good and also features the very important search functionality.

Blending between terrain-materials happens on a per-vertex basis, often also referred as "texture splatting". I like per-pixel blending but per-vertex blending allows cover bigger terrain chunks. Unlike in Unity, Torque3D can't smoothly blend multiple materials upon each others. It does blend in a linear way between material "tiles" but you can't mix. This is not so good, as creating terrain texture variation becomes more difficult.

Terrain blending

Terrain materials consists of a diffuse map that gets stretched across the whole terrain mesh and a detail map that is blended in at a specifiable distance from the current camera position. Moreover you can define an additional normal map for the detail.

Paint brushes allow to paint materials or terrain height easily. The brush size can be resized on the fly by holding CTRL and using the mouse-wheel. Unfortunately this also zooms the camera at the same time. Moreover the brush size value doesn't get updated in the GUI. Otherwise the change can be changed via the GUI. Also not so good is the maximal brush size of 40 units. The painting or sculpting process works very smooth – no performance problems! In Unity I sometimes had it working less smoothly. Also nice are two slope filter options, so painting only happens in the specified slope ranges. What should be added though are presets for fast switching or memorizing values, plus noise/blur functionality as hard filtering doesn't always give a nicely blended material distribution in transition areas.

I tried to import a height map but that failed. It says to look into the console for further details but I have no idea how to open it!!!

At the distance the terrain LOD sometimes gives slight shading artifacts on slopes due the vertex-lighting. The triangulation can become noticeable at distance, but no "popping" effect occurs. Also no cracking holes at cliff-like mountains, something I sometimes saw with the Unity terrain.

An interesting feature is the possibility to project terrain UVs from the sides for a specific texture. Unfortunately there is no instant feedback when editing properties of terrain materials, one has to close the dialog to see the changes. It's classic GUI mistake – instant feedback allows faster tweaking!

Rivers and Roads

Let's get to something nicer: road and river creation tools based on splines! You can change the edit-mode to create decal-roads, mesh-roads or rivers. Decal roads are a flatly extruded shapes along a spline path with a decal texture. Creating paths for roads and rivers, is ultra easy and fast. Simply click on the terrain where you want the next curve-node to be. The spline can be tweaked afterwards: move, remove/add nodes or changes the width! When creating rivers, holes between the river surface and the terrain surface gets shaded red ( in editing mode), so you instantly see layout-errors, nice! Rivers have a refractive and reflective material with mesh and normal map deformation for waves. They also have a foam texture at their borders but it's unfortunately not smoothly blended out at the borders – thus on beaches it might get a hard cut.

River Waves Spline-Based Roads Bridges

The "mesh-roads" also gives height to the roads. This can be used to also create bridges fast. What I am missing (or I simply didn't found out how to do it) is the possibility to use transparency for decal based roads, so they can be made to blend it's edges smoothly with the ground. Imagine using it for paths that don't have sharp shapes.Sure, you can paint paths, but using decal roads might have it benefits, too. The reflections of the river may become unaligned, if the rivers flows quickly downhill (strong slopes) – but that's not surprising. 

Btw. the trees you see in some of the screenshots are COLLADA files that I downloaded from 3DVIA. Adjusting materials is not always straight forward but over all it works painlessly. 

 To be continued …

I already reported about prior attempts. Now one of the Unity developers uses his "do-what-you-want" Fridays to experiment with a visual scripting system.

Unity VLE proto

That 'development experiment' is currently called "Visual Logic Editor". You will notice that it's purely event-driven plus it contains low-level logic-components. Thus it looks more in the style of Crytek's Flow Graph and maybe a bit like Unreal's Kismet.

This kind of system are also used a lot in procedural content generation like found in .werkkzeug, mapzone/substance air and genetica. Or for Shader creation like with ShaderFX or mental mill.

Virtools hierarchical graph works quite differently as data and program flow are modeled separately – Kismet seems a bit like like a hybrid in that area, but as I never tried I don't know for sure. I hope at one point VLE at least goes in the direction of encapsulated hierarchical flows, because otherwise it may become quite messy with growing logical complexity – most systems add that at a later point anyways.

Example of how messy a Flowgraph can look like (found on the web):

Messy Flowgraph

The key for visual scripting system are hierarchical ones. It's like a LOD – level-of-detail system or programming functions/methods plus it facilitates re-usability. Personally, I prefer modeling state-machines that defines behaviour with these kind of of hierachical visual-scripting systems, as you can *look* at the relations and patterns. In code it's not that visible at a glance, in my humble opinion – even when using Co-Routines.

Last time I gave an overview on what VBuilder is and how it improves iteration times. This time I'll give a small example by showing some extracts of what it takes to setup a project.

VBuilder is driven by commands coming from an XML file. Here is an how this can look like:

<!– register data resource –>
<register_dataresource xsrc="demoproject.rsc"/>

<!– load the cmo –>
<load_cmo xsrc="../CMOs/main.cmo"/>

<!– execute build process –>
<execute_script name="INIT"/>
<execute_script name="Load Buildings"/>
<execute_script name="Load People"/>

<!– set the save options for images and sounds –>
<set_save_options name="images" value="IMAGEFORMAT"/>

<– save to VMO –>
<save_changes name="content/demo.vmo"/>

So first one or more data resources are registered. Basically it's adding the search paths for external resources like textures and audio. Then a CMO is loaded. It contains the import and processing logic which then gets triggered. Usually you have textures outside but if you want to include them for the final file, this can be done like shown above with the save_options commands. At the end the new VMO, that includes freshly imported assets, is saved and can be started ie.e with the webplayer.

Btw. VBuilder also supports commands like setting values for script-parameters – very useful for making sure that debug-information is turned off for release builds!

So how does the assets import looks like? Well, this is adjustable to your needs but here is how I often do it:

So basically it's a scriptable build pipeline. Some people asked in the past years what we do and here you got it finally unveiled. It's actually a pretty simple concept and similar to bigger gamedev projects. I could bring it even closer to traditional gamedev projects: a future version could detect what files changed and only process those. That could be VBuilder V2.

Feel free to contact me about it, if you're interested to use these tools. I say tools, because I would add BBs like the Directory-Parser which is especially useful for projects that did not license the XE player.

In early 2006 I started to rethink the build-process for 3DVIA Virtools projects. It's a topic where many people from the Virtools community dive into one day or the other.

The problem

The standard method of doing an assets update for your project is, to let the 3d artist export the new assets versions, then a Virtools developer drops them into the CMO from the resource database and chooses what to replace and what to keep. One by one….

Some developer used custom scripted loading processes and so did we. We used text files and assets loading buttons for some projects. Text contained data of what material or mesh uses what shader and what attributes. But it came out that updating/maintaining those text files was quite error-prone and somehow not really artists friendly. Moreover building the final product for testing still required a bit of the time of a Virtools developer … time that was better spend on bug-fixing or adding features.

The solution

So, the new iteration was a command-line tool we created. Currently I am thinking about a new, better name. For now I will refer to it as "VBuilder". It's a one-click processor that is able to produce VMOs from CMOs using a list of simple processing-commands inside a XML file. A different XML file can be passed to the tool via the arguments, so it's possible batch-build for different VMOs.

We started to use directories as rough top-level for classifications of 3D assets: roads, buildings, cars, people. Adding a new car or a new building became a simple task: the 3D artist exports his new car as NMO to the "cars" directory, then he triggers VBuilder and within minutes a deliverable VMO file is available for testing.

What it requires though, is some up-front import-pipeline coding inside Virtools for each project (which might be reusable for different projects) and – in our case – naming conventions for objects and materials inside 3ds max etc.

What effect did we achieve with this?

Initially we had an iteration time of aprox. one day. This has to do with the fact that a Virtools programmer is not always available or ready to interrupt his development work for an assets integration-cycle.

So the artist may come to him and say: "Hi, I updated some buildings and some cars, can we have a look at it?". The programmer responds: "Let me just finished this little script first. It will only take 20 minutes" … … … then 2 hours later: "Ok, took me longer but now I am read… ???!! Hello?" – the artist went home as he comes to the office a lot earlier than the programmer!! He then does the integration and writes a notification about it. Next day, similar procedure. You see, this scenario really may happen and if you have a lot more Gfx ppl than coders it might get worse. I remember one project, where we had a junior Virtools developer doing mostly one thing: reimport new iterations from the graphics team.

With VBuilder the iteration cycle, for already available content-types, went from worst-case one-day to worst-case 5 minutes. Sometimes it only took 1 minute including startup of the player for testing. The best thing is, it even scales. I was able to support eight 3d artists while having time for adding features or doing bug-fixing. They were doing their stuff and it only needed my involvement when new item-types had to be created.

So with that team and VBuilder we were able to theoretically have several hundreds of content-update iterations or content-extension iterations per day! No idea how many they really did but they did plenty. That's a boost, ain't it?


So, after 3 years beeing in use I am considering making it commercially available. It's no magic tool but it allows what I have described above. If you have several 3D artists in your team and you want to free programmer resources, this might be something for you! For me the effort to make it available only makes sense, if there are several teams or people willing to buy this. Thus if you think this is something for you, get in touch with me. Write me an eMail with "VBuilder" as subject. Also let me know what you think of what would be a fair price for you and on how many machines you would like to run it on.

Making it even better

I have a couple of interesting ideas of how to bring VBuilder to the next level. Currently it's focus is triggering the import and processing and building VMOs. This has some backdraws when working with the CMOs inside Virtools "Dev" and I think there are some interesting ways to make it even more efficient. If there is commercial interest, I would bring VBuilder to a new level!

To be continued …

Now this gave you a rough idea what VBuilder is about. In the next part I'll go into some details on how exactly it works.

I am becoming a .Net/C# fan πŸ˜‰

With it's reflection ability, you can do some nice things. For example output all public data values of an object onto your screen. A little minimal example for Unity debugging/tweaking purposes …

Let's say we have two classes with public data we are interested in

    class MyDataOne : Object
        public float AirDensityRo = 1.225f;
        public float LengthInMeters = 2156.33f;
        public float MetersPerSecond  = 2.0f;

    class MyDataTwo : Object
        public int Iteration = 0;
        public float Offset = 13.0f;
        public float Affinity  = 2.0f;

We then save both instances into a list

List<Object> DisplayedDataObjects = new List<Object>();

void Start()

   DisplayedDataObjects.AddRange(new Object[] { new MyDataOne() , new MyDataTwo () });


 And in the OnGUI context you can draw the values for example like this


        float yOffset = 15;
        foreach (Object obj in myDisplayedObjects)
            yOffset += 5;
            GUI.Label(new Rect(5, yOffset, 240, 20), "== " + obj.ToString() + " ==");
            yOffset += 15;
            FieldInfo[] fields = obj.GetType().GetFields();
            foreach (FieldInfo field in fields)

                if (field.GetValue(obj) != null)
                    GUI.Label(new Rect(1, yOffset, 240, 20), field.Name + ": " + field.GetValue(obj).ToString());
                yOffset += 15;

The nice thing is that you can rename (refactor) member names and classes without worries as changes will visible immediately. With the list you can also modify quite quickly in what objects you're actually interested in.

The reflection stuff is in "System.Reflection".

Just a little note, mostly for that I remember it better in the future πŸ˜‰ . Like Virtools, Unity's coordinate-system is Y-Up, unlike 3ds max where it's Z-Up.The Virtools exporter does all the conversion for you under the hood (except for Characters).

Looks like for Unity you need to pay attention. Currently my level in Unity is rotated 180 degrees around the up-axis, compared to the 3ds max scene. I realized that a bit late …  Anyways, for characters, car and the like one can do the following to get the same Z-Axis alignment as forward orientation in both applications:

Go into pivot-edit mode ("Affect Pivot Only" in the Hierarchy of the Command Panel) and rotate the pivot so that Z-Axis (blue) points forward, the Y-Axis points upwards and the X-Axis points to the side (left side). Then in the FBX export dialog choose "Z-Up" under "Axis Conversion". This way, it's very close to the Unity system – only the X axis is mirrored.

I've already my roads most of the time hovering above the terrain but still sometimes the terrain temporarily "shines" through depending on distance and view angle. I guess it's due the terrain's LOD, so some polys might become higher than intended on some LOD levels.

Terrain and roads intersection

In Virtools there is something called "Render Priority": a per-object settings that can be adjusted in the hierarchy manager. It can help for these kind of situations. I was looking for something similar in Unity. The editor itself doesn't seem to have anything related but the shader framework, called ShaderLab, itself has.

So you have to download the built-in shader sources, and create a derivate. First I thought it's the SubShader RenderQueue-Tag, but that didn't had any visual impact. You have to adjust/bias the z/depth buffer value via the Offset state.

Less intersection due Offsetting the depth

In my case I went through the "diffuse" shader and added an "Offset -1,-1" to any spot where RenderStates where set. Like you can see from the image above, it helped a lot. Unfortunately it's not perfect, I am still having tiny but annoying cracks here and there when driving or flying along the roads:

still some small artefacts

I guess I've no choice and adjust further the terrain heights manually to get rid of them…