A closer look at the Unreal Technology Demo

Posted on Leave a commentPosted in Game, Unreal, Unreal 2, Unreal Tournament, Unreal Warfare

At the European Computer Trade Show, on September 6th 2000, Epic Games unveiled a technology demonstration of the Unreal Engine, showing new features and capabilities that they were introducing to the engine. A number of new features were shown that Epic Games were looking to introduce to the engine in the short term, along with PlayStation 2 support, but with the long term goal of producing a new engine entirely. This iteration of the engine eventually came to be known as the Warfare engine, now known as Unreal Engine 2, the predecessor to Unreal Engine 3.

The technology demonstration was unsurprisingly comprised of a number of different demonstrations but a lot of these provide some fascinating insight into the development of the engine and the upcoming games at the time. We’ll be going over each of these as they appeared in the video below and doing a short analysis on each.

Skeletal Animation

Warrior as shown in the Unreal Technology Demonstration.

The first scene in the video shows us a demonstration of the then new skeletal animation introduced to Unreal Engine. The model shown here, which you can see again in the above screenshot, doesn’t appear to be related to any particular game that was in development at the time, it merely appears to have been produced for the purposes of the demonstration. I do recall hearing somewhere that Epic Games outsourced the production of the model, but don’t take my word on that.

Previously, animations in Unreal Engine were done per-vertex, which meant that the engine would interpolate the vertices to a new coordinate on each frame, essentially by storing multiple copies of the whole mesh for each frame of an animation. For this, Unreal Engine had it’s ‘3D’ model format implementation which was split between two separate files; one containing the mesh and the other containing the transformation of the vertices for each frame of the animation.

It was a little inefficient but it was quicker for the CPUs of the time to process when compared to using skeletal animation, the only downfall was that it used more memory, which inflicted heavy limitations on the complexity of animations which artists could create. The same method was used by id Software for Quake, Quake II and Quake III, though Quake III extended on this to take greater advantage of the higher memory available on systems at its time of release by using greater precision for the coordinate of each vertex (the MDL and MD2 formats, used in Quake and Quake 2 respectfully, used a very low level of precision that resulted in a wobbly effect for animations).

This format saw continued use in Unreal Engine 2 certainly to a lesser extent than before. An example are the flags used throughout Unreal Tournament 2004, which took advantage of per-vertex animation.

The addition of support for skeletal animation to the engine meant that artists could introduce far more complex animations, as well as the ability to blend multiple animations together or for programmers to alter how bones moved during run time to allow characters to look in specific directions, without even requiring a predefined animations. Obviously the implications at the time were huge.

A wireframe view of the Warrior mesh, showing the skeleton as well. This gives a good glimpse at the bones used to perform the facial animation.

Skeletal animation saw a surge in use at the end of the 90s, and by 2001 almost all commercial games appear to have been heavily using skeletal animation over per-vertex animation. Regardless, the technology certainly wasn’t new, it was developed in the late 1980s and saw use within films such as Toy Story, released in 1995, and was a major hallmark of the cancelled game Into the Shadows, which was in development by Triton in 1995.

One key feature Epic Games seems to have chosen to point out here is the ability to add facial animations to characters, likely to demonstrate the level of complexity that artists could expect from the addition of this new technology. The system did not introduce anything on the level that we would later see brought by Valve’s Source Engine, which used a combination of skeletal animation for typical motion and per-vertex animation for facial animations, which gave animators a greater degree of control than was achievable from skeletal animation for facial animation.

From the screenshot below which came from Epic Games’ Unreal Developer Network, you can see the environment in which the facial animations would be produced.

Screenshot taken showing Unreal Warfare soldier being manipulated in Maya.

Another downside of Epic Games’ implementation of facial animation, from my understanding, is that the facial animation wasn’t very flexible; the facial animation was only controllable from modelling tools such as Maya and would have been baked down into individual animations. This would have meant that any changes for an expression would have had to been made outside of Unreal Engine’s UnrealEd, then imported back into the engine again once completed.

To a limited extent, it was possible to export a number of different facial animations, each for various expressions, and for these to have blended together to be combined with animations for speech or other bits of animation, so that characters could express themselves using the same mouth movements without having to create unnecessary duplicates of animation, but this technique would have been very limited to those seen in the years to come that allowed more precise control over facial animation.

Valve opted to use an alternate method for facial animation in the Source Engine; per-vertex animation.

By comparison, Valve introduced a more flexible method which was supported by their own tool, rather boringly dubbed the “Choreography Tool”, or “Faceposer” as it’s more commonly known. By comparison, this tool allowed Valve to produce entire scenes, using their own library of animation overlays and flexing the faces of the characters throughout the scene, and then to preview them within the tool before placing the scene within a level.

It’s worth noting that skeletal animation was eventually introduced to Unreal Tournament in a subsequent update and also used widely for the PlayStation 2 release of the game, however it didn’t see such extensive use until developers began utilising Epic Games’ then new Unreal Warfare engine in 2001.

In an IGN article produced for the demonstration, Epic Games apparently put forward a statement on the new feature that reads the following.

The skeletal animation system, using quaternion-based interpolation, allows for both loss-less and lossy compression of the motion data. The rendering pipeline of the engine is being modified so that characters (and additive solid geometry) can be processed through the hardware T&L pipeline of Direct3D cards with that feature. That means the theoretical limit for polygons and, more importantly, the numbers of characters on screen jumps substantially for applications intended for Microsoft Xbox or computers equipped with hardware T&L-capable cards like Nvidia GeForce or ATI Radeon and the myriad of others that will follow. The new features of DirectX 8 in particular will enable skeletal characters to make full use of the hardware to accelerate rendering of smooth-skinned meshes.

It’s interesting to hear Epic Games refer to the Xbox here, considering that Unreal Championship ended up becoming an Xbox exclusive.

High Detail Models

This part of the video is one of the more interesting segments historically, as it shows a look at an early version of one of the Locust soldiers, which were later found in Gears of War, and at this point they were referred to as the Geist (a German word, meaning “Ghost” in English). At this time, Gears of War was known as Unreal Warfare (the same name that was widely used to describe Epic Games’ upcoming technology) and was in the very early stages in development; very different to the game we received in the end, in terms of both gameplay as well as visually.

The character displayed uses the symbolism of the Locust prominently on his front as well as on his back, which appears to be one of the few designs which has survived the evolution from Unreal Warfare to Gears of War. It’s evident from this that the symbolism of the Locust was established very early on and surprising that Epic Games retained this throughout the game’s development.

The character’s design here, especially with regards to the human appearance and de-saturated skin, seems very similar to what we saw in a later Unreal Engine technology demonstration shown in 2002, which also showed content intended for Unreal Warfare. It’s likely this design, at least stylistically, for the Locust, remained for quite sometime and likely wasn’t entirely thrown out until the team ditched Unreal Engine 2 around the end of 2003, after which the designs in the final game retained the humanoid appearance of some classes of the Locust and the de-saturated skin tone, but overall it seems Epic Games settled upon a more alien design.

It’s possible the reason a less human appearance was chosen for the Locust was due to the team changing focus towards a single-player experience, rather than the class-based multiplayer they had originally envisioned for the game. As this change occurred, the primary enemy of the player within the game became the Locust; this meant opening up the range of characters they would be pitted against and to introduce more variety. This also likely helped create more of a divide between both the Locust and Cog generally, and was intended to make the Locust appear considerably less friendly.

When the scene switches over to show the model from the back we can see a panel with the label ‘SLARIOUX’. It’s possible that this is the name of the character we’re seeing here, the implication could be that this was intended to be a character of importance? It’s unlikely we’ll ever know for sure but this certainly wasn’t something we saw retained in later iterations of the game, as the Locust eventually had their own language and generally their armour did not feature names of any sort. Considering Warfare’s multiplayer focus at this point in its development, another possibility here is that the name plate would feature that player’s own name – something that Unreal Tournament 2004 would feature to a limited extent, displaying the player’s name on the number plate of a vehicle they’re occupying.

While not featured within the video, we can see that the Cog also retained the same symbolism which we see widely used in the final game, which is confirmed by several screenshots featured on the UDN from around the same time. This said, the Cogs design in these screenshots remains very different to that which we see in the final game, and the overall cog theme is perhaps not quite as pronounced as in the overall design below. Again it’s interesting that Epic Games seemingly settled on the symbolism for both sides so early on.

In the above images, it’s certainly interesting to see that the Cog soldier appears to be using the same skeletal rig featured in Unreal Tournament’s PS2 debut, which introduced skeletal animation. It’s also interesting to see the Cog weilding the weaponry also featured in Unreal Tournament; a possible implication that Unreal Warfare was initially using Unreal Tournament as it’s foundation when it started development, this is perhaps further supported by screenshots showing featuring Unreal Tournament’s HUD while displaying assets intended for Unreal Warfare, one of which can be seen below.

Since the HUD here is from the PlayStation 2 version of the game, which introduced the support for skeletal animation, it’s perhaps not surprising to see the Cog soldier making use of the same skeletal rig and animation set. As a matter of fact, it’s very likely that the support for skeletal animation featured in Unreal Engine 2 is simply an iteration of the skeletal animation introduced in the PlayStation 2 version of Unreal Tournament, as that iteration of the engine continued to evolve internally within Epic Games. It certainly seems to be the case that Unreal Warfare, as a game, was built from the PlayStation 2 version of Unreal Tournament.

High Level and Texture Detail

Again, this segment of the video is quite interesting for historical reasons, because it possibly gives us some insight into how other games being produced, using Epic Games’ then new technology, were progressing at the time. Initially we see a map I can’t identify, which was probably produced purely for the purposes of the demonstration, but afterwards we see something interesting; a rather futuristic setting.

Several games that Epic Games were involved with at the time featured a futuristic setting, these range from Unreal Warfare, Unreal 2 and the working title, Unreal Tournament 2, so these screenshots could in essence show any one of these.

Unfortunately I can’t say for certain what we’re seeing here but I believe, on unfortunately very little evidence mind you, that this is Unreal 2. Why? Well there appear to be some subtle indicators here that we can pick out when comparing the shots to content that exists in Unreal 2. If this were the case however, Unreal 2 would have been at such a primitive state at this time – though there is certainly indication that the game was in development at this time.

Unreal 2, of course the sequel to Unreal, was in development outside of Epic Games, and was instead being produced by Legend Entertainment. Unfortunately after the release of the game and shortly after the release of it’s multiplayer expansion, the studio was closed down.

As you can see, there are some rather subtle indicators but of course it’s hard to know for sure – I believe there likely are other textures that match up though.

If there was more evidence to link this to Unreal 2, I would even go as far as saying that this appears to be an earlier iteration of the level found in this screenshot below which was released during Unreal 2’s development, in late May of 2002 (though this iteration of the level actually dates as far back as 2001, as it’s included in a leaked build of Unreal 2 from the time). It features the same crane mechanism, a similar looking table and uses textures from the same texture group, though clearly it’s considerably more varied and detailed, and that’s just speculation on my part.

If this is true, it does imply that the operating table, as it is, has the crane mechanism positioned in the wrong place in the video. Oops.


I hope you enjoyed this article! Eventually I want to cover more regarding the development of Unreal Warfare and the development of the Unreal Engine in general, so stay tuned!


Resources

GamesTM – Gears Of War intended to be like Battlefield, had mechs and class-based combat

Unseen64 – Into the Shadows

GDC 2001 Unreal Technology Demo

Postmortem: Epic Games’ Unreal Tournament

Unreal Developer Network

UT: New Tech!

List of Unreal Engine games

Weekly Update

Posted on Leave a commentPosted in Article, Game, Projects, Requiem Avenging Angel

I’ve kind of realised that I’m not doing frequent enough updates. Perhaps it’s time I got into the habit of doing weekly updates just so you know what’s going on and that I’m not totally idle.

So yes, I’ve certainly slowed down with producing videos. It’s not intentional but I’ve kind of lost the motivation a little due to how long the last few videos have taken to produce and the amount of crap I’ve had to deal with when it comes to the Source engine.

Generally I just don’t look forward to launching Hammer, dealing with the crap content pipeline and essentially basically showing things that I’d imagine most of you have already seen; it doesn’t make me feel especially productive. I’m looking to do videos on other things, but I’m afraid I don’t have anything in the pipeline quite at this time.

I’m gradually looking at switching my format to doing more analytical works which is something I’ve always wanted to focus myself towards, primarily in written articles as I can cover more than I could in a video. There are two articles in the works at the moment, one focusing on Unreal Engine 2 and another that covers the last Half-Life 2 video I produced.

On the side as well, I’m spending considerably more time now writing code for projects such as reverse engineering the model format in Requiem Avenging Angel and working towards my open-source Hogs of War project, though I’ve taken some time away from those two specifically to focus on a game I’m working on in my free time which unfortunately is unrelated to the purposes of this website but I might sneak a little plug in for it when it’s closer to completion in the future.


With regards to the Requiem Avenging Angel model format, I guess I might as well begin going into some of it here considering we already published some our work so far.

For starters, Requiem features two separate model formats. One specific for static meshes which is quite simplistic and then another for it’s models that use skeletal animation, which also appear to support multiple textures. Both of the formats use slightly different structures from one another but for the time being we’ve primarily focused on the more simplistic model format.

The very first byte in a static model is a flag that declares how the model will appear within Requiem’s engine. Through some experimentation we were able to determine that the default state for this, which is flag 0, causes the model to use standard Gouraud shading, where as flag 1 results in flat shading and flag 2 results in an unlit model.

After this the file then contains the name of the texture sheet the model will use. This begins with a 32-bit integer that lets us know the length of the string, this is a little unusual and doesn’t appear to have been retained in the animated model format as far as we could tell, but afterwards is followed immediately by the texture name itself. The texture name in each of the models never exceeds 64 bytes. We can then load in the texture name using the length provided within the file.

After which we then immediately stumble into some data declaring the rest of the contents of the model. This begins with a 16-bit integer outlining the number of vertices within the model, then followed by another 16-bit integer that unfortunately I don’t appear to have noted down, oops, and then finally one last 32-bit integer that lets us know how many faces the model features (I think we may have concluded that the vertices was a 32-bit integer as well? My notes suck!)

Finally, we can move onto actually loading the data of the model, such as the vertices and faces. This I will leave for a more dedicated article at another time; we’re planning on going over the model format again over the course of this week but I can say that the vertex coordinates made very little sense to us and they’re something we’re actually still very stuck on. The other noteworthy feature of Requiem’s model format is that faces do not use fixed sizes, and can have any number of triangles per-face (we’ve seen instances of at least 6/7 triangles per-face).


Anyway that concludes this weekly update, hopefully I can keep this up!

 

Gears of War development ‘previews’

Posted on Leave a commentPosted in Game, Gears of War

Below is a collection of thumbnails that were generated for Epic Games’ Gears of War, which were packaged with the game, and preview several different levels that were produced during the development of the game.

It should be obvious why these are interesting in a lot of respects, especially as they show a lot of content that didn’t make the final cut. Each of these previews appear to have been generated either for levels that were produced purely for testing mechanics of the game but as well as levels that were used to lay out prefabricated areas.

Unreal Warfare Soundtrack, or portions of it

Posted on Leave a commentPosted in Game, Gears of War, Unreal Warfare, Video

Here’s something that might be interesting for a few of you, but here we have three songs used in the Unreal Engine technology demonstration from GDC 2002 and one additional song that wasn’t used in the demonstration.

These songs were packaged with Star Wars Republic Commando, among some other things which we’ll discuss at some other stage in the future.


For those that don’t know what Unreal Warfare is, Unreal Warfare is what eventually became the Gears of War you know today. It was also often used as the name to describe the second iteration of Epic Games’ Unreal Engine, as it initially served as the driving force for many of Epic’s innovations at the time, and before Epic Games had dubbed their new technology as “Unreal Engine 2”.

It’s hard to know exactly when development began on the game, but it’s apparent that the game was in development from as far back as 2001 and didn’t cease to exist as Unreal Warfare until 2004, when Epic Games moved the project to the then in-development Unreal Engine 3 and recycled assets from the game for Unreal Tournament 2004.

Many of the key concepts, such as the Cog and Locust (known at the time as the Geist), the iconography and elements of the universe, were well established very early in the game’s development.

That being said, the game changed dramatically in-terms of gameplay during its development cycle, having originally been intended to be a tactical class-based first-person shooter before then becoming the over-the-shoulder experience when making the move to Unreal Engine 3.

I don’t currently have an article available here on the website regarding the game but it is something I would love to do at some stage. I’m sure a quick Google search should pop up some results.


If you’re interested in downloading the tracks then I’ve made them available here.

Collection of early Unreal Warfare screenshots…

Posted on Leave a commentPosted in Game, Gears of War

Most of these are taken from Epic Games’ UDN, and there’s plenty more there I haven’t included so I highly encourage people take a look!

If you’re not sure what Unreal Warfare is, it’s essentially what became Gears of War. The screenshots below show content from the game back when Epic Games were still developing Unreal Engine 2, which should give you a good idea of how long this game was actually in development for.

 

Half-Life 2’s Evolution : aaron/canals_01_15 (2002/12/12)

Posted on Leave a commentPosted in Game, Half-Life 2, Video

It’s been an incredibly long time since the last video, but the next one in the series is finally here.

Keep in mind that this ended up getting a little rushed in the end, as I wanted to get it out of the way so I could move onto other things. Turns out moving to Source Filmmaker ended up causing the video to take longer due to a few technical faults along the way, and then work got in the way, and it’s likely in future I’ll be producing these very differently to how I have been previously to save myself more time.

As usual, keep in mind that this series is solely focused on displaying the geometry of the levels rather than playing through each one individually. If you enjoyed this video and want to see more in the future then I highly recommend supporting me on Patreon, as this goes towards supporting the website, the archive and videos such as this.


This is part of a video series showing the gradual evolution of Half-Life 2. It’s not intended to demonstrate gameplay, as most of these levels, in their original form, weren’t playable. Because of the number of levels to cover and the amount of time it takes to clean them up enough to be viewable, these will be kept as quick glances.

This level is produced from the VMF, canals_01_15. The level was likely created by Aaron Barber.

The original VMF can be downloaded here.

 

SiN Emergence things

Posted on Leave a commentPosted in Article, Projects

A long time ago now, one of my many hobby projects was looking at how feasible it would be to produce an open-source reproduction of SiN Episodes, so that work on it could essentially continue (or to just otherwise bring it over to Source 2013). I decided to return to this today and felt it would probably be interesting for a few to share how this is going right now.


I actually ended up revisiting the project as a result of an article I was working on to explain how you can get the SiN Episodes SDK functioning again. Unfortunately it seems that the steps I used previously will no longer work as Valve has changed how Steam’s config is set up, which was part of both the solution and the cause of the problem to begin with.

Obviously not great but unfortunately this was going to happen sooner or later due to the SDKs inherit reliance on Steam and the lack of support it receives due to the obvious fact that Ritual Entertainment no longer exists. So the value in an open-source reproduction of sorts is quite apparent, or to me at least.

This initially led me to look into reverse engineering the SDK to try and figure out if it was possible to work around the check it was trying to perform. Keeping in mind here that it’s not something I’m highly experienced with.

From the looks of it (by looking at the leaked 2007 codebase) there’s a Steam check which then moves over to try and grab the Steam config (which is where the failure occurs) but there’s a separate path here which looked like it skips this check.

I spent a short amount of time in a decompiler to see if I could figure out where this check occurred by using the “%s=%s” string, as seen above, as a reference point and managed to get a rough idea where the alteration needed to be made. Unfortunately I did seem to be running in circles a little, as the decompiler was only showing one other string similar to this one which wasn’t the one I needed, which you can see in the image below.

After spending a little while longer on it, I did eventually find, roughly, where the line was that I was looking for but I’ve decided to leave it for another day for now before I spend some extra time on it, just to be absolutely sure.

Moving on, I ended up looking once again at my SiN “Reborn” project.

At the moment it’s being developed using the multiplayer branch of Source, and there’s a few reasons for that really… One; I would be more keen to get some sort of multiplayer game going as a starting point as it would be worthwhile, considering SiN Episodes: Emergence wasn’t released with any multiplayer support whatsoever. Two; my understanding is that the multiplayer branch of Source has had more TLC from Valve than the singleplayer branch, not that Valve have touched the Source 2013 release for a while now, but it otherwise has some features that aren’t available on the singleplayer branch (keep in mind it’s been a considerable amount of time since I last properly touched Source, so I’m just going by memory here.)

Most of my time today has been spent familiarising myself with everything again. At the moment there’s a rough outline of the Scattershot and the Magnum that have both been implemented with some rudimentary code for the melee attacks and special secondary attacks that were used in the game. As well as this, we’re happily parsing some of the extra data that Ritual added for the weapon scripts, and all the items have been implemented (besides the ‘ass’ aka Assault Rifle and health pickups). Easy parts out of the way.

Things like the HUD still need work, likely to come later rather than sooner, but it’s interesting to see that Ritual created weapon icons for each of the weapons in the game which work within Half-Life 2’s weapon selection HUD. It seems as if SiN’s HUD might have been considerably different in the game at some stage of its development and it does appear there are quite a number of unused textures for the HUD as well here, possibly just left overs from prototyping but it would be interesting to know for sure.

While I was looking through and tidying things up, I decided to alter the animation code a little as well to play better with the character animations used in the game. It makes sense to me to try and alter as very little of the original content as possible, so I wanted to see how well the animations would work for multiplayer.

This ended going surprisingly well (and I probably spent way too much time on it too), with support for different animations based on speed and the players current state now implemented, which you can see from the video below. An example being how the player switches between a more relaxed animation set before switching to a more active animation set upon either firing his weapon or getting attacked.

Looking pretty swell, even if I do say so myself. Unfortunately, as you can see from the video, it turns out that the Magnum world model seems to use a different bone for the attachment, hence why it’s in his groin rather than in his hand where it belongs. I’ll likely look to see if I can implement a workaround for this without altering the model.

My other concern here though is that a few of these animations may not necessarily be available for the other character models in the game, as quite a few of them appear to use their own animation sets. It’s something I’m going to need to take a look at but I really hope this isn’t the case.

Anyway that’s all I’ve got for today. I’m really going to try and post here more frequently about what I’m doing, and I’m interested to know what you guys think. If anyone is interested in contributing to projects like this then I really encourage you to get in touch as I’m always looking for help!

Dominant Species Patch

Posted on 2 CommentsPosted in Announcement, Article, Game

This is something I’d been meaning to post for a while now but unfortunately didn’t quite get round to it, primarily because I wasn’t entirely sure if its content was right for this website. Having thought about it, this is a step towards helping preserve an old game that many otherwise may not have heard of before so it makes perfect sense to post it here.

Dominant Species was a game that was released in 1998, and it seems to me like a game that was somewhat lost in time with very little attention given to it as far as I’m aware but seems like a unique game for its time. It certainly has a charm about it.

If you’re not familiar with the game, it was developed by Red Storm Entertainment. The same guys that have developed countless Tom Clancy games. And it’s a 3D RTS, which according to Red Storm themselves, was one of the first 3D RTS games as well which definitely makes it quite significant.

On a whim I came across the game online and ordered myself a copy but I guess to no surprise the game struggled running on modern operating systems (such as Windows 7/8/10), in particular it failed to initialise a fullscreen instance of the game and it also fails at detecting the CD properly.

After spending a while poking and prodding the game though, I not only found a list of launch arguments for the game that allowed it to run in a windowed state, which worked around the issue initialising it in fullscreen, but I also managed to track down where the game attempted to check for its CD to ensure you had a valid copy of the game and disable it through the wonders of reverse engineering.

I did also experiment with a wrapper to try and get the game running in fullscreen but after discovering the launch arguments I didn’t go any further with this. It’s something I’d like to return to though at some point in time as it would be a wonderful learning experience.

Keep in mind that I’ve only done this for the singleplayer at this time, so right now the multiplayer menu will still ask you to insert the CD.

I guess you could probably consider this a crack? Maybe when I have some time I’ll get round to doing the multiplayer as well but this should be relatively easy to do. Unfortunately it’s been a long time since I did this so I don’t have my notes available right now but if anyone else makes an update to this then be sure to let me know and I’ll be happy to mirror it here.

Download

Let’s Speculate! Half-Life 2 Lighting Zoo

Posted on Leave a commentPosted in Article, Game, Half-Life 2, Let's Speculate!

The Lighting Zoo, otherwise known as ‘lightingzoo’, is a level included in the pack of development VMFs that was leaked with Half-Life 2 back in 2003. It’s one of the lesser interesting levels in the pack of levels, but we’ll be covering it anyway just to quickly get it out of the way. Obviously on this occasion I won’t be bothering to produce a video but expect a number of screenshots demonstrating the level.

The map is marked as being last modified on the 6th of May 2002 but it’s hard to be sure as to who the original author was but it was likely produced by someone within Valve who didn’t work primarily as a level designer, more likely the work of one of the programmers at Valve. We can pretty much conclude this as the map features incredibly simplistic geometry, though includes a few different sections that seem to test the capabilities of the lighting tool, VRAD, at the time; displacements, animated lights and normal maps are featured in the different sections of the level.

Keep in mind that this obviously doesn’t reflect entirely how this level may have looked at the time as it was built using the Source 2013 level tools and of course the level was actually produced in 2002. My reasoning behind using the 2013 version of the Source Engine is purely just for stability and because I can make whatever changes as needed while demonstrating them. It’s unlikely we’ll ever see a build of Half-Life 2 from that period ever surface but we can dream.

Honeyview_lightingzoo_hogsy0001

Overall there seem to be four different sections of the level as you can see from the screenshot above. The first two sections (left to right) appear to primarily be intended to see how lighting was working for displacements. At the time I would guess that displacements were more likely to have been using per-vertex lighting, rather than having their own lightmap but it’s also possible this level was produced to test the introduction of lightmaps on displacements. It’s hard to know for sure but regardless, there’s quite a lot going on towards displacements in this level and how the lightmap is applied to those displacements in general.

For the first section of the level, we’re presented with a rather simplistic room with a skybox and a sand texture using a normal map. It’s likely this was to ensure the lightmap also included the correct directional data for it to influence the normal map on lightmapped displacement surfaces but apart from that it’s not particularly interesting to look at. The texture used for the sand was removed at some stage before Half-Life 2 shipped, so that had to be pulled over from the leak.

Moving on from that we also have the two middle rooms that contain a number of different displacements. I would expect that initially when displacements were first implemented in Source, Valve weren’t using lightmaps but instead used per-vertex lighting, though that’s purely speculation on my part but that being said it does seem like displacements didn’t support any kind of collision hull when they were first added to the engine as a few earlier maps also include brushes along with the displacements (thanks to H.Grunt for informing me about that). I thought it was worth pointing this out, as it might be easy to forget that a lot of the functionality, that we can sometimes take for granted in Source today, was very gradually introduced into the engine overtime through both development and prototyping with the rest of the development team.

The displacements included in these parts of the map aren’t your typical shapes, with displacements typically being used for terrain in Source (though they were also used for pipes and more in some circumstances) though this is also likely why the displacements included here are unusual in shape as it’s easy for issues to sneak past if level designers aren’t typically using displacements in this fashion, but I’d say more importantly is that it also lets you push and extend that functionality beyond the scope of what level designers might have been doing with that functionality at the time. Perhaps a good example of the influence that the programmers had on the design of the game, besides the actual designers of the game themselves.

In the section here, which is where the player initially spawns, we have a large displacement centered in the middle surrounded by a number of spheres at each corner and a number of lights at each corner as well. It’s an unusual set up, more unusual is the extra light on the bottom right of the room which you might be able to pick out from the overview earlier but it’s likely this might have been a simple mistake.

It’s possible this area was intended to test both displacements with environment mapping and normal maps as there’s a number of env_cubemap entities that have been intentionally set up in this section of the level, though for the material in question which was pulled from the leak, it’s difficult (or impossible rather) to see the environment map with how the material was set up, I changed this so that we can see the environment map on the surfaces more easily but I’m not quite sure why this was done; it could be that this was in error by someone at Valve.

I guess Valve can be glad to know this all still works, heh. There isn’t much more to say about this particular section, it seems quite evident that it was intended to test both environment maps, normal maps and lightmaps on different displacement surfaces, either to check for any regressions or to ensure the initial implementation was functioning as expected.

The next section we’ll take a quick look at is very similar though a little more simplistic. It features yet another sphere but this time without a normal map or environment map and instead just a simple diffuse + lightmap, it’s essentially identical to the others but with a different texture. It’s likely the intention here is similar to the other section we looked at but just lighting generally with unique displacement shapes.

There’s also two adjacent displacement planes we can find near the entrance which are slightly slanted from one another, with a light slightly shifted to the side of just one of them. From a glance it’s pretty unclear what the intention here was but my guess is that it was to check that the lightmap between two separate lightmap planes was smooth, as if they were a single surface; with displacements there aren’t any ‘smoothing groups’, instead the tools essentially treat any adjoining displacements as one surface and the normals are calculated automatically so that the lighting smoothly transitions over them (or that’s the intention anyway), this is likely why the light is shifted more so to one side.

Honeyview_lightingzoo_hogsy0006

There isn’t a whole lot more to this room so we’ll be moving now to the final section which is basically made up of two adjacent rooms which seem to mirror each other but feature different texture sets, one with a simple diffuse and lightmap, and the other with the diffuse, normal, environment map and lightmap that we saw earlier. Within these rooms there’s one coloured light in the corner, and then on one side we have a brush positioned above a displacement with an animated spotlight above it (likely checking that a shadow is correctly cast down onto the displacement), and finally a cylinder with smoothing groups applied and a spotlight cast through a slit made of brushes.

I guess we’ll start off with the brush placed above the displacement. Like I said, it’s likely this was to check that shadows were being cast onto the displacement correctly but otherwise there doesn’t seem to be any other purpose. The fact that there’s an animated light was also likely to ensure that the lightmap was correctly updated on the displacement.

2016-08-29_20-05-52

I don’t think much more can be said about it so we’ll immediately move over to what’s on the other side of the room near the entrance (and we’ll skip the light in the corner). This isn’t so much to do with displacements this time but seems purely just for smoothing groups, typically for complex geometry like this you would change it to a detail brush to avoid any issues with CSG splitting the geometry up too much but interestingly this isn’t the case here which seems to have a negative impact on how the geometry ends up being lit.

From the screenshot provided below you can likely see how the different junctions produced during CSG have effected the overall lighting of the cylinder, with VRAD seemingly unable to completely trace some of the lighting to the rest of the geometry and also failing to keep the appearance of a smooth surface because of it, though the larger lightmap might also partly be to blame in this instance.

I would guess that this was intentional as it’s unlikely this was any different at the time but I’m unsure what the intended goal of this was, whether a solution was being explored or just to demonstrate it in general. The rest of the cylinder is otherwise fine and not effected by this (there is some issue with the light incoming from the hallway being applied to the cylinder). The same issue also appears on the cylinder in the second room but that’s unlikely to be surprising.

I think that’s about everything I can think of covering in this map, the only other thing noteworthy is that the map seems to use the same hallway structure found in other ‘zoo’ levels though slightly modified like the two larger rooms were slotted into it, but it’s very much just your typical hallway otherwise but as with most of these levels you’ll find it easier to use the ‘noclip’ function rather than walking through them.

If you found this interesting then do let me know and I’ll continue on with it, I know this is one of the least interesting levels in the leak but I like to cover things that most people would otherwise overlook. There’s a lot more than meets the eye they often say, though we can only really speculate on most of what we find in the leak and levels such as this. If anyone else has any comments or suggestions, or hell, anything, do let me know and I’ll update this accordingly but I do hope it was insightful!