Wii testpage

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 is 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 is 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 modeled 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 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 is.
 * 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. 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.
 * 2048x2048
 * 2048x1024 (Landscape letterbox was acceptable, portrait was not.)
 * 512x512
 * 512x256 (Landscape letterbox was acceptable, portrait was not.)

Creating Textures

 * Developers created their textures by making tiles from the original scene textures.
 * Developers rendered sections of models where the artist has 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 Bumpmapping was not supported for environments due to a lack of budgets 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. Waste texture space with incandescence textures that were mainly black as in common the other platforms was avoided. Additive decals were used instead to pick out just the areas that a developer wanted to highlight. Bloom was not supported meaning 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 - 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.

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 vertexes as you want and apply them any color. It has a very convenient color picking tool. The button that says “selected vertex color” is very useful as well, it will pick the color from any vertex you may have selected. You can open the color palette to create your color, and after that you can make it darker or brighter if you move the slider situated next to the color sample. You will use “replace” almost at all times.

It is possible to apply an alpha value, just move the slider situated next to the alpha color 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 colors to vertexes painting directly on them. The radius can be set up using the sliders. You can apply more or less color 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 color difference between vertexes). This is what smooth does:

FRD Vertex Lighting Tools
You can bake light information into vertexes using this tool. The light types than 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 color to your mesh before you start baking your lights. If your mesh doesn't have a color to start with this tool won't work. Just select your mesh, and apply a random color to it using the “apply color” tool. The color 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 Colors” button. It is very important that the first time you replace the colors 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 colors” or “multiply Vertex colors”. If you feel your light wasn't strong enough you don't have to change all lights values, just click on “Add to Vertex Colors” as many times as you need. Example (Point light. / Intensity: 0.150 / Decay: Quadratic  / Shadows: Off):

Vertex Light Preview
Developers could see how their vertex colors 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 color 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 colors. 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 vertexes. See the example below.

Darker, less contrasted textures gave more consistent results, avoiding burnt or black areas. Adjusting low lights where possible with vertex colors was key for best results.

Making a Difference!
If developers had many similar instances, they tried to use vertex colors 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 are looking at unique objects rather than running through an episode of 'Roadrunner'! (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 is 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 other textures meant for 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, 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 results and adjusted.
 * Developers used the 'PolyColorPerVertex' plugin (Similar to Photoshop 'variations') to select groups of vertices and modify their values where applicable.
 * Developers looked at 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 permanently 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 unneeded). 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 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 fall off 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 didn't 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 color bleed from their textures but this would increase your render times.

Color 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 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 getting from 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 will display on it as 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 its 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.

Color Balance (vertex bake tab). Developers could easily increase or decrease the amount of light they applied to their vertexes 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 was 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 color 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 Color 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.