Whitebox in Engine

Now that I've got a reasonable idea of the CryENGINE basics, the next step is for me to begin importing my simple whitebox models into the engine and start laying out the level. 

With the terrain size set up in CryENGINE so that I would have plenty of area as a distant landscape as well as my Stretton Circuit diagram in engine to scale as reference for the layout of the area I had made the job of placing the whitebox model's, buildings, tyre walls etc accurately in the correct places. 

With the track model placed roughly in the center of the map the next step was to begin modifying the terrain around the track so that the terrain itself (or the grass in layman's terms!) met the edge of the track correctly. This process is, kind of simple, thanks to CryENGINE's tool set which allows you to simply sculpt the terrain within the engine itself. There are are large range of tools within the terrain modifier with lots of flexibility. The tool itself is is basically a paintbrush which allows you to sculpt the terrain wherever and however you want with the ability to change the size of the brush, the strength of the brush and the height of the terrain being painted.

Unfortunately the process has been extremely time consuming as the brush itself can be quite fiddly to use, especially in area's where you need lots of accuracy and need to make small adjustments such as at the edges of the track where it should meet the grass.  This is because the smallest radius of the brush that you can use is 1 metre, so basically the brush, which is simply a circle, at its smallest is still 2 metres wide. Fortunately there aren't may drastic elevation changes in the circuit apart from a gradual reduction in height at the at the western hairpin. Getting the terrain to a reasonable point took longer than expected, but after a few days I'd managed to get the terrain surrounding the track at the right height at the edges of the track all the way around as well as having slightly raised terrain inside of the track, what you might call islands, using the reference photograph's I had collected to ensure the terrain resembled the real location as closely as reasonably possible. 

At this point the surrounding landscape was kept flat and I focused on getting the whitebox models imported into the engine and placed in the correct places. At this point I encountered the next problem. The whitebox models I was importing into the level were just very simple, primitive shapes but for some reason, in the engine, some of the faces of the objects were displaying very strangely with strange flickering shadows almost like a hologram effect, and this appeared on multiple objects that I imported. 

Simple whitebox model before being imported to CryENGINE.

The same model in CryENGINE with the strange shadowing clearly visible.

More examples of the strange shadowing.

Whilst continuing to add my whitebox models to the level and placing them I struggled to find out why some of them were displaying this strange shadowing. Even after consulting my peers at university as well as a tutor I was still stuck for an answer! As with many things with this work, there's usually a simple solution to the problems, making them all the more frustrating when you figure them out! Although the shadowing didn't really matter, as these whitebox models were just placeholders at the moment until the final models replaced them, I hadn't come across this error before and wanted to get to the bottom of it! I also didn't want to come across the problem when importing my final models. I dont know why it crossed my mind, but because these were simple whitebox models, I hadn't been unwrapping them as I was just applying a simple grey/ white texture as you can see. It turned out that this was the problem! All primitive objects in 3DS Max dont need unwrapping to just apply a flat colour texture but as soon as a primitive object is modified in anyway the UV's can become a bit scrambled. 

Thankfully it was a quick fix, by applying a flatten mapping modifier to each whitebox model's UV's the flickering faces were gone! 

I could now focus on the getting the level planned out fully using my whitebox models which took me to the end of the week. I had begun placing whitebox tire wall models all around the track, but again this was taking up a lot of time individually placing each tyre wall model around the track and using the reference to ensure they were placed correctly around the circuit. I decided after placing the tyre walls roughly half way around the track that it would be a waste to spend anymore time doing this as I now had a good idea and could continue placing them once I had my final tyre models. 

Below is the track and main buildings planned out;

Re-Familirasing Myself with the CryENGINE - Back To Basics

With the bulk of larger assets, the track for example! being modeled in 3D Studio Max, most of them at least at the white box stage, I need to start importing things into my chosen game engine (Crytek's CryENGINE) and begin the layout of the level. 

I haven't gone near the engine for well over six months now, the last time being during the second year group project, and unfortunately, even then, I didn't spend much time with the engine as I was mainly tasked with concept work, modelling and texturing. One skill taken from that project in relation to the engine though, was that I was able to confidently prepare the assets in 3DS Max, ready for exporting to the CryENGINE, something which the other group members seemed to struggle with on occasion!

First things first was to download the latest engine, which was CryENGINE 3.5.6. After opening the editor I wanted to start by just spending a few hours learning the basics again. I began by creating a new level and editing the terrain, experimenting with the height map resolution and meters per unit and the painting the terrain.

I decided that for now I would just fill the whole map with a terrain at the same height so I basically had just a complete flat map to begin building the level. 

Once I had this in place I wanted to import the circuit diagram I had made. I think I could put the diagram itself on the actual terrain so that as I modified the terrain the actual diagram would stay in place which would probably make it easier to keep the layout most accurate, but, I decided to just import the plane from 3DS Max, which was already the right size to just have the diagram applied as a texture. I could then hide it when I was using the diagram.

Before I could export the plane needed for the diagram, as with building the assets in 3DS Max, I had to ensure that the scale was correct within the engine, especially as this is what the player would interact with, it's important that everything is the correct size. The unit size of 3DS Max and CryENGINE also had to match, other wise, an object that was the correct size in Max may appear really huge or tiny once exported to CryENGINE if the units didn't match. 

This appears simple at first, but as you may know if you work with any of these programs, things never are. Changing the units in 3DS Max I exported the track model as you can see below;

Errrmmm?... pick one?!

Okay so things haven't gone right straight away. As you can see from the image above, altering the unit size in 3DS Max drastically affects the size of the model after exporting it into CryENGINE. One of these has got to be the right size though? surely? 

Okay, so I cant just pick one and hope for the best. I want the circuit to be exactly the correct size, and either way, once the engine is in game mode and you're able to use the player to explore the level its going to be immediately noticeable. 

There was only one way to be sure that the unit set up in my 3DS Max file. I did this by modelling a 1x1x1 meter box inside 3DS Max and exporting it into CryENGINE. I also built a 1x1x1 meter box in CryENGINE using the solid designer tool. Once these boxes matched, I knew that the units were set up correct inside 3DS Max and all of my models would be to scale once exported to CryENGINE. 

You can see in the image below the two 1x1x1 meter boxes side by side. They match!

Phew! take a breath! 

As you can see from the image above I also played about with some of the other basic CryENGINE tools such as player spawn point.

All I had to do now was export the plane from Max and apply the track diagram in CryENGINE as a texture. Converting the diagram to a CryENGINE texture, known as a Cry Tiff was a simple process using the Photoshop plug-in. The plug-in was already installed from last years group project and I had gone through the process quite a few times during that project.

Once this was done, the texture was applied in CryENGINE!

Erm, no, hang on, that's not right is it?! 

Okay, so the texture's applied, its the right scale, but its a little pink. Its not ideal but its a start! I could probably get on like this to be honest, but I'll eventually come to a point where I need to start texturing the rest of the level and in all honesty, I don't want a pink Stretton. 

Oh yeah, one other thing, when I zoom into the diagram now, which I need to do for the placement some of the smaller assets, this happens;

Lots of tiny diagrams!

Okay CryENGINE, something's not right, again if your familiar with these programs, there's always something not right, always something that just doesn't work right away, always something that needs fixing. Ahh I'm getting tired of this! Only a few more weeks to go!

And then it finally clicked, (after opening the material editor again).

I remember we had this problem with the group project. An important file called 'resource compiler' was missing from the CryENGINE download so the engine wasn't able to process the materials properly. Looks like the file is still missing! get it sorted Crytek! you see, its this kind of thing that I'm tired of!

Anyway, lets bring this blog to an end. After downloading the 'resource compiler' or 'rc' folder it seemed to work. For now! 

The next stage is to begin exporting the white box assets into the engine and begin laying out the level. 

Full Track Reference

Before Christmas I was given the circuit all to myself to collect reference photographs! What a cool experience.

Unfortunately the conditions weren't perfect as it was begging to rain but thankfully it stayed off for the few hours I spent at the circuit. The fact that it was winter also wasn't ideal as the conditions weren't what I plan on re-creating in my level. My plan was to gather as much photographic reference as necessary to allow me to begin recreating the track accurately and with a good level of detail. I started by actually walking along the race track, armed with my camera and tripod to ensure that the photographs taken were always roughly at the same height. Starting at one point on the track and standing roughly in the center of the track I placed the tripod and took 5-6 photographs from left to right, i then walked approximately 10 steps forward and repeated the process until I had walked the whole track which took roughly 2 hours. I was happy that this process would give me enough reference images to ensure I would be able to reconstruct the circuit at home without having to return the the track unless absolutely necessary.

After photographing the track itself I then continued to photograph the rest of the complex from various angles as well as photographing the horizon from different locations to use as reference for distant objects within the level. Although some of the features of the complex would not be seen by the player within the level such as the rear of certain buildings I still want to include them for when I am taking shots and flythroughs for my portfolio.

All of this reference is invaluable, as this stage massively influences the final outcome of any project. The reference is used throughout the project from concepting, modelling, building the level and texturing the models, but more importantly for a project like mine where a real world location is being created, of course some artistic license can be used to ensure the environment is interesting and aesthetically pleasing for the player but you have to imagine that what the consumer is looking for is an accurate representation of the location.

In a few hours I'd taken just over 600 photographs which I'm sure will come in handy throughout the project and hopefully, strengthen the final outcome of the project. I'd just like to thank Nick at the Stretton Circuit as well as Stuart and Ruth, the circuit owners for giving me permission to walk the track and giving me the place all to myself. The project would be a much harder job without this opportunity. 

Project Underway!

Usually the hardest thing with a large scale project such as this FMP is, where to start?! Luckily, I've had a bit of practice during the previous two and a half years on the Game Art course, believe it or not, most of the time our tutors know what they're talking about! So, my answer to the question? Im going to go with Whiteboxing! 

One thing I didn't know until now though is that the term white box actually comes from PC's that don't have a brand name, hence, a white box! A little trivia for you there.

As I have a pretty decent idea of the overall layout of my level I decided I can pretty much get stuck into this quite quickly. Because, I have a feeling that once I've got the bulk of the main features of the level in place it may still look quite open and empty, so the sooner I have my level white boxed, the sooner I can begin to look at which areas need more attention, and use the whitebox to design some more concepts with more focus on the finer details.

I began by modifying the track diagram I had designed in Photoshop by roughly dividing the track itself using a simple grid, simply for me to follow inside 3DS Max;

I did this, as I decided the best way to model the circuit itself was to use a Spline as this would enable me to follow the track precisely and give me the most flexibility with the mesh density whilst the circuit itself is quite twisty and obviously is wider at some points and narrower at other.

To ensure the white box was to scale I applied the track diagram to a plane within my 3DS Max scene, if you look closely at the diagram you can see a scale indicator (bottom right) of 20m. I simply created a 20m box within the scene and then scaled the plane until the circuit diagram matched the box.

Spline tool (shown in blue) used to model the circuit

Just modelling the track itself took ages! much longer than I though it would. I assume that this wont be the final mesh used so I couldn't decide how many tri's would be reasonable for it. To help me with this I thought about what features of the track itself, (bare in mind I am only talking about the tarmac part now!) should have the highest priority. At the end of the day its a fairly flat open thing, but on the other hand it is the focal point of my whole level. So, keeping it simple for now I decided that, with the main layout of the track modeled, I should concentrate on;

-the corners, to ensure that each corner has enough geometry, consistent with the rest of the circuit to ensure they flow without looking too 'jaggedy' as they can in older racing games, even on PS2 and Xbox. 

-track banking, in real life even the roads are banked (also referred to as the angle of camber), where the road turns or angles, usually towards the inside of the corner. I decided that this needed to be included in my level for realism, but I also have a feeling that this will aid in the play-ability of the level, making easier for the player to turn the vehicle at each corner, (although this is just a theory!). 

For now, as you can see from the images below, I divided the track quite generously, and have kept it ever so slightly higher in the middle all the way around. I have a feeling though, that I may come back to it and reduce how many times I have divided the track, all depending on how the final level build performs. Apart from the track, I've only managed to get a few of the main buildings in place, again using my 'to scale' map as well as some placeholder tyre walls along one part of the circuit, but for now I think this will do. 

I dont really want to spend any more time in 3DS Max at this point and think it would be best to get this stuff straight into the Cry ENGINE to finish the whiteboxing stage, as the terrain surrounding the complex and the track itself will all be done using the terrain paint tool within CryENGINE.

NEXT JOB - install the latest Cry ENGINE and familiarize myself again with the basic layout and tools. Then begin importing this weeks white box models and develop the whitebox from there!

Project Brief

Summary

Main goals; Create a racing game with one track based on a real-world circuit (Stretton Circuit, Leicester) with an interactive element in the form of a playable vehicle which represents the main character.

Purpose; Emphasis will be on the accuracy and attention to detail of the real-world circuit in order to showcase my environmental modelling skills, the vehicle model will also demonstrate my ability to model existing objects/ vehicles with a high degree of accuracy and attention to detail. The playable vehicle will demonstrate my knowledge with the chosen game engine as well as my problem solving abilities. The main goals will have complete priority during the project and will need to be completed to a visually and technically high standard.

Secondary Goals; My secondary goals include items highlighted in page 11 of my design document including sound, a HUD, variable weather and the inclusion of AI etc. These items will only be explored depending on the status of my main goals

Platform

Possibilities;

Mobile Device/ IOS;

Pros;

• Huge market appeal for mobile games development which may result in better job opportunities
• Mobile devices are becoming more and more powerful, and are able to run games with reasonable 3D graphics
• Support for mobile game development from Unity 3D and UDK
• More suited towards solo game development

Cons;

• Graphically less impressive that console and PC games
• Have to be extremely optimised to function properly, some sacrifices may need to be made on more CPU intensive tasks such as particle effects etc.
• Less functionality typically due to lack of dedicated gaming controls, usually touch screen/ tilt functions
• Outrageous number of devices and operating systems on the market, IOS or Android are probably the only two worth approaching
• Would possibly need mobile device to demonstrate project for degree show

Current Gen (PS3, Xbox 360, moderate gaming PC)

Pros;

• Most familiar modelling 3D assets with specifications aimed towards this category
• Good graphical capabilities
• Reasonable freedom with ranging poly counts
• All supported by optional game engines (Unity 3D, UDK and CryENGINE3).
• Project development will take place using lab computers which falls into this category, lab computers will also be used during degree show
• Potential for fantastic looking portfolio work

Cons;

• Lots of job competition in the current market
• Next gen consoles now released
• Finished project would have to be extremely polished to be acceptable as a current gen game

Next Gen (PS4, Xbox One, High-end gaming PC)

Pros;

• Familiarity with 3D model asset creation for current gen is easily transferable
• Extreme graphical capabilities
• Lots of freedom modelling and texturing with huge budgets

Cons;

• Only recently released, little support from optional game engines (Unity 3D, UDK and CryENGINE3) apart from the CryENGINE3.
• Much longer development time required to reach next-gen standard
• Need to consider hardware limitations, are lab computers on par with next-gen consoles?

Choice; (PS3, Xbox 360, moderate gaming PC)

Tools and Software

• Digital camera for gathering reference images.
• Photoshop CS3 for image manipulation and texture painting.
• 3D Studio Max 2012 for Modelling, Mapping, and manipulating UVs (texture coordinates).
• Zbrush for high poly meshes and normal mapping.
• The internet/ library for research and any additional reference material.
• nDo2 for Normal and AO maps.
• Marmoset Toolbag for final renders.
• Open office/ Microsoft Word

Engine possibilities;

Unity3D Engine;

Notable games developed in Unity3D; Drift Mania, Rain, Call Of Duty Strike Team

Pros;

• One notable racing game as noted and extensive car tutorial available

• Meant to be an easy engine to learn
• Ability to develop for multiple platforms
• Extremely large developer community and lots of documentation is readily available (car tutorial available).

Cons;

• No prior experience with the engine and no support available from tutors at uni as the engine is not used on the Game Art Design course.
• More advanced features such as real time lighting/ shadows does not come with free Unity3D download
• Not as many advanced features as UDK and CryENGINE3
• More suited towards smaller mobile games
• Hardly any tools in comparison to UDK and CryEngine3

UDK (Unreal Development Kit);

Notable games developed in UDK; Remember Me, Dishonored, Borderlands, Mass Effect

Pros;

• Extremely large developer community and documentation
• Some tutorials and documentation available on vehicle export into UDK
• Lots of knowledge available at uni to help with an problems during project
• Some experience with the engine through uni projects (Blitz Building and Rooftop projects)

Cons;

• No notable racing games developed

• Program can be temperamental at times
• Poor lighting compared to CryEngine3, lighting needs to be built along with other paths before playing level which is more time consuming
• Tool-set and user interface can be complicated at times

CryEngine3

Notable games developed in CryEngine3; Far Cry, Crysis, Sniper: Ghost Warrior 2

Pros;

• Incredible real time lighting and rendering inside the viewport which is more suited to outdoor environments such as my race track
• Better for 'realistic' looking environments
• Substantial developer and community support on the CryDev forums as well as the CryEngine3 SDK documentation including vechile asset production pipeline.
• User friendly Engine and scene management allowing for higher polygons, more draw calls, and overdraw
• Intergrated time of day system
• Tutorials available on vehicle creation and AI usage
• Documentation available on UI and HUD
• artist-level programming in flowgraph is extremely powerful and simple

Cons;

• No notable racing games developed

• Needs to be connected to the internet to run (only for first sign on in 3.5.4)
• Smaller community and less documentation than Unity3D and UDK
• Editor can run slow with real time viewport without decent specification PC

Choice; CryEngine3

Technical Specification

Final Project

• Final project will need to run on lab computers
• Target Framerate; 35 FPS, Lowest acceptable framerate ; 30 FPS.
• Draw call limit;
  • Maximum average; 500 calls
  • Maximum Peak; 2000 calls

Environment

• Track scale can be seen in page 14 of the design document, track length is 850m and should take on average 60 seconds to complete one lap depending on player skill.
• The whole environment including track, props, surrounding complex and environment backdrop should be no more than 500k tris (subject to change).
• Only the race track area will be explorable using the vehicle, this includes grass embankments and curbs etc.
• The race track and surrounding complex (explorable area) will contain the most detail and therefore demand the highest poly limits. Poly counts for backdrop environment objects should be kept to a minimum to ensure the target frame rate and draw call limits are met and the final game runs smoothly.

Preliminary Environment Assets

-Track, curbs -Track lights
-Control Box, lights -Pit Lane and complex
-Foliage -Fencing
-Tyre Walls -Smaller huts/ buildings
-Foam Crash Walls -Crowd Area assets
-Cones -Environment background elements
-Barrels -Fuel Tanks
-Signage/ advert boards -Other unique assets

A range of these assets should be re-usable and/ or modular and have enough detail that little or no repetition is noticeable.

Textures

A full range of textures will be used ranging from 256 pixels minimum to a maximum 1024 pixels.

Preliminary texture usage;

-Diffuse, Diffuse with alpha

-Normal

-Specular, Colour Specular

-Environment

-Detail

-Opacity

-Decal

Vehicle

• The drivable vehicle should be no more than 40k tris (subject to change)
• If included, AI opponent vehicles should be no more than 30k tris (subject to change)

Textures

• Vehicle should require no more than 2 unique textures at 1024 pixels.

Preliminary texture usage;

-Diffuse, Diffuse with alpha

-Normal

-Specular, Colour Specular

-Environment

-Detail

-Opacity

-Decal

Issue; Despite the chosen engine's (CryENGINE3) advantages in support of making my project look realistic, my research on using vehicles in the engine has so far failed to show any 2 wheeled vehicles being used, all documentation and tutorials, including the Crytek Dashboard documents, only describe vehicles with 4 or more wheels being exported. If I am to include a 2 wheeled vehicle (minimoto) in the final build of the game it would need to animate properly including leaning, tilting and correct physics. I will not immediately write off the possibility of the inclusion of a 2 wheeled vehicle, but at this stage the inclusion of a 4 wheeled vehicle (go-kart) seems more achievable all factors considered.

More research will be done on this before a final decision is made. I think the best way to approach this will be to export a very simple 2 wheeled vehicle and explore the various parameters to see if the correct animations needed can be achieved. Before this is done further consideration will be taken as to which vehicle (minimoto or go-kart) would be better suited to the final build.

Documentation

My Final Major Project will be documented in my design document;

The design document will be on going and will outline the whole project, including research and development, problems I have encountered and solved, concepts and planning, as well as documenting the assets that are produced.

My Final Major Project will also be documented on this dedicated blog;

www.joedempseygameartfmp.blogspot.co.uk

Concepts

Here are my first concepts from the previous post on their own so that you can view them larger.

These concepts are purely to illustrate the atmospheric conditions that I'd like to capture during the main game-play, with strong warm lighting creating a vibrant level full of rich tones and a diverse colour palette, which I feel the cryENGINE will enable me to do. 

The Proposal, in detail - Part Two

At the end of the summer break last year, before beginning my third year I spent a day at the Stretton Circuit with my minimoto. As well as spending the day racing around the track I also thought it would be a great opportunity to begin gathering some reference images for use in concepting, my project brief and during the proposal stage. So, I took my camera with me and walked around the track between sessions to snap some pics.

Below are some examples of the photographs I was able to take;

These initial reference photographs weren't intended as reference for the modelling stage but instead to highlight the richness of detail at the circuit on and off the track, from the wealth of racing oriented props to planes and helicopters flying overhead from the adjacent airport to racers preparing their bikes/ karts in the pit areas. 

These first reference images were a great starting point to begin developing the visual style of my project. Also, with it being the summer, the conditions were perfect to describe the atmosphere and conditions I'd ideally like to achieve during the game-play.

Firstly, using satellite images from Google Earth I constructed a circuit diagram to describe scale, the playable area and the level of detail likely to be used throughout the level. 

Below is my circuit diagram to scale;

Explorable area;

Only the part of the map highlighted in red below will be explorable using the vehicle;

Level of detail;

The heat map below describes the amount of detail contained within the environment in relation to polygon counts and texture budgets etc.

Visual Style and Game-play;

The game should be visually accurate and realistic to the real-world location but should be strong and vibrant similar to the notable games above giving it a wow factor and grabbing the players attention. The game-play should be less simulated than some of the above games with a slight arcade feel so that the game is easy to pick up and is quickly enjoyable and fun to play.

The diagram below best describes my aim for visual style and game-play in relation to other notable games;

From this I began to put together some quick concepts intended to highlight what's described above, the visual style my project including lighting, weather conditions, and colour palette etc. 

Below; screenshot concepts of how the game should look during gameplay;