The World of 3D

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 ! πŸ˜€

CPU GPU love

Last year I've written about NVIDIA aiming for doing more general computation and INTEL going for more specialized, parallel vector computation. Since then we got tons of more info about Larabee, CUDA, Stream SDK, OpenCL, DirectCompute etc – all indicating that there might be a fusion one day.

According to a well-known german IT-News Site, INTEL revealed at the IDF09 that at the end of 2010 something called Advanced Vector Extensions (AVX) will be added to DIE of the processor generation named "Sandy Bridge". At a later time, this will be the place for the Larabee integration. Prior to that – in early 2010 – intermediate versions will be available where the INTEL's CPU / GPU mix will in the same box.

Sounds like this won't be "one" unity but separate units very, very close to each other. Obviously this will increase the speed of data-sharing.

"The CPU and the GPU create a co-processing environment where we have the CPU operating on very complicated sequential codes and the GPU operating on massively parallel applications."

Jen-Hsun Huang, NVIDIA’s President and CEO

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…