General R & D

This page contains a random collection of R&D tests. Its a bit of a mish-mash of stuff, but theres a good range of things that may be of interest.

The first 2 videos here show a small project I developed whilst getting to grips with Unity. This was early version 3. Its basically a space navigation system where the player can override direct control of their vehicle and switch to auto-pilot which tracks a user defined target. Under the hood, I also built a custom level builder that wrapped around an XML based level description. Each system has its own sun, that all the planets orbit around relatively. Each planet could also have multiple moons. All node data was pulled from the XML file, including the absolute position of the system itself, the size of the sun, the size of each planet, the speed of its orbit around the sun, etc.

Simple top down navigation demo. An exercise in 2D navigation with waypoint navigation and an 'auto-pilot' mode. Various components written to handle player control input, navigation, auto-pilot and planet orbiting behavior

Just for fun I switched the project from a 2D top-down game to a fully 3D cockpit view. The only thing I didn't get working was damping on the pitch, roll and yaw when under manual control - ah well...

A more advanced version of the 2D demo, this time offering full 3D navigation. The same waypoint and auto-pilot features are still available, but this time the player interaction model handles pitch, yaw, roll and forward motion (at incremental speeds). Various components written to handle player control input, navigation, auto-pilot and planet orbiting behavior

Simple point and click navigation using ray-casting and surface collisions. All inputs based on mouse position projected into camera space. I added a "mode" whereby if the user stopped clicking for any length of time, an automated system would kick in and start firing rays at random points and time.

Simple mouse click type navigation. This is emulating a control interface typical of most RTS and isometric Dungeon Crawler games where the player clicks to define a point for their avatar to navigate to. Holding down the left mouse button allows the player to drag the navigation target around. Various scripts were written to handle raycasting from the camera to the mouse click location, projecting from camera into world space. The character chasing the mouse also conforms to any surfaces tagged as 'collision' (in World Y) whilst navigating to the last successful raycast hit point. Not interacting with the demo for 10 seconds triggers a random mode where arbitrary rays are fired at random time intervals to keep the character moving - this is akin to a roaming type behavior.

The next video shows one of my biggest single projects to date. This was a complete system prototyped in XNA as a proof of concept for a time of day management system. This was built for Armada of the Damned at Propaganda games and went on to be wholly incorporated into the main game, including the shaders I wrote for the sky itself (albeit slightly modified and optimized).

I did everything here from building the artist editor in C#, to developing the entire engine-side management framework and the shaders to handle all the rendering. I used XML to store artist generated data that the engine could read and initialize. At its basic level, the system stored "states" of time that described the sky and general environment settings like fog and lighting. These states were interpolated between in a linear fashion providing a simple timeline. Global parameters could be set to control the transition between night and day and this influenced the position of the sun and moon. I also exposed a special "supernatural" layer that could be switched to at any point, which was a major theme for the game.

This was a prototype sky system I wrote as a working example of how we could build dynamic atmospherics for the "Pirates of the Caribbean - Armada of the Damned" project (now cancelled). The Sky system was broken into 2 components. An editor built entirely in C# that had the capacity to create, load and edit sky data, and an XNA / C# viewer that could load and visualize the sky data. The Sky system allowed artists and designers to configure how the sky would look at different times of day. It allowed for a full day to night cycle or could loop between a smaller subset of time for fixed time of day. Controls extended to several layers of cloud cover, perimeter clouds, overall cloud colour values, haze and background colour, cloud highlight colour and the prototype also included a predominant light source and dynamically generated cube-map for reflections. The prototype was used as the basis for a full engine implementation. The shaders written in native hlsl were used pretty much directly with some minor syntax changes. An editor was also built that integrated tightly with our main content tools and exposed the same functionality as the prototype.

I wrote this script for a friend who needed a quick way to decimate level geometry based on a user defined pattern. This basically automated the process of breaking large models down into chunks that could be more efficiently culled in real-time (Unity was the target platform)

Ideally, levels (static geometry) are authored in an efficient manner either as modular instanced components that can be culled efficiently at runtime (based on camera view frustum or Occlusion) or as discreet "chunks" that factor in where the player can navigate and thus strip out unnecessary geometry. This, however, is not always the case. Sometimes it is more effective for artists to author environments as singular components and have this data processed offline as part of a build step. In order to do the latter, typically, the content creators are provided with some kind of interface to how the resulting level will be split up, most often a grid composed of uniform dimensions. This video demonstrates one such process working within Maya. Simple geometry is used in this case, however the process would be just as effective on a complex level. The grid used to do the cutting can contain non-uniform dimensions (as shown). All level objects are cut up as part of the process so that the chunks do not overlap one another and align perfectly at runtime - note the green, red and blue objects. Authored in Python.

Just for fun, I wrote a very simple A* path-finding algorithm using Python in Maya.

Simple A* path finding demo written in Python and working in Maya. The Blue and Red nodes represent the current and required locations respectively and the black locators are nodes for a way-point graph. I didn't restrict this solution to a 2D grid of way-points as you would typically do in a conventional way-point based solution. I don't employ any path smoothing once the solver has generated a path so it looks a little "steppy" in its current form (the curve object in Maya is used purely for visualization purposes). I wanted to see if I could quickly mock this up in Maya with the intention of re-writing it in Unity Script (C#) at a later date to be used in one of my concept projects. for more information on the solver itself, review the following http://www.policyalmanac.org/games/aStarTutorial.htm More info at my personal website here http://www.kevhayes.com

Look development done at Propaganda Games using Mental Mill. This shows a complex shader that could "grow" barnacles and grime on a character to make them look like drowned, other-worldly creatures.

Here is a real-time preview of the output of the network shown above:

Realtime shader prototype for the "Pirates of the Caribbean - Armada of the Damned" project intended to be used as the basis for character transitions between supernatural states. The shader would give the appearance of growing barnacles and grime over the surface of the character to give the overall supernatural / drowned pirate look.

Another C# / XNA piece used to demonstrate how we could store small packages of tint-data to be used in-engine to get additional variation between customizable character components

Simple vertex color based terrain blending with support for independent UV scaling - CGFX shader in Maya.

Another Mental Mill prototype to demonstrate the use of masks in a shader to define areas of customization on character faces

This is the shader as it was originally authored in Mental Mill. I later optimized the output to be more efficient and cleaner to read, as well as adding Maya specific syntax for components such as the viewport Camera.

This is the shader above, shown in context of a larger customization demo developed in Maya using a combination of blend-shape and shader based manipulation.

A quick Prototype I put together in Maya 2008 leveraging blend shapes and a bespoke shader that could blend normal maps together based on weighting information set through the UI and texture masks within the shader, as well as handle skin tinting and decal placement for tatoos. This prototype was built to demonstrate a system of player customization as well as content authoring tools derived from the same framework that would allow for mass character creation and randomization.

This is the first incarnation of my custom vertex color tool (shown on the General Tools page). It was built to service content created for Armada of the Damned where we made use of the RGB and A channels to store independent data such as AO (greyscale only), Terrain blending and foliage deformation weighting. Uniquely, this tool allowed the artist to store the channels separately in order to make it easier to work on the individual data and then collapse all the channels into an export color set prior to exporting the model asset

An alternative to the built in Vertex Color Set Editor in Maya 2008. This was created to facilitate a specific non destructive workflow requested by Level Artists, that had functionality to bake (and increase the intensity of) Vertex AO, allow working on independent channels in full color and would merge layers together in an intellegent way for use at runtime.

Old R & D learning how ray-casting worked in 3D Studio Max - Version 8! - Very rudimentary stuff but it was a great learning experiment.

Another Ray-Casting experiment - building a simple conform to surface command