• 3D engine
  • The Renderer
    • Pixel and vertex shaders
    • Lighting
    • HDR (High Dynamic Range)
  • Animation & FacePoser
  • Geometry
  • VGUI
• The Physics System (Based on Havok)
  • Rigid body dynamics & constraints/joints
  • springs, ropes, cloth & vehicles
  • Water & Fire
  • the particle system
  • Monsters/NPC's & procedural physics
• The material system (brings the other components together)
• AI System

The Renderer

This is the part that makes the most use of your graphics card and the bit that often gets more attention than it arguably deserves. The Renderer creates the picture you see on your screen: it takes the geometric and textural data and then through a rather complicated process creates a "3D" image. Valve didn't create the Source engine's renderer from the ground up, instead opting to use Microsoft's DirectX API. Doing so saved Valve much valuable time, due to DirectX's already established hardware-support base. The original Half-Life engine was designed to work with both OpenGL and DirectX (Direct3D). In designing Source, Valve dropped OpenGL in favour of DirectX in mind of its rapid evolution and superior support for features like SM1.0 and 2.0.

Pixel and Vertex shaders
In case you're wondering, a shader is a program that runs once for each vertex or pixel that is going to be displayed. In the case of real time graphics, shaders are almost always run on your graphics card.

The idea of shaders is to replace fixed function T&L (transform and lighting), allowing programmers to create their own shader effects instead of a limited number of preset ones built into the hardware. This means that if a new bump mapping technique comes along, a programmer can make a shader for it to run on existing video cards, instead of having to wait for the next generation of hardware to have it built in. Unless, of course, current hardware couldn't handle such a shader (either its complexity or length).

(http://www.hlfallout.net/images/content/articles/features/full/antlion_shader_full.jpg) image: http://www.hlfallout.net/images/content/articles/features/thumbnails/antlion_shader_thumb.jpg Source's use of shaders add much to a scene's realism.

Source fully supports pixel and vertex shaders version 2.0 and Valve have intimated future support for 3.0. All its shaders are written in HLSL (high level shader language, as opposed to the difficult to use "low level") and can simply be dropped into the engine without the user having to recompile anything. This makes Source's graphics very flexible.

For the player, this means more complex and diverse special effects, the most talked about SM2.0 effect is HL2's water which includes stunning reflection and refraction shaders. If you want a more indepth explanation of HL2's shading, take a look at this pdf on the subject (6.65MB) (http://www.hl2fallout.com/downloads/content/articles/D3DTutorial10_Half-Life2_Shading.pdf).

Lighting
The core of the Source engine's lighting uses light maps and vertex lighting. Light maps are calculated before the game runs and are basically textures that are applied to certain surfaces in game. When a map designer compiles their map, a tool (either created by Valve or a 3rd party) calculates the lighting in the map using radiosity calculations (http://www.siggraph.org/education/materials/HyperGraph/radiosity/overview_1.htm) and then dumps it to a light map.

(http://www.hlfallout.net/images/content/articles/features/full/Vertex_polygon_full.gif) image: http://www.hlfallout.net/images/content/articles/features/thumbnails/Vertex_polygon_thumb.gif Normals, vertices and polygons.

Light maps create very pretty lighting for static geometry, but are useless for moving objects. For these, Source uses vertex lighting (a vertex is the corner of a polygon). The Source engine takes each vertex of a polygon and calculates how bright it should be depending on which direction it's pointing (its "normal"). The calculations depend on the distance from the light source and how bright the light source is.

The down side to vertex lighting is that objects don't create shadows. To make matters worse, 2D light maps only allow for movable objects to be in complete shadow or not at all, resulting in a harsh transition from light to dark. Valve have found workarounds for both these problems, but they are not fool proof.

In order for movable (or dynamic) objects to create shadows, Source uses a method called "projected shadowing". This takes the vertices of a model and projects them onto the background surface, creating a shadow polygon. The angle at which it is projected depends on the light source's position.

NOTE: In Source, there is one master light which determines the direction of all shadows in the level.

This method has its drawbacks as you can sometimes see in the videos and screenshots of HL2. The problem being shadows are only created on the fixed geometry. This means dynamic objects sitting on top of one another don't appear to have any shadow (i.e. objects don't cast shadows on each other), until you take a look at the floor below. The floor then has all shadows projected on top of each other (combined). This is because projected shadows can only be made on flat surfaces and the dynamic objects in HL2 and other Source games are more often than not. uh. un-flat.

As for the instant light to dark problem, this can be fixed with clever light placement and "cone" lights which have a "virtual shadows", so to speak. If half the vertices of a model are inside the light's cone of influence then only half the model will be lit by that light. This effectively means you can have very smooth transitions between light and dark, but global light sources like the sun can't use this method to improve lighting.

You can find more information on vertex lighting here (http://www.planetunreal.com/phalanx/tut's/tutorial_vertex.htm) and here. Some more in depth information on light maps can be found in this article: http://www.opengl.org/resources/tutoria.../node132.html (http://www.opengl.org/resources/tutorials/sig99/advanced99/notes/node132.html)

Something that has caused confusion in the past is "dynamic lights". A lot of people often ask Valve if they have dynamic lights and the good folks at Valve always reply "yes", with some indignation. This is because dynamic lights were in the original Half-Life and just about every other 3D game that ever existed. All a light has to be in order for it to be qualified as dynamic is to be able to move and have changeable attributes (some people treat moving and changeable attributes as the same thing). It doesn't mean that it will cast real time shadows like in Doom 3 or Unreal Engine 3.0. Although Source may support some kind of real time dynamic shadowing it's never been demonstrated and is not mentioned on any of the currently released Source documentation.


HDR (High Dynamic Range)

(http://www.daionet.gr.jp/~masa/rthdribl/) image: http://www.hlfallout.net/images/content/articles/features/thumbnails/hdrtube_thumb.jpg Click for a demo of HDR in action (external link).

Something that a lot of fuss is made over, but isn't really understood is high dynamic range. The reason it is misunderstood is not because it's a highly complex concept, but because it can be difficult to explain and people often mistake things like "light blooms" to actually be HDR instead of something that HDR can produce.

Let's say you have two rooms, one next to one another. One of them is brightly lit and the other is dimly lit, yet you can see just as well in both rooms. The fact probably doesn't seem that odd to you but it should. One of the rooms is no where near as bright as the other, if you took a measurement of how sensitive your eye is in the brightly lit room, it would indicate that you should barely be able to see in the other. Yet if you spent 1 or 2 minutes in the other room you would be able to see just fine in there. In the real world, this is because your eye's sensitivity changes depending on the brightness of your surroundings. This is to do with the way the eye's receptors deal with light, and the expansion/contraction of the iris.

If you had a room that was mostly dark except for one very bright corner, the objects in that corner would almost appear to glow as they are so much brighter than the rest of the room. This is described as a "light bloom". If you lit up the rest of the room then they would look normal. Consider when the corner behind you is still in darkness and upon looking at it, all you can see is a blackness with the exception of one or two greyish objects. Before the room was lit up the aforementioned objects appeared to have more vivid colours. These effects are caused by your eye changing its sensitivity to match the average brightness of whatever you're looking at. Areas of your vision that aren't close to this average will either be too bright or dark to make out much detail.

In computer games without HDR, this simply doesn't happen. This is because only colour information is stored for each pixel and subsequently each object or surface in game. How brightly an object is being lit isn't actually stored so when lighting the surface of an object, the renderer just increases or decreases the colour value's to show how brightly it's being lit (without any reference to the brightness of the surroundings). With HDR, the renderer stores the brightness of each pixel. With this extra information, the scenario described in the above paragraph can now be simulated in game. This is because the intensity of a light source can now be higher or lower than total black or white which are the limits of the colour channel. Of course, at the end of the rendering pipeline the colour values are still increased/decreased depending on how brightly the pixel is being lit. However, lots of new effects can be created with the HDR information.

Here's a real time demo of HDR in action: http://www.daionet.gr.jp/~masa/rthdribl (http://www.daionet.gr.jp/~masa/rthdribl/)

Animation, Geometry and VGUI

Animation & Face Poser

(http://www.hlfallout.net/images/content/articles/features/full/alyxfacialanim_full.jpg) image: http://www.hlfallout.net/images/content/articles/features/thumbnails/alyxfacialanim_thumb.jpg Alyx shows who's boss of facial animation.

Like in most modern engines, the animation is controlled through a skeletal/bone system. In fact, the original Half-Life engine pioneered the use of skeletal techniques (to great effect, I might add). Multiple animations can be applied to the same model at once, allowing for complex animations to be made out of several "pieces". This approach also allows for integration with the physics system.

For the player, this means more realistic characters and monsters. Because two animations can be played ("blended") at once, a character can run, shoot and react to being hit by a bullet all at the same time. This can be accomplished with other animation techniques but they aren't as convenient for this purpose.

Possibly the most unique feature of Source is the facial animator. From what players had said about the first game, Valve decided that more realistic characters were essential for Half-Life 2. In order to achieve this goal, Valve thought up a system that includes simulated facial musculature and voice recognition (aided by text files in most cases).

To create complex facial expressions, Source uses "keyshape" animation (also described as morph target and vertex animation by Bill Buren from Valve). This involves a set of predefined expressions that can be combined/blended and interpolated between to create the life-like facial animations seen being used by Half-Life 2's characters.

In order to save the animator time and energy, Valve have also implemented voice recognition software (VRS) into the Source engine. To achieve an accurate animation, a text file will have to accompany any speech files. Apart from that, a level designer needs simply to drop a sound file and its corresponding script into the Source engine to make a character speak. All the facial movement will be generated from interpolating between keyshapes that are chosen by the VRS depending on which word is being spoken. These keyshapes will also be combined with a keyshape that represents the characters current mood. The animation system most likely uses weights to make sure the right keyshape gets priority over the right part of the face (valve calls this "simulated musculature").

Geometry

(http://www.hl2fallout.com/screenshots/screenshots/gman_oldnew?full=1) image: http://www.hlfallout.net/images/content/articles/features/thumbnails/gman_oldnew_thumb.jpg Source's increased capabilities allow for amazing high-poly characters.

Geometry in HL2 comes in the form of meshes (e.g physically simulated objects, characters), static meshes (non physically simulated objects), sprites (particles, a single quad), the BSP tree (surfaces created in the hammer editor) and some variations on those already mentioned.

NOTE: it may be that all geometry is stored using BSP trees, but when I refer to the BSP tree I mean the geometry actually created in the Hammer editor (map editor for Source) that usually has a light map applied to it and that allows objects to cast projected shadows on to it.

A BSP tree (Binary Space Partitioning tree) is used in the Source engine to store the vast majority of static geometry (and maybe some non-static). It's beyond the scope of this article to discuss all of the things but for a further explanation of the BSP tree, see this article http://www.gamers.org/dhs/helpdocs/bsp_faq.html (http://www.gamers.org/dhs/helpdocs/bsp_faq.html) (although Source most likely uses it for more purposes than the article mentions).

When I say "meshes", I mean the objects whose geometry resides in a separate file to the map file. The Source engine uses the .mdl file format for mesh storage. Meshes are usually used for movable or complex static objects. This is because they can be imported from programs such as XSI and 3dsmax that are specially designed for modelling and animation. Plus, the .mdl file can be used by multiple levels without having to copy the geometry to each map file. Or, in the case where you have many instances of the same object in one level, it doesn't waste space inside an overcomplicated BSP tree.

VGUI
Something to get excited about if you want really fancy menus or in game computer terminals, is Valve's graphical user interface. A GUI is the opposite of command/bash prompt, instead of typing in commands you have a graphical display that you can interact with. The idea of VGUI is to allow developers to make GUI's that are rendered using the Source engine and that can be displayed on any surface in game. VGUI is more than just a menu system: it provides windows, buttons, popup boxes etc. These can be displayed depending how the developer wants them and where their wanted.

VGUI can be used both in and out of game (on Steam for example). It's not clear if Steam already uses the full VGUI at the time of writing (or if it ever will do). However if it were to, in theory, you could use pixel shaders for fancy effects on your Steam UI.

NOTE: Someone from Valve referred to the Source engine's incarnation of VGUI as VGUI2.

Physics System
One of the first things Valve decided they needed for Half-Life 2 was a physics system that allowed the player to make a bigger impact on the world around them, and provided a wide range of game play possibilities. They were searching for a system that would allow such a level of interaction that it could form a core part of gameplay and not just another piece of eye-candy. What they eventually decided upon was the Havok physics engine.

Since they licensed and integrated it into Source, Valve have been tweaking and adding to Havok to the point it's virtually a new animal. Almost every aspect of the Source engine follows on from the physics — including the sound, graphics, AI and animation. When asked whether or not they would be upgrading to Havok 2, Valve seemed to suggest they probably wouldn't, in part because H2 wouldn't be much of a step forward from what they currently have.

(http://www.hl2fallout.com/screenshots/screenshots/striderattack?full=1) image: http://www.hlfallout.net/images/content/articles/features/thumbnails/carshoot_thumb.jpg Nearly every object in HL2 is subject to realistic physical interaction.

Rigid body dynamics & Constraints/Joints
As the name would suggest, a rigid body is something that cannot be crushed, bent or in anyway deformed. Rigid body dynamics are the most common application of physics in today's games — it's simply the physical simulation of non-deformable objects. It's used for simple objects like boxes, barrels and the odd plank of wood. It is also used for ragdolls, which are simply rigid body's joined together.

Joints are joints... they allow you to attach two objects together. You can give the joints constraints so they can only move in certain directions and only so far. This is how ragdolls are made and to my knowledge how the mattress in the traptown video was able to flex. Some joints can be broken and others can't, with the breakable joints there is a threshold on how much force can be applied before the joint fails.

The opposite of rigid body dynamics is soft body, it's unlikely that the Source engine supports it, but it's not something that is years away. It's roughly as costly, in terms of performance, as cloth simulation. We can only hope that it's not too long before Valve implements it into Source so the in game bouncy castle is no longer a dream but a reality.

Springs, ropes, cloth & vehicles
Springs in the Source engine are normally invisible objects that sit between two other physically simulated objects and act just like real life springs. To put it another way, these "springs" magnetize the two objects so they repel each other when they get too close and then re-polarizes one of them when they get too far apart so they attract... actually just forget the bit about magnets. However, just like joints, springs can be set to break.

Ropes are as the name suggests ropes. They can be defined in the hammer editor by simply joining two points together and specifying how many nodes there should be joining the rope or cable together. The more nodes the better the rope looks and the more realistic it is (but the bigger the hit on performance).

Cloth simulation is handled in a similar way to ropes — just lots of nodes joined together. Unlike ropes, cloth simulation takes up a lot of CPU time and has only been used in games where the CPU is free from stress (and even then, the simulation would have been highly inaccurate).

Vehicular simulation in the Source engine is basically a combination of the systems already discussed, but with some extra code and tuning. Wheeled vehicles in the Source engine are managed by a specialist part of the physics system to make them more realistic without sacrificing performance and development time. The vehicles use the same springs and rigid body dynamics as the rest of the system, but also have extra bits of code here and there to make them easier to use and more reliable (for both the player and the developer). Boats, hovercraft and air vehicles are all handled the same way as wheeled vehicles except they also use their own physics subsystems.

Water & Fire

(http://www.hl2fallout.com/screenshots/screenshots/zombie_burn) image: http://www.hlfallout.net/images/content/articles/features/thumbnails/zombieburn_thumb.jpg HL2 uses fire to great effect.

Another source of confusion is water simulation. When Valve say the water is physically simulated, they mean objects have buoyancy. They don't mean the Source engine has fluid dynamics. Fluids in Source don't really exist. "Water" areas are just zones of game space that have special physical properties. When an object enters these areas, it behaves differently. It most likely slows down and begins to float upwards (unless, of course, it's denser than the fluid in question or it is a witch). Fluid dynamics is completely different - the actual fluid is simulated instead of just its effects on other objects. At this stage, Valve has indicated that fluid dynamics won't be incorporated into Source. And we wanted to throw buckets of water at the G-Man!

Fire, it seems, isn't something built into the Source engine, but rather a game specific feature (in this case Half-life 2). However, it is an interesting use of the Source engine's features - including the particle system and the material system. Fire can spread throughout the level moving from one flammable object to the next. It's not clear if Half-Life 2 will have this enabled, though.

Particle and Material Systems

The Particle Systems
Something that bothers me about the term "particle physics" being used to describe this area of computer simulation is that it could be confused with that other particle physics (the one that my teacher tries to make me learn). When I say particle physics, I'm referring to the sparks, dust and smoke effects that games use, not beta radiation, photons, quarks, leptons, w+ and the others that I should know.

A particle in the Source engine is a "point-like" object normally represented by a sprite (flat, single, 1 sided polygon) but can also be attached to a model. Points have no area or volume and so can only be represented by a set of coordinates (or relative to another object). They are quite literally a point in space, which makes them the easiest object to physically simulate.

NOTE: it's feasible to create rigid body dynamics (amongst other things) by joining point like objects together (e.g vertices, nodes) and giving them physical properties... this makes sense as the universe is made out of point like objects joined together (down to a certain level). However there are other (faster/more popular) approaches.

Particles in the Source engine can have any of the physical properties a rigid body can, except for a width, height, depth and torque obviously. However, a particle does not always need to have this level of interactivity. Sometimes it doesn't even need collision detection. The most common applications for particles are smoke, dust, fire, rain/snow, blood, sparks and generic debris.

Monsters/NPC's and Procedural Physics

(http://www.hl2fallout.com/screenshots/screenshots/striderstreets?full=1) image: http://www.hlfallout.net/images/content/articles/features/thumbnails/striderwalk_thumb.jpg The Striders' movements are handled in real-time by the physics system.

Hundreds of real-world interactions are physically simulated in the Source engine. This includes characters who apply forces to the rest of the world and can have forces applied to them. How the Source engine treats the character's physical interactions is dependent on how the developer implements the character or monster. Half-Life 2 treats the player's physics differently to a combine soldier and the Strider's physics are treated differently to both of them. Exactly how they are treated I don't know, but it has been said that the player is a force field with a ball attached at the bottom to simulate locomotion.

The term procedural physics is used to describe animations that are created on the fly by using real time physical interactions. Apparently, the Strider's walking animation is created using this technique. It is controlled using a script file that has all the commands for making the Strider walk. The commands apply forces to the legs to move them in the right direction (this is practically like simulating the Strider's musculature). Because the Strider's legs are physically simulated, other forces, outside of those created by the script, can be applied to them. It also means the legs have collision detection and will stop moving when they hit a heavy object, allowing the Strider to traverse over rough terrain in a natural way (legs don't go through the ground or hover in mid air). As long as the environment is different, the Strider's walking animation will be different each time.

NOTE: I'm just using the Strider's walking animation as an example, I'm not sure how much of it is created by procedural physics.

This web page contains examples of most of what I have been talking about: http://meqon.com/downloadarea/downloadarea.php (http://meqon.com/downloadarea/downloadarea.php). Here's a softbody demonstration http://panoramix.ift.uni.wroc.pl/~maq/eng/softbody.php (http://panoramix.ift.uni.wroc.pl/~maq/eng/softbody.php)

The Material System
Materials in the Source engine are used to give an object all its physical and aesthetic properties. If you applied a wood material to a plank then it would behave and look like a plank of wood. It would have the right mass, toughness, sound and look of that type of wood. If you gave it a metallic material, those properties would change accordingly.

Materials can hold information like the density, the shader/texture used, the sounds it makes when being broken, stressed, dropped etc. and how much it can take before being broken. It's a simple concept, but very powerful. The AI can also use information provided by the material of an object in its decision making - as can the player (but by different methods obviously).

NOTE: Objects break at predefined points, which are connected by a joint. The joints can be used to simulate the object being flexed.

AI and Conclusion

The AI System

(http://www.hl2fallout.com/screenshots/screenshots/Manhack_swarm?full=1) image: http://www.hlfallout.net/images/content/articles/features/thumbnails/squadcombat_thumb.jpg HL2's AI system will allow for dynamic squad combat.

AI is a complicated and rapidly developing area of computing to be sure. An artificial intelligence system has to be capable of reacting to its environment in a non linear (or seemingly "random" way). It has to be able to make decisions based on the information available to it (otherwise it's not true AI). The average AI works by assigning every objective with a weight (based on feasibility, importance to its parent objective(s), its current situation etc.) then makes the most heavily weighted its primary objective. After which it takes the appropriate action(s) to achieve this objective, how it chooses the right action depends on how complex the AI is.

To be honest, I'm not fully aware of what the Source AI is capable of. Valve have said all sorts of things that indicate it's very, very powerful. I'll just make a list of the more significant things I can recall:

NOTE: first 5 points taken from Source info sheet.

• Allows level designer to hook up I/O between entities to control AI within the game
  
• Sophisticated navigation: characters that run, fly, jump, crouch, climb stairs and ladders (and even burrow underground)
• AI senses things using sight, sound, smell
  
• AI relationships determine friend/foe status of other entities
  
• Battle AI allows squads of AI characters to operate together, know when to advance, retreat, lay cover fire, etc.
• If an NPC sees you running towards an important object it presumes you intend to do something with it and takes appropriate action.
  
• The sequence where the Strider blows up the bridge was unscripted and unexpected by Valve
  
• The AI knows to move out of the way of fast moving heavy objects.
  
• The AI can remember your last position when it loses sight of you and can cover any escape routes that it thinks you may take and it knows about.
  
• The NPC's will refuse to take stupid orders
• The AI can use physical objects