Art Development

* Art Development
* Artist's Guide to Wii
* Artist Object Budgets

## Getting Started

**1:100 SCALE** - ALL background art had to be modelled 1:100 in Maya (because Maya handled large values badly). An export scale was then used to scale the object back up – this will be explained later.

To work in Maya at 1:100, you simply had to set the working units to centimeters and treat 1cm as 1m (goto... window > settings/preferences > preferences > settings > working units > linear > centimeters).

It was useful to set the project folder in Maya to d:\user\work\<projectname> - that way all your Maya data is saved into the correct location. Using a different folder elsewhere would usually end up with pathing problems and you would need to re-path you textures each time you export something for the game.

**BACKFACE CULLING -** Backface culling was always turned on in Maya (goto… view > backface culling) if a developer was viewing their work in a shaded view.

**NAMING FILES -** All game assets had to sit within the <projectname> folder under the appropriate sub-folders.

Anything that was not an in-game asset such as documents, concept art and reference material would go into the <projectname>\_development (e.g.: d:\user\work\bf\_development\concept\_art) folder.

To stop accidental spelling mistakes developers had to use abbreviations for long class names and categories at all times.

For example: Battlefront has common classes/factions like Imperial/Empire, Confederacy of Independent Systems, Rebel and Republic.

These were standardized to IMP, CIS, REB and REP.

Levels names such as Kashyyyk, Mustafar, Coruscant were simplified to KAS, MUS and COR to stop simple spelling mistakes from happening.

Names always had to be consistent between setup files, build files, and art assets.
Directory names had to be the same as the filenames. Additionally, Maya file filenames had to be the same as the in-game .xml files.

For example...

bf / capitalships / cis\_command\_int / cis\_command\_int.mb
bf / capitalships / cis\_command\_int / cis\_command\_int.xml

**FOLDERS AND FILE STRUCTURE** - All background assets had to sit under <projectname>\backgrounds\

Each level had the abbreviated folder name like this:

<projectname>\backgrounds\kas

Within this folder there were the following folders:

BUILDINGS
FOLIAGE
PARTICLES
PROPS
SKYDOME
WORLD
TEXTURES

**Buildings** - The buildings folder contained all background structures both in XML and Maya format. Buildings are any object that is a static background element and has a lightmap.

**Foliage** - The foliage folder housed rocks and foliage files that were placed using the Terrain Editor.

**Props** – This folder contained all dynamic props such as destructable items and physics objects. Props were objects that did not have a lightmap.

**Skydome**  -This folder contained the level's main lighting XML and its textures. It also housed the level's skydome cubemaps that were created using HDRshop.

**World** – The world folder had two other folders within it – export and textures. The terrain folder itself contained the save data from the FRD World Editor. The export folder contained the ingame terrain files that were exported from the World Editor.

**Textures** – All textures for the level buildings and props resided in this folder.

## Polygon and Texture Limits

Background w/o terrain - 90,000 polys

Detail Geometry - 15,000 polys

Foliage Spraying - 10,000 polys

Capital Ship Exterior Geometry - 10,000 + 15,000 polys

Vehicle Geometry (inc 3rd person cockpit) - 5,000 polys

Vehicle Geometry (1st person cockpit only) - 4,000 polys

Weapon Geometry (1st Person) - 4,000 polys

Weapon Geometry (3rd Person) - 500 polys

Destructible Prop Geometry - 4,000 polys

Character Geometry - 3,500 polys

Background w/ terrain - 150mb

Background w/o terrain - 180mb

Vehicle exterior - 10mb

Vehicle cockpit - 10mb

Capital Ship interior - 120mb

Capital Ship exterior - 30mb

Misc textures (Effects/Resident/UI textures) - 50Mb

Weapons - 10mb

Characters - 5mb

For surfaces the player can walk right up to textures should ideally be applied at **512 pixels across 1 metre**. This will be halved ingame to 256 pixels per metre.

Textures will be mipmapped, so if someone had multiple elements on one texture, they had to leave at least a 16pixel gap between them to prevent bleeding between elements. In most cases, a specular map was in greyscale, as this would save memory when the texture was compressed.

Developers didn't actually convert to greyscale mode in Photoshop, they just desaturated the image completely (CTRL+Shift+U). The only time they needed colour in their specular map was in cases where the material would tint the reflection (for example, heat-treated metals).

All textures were saved in **Targa (.tga)** format and saved as 24-bit. if there was no alpha channel, or 32-bit with an alpha channel.

## Creating a Prop

**BASIC PROPS:**

A prop is an object that is interactive with the player or gameplay. Props are usually dynamically lit and in most cases can be destroyed.

A prop can be any shape or size but it must sit on the origin i.e. the base of the prop should be at x0 y0 z0 and should face along the Z axis (front of the prop z+ back of the prop z-).

A prop can have up to three levels of detail (LOD's) and each LOD needs a physics rep/rigid body and should fit the object as close as possible.

Props should also have (if destructible) broken parts known as B\_GIBS that appear when the object has been blown up and a damaged state that remains in place after the explosion. A maximum of 6 gibs should be used on a prop, as more than this increases memory usage.

All of this data needs to sit under a group called BTOP and is to be organized like this:

BTOP
exportscale

Also, you can see a group called exportscale that sits outside of the BTOP. This group’s X Y Z scale should be 100 and must exist in all scenes that are modelled 1:100 as described earlier.

Once a prop has been created, you had to make sure you saved and exported it to the props folder within the appropriate level folder:

D:\user\work\<projectname>\backgrounds\<levelname>\props\

If it is a generic prop (i.e. it will apear in various levels) then it was saved to the generic props location:

D:\user\work\<projectname>\props\

and a descriptive subfolder was created for these. For example: bf\props\misc\misc\_command\_post\

The placing of props was done by the designer using the Setup Editor. Props were not to be placed into a level via the World Editor – only background components were.

**ANIMATED PROPS:**

Animated props are set up in a similar way to basic prop; however, the B\_ parts are replaced with bones instead of groups.f

For example, a developer might have wanted to create a communications antenna that extends once activated. Here is how to set this up:

CHRTOP

As you can see, the base was going to be static, as it was just a normal group and the antenna had a bone instead of a group so that it could be animated.

**DOOR PROPS:**

Doors are useful for culling an entire room from the player’s view. These are particularly useful between interior and exterior sections.

If a developer was to make a door, they simply had to create the geometry to fit inside the door frame of their level and save it as a prop. The door, when placed in the game, would sit half in one room and half into the other, like this:
This is so that there are no visible gaps around the portal line when the room is not drawn. For example, if the player is stood in room 1, he will see room 1 and the door but not room 2 until the door opens.

Doors could be all shapes and sizes, but they were limited to translation and rotation.

Here is a typical door prop structure:

BTOP
exportscale

The origin (0, 0, 0,) of the door prop is the axis for rotation and translation. So, if the door needed to be rotated from a hinge, then the origin must be at the point at which you would want the door to rotate around.

## Creating a Character

In-Game Characters: 3000-3500 polys, around 20-25 bones

Cutscene Characters: 4000 - 5000 polys, around 80 bones

2048x2048 (diff, norm, spec) used for the body, 1024x1024 (diff, norm, spec) shared between the face and arms.

## Creating a Weapon

**NOTE**: All weapons faced along the Z-axis (front of the gun is z+, back of the gun is z-).

1st Person: 3000-4000 polys

3rd Person: 3000-4000 polys

.mb and .xmls should have \_firstperson or \_thirdperson at end of filename to clarify which version they are.

e.g.     mp5k\_firstperson.xml
mp5k\_thirdperson.xml

The origin of the first-person weapons needed to be at the wrist position, with a DOF\_CENTRE to show the centrepos.

The origin of the third-person weapons was at the centre, with a DOF\_WRIST to show the wrist position (i.e. the other way around – unfortunately, this was necessary).

Also, a DOF\_SHOOTPOS was also to be placed at the centre of the barrel end, but very slightly outside of the mesh – otherwise, the bullet would just collide with the gun’s geometry.

Weapons were set up almost the same as the animated props like this:

CHRTOP

## Creating a Vehicle

**NOTE**: All vehicles faced along the Z-axis (front of the vehicle is z+, back of the vehicle is z-).

**EXTERIORS -** 4000-5000 polys (including any 3rd person cockpit)
4096x4096 (diff, norm, spec)

Shoot positions were labelled with a DOF for both primary and secondary fire. For primary weapons DOF\_SHOOTPOS\_PRIMARY1, DOF\_SHOOTPOS\_PRIMARY2, etc. and for secondary weapons (e.g. rockets) DOF\_SHOOTPOS\_SECONDARY1, etc.

Each vehicle needed to have Physics Bounds (created using the Create Rigid Body tool in the FRD tool shelf) and also required B\_GIBS for when the ship was destroyed.

To add trail FX to ships you simply had to place a DOF\_TRAIL on each of the wing tips. Example: DOF\_TRAIL\_1, DOF\_TRAIL\_2, and so on.

DOF\_THRUSTER also had to be placed on each thruster on the mesh.

Each space-going vehicle required a re-entry effect shield. This was defined by creating a simple mesh around the ship model and labelling it B\_shield.

Vehicle LODs needed to be saved as separate Maya and XML files, but had to be identical in structure. In other words, they needed to have the same amount of parts, DOFs, etc. (please note: No new/extra textures were to be used on the LODs)

Each LOD file needed to be saved next to the main “high” poly model. For example...

bf/vehicles/reb/reb\_xwing/reb\_xwing.mb
bf/vehicles/reb/reb\_xwing/reb\_xwing.xml

bf/vehicles/reb/reb\_xwing/reb\_xwing\_med.mb
bf/vehicles/reb/reb\_xwing/reb\_xwing\_med.xml

bf/vehicles/reb/reb\_xwing/reb\_xwing\_low.mb
bf/vehicles/reb/reb\_xwing/reb\_xwing\_low.xml

**INTERIORS -** up to 4000 polys (including any exterior)
2048x2048(diff, norm, spec)

The cockpit position was similar to the cockpit in the exterior version; however, it did not have to match the actual exterior geometry.

Visibility was VERY important in cockpit mode. The cockpit had to not obscure the centre of the screen and could take up no more than 25% of the screen, even if realism were to suffer. (note: the character arms would not be drawn)

Developers saved out the cockpit file alongside the main files like this:

bf/vehicles/reb/reb\_xwing/reb\_xwing\_cockpit.mb
bf/vehicles/reb/reb\_xwing/reb\_xwing\_cockpit.xml

## Creating a Background Component

A background component is an object that was loaded into the World Editor and formed the static background/level geometry.

All geometry for a background component had to sit inside a room node (RO\_) otherwise it would not be exported and would not appear in-game.

This is a typical background component setup:

RO\_default

RO\_small\_building\_int

RO\_underground\_cave
exportscale

In the game, there was a default room (RO\_default) that was there all the time. In other words, the RO\_default represented the game world/space and was drawn all the time. Objects inside RO\_default absolutely had to make good use of LODs and occluders as this was be the primary way of reducing the number of polys being drawn in worldspace.

**NOTE**: For the purpose of keeping a scene as tidy as possible, it was a good practice to place technical elements in a group called TECH. It was recommended for developers to have a TECH group within each top node, i.e. BTOP or RO\_ and inside these groups should be things like PORTALS, DOFs etc.

## Portals

Rooms were joined together with portals – these portals are polys (quads) that were placed at a doorway into another room. Portals had to be planar along the y-axis. Horizontal portals could be used in some situations when the player could not pass through them.

A portal had to sit in one room and point to another room. To do this, you simply had to create a poly that fit the doorway area and rested on the room's border or edge.

Note: Room 1's geometry must not overlap into Room 2 otherwise a flickering/disappearing room effect will happen and may cause other problems.
As you can see from the following image, the portal geometry (PO\_02) is a child of RO\_01 and because the portal is called PO\_02 the engine knows to link room 01 to room 02.

Developers had to always try to make room names descriptive as it would be less confusing when you would have lots of rooms to deal with. (i.e. RO\_entrance\_hall or RO\_landing\_bay etc.)

## Fade Portals

A fade portal could be used to turn off a room at a distance. Fade portals did not actually fade out but rather instantly turned off at a set distance. To set up a fade portal, you simply created and applied a beam shader onto the portal.
As you can see here, this setup would turn off the portal when you were 100m away from it. To increase or decrease the distance, you simply had to change the distance start setting. All other values were 0.

To archive the fade effect, you would need to create an extra poly that sits in the same place as the portal, but this time apply a texture that represents the adjacent room. After that, you would need to apply a beam shader to it with the same settings.

## LODs

In Maya, you would need to create the different LOD states of the geometry and name them B\_<name>\_high, B\_<name>\_med and B\_<name>\_low.

Afterwards, you would need to group these separate objects under a group called LOD\_<name>, where <name> is the same as the name in the individual objects. Then, you would have to place all the LOD\_<name> group inside a group called LIGHTMAPPED (if using lightmaps) or GEOM (if it is a prop) and then place that group under the BTOP.

You had to have at least two states in a LOD - otherwise you could not label it as LOD\_ .If you required just two states, you could use the B\_<name>\_high and B\_<name>\_low.

The LOD distances could then be set up on a component or all the components within the World Editor.

## Occluders

Occluders were simplified 3D meshes that represented the volume of an object/background component. What happened was that when a character, prop, room or vehicle went completely behind the occluder, it was switched off and not drawn. This reduced the amount of polys visible from the player's perspective.

Occluders were highly effective in outdoor areas that were extremely hard to portal efficiently such as… well, pretty much all of the Battlefront levels.

Occluders had an associated 'cost' in CPU time just like Portals. Simply put – the more occluders on-screen = more CPU time.

## Simple Collisions

Every background component had a separate simplified collision mesh. This mesh represented the actual geometry the player, vehicles and A.I. walked on and collided with.

Small details, such as pipes, were represented as simple bounding boxes and stairs or small steps would become ramps.

All this simple geometry would then sit inside a group called COLLISION\_<desciptive\_name>.

Hit decals and bullets would first have to be tested against the simple geometry and then actually tested against the background geometry to decide if it had hit or not. So, if you were to have a wooden fence made from a number of posts and crossbeams, you could represent this as a simple bounding box as the hit would still test against the background.

## Decals

Decals could be used to break up surfaces, add detail and/or add lighting FX to areas where the lightmap resolution was poor. However, developers had to use them carefully as huge polys with alpha would increase the fill rate and impact the performance of the game.

In addition, it was recommended to use additive and multiplicative for light and shadow effects because alpha textures did not compress down as much as a texture without alpha.

Decals could be flat against other polys as long as a developer set the layer attributes in the FRD Shader Tool. To do this, you had to create a shader and load the textures you want, then scroll down to the 'extra values' section and in the ID field type 'layer' and in the 'value' field type '1'.

This would force the shader of the decal to draw on top of the poly behind stopping any z-fighting.
If you wanted another decal to draw over the top of the previous shaders, you simply had to follow those steps again and increase the 'value' to 2 and so on.

In most cases, decals would not want to cast shadows or have a lightmap applied to them. Grouping decal geometry into its own group meant that you could select all of them and set the 'cast shadows = off' attribute using the attribute spreadsheet.

If you were to do this, you would need to select all the geometry within the decals group (don't select the group itself) and then open up the attribute speadsheet (window > general editors > attribute spreadsheet) and select the render tab. On this sheet, you should have been able to see a column called 'cast shadows'.

## Lightmap UVs

Background components could be lightmapped using the in-house renderer called Bacon.

However, to do this, your model needed to go through the following process:

* Group together all your geometry that needs a lightmap into the group LIGHTMAPPED. This group should not include portals, DOFs, lightglows or beam shaders but must contain all geometry that you intend to have pre-baked lighting.
* Click on the “light map” FRD tool on the FRD shelf and enter in the pixels per meter required for your component.
	+ **NOTE**: Developers were working to 4 pixels per metre and because they are working at 1:100 scale, the value in the FRD lightmapping tool was set to 400.
* If this is the first time you have set up lightmap UVs on a component, simply click “Auto Layout Lightmap UV's”; otherwise, click on “delete all lightmap data” if you have modified the geometry of an already lightmapped component.

## Lights

Background components – especially interiors – needed lights added to them. There were two ways of doing this:

* Add lights into your Maya files – create a LIGHTS group inside your RO\_ group and create lights into the desired position. The problem with this method is that you are working blind because there is no way of getting realistic feedback of what the lighting will look like once rendered in Bacon.
* Add lights using the World Editor – this method is better because the coders have control of getting the lights to match/simulate the intensity and falloff of the Bacon lights.

The lighting information from these lights will be baked onto a lightmap texture.

## Light Glows

A light glow was a single four-sided mesh with an additive texture applied to it. Light glows could be used to add extra visual FX to background geometry interned to be a light source.

For example, you might have a light bulb in a room or a car head light that would look really cool if the light source had some sort of star filter effect of it.

If you were to create a light glow, you would simply have to create a quad/plane and apply your desired texture to it. This works best if you create an additive shader and use a texture like this...
After that, group the geometry and call the group node GLOW\_<descriptive\_name> and place it into a group called LIGHTGLOWS with each of the RO\_ groups.

Next, you would need select the GLOW\_ and use the FRD tool “Attribute Editor” and click “Add attributes to selected” The attributes that could then be added to a glow are:

* Distance Fade: Fade out with distance.

* Distance Scale: Scale with distance.

* Blend Mode: Choose from `Add` or `Multiply` to change the way the glow is rendered.

## Creating a Capital Ship

**EXTERIORS** - The budget for capital ship exteriors was 10,000 polygons. An additional 15,000 could be added and flagged as detail, which would only be turned on when close to the ship.

3 sets of 4096x4096 maps can be used for the exterior. The center of capital ship exteriors was the origin.

**INTERIORS** - Around 6 texture sets were used for the interiors of capital ships and the creation of the interiors was pretty much the same as that of background components.

One additional feature of capital ships is the TRANSFORMATION PORTAL. These portals allowed the interior of the capital ship to be in a completely different location to the exterior but make them look and work like they are in the same place in the world as though by magic.

**CAPITAL SHIP LODs** - Capital Ship LODs needed to be saved as separate Maya and XML files, but also had to be identical in structure. In other words, they needed to have the same amount of parts and DOFs etc. (please note: no new/extra textures were to be used on the LODs)

Each LOD file needed to be saved next to the main “high” poly model, for example:

bf/capital\_ships/cis/cis\_cruiser\_exterior/cis\_cruiser\_exterior.mb
bf/capital\_ships/cis/cis\_cruiser\_exterior/cis\_cruiser\_exterior.xml

bf/capital\_ships/cis/cis\_cruiser\_exterior/cis\_cruiser\_exterior\_med.mb
bf/capital\_ships/cis/cis\_cruiser\_exterior/cis\_cruiser\_exterior\_med.xml

bf/capital\_ships/cis/cis\_cruiser\_exterior/cis\_cruiser\_exterior\_low.mb
bf/capital\_ships/cis/cis\_cruiser\_exterior/cis\_cruiser\_exterior\_low.xml

## Creating a Walking Vehicle

Walking vehicles needed to be set up as follows:

* Each section of an articulated leg should be under its own B\_ folder. For example, B\_LEFTSHIN, B\_LEFTANKLE etc.
* DOFs should be placed at each joint, with a sensible name for each one. For example, DOF\_LEFTANKLE TOP, DOF LEFTANKLEBOT etc.
* If your vehicle also has an animated head, the DOF for the joint between the head and the neck should be called NECKTOP.
* The vehicle should be in a default standing pose.

Developers had to make sure the folders containing the geometry were named to describe the position of that joint, and the geometry is named using that convention as well, i.e. – B\_RKNEE (containing) R\_KNEE (containing) DOF\_RKNEETOP and DOF\_RKNEEBOTTOM.

When placing DOF locators, only one per position was required. For instance, rthigh and rhip required only one DOF and could be placed under either part as long as it correctly described where you would like the rotation of that part to begin.

## Creating a Turret Prop

**NOTE**: The centre of a turret was at the origin and face/point along the Z-axis.

Exteriors - 2000-4000 polys / 4096x4096 (diff, norm, spec)

BTOP
exportscale

Each turret required physics bounds (created using the Create Rigid Body tool in the FRD tool shelf) and also required B\_GIBS and a damaged state B\_DAMAGED for when the turret is destroyed.

For the animation of your turret, you would need to specify where the pivots between the parts would be. To do this, DOFs were placed at each joint, and their axial rotation specified within the name, e.g. DOF\_Y\_AXIS for the turret and DOF\_X\_AXIS for the gun.

#### **Creating Turret LODs**

Turret LODs needed to be saved as separate Maya and XML files but they also had to be identical in structure. In other words, they needed to have the same amount of parts and DOFs etc. (please note: no new/extra textures were to be used on the LODs)

Each LOD file needed to be saved next to the main “high” poly model, for example:

bf\props\turrets\reb\reb\_turret\_vehicle.mb
bf\props\turrets\reb\reb\_turret\_vehicle.xml

bf\props\turrets\reb\reb\_turret\_vehicle\_med.mb
bf\props\turrets\reb\reb\_turret\_vehicle\_med.xml

bf\props\turrets\reb\reb\_turret\_vehicle\_low.mb
bf\props\turrets\reb\reb\_turret\_vehicle\_low.xml

## Skies, Atmospheres and Scene Lighting

A background may require a skydome folder that contains all the data needed to create consistent lighting, atmosphere and sky colour.

A level required 3 elements to give consistent lighting and atmosphere:

1x Cubemap for the atmosphere, 1x cubemap for the space skybox and 1x image-based lighting texture (that was used to light the level).

For example: bf\backgrounds\tat\skydome

tat\_ground\_sky.tga – this texture is a cubemap and loaded into the atmosphere shader. This texture represents a 360-degree image of the atmosphere colour. As the player moves up into space you essentially leave the atmosphere behind you like a sort of volumetric layer above the planet surface.

tat\_space\_sky.tga – this texture is also a cubemap and represents a 630-degree view of outer space. As you move out of the atmosphere, you see more and more of this texture.
Typically this texture would have stars, nebulas, and possibly some small planets and/or moons.

tat\_ground\_ibl.tga – this texture is a variation of the tat\_ground\_sky.tga texture (but not necessarily the same) and used as a light (a Mental Ray IBL node) to light the level so that it matches the atmosphere.

tat\_ground\_ibl.xml – this is a scene setup using Maya that contains the main planet lights such as sunlight and IBL node (tat\_ground\_ibl.tga as described above). This XML is then used to light the whole world/level.

## Creating a World

**TERRAIN** - Clicking on new BG would create a new terrain world. If you did not want a terrain level, you could simply run the World Editor and start importing components.

**FOLIAGE -** These objects were saved into the foliage folder within the level's background folder, for example bf\backgrounds\tat\foliage.

Foliage could be anything from a flat poly (quad) to a very low-poly mesh. Foliage did not need to be just grass and plants, it could be other small details such as rocks, sticks and rubble and even litter.

More information regarding Terrain and Foliage here.

## Milestone Art Cut-off

The art cut-off for a milestone happened roughly two weeks before the milestone build is sent.
This ensured that all art was submitted so it could be checked/implemented by the code and design departments in time for their cut-off point which is one week before the milestone deadline.

The following week was when the build got tested by QA to ensure that FRD delivered a stable build of the game.

After the art cut-off NO artwork could be submitted to Perforce unless a developer was instructed by a lead or if they were working on a task/problem that was directly related to the milestone build.

## Notes on using Perforce

No Maya swatches. This happened when someone would submit a textures folder rather than selecting the files within the folder. If a developer happened to upload swatches they had to ask (redacted) to delete them or instruct them on how to remove them safely.

No “test” stuff unless it has been requested by a lead or a coder. Where possible, all test items had to sit within bf\backgrounds\test\_levels\<name\_of\_test\_folder>.

No workspace.mel – again, like the swatches this could be accidentally uploaded by submitting the folder rather than the files.

No manual revisions of files – there is no need to submit increments like “my\_file\_01.xml” ,“my\_file\_02.xml” ,“my\_file\_03.xml” and so on. Perforce handled version control, as that is what it was used for. A developer's files had to be saved as “my\_file.xml”.

No textures along with Maya and XML files – developers had to stick to the file structure previously mentioned.

## Important Notes

Developers ALWAYS had to make sure whatever they submitted to Perforce would build. They always had to check that their textures were pathed correctly and were submitted to Perforce. They had to ensure they had an export scale node present and that they grouped everything under a BTOP (for props) or RO (for background rooms).

If the asset already existed in a build file (i.e. a designer placed a developer's file into a level) they always used the G6 asset remake web interface to make sure that it would build without errors, before asking the setup person to remake the asset.

## Modelling

To create Wii levels from the higher-gen counterparts, there was a need to re-model, re-texture and re-light. Developers would need to adhere to any limits imposed, as failure would lead to developers repeating the same process again. There was little margin for memory overspend on the Wii format.

## Stripping Models

LODing – this process was used to reduce the polys in the model. There was a **PER VIEW** limit of 80K on screen. This was fixed and certainly had to be adhered to. Developers had to make sure they had their HUD set to display total polys on screen while working, in case there was a visual spike in an area that requires fixing. It was even more important that developers spent polys around the player's eye level and saved them in non-vital areas.

### **Tips for reducing Polygons**

* **Flatten it**: Developers used single planar faces to replace whole flat wall sections. All surface detail could be added to the textures.
* **Think Ahead**: Developers modelled with texturing in mind. They did have the opportunity for unique textures and had to think in tiles.
* **SAVE SAVE SAVE!**: Developers had to delete back facing polys, bevels, segments in curves wherever possible. Every little bit helped.
* **Be Square**: Developers tried to work in quads – it aided tiling textures and helped to keep the mesh clean.
* **Fake it!:** Developers analysed from a player's point of view how close they could get to objects. They judge their culling on where they could fake objects with lighting and textures and where they needed 3D detail.
* **At least 50% less fat:** There was a reduction of between 50 and 65% polys per level. There were exceptions depending on how geometry heavy a level was.
* **Does it work?**: When a developer was happy with their conversion, they had to make sure they tested it regularly; after modeling, after texturing and after lighting on a Wii-based Art Machine.

## Drawing Objects

The Wii interpreted on a 'per-object' rather than a 'per-poly' basis. This meant that – if the player could see just one pixel of a building on screen – the Wii would be drawing the whole building/prop/scene. Where possible, developers would need to break large items up into separate geometry groups as this would limit the opportunity for wasting memory on parts the player could not see. This was particularly important when there were portals between rooms.

## Portals

These worked the same as on next-gen and were not changed from the original hierarchy of the level.

## Outliner

For the most part, developers stuck to current naming conventions for the outliner.

## Saving and Exporting

Developers saved and exported their models with ' wii\_ ' before the current name of that item. For instance, apartment\_top.mb and apartment\_top.xml would become wii\_apartment\_top.mb and wii\_apartment\_top.xml. This made it simple for the programmer to find their converted files.

## Texturing

All textures were halved in size when they went into the game. This was kept this in mind when tiling as crispy details would look softer and would therefore require compensation. There are NO exceptions to texture sizes than the ones mentioned below. If a developer made textures that did not adhere to these rules, they would either appear lower resolution than anticipated or would not stream at all.

* 2048x2048
* 2048x1024 (Landscape letterbox was acceptable, portrait was not.)
* 512x512
* 512x256 (Landscape letterbox was acceptable, portrait was not.)

Developers could make textures smaller than 512 x 512 (as long as they were to the power of 2) but these did not stream (but were preloaded instead), so usage of them was kept to a minimum.

## Creating Textures

* Developers created their textures by making tiles from the original scene textures.
* Developers rendered sections of models where the artist had already created layered wall effects to create new tiles.
* Developers tried to create packs of tiles.
* Developers created unique looking textures on their models by cherry-picking details from several different maps.
* Thou shall not create textures that (look like they) repeat.
* Developers tried to avoid too much high-frequency noise. Due to the softer nature of textures in game, noise tended to look soft and mottled, and also look messy rather than deliberate.
* Multiple UV sets and effects that rely on them could not be used.

## Normals, Effects and Alpha

Normal and bump mapping was not supported for environments due to a lack of budget for them (it was supported for characters, however).

Wherever possible, incandescence maps were baked into the color map and used the vertex colors used to brighten that area. Wasting texture space with incandescence textures that were mainly black, as was common on the other platforms, was avoided. Instead, additive decals were used to pick out just the areas that a developer wanted to highlight. Bloom was not supported, which means the developers could not rely on this effect when creating incandescence layers.

Specular maps could be used – it was recommended use extremes of tone. Due to the way the Wii rendered specularity, there was a need to enhance the brightness of the specular map on metals, shiny surfaces and glass – then test on a Wii Art Machine.

Using textures with alpha channels was avoided where possible, as it doubled the size of the texture. Vertex alphas were used where possible.

## Vertex Lighting on the Wii

Lightmaps were not used on the Wii as it was way too expensive, leading to the requirement of an alternative, with the best one being vertex lighting. A Maya plugin was used to procedurally generate a directional light baked into a scene and then tweak shadows, color and other lighting by hand.

## Lighting up your Scene

*This section acts as a tutorial.*

Here's an example of a wall that has been stripped down as per the instructions previously. To achieve detailed lighting, we will have to cut in some extra polys.

This is how our polygon looks like (2 triangles).This is how the vertex colour looks like (2 triangles).
We now need to cut in extra polys to create highlights. As we can see, there are some lights embedded on the texture so we're gonna make them glow!

Additional polys cut in (30 triangles).Vertex Colour (30 triangles).
We spent 28 triangles creating a small light effect, so we will need to spend even more triangles to create more complicated and detailed effects. This is why it is very important to have a super low-poly base to start with. (Yes, yes, we *could* have optimized this mesh much more, but this is a tutorial, after all…)

We will basically use three tools to do our vertex lighting:

* Edit polygons>Colours>Apply colour
* Edit polygons>Colours>Paint vertex colour tool
* FRD Tools>Vertex lighting tools

### **Apply Colour Tool**

With this tool you can select as many vertices as you want and apply them any colour. It has a very convenient colour-picking tool. The button that says “selected vertex color” is very useful as well – it will pick the colour from any vertex you may have selected. You can open the colour palette to create your colour, and, after that, you can make it darker or brighter if you move the slider situated next to the colour sample.
It is possible to apply an alpha value – just move the slider situated next to the alpha colour sample. This is very useful if you want to make a decal shadow look more or less transparent, amongst other things.

### **Paint Vertex Colour Tool**

With this tool you can apply colours to vertices, painting directly on them. The radius can be set up using the sliders. You can apply more or less colour, depending on the opacity value you are working with. You'll usually use the replace mode, but from time to time you can use the smooth option, specially when there are visible hard edges (due to a big colour difference between vertices). This is what smooth does:Non-smoothed.Smoothed.
### **FRD Vertex Lighting Tools**

You can bake light information into vertices using this tool. The light types that can be used are: point lights, directional lights and spot lights. You can use ray trace shadows and decays.

Important! You MUST apply a vertex colour to your mesh before you start baking your lights. If your mesh doesn't have a colour to start with this tool won't work. Just select your mesh and apply a random colour to it using the “apply colour” tool. The colour you apply doesn't matter, you'll replace them later anyway!
Set up your lights. Now, select the lights and the meshes you want to use and click on “Replace Vertex Colours” button. It is very important that the first time you replace the colours so that you have a clean base. Later on, you can keep on adding lights and add their light information to the mesh using the button “Add to vertex colours” or “multiply Vertex colours”. If you feel your light wasn't strong enough, you don't have to change all lights values, just click on “Add to Vertex Colours” as many times as you need. Example (Point light. / Intensity: 0.150 / Decay: Quadratic / Shadows: Off):

1 single pass (replace mode)2 passes (add to vertex colour mode)5 passes (add to vertex colour mode)
## Vertex Light Preview

Developers could see how their vertex colours look like in Maya via shaded mode (pressing 5) or textured mode (pressing 6). The problem was that Maya had a dynamic light developers had to turn off to appreciate the real result. If a developer was to do this, they would go the “lighting” menu in their viewport, and choose “no lights”. Developers would change from textured to shaded very often, so they needed to create a button with a little script so that they go directly to shaded mode no lights or textured mode no lights.

## Converter - gets your whites Super White!

When a Wii level was lit – developers had to take into account that when their level was converted to run in-game – the strength of information applied to a vertex was doubled. Without this, the brightest highlight that would be achieveable would be the original colour of their texture. Developers used the SD colour vertex plugin to adjust once they have tested their map in a Wii Art Machine.

As explained before, the converter would double in strength the vertex colours. Developers had to keep this in mind when doing very bright (or even white) textures, such as ice or snow. The best solution to gain greater control over the final result was to decrease the brightness of their texture, rather than the brightness of their vertices. See the example below.

Darker, less contrasted textures gave more consistent results, avoiding burnt or black areas. Adjusting low lights where possible with vertex colours was key for best results.
## Making a Difference!

If developers had many similar instances, they tried to use vertex colours to vary their appearance. They were generally using less geometry and therefore less unique props and textures. Adding tonal difference made the player feel as if they were looking at unique objects rather than running through an episode of 'Road Runner' (cactus, rock, mountain, cactus, rock, mountain… ad infinitum)!

## Getting Things in Contrast

A quick tip for making sure contrast was even between low and high LOD lighting was to set a hard/soft edges pass. After several experiments, it was found that, if a developer set their hard/soft tool in Maya to 50(deg) and ran it both on their high and low LODs, it created clean lines and good contrast in models when lit.

## Incandescence

Developers could use incandescence. White lit the poly up no more than the brightness of the original texture meaning they needed to paint their lights into the color channel where possible.

## Decals

Developers could use decal layers to create shadows that were too complicated to cut on a mesh. Decals were expensive, though, where alpha was used, so they were kept cheap and used only when needed to. Developers had to weigh the advantage of using a decal instead an incandescent light for example, against cutting additional polygons into a mesh.

## Animated UVs

These were treated like the other textures meant for the Wii (shrink where possible). The Wii conversion did not affect the animation.

## Wii and the Terrain Editor

When the task of stripping down the models was completed, there was need to light these as a single group in Maya. Afterwards, the developers exported a single XML to add to the game.

The pipeline was as follows:
* In Maya, using the plugin Wii importer, developers used the 'world.xml' to import the entire scene, with instances, scale and positioning data into one large Maya file. It was vitally important that developers stuck to the naming convention of 'wii\_' for each of the prepared buildings, as the importer would look specifically for them.
* Developers added a directional light to the scene and checked that their lights were set from 'volume' to 'point'. Then, they selected the whole scene and used the bake plugin to bake their lights into the scene. They checked the results and adjusted things accordingly.
* Developers used the 'PolyColorPerVertex' plugin (Similar to Photoshop 'variations') to select groups of vertices and modify their values where applicable.
* Developers looked at the screenshots of the original level and lightmaps. Emulating the original level as closely as possible was a must. Developers cut in additional polys to create sharper-edged shadows and add decal shadows where shapes were too complicated to cut in.
* When ready, developers exported the scene to test.
* Developers tested on an Art Machine with a designer where possible for poly and texture limits.

## It's full of stars...

Unless the level was to be set permanently at night, these steps had to be followed:

* Developers grabbed the ground polar map for their level (they would also see the sky HDR maps but those were not needed). They were in landscape format and were found in YOURLEVEL/skydome/YOURLEVEL\_ground\_sky\_ibl.tga. The TGA format map was needed.
* Developers opened this file in Photoshop and removed the sun(s) if present. These would be added later in code as a decal.
* The image was resized to 2730x1365 and saved as a targa.
* The image was saved as wii\_YOURLEVEL\_ground\_sky\_ibl.tga and uploaded it to the root of the developer's level in Perforce.

## Vertex Baking in Turtle - for the Wii

Vertex-baked lighting was much quicker and more effective using Turtle.

Developers worked on a per-room basis, lighting one room at a time and using the original lights that were normally put though Bacon, but modifying their intensity and falloff to get the required results.

Turtle's vertex baking had the same limitations of Maya's tools - if you had large polygons, you may have needed to divide them up to get better interpolation over large areas. Enabling shadows generally did not work very well due to the reduced vertex count and normally resulted in large black streaks.

First, developers made sure they had Turtle installed and loaded in Maya, switched to Turtle inside of the render settings, then selected the render tab. From there, they switched over from plugin render to vertex bake.

**Vertex Bake Tab**

Bake Options -
    Turning off Bake Shadows ignored all shadows you might have set up on lights.
Bake alpha allowed Turtle to take into account alpha maps, but with Back Shadows off there was no benefit to having this on.

Output -
Developers switched from Full Shading to just Illumination as this would only take into account their lights and not the texture applied to the model. It was also possible to enable final gather to get some colour bleed from their textures but this would increase your render times.

Colour Balance -
In here was where developers could specify whether they wanted to overwrite the existing vertex data or add, subtract or multiply etc. Setting Alpha Blending to None left any existing vertex Alpha information intact.

Filter -
Filtering was quite important as it gave much smoother results. The default settings worked well.

**Turtle Bake Layer Editor**

The Turtle Bake Layer Editor could be found under Window>Rendering Editors>TURTLE>Turtle Bake Layer Editor.

This was where the developers added the geometry they would like to be baked to (if needed; certain) objects. They also needed to be visible – any lights that were visible in the scene would cast light into the scene. It was very handy to create a new layer for every room and name it with the same room name (ex, RO\_warehouse would be named warehouse on the layer editor). This way, developers only had to select the room they wanted to bake from the layer editor – easy!

It was recommended only lighting one room at a time due the the fact that, without shadows enabled, you would get light going from one room to the other through walls. There were experiments with duplicating the lights from adjacent rooms to the one someone was working on to fake the lights spilling though doorways, which worked rather well.

Now, a developer should be ready to bake; if all is set up correctly, the developer could just hit render. The render window would pop open, but nothing would display on it, considering it is effectively rendering to the model.

With this process, lighting should be baked into the verts. Now, instead of editing the data on the verts, it is way quicker to just tweak the light's settings and re-bake the lighting. To assist with this task, a MEL script was written.

## Tricks!

***Lights.*** The light types that could be used for vertex baking were: point, area, directional, spot and ambient. Unfortunately, volumes were not supported. Point lights with linear decay were recommended for interiors. Quadratic decay on point lights were used to create local tiny light effects.

***Colour Balance*** (vertex bake tab). Developers could easily increase or decrease the amount of light they applied to their vertices by changing the RGB value. 1 was the default value, so if 0.5 was typed, there would have a darker effect, and if 2 was typed, they would be a brighter effect. This was very handy when combined with the quick lights adjuster (read below).

***Ambient occlusion***. Applying ambient occlusion to the whole room after the final lighting had been done, increased the shadowing effect, and it made any room look more contrasted. Once finished with lighting, developers could go to render settings-vertex bake-outputs and untick all outputs, tick custom and click the arrow to link a new material (the “create render node” window would emerge), then select llr Occ Sampler from the list. Now, developers could the ambient occlusion shader to their needs. Afterwards, they went to render settings-vertex bake-color balance and changed the RGB blending to multiply. They clicked render - now an ambient occlusion over their original lighting. Awesome! [Developer Tip: Do not set minimum colour to black on the ambient occlusion shader. Set a dark grey instead (this will prevent you having pure black areas on your scene).]

## Quick Light Adjuster MEL Script

When the script was launched, you will see the window below. The first slider allowed you to input a light intensity to all of your selected lights. This only changed after clicking apply. The quick intensity controls were a quick way to Divide or Multiply the lights' intensity by 2 or 1.5. This worked on a per-light basis, so if a developer had two lights and selected a light with an intensity of 2, and another with an intensity 4, multiplication by 2 would result in the lights having the values of 4 and 8.

The Colour slider allowed developers to input a colour for all the selected lights. The Quick buttons effected the saturation of the light colour. There was also a set of quick controls to allow for changing any lights' decay type at the click of a button.
## Let there be...*something to bump into!*

To improve frame rate and free up vital memory, a low poly collision mesh was used. See the guide below on how adding these to a scene was done. It had to be perfect, meaning frequent testing was done, and if something was wrong – the process was restarted.

## Particles, Detail Geometry and Foliage

All the detail geometry and foliage was lifted directly from the world XML. It was altered in code and appeared on a dithered basis per meter.

Particles worked in the same way. When the other SKU particles had been edited in the Terrain Editor, the section of code that was created in the world.xml was extracted. This could then be copied into the same location in the developer's own world.xml that was being used for the Wii. If the world XML was shared with the other SKUs (as in most cases), the particles would come through as soon as the engine-side code had been created.

## Finally

A clean mesh and methodical working helped break down this task and made sure developers ended up with a viable working model.

## BF3 Object Artist Budgets (December 06)

### Characters

In-game characters: 3000-3500 polygons. Around 20-25 bones / Cut-scene characters: 4000-5000 polygons. Around 80 bones

2048x2048 (diff, norm, spec) for body / 1024x1024 (diff, norm, spec) shared between face and arms

### Weapons

Weapon models must be orientated along the Z axis.

1st person: 3000-4000 polys / 3rd person: 500 polys (1000 for large guns)

Both versions share 4096x4096 (diff, norm, spec)

.mb and .xmls should have \_firstperson or \_thirdperson at end of filename to clarify which version

eg.        rep\_fusioncutter\_firstperson.xml / rep\_fusioncutter\_thirdperson.xml

* The origin of firstperson weapons will be at the wrist position, with a DOF\_CENTRE to show the centrepos.
* The origin of thirdperson weapons is at the centre, with a DOF\_WRIST to show the wrist position (ie the other way around – unfortunately this is necessary).

Also, a DOF\_SHOOTPOS should also be placed in the center of the end of the barrel.

### Vehicles

Exteriors:  4000-5000 polys (including 3rd person cockpit) / 4096x4096 (diff, norm, spec)

Cockpit:  up to 4000 polys (including any exterior) / 2048x2048 (diff, norm, spec)

These are separate models but can share textures. The cockpit model’s position should be similar to the cockpit in the exterior version.

Cockpit should have \_cockpit at end of filename. A DOF\_CAMERA can be placed for the camera position.

Visibility is VERY important in cockpit mode. The cockpit shouldn’t obscure the centre of the screen and should take up no more than 25% of the screen, even if realism suffers. Character arms will not be drawn.

Shoot positions should be labelled with a DOF

Eg. For primary weapons: DOF\_SHOOTPOS\_PRIMARY1, DOF\_SHOOTPOS\_PRIMARY2, etc

For secondary weapons (eg rockets): DOF\_SHOOTPOS\_SECONDARY1, etc.

The centre of vehicles should be at the origin.

### Capital Ships

The budget for capital ship exteriors is 10,000 polygons. An additional 15,000 can be added and flagged as detail, which will only be turned on when close to the ship.

3 sets of 4096x4096 maps can be used for the exterior. The center of capital ship exteriors should be the origin.

Around 6 texture sets should be used for the interiors of capital ships.

### Art Naming Conventions

AIM: Keep names consistent between setup and artists

* Keep directory name same as filename
* Keep .mb filename same as .xml filename
* Use abbreviations cis, rep, imp, reb
	+ eg, for droid command ship interior (bf / capital\_ships / cis\_commandship\_interior / cis\_commandship\_interior.mb)
* Level names are abbreviated to 3 letters (eg bes, tat).

ALL art modeled 1:100 in Maya (because Maya handles large values badly) apart from characters. The export scale should be set to 100.0.

Setup should try to use these same names in the build resfiles and templates.

Scene objects / props should be put in the props directory on perforce. Any props specific to a level (ie can't be reused on a different level) should be in a sub-directory with the levels name.

### Background File Structure

All backgrounds must sit under bf\backgrounds\. Each level has an abbreviated folder name like this: bf\backgrounds\**tat**

Within this folder there should be the following folders:

* **Buildings** - The buildings folder contains all background structures both in xml and maya format.
* **Foliage** - The foliage folder houses rocks and foliage files that are placed using the terrain editor.
* **Props** – This folder contains all dynamic props such as destructable items and physics objects.
* **Skydome**  - This folder contains the levels main lighting xml and its textures. It also houses the levels skydome cubemaps that are created using HDRshop.
* **world** – The world folder should have two other folders within it; export and textures. The terrain folder itself contains the save data from the frd world editor. The export folder contains the ingame terrain files that are exproted from the world editor.
* **Textures** – All textures for the level buildings and props should reside in this folder.

### Perforce

Do not upload maya swatches. This happens when you submit a textures folder rather than selecting the files within the folder. If you happen to upload swatches please come and see me and I'll delete them.

Do not upload “test” stuff unless it has been requested by a lead or coder. Where possible, all test items should sit within bf\backgrounds\test\_levels\<name\_of\_test>

Do not upload workspace.mel – again like the swatches this can be accidentally uploaded by submitting the folder rather than the files.

Do not create manual revisions – there is no need to submit increments like “my\_file\_01.xml” “my\_file\_02.xml” “my\_file\_03.xml” and so on. Perforce handles version control, thats what we use it for. Your files should be saved my\_file.xml.

Do not submit textures along with maya and xml files – Please stick to the file structure as described earlier in this document.
ALWAYS make sure what ever you submit to perforce will build. Double check that you textures are pathed correctly, ensure you have and export scale and you have grouped everything under a BTOP or RO.

If the asset aleady exists in a build file ie. A designer has placed your file into a level, you should always use the G6 asset remake web interface to make sure it will build without errors, before asking the setup person to remake the asset.
## References

* BF3\_ART\_DEVELOPMENT.sxw (31/03/2008)
* an artist guide to wii conversion.odt (14/05/2008)
* artist object budgets.doc (06/09/2006)