External Development Processess

Models and Textures

• The EVE ship models that were required for this project were extracted from their directories using an external program known as Tri-Exporter. Models were exported as .OBJ and required conversions to .ASE in 3D Studio MAX. Textures exported as .DDS and were converted to 32-Bit .TGA. Four types of map were required for each model that would be used:

• Diffuse Map: RGB layer, which controls the overall colour of the model.
• Emissive Map: Greyscale alpha based layer upon the diffuse, which controls lighting out of the model. This was placed within the Alpha channel of the Diffuse Map to save space. (Sometimes used for transparency.)
• Specular Map: Greyscale alpha map which highlighted how “shiny” the texture would be.
• Normal Map: RGB layer, which tells the engine how light, should affect the model to give the impression of increased detail.

• The exported models required mirroring and so did the textures in order for the UV’s to align correctly to the mesh, due to imperfections in the export process. For models with transparency, polygons which were affected would be isolated on a separate material ID in 3D Studio MAX so a second material with a corresponding alpha layer for the transparent areas, could be used once in UDK after Import. If a model required “breaking”, I would perform it in this suite before exporting the individual segments.
• The Normal maps Eve Online offered were not compatible with UDK, so instead I used the program Shadermap Pro to create my own Normal maps using EVE as a reference, enhancing in Photoshop as necessary.

Sound and Video

• All sounds had to be recorded or exported and saved as 44,100khz, 16-Bit Stereo or Mono WAV files for UDK. This was done in Sony Sound Forge, which also included any normalisation that was required to the track to enhance the sound.
• The film was going to feature “UI-Scenes”, which were created in Adobe After Effects. In order to stick to the concept of “Pure Machinima” as closely as possible, these were not added post-rendering in Adobe Premiere, but instead imported directly into UDK.
• The UI Scenes were saved as a lossless .AVI’s using Lagarith codec. It was converted to a pre-multiplied Bink Video file (for pixel perfect accuracy), using RAD Game Tools.
• By integrating the movie files directly, benefits and disadvantages both appeared. “Tracking” ships was no longer an issue, as the UI Scenes were attached to a plane which was attached to the actor in question. Originally they had integrated alpha layers, but a compatibility issue led to having to create the alpha movie stream as a separate file. This led to synchronisation issues later on, which were overcome by extra work during Internal Development.

Internal Development Processes

Static Meshes and Dynamic Materials

• Once imported, the models required the generation of LOD fall-back meshes. This allowed models to “switch out” for meshes of lower detail when further away from the camera, to increase performance.
• The majority of models in the movie are moving in real-time, this meant that standard lighting solutions would not suffice. Dynamic lights were created which are calculated in real-time, which also faithfully stuck with the original project objective to emphasise real-time movie capabilities, although increased load on the processor.
• The hardest material attribute of Trinity to recreate in UDK was the reflection map. Basically, this allowed the reflection of the world in which the models resided to be reflected off of their shiny surfaces, and not just a generic light. To overcome this, I created sky-domes (the enveloping space environment for the models) using a material that included a camera vector. This meant that dependent on where the camera was facing, a spherical, seamless environment was projected back. I added a cube-map reflection actor, which took a six-sided screen-shot of this projection of the world and applied it to a texture. Using this with a reflection vector node, I combined it with the specular map of each ship material as an alpha reference. This allowed faithful reflective surfaces to be recreated within UDK at differing levels, relative to that of the ship itself.
• Once all materials were complete, these were attached to the relative material ID’s previously set in 3D Studio MAX for each model, allowing the models to now be placed within 3D space for scripting and animating.

All Images Are Best Viewed In Fullscreen Mode (FS).

Particle Systems and Projectile Scripts

• Every explosion, engine thruster, jump activation and several other animated effects, were created using particle systems. Using the particle editor, modules of particles (which were effectively instanced materials with scalable properties, such as velocity, scale and colour), were added in order to create fiery blue engines, or massive explosions that would change size and intensity over time.
• One example of particle effects were the engine trails on every ship, which would then have to be meticulously placed and attached to each ship and scaled appropriately.
• In scene 4 and 5 especially, torpedos and shells are exchanged between the two fleets. Although I am not a programmer, it was obvious that in order to create a more realistic and effective engagement, which did not involve having to script every single shot fired, I would have to program my own unique projectiles. Using unreal script, I spent time learning how to create my own projectiles with physics, that I could spawn in the engine. Using this, I programmed several projectiles, missile and shell based, which differed in size and speed, to indicate calibre. I made two versions of each of these also, ones which would explode with blue particles to indicate shield impacts and orange with fire to show armour.

Scripting logic circuits in kismet

Triggered Actors and Sound Cues

Many assets within the film required scripting, to dictate when they would trigger. For example: A model changing its material, or an explosion to commence. These were all done through logical kismet operations.

• Kismet is the suite within UDK which gives the user access to a number of logical nodes, which can be placed in sequence to set the properties of actors at any point.
• In order to trigger sounds, a play sound node was added, along with the appropriate sound cue, with a certain volume and range. This would control how sound would dissipate over range.

Instanced Materials and Video Playback

• The issue of having two separate video files for both the diffuse and alpha channels for UI sequences meant that they would have to be synchronised individually. I did this by creating instanced materials. These were attached to parent materials which had scalar parameters which I could change on the fly, in this case, the alpha (transparency) of the material. To synchronise the UI, I triggered the playback of both videos at the same time, while simultaneously changing the alpha on the video to “viewable”, which allowed me control of what exactly was seen on the screen and when.

Particle and Projectile Systems

• One of the more elaborate kismet operations I designed had to be made in order for the projectile that I programmed previously to get spawned in the correct locations and “fired” to designated targets. I did this by adding target actors to all the ships I wanted to engage, which would act as target locations for the projectile. Spawn locations were placed in the same fashion. All the targets were then attached to a node which would interpolate their vectors in space at any given time; in this case, that time was dictated to when a shell was fired. All the targets were attached to a random switch generator, which once in play, meant that whenever a shell or missile was fired, a random spawn point and target was generated to give the projectile a path for that moment in time.

Animation Production

Dynamic Actors

• Animating was easily the most time intensive process during the projects development cycle. Using a Kismet reference known as Matinee, tracks can be created which link to all the actors within a level individually. Here, they can be key-framed to move anywhere in space, or have their properties changed over time, using curves. There were literally hundreds of moving actors in this movie, all of which had to be key-framed and animated to dictate their position in space.

Material Instance Actors and Cameras

• Material Instance Actors were actors that could be linked to matinee in order to change the properties of scalar parameters within material expressions. I added these to UI scenes so I could trigger their visibility, while at the same time referencing the animation of other actors. Such as triggering the information of a ship to appear, when that ship was being followed by the camera.
• Another obstacle was camera animation. Even if you had managed to key-frame fluid model animation, you then had to key-frame the camera to follow it just as, if not more smoothly. Not managing to do this would lead to “jagged” motion scenes that would decrease the films performance.

Evaluation on Design versus Performance

Summary:
A game engine, similar to that of any 3D rendering program, with the continuation of technological progress in both software and hardware, tries to illustrate how something artificial can look as real as possible. It does this by breaking down how something looks and sounds into attributes and traits, allowing a user to determine how each of those traits are seen. In this case, it’s the colour of a model, how shiny it is, how focused that shininess may be, how light might react off of geometry that isn’t actually modelled with the inclusion of Normal maps – and many other things.

Creating games or Machinima, dependent on the engine, gives the user a degree of control over all these things. Unlike real-world cinema that dictates how a scene will look without post-processing in additional suites, development in a 3D engine offers basic control right from conception. This also inevitably gives birth to the issue that human control over every aspect could lead to human error in every aspect – replicating how you perceive a spaceship might navigate space, may not actually be how it does it in the real world. Creative license can be argued in each case.

At the same time, due to this, I decided to stick as close to the concept of “Pure Machinima” as possible in order to be honest to the other mediums. This basically means, creating a Machinima to a point where it can literally be viewed from the engine itself in sequence, without having to travel through other external post-process applications; The true concept of “real-time rendering”. This also led to many obstacles that had to be overcome. The real issue I found after developing this project, was not necessarily how “good” can I get a scene to look and animate, but rather, the question of whether it feasible to do so considering real-time rendering was extremely demanding on a system. The following shows the sectors of development, evaluating the advantages and disadvantages to production.

Models:

The models on average were between 3000-5000 triangles. During my pre-production tests, this seemed to be a fine number to work with, but in the initial scenes, I had not contemplated methods to create other systems which would also impact performance, such as physics projectiles, lighting solutions and particle systems. By the end of scene 5, it was very noticeable and the frame-rate dropped considerably during recording. Models had LOD’s (Level of detail) generated, which decreased their triangles to between 500-1500 average. This helped a lot, but also decreased detail in some scenes.

Textures:

With EVE Online as the benchmark, having models that looked faithful to those in the Trinity Graphics Engine required creating complex and rich materials that would react individually inside UDK, but reflect to that of Trinity as close as possible. Using the material editor, the four texture maps can be combined to create realistic materials using a variety of logical nodes and methods.

Textures can be controlled right down to the number of pixels present on the screen – a dream for artists. However, these textures are finite in resolution and therefore finite in detail. This is particularly noticeable in large objects. The planet for example in scene 1, can be seen to get quite pixellated when the camera gets too close. Later in development I found methods of overcoming such issues, but wasn’t able to introduce them. For this particular issue, I would have switched the material of the planet as the camera was closer, to one which focused the resolution to what was being seen. This would also mean that more memory would be used for caching texture files though. Another hit to performance.

Resolution also took a toll on the UI scenes, which were far crisper out of UDK than they were within, and would have been better off being post-processed in an external application.

Lighting:

I decided to move away from static lighting (which is baked into the level itself before load to save on performance) and instead go with the performance demanding dynamic lighting. This is lighting that is calculated on the fly as the scene is played out and rendered in real-time. I found this to both be beneficial and detrimental in many areas. A more realistic illustration of ships on the battlefield was obtained, however the performance hit was quite noticeable at times when a lot was occurring on the screen. This would mean that expensive computers capable of handling and rendering such scenes would be required for smooth playback, which is not available to all.

Effects:

The projectiles I programmed each had individual templates and physics properties. This meant that their positions would be interpolated at a fast frequency to determine whether they hit an object or not. My initial approach was to have thousands of these projectiles as shells and missiles on the screen, but my PC simply stopped rendering them because of the sheer size. I decided instead to use a particle system which had no physical properties and therefore would not hinder performance for the majority of the shells and only incorporate a few projectiles to add a more believable scene.

Animation:

Animating models is very time intensive, if you want to do it right and have it look natural. As there was a time-scale for this project, I had to sacrifice animating several models that I wished to initially, purely due to this. Many ships also run on the same animation key-frames as each other, but I ran these animations relative to their initial locations, so they look different. Once time is taken however, the illustration of some scenes was quite compelling. One of Machinima’ most impressive traits is the free camera movement, and the realisation that the world around the viewer is literally taking place and unfolding before their eyes, the camera is not breaking transition or skipping time, but rather moving within the world in real time.

Animating position wasn’t the only thing that was of concern, but rather their movement towards said position had to either be interpolated or linear. What this means, is that Matinee offered interpolation algorithms which gave the user access to the gradient of an animation sequence. This was very useful to have ships flow fluidly and cameras to move smoothly.

However it also had many negative effects due to the calculations sometimes being too precise in method. Animating using interpolation could lead to models moving strangely or incorrectly due to their nature. A ship would roll the wrong way for example, when given no rotation key-frames, because the engine would think it was supposed to. This led to going over all the animation very carefully and adding key-frames, or removing them if required. 10 seconds of animation could take several hours to process properly with all actors involved.

Sound:

Sound could be controlled in many ways, right down to added effects such as reverb and distortion. The most useful feature I found, was that the sound would automatically adjust its pitch and volume within a spherical “range”, dependent on how far away the camera was. This offered 3D surround sound without any of the post-production mastering requirements.

A downside is that sound also had to be synchronised to animation, which was quite demanding at times, as the editor would not allow Sound Cue’s to be played in real time, and only from the start. This meant every time I wanted to preview the movie, I would have to watch the scene from the beginning, which took more time.

Emergent Behaviour and Future Plans:

I did notice during development some intriguing results while recording scenes. Due to using a random generator, in combination with physics-based projectiles, sometimes small things would change in a scene that didn’t happen previously. Ships would get hit at different times, or explosions would occur where I had not scripted them. I realised at that point that my movie, even though very simply, was dynamic in nature. It could change each time without having to adjust key-frames or materials.
For example, a ship might explode in one viewing of the movie, which wouldn’t in a second – and due to this, it would cause a butterfly effect of scripted events to occur that could not be predicted. This could inevitably lead to new forms of movie being watched each time, with no required interaction.