Introduction

Welcome to the artist training tutorials for BigWorld technology.

The following lessons are designed to be progressive, meaning that you should follow them from start to finish in order to learn the complete production workflow.

Although 3ds Max is used in many of the examples in this manual, the same themes and concepts apply for Maya users. Hence, it is inadvisable to skip tutorials.

Content Tools Reference Guide–Further information about the tools can be found the Content Tools Reference Guide.

* 3ds Max example files are also provided to assist in learning the processes.
Example files can be found in bigworld/doc/tools_tutorial_examples/. This tutorial folder contains the following:

* A Folder bigworld/doc/tools_tutorial_examples/working_files, under which you will find 3ds Max files relating to the tutorials found in this guide, and their associated maps, laid out in a folder structure similar to the one recommended in the lesson Manage Resources.

* An empty file structure which you may chose to use to start your project. If you copy this into your mf/your_game folder, then you will be able to use the empty /res folder as a place to put your art assets if you wish.

* A BigWorld Material library, for 3dsMax which contains all the BigWorld shaders.

The following tools are used throughout the tutorials:

* ModelEditor - To view or modify your exported objects.

* WorldEditor - To build the game world.

* ParticleEditor - To create and modify particle systems.

* 3ds Max - To create 3D content, including the proprietary BigWorld exporters.

* Maya - To create 3D content, including the proprietary BigWorld exporters.

* Exporters - To export objects and animations from your chosen 3D application. Instructions on how to install the BigWorld exporters are found in the Content Tools Reference Guide.

* Photoshop - To create texture maps.

* SpeedTree - To create dynamic trees.

Copyright 1999-2011 BigWorld Pty. Ltd. All rights reserved. Proprietary commercial in confidence.


Setup a New Project

  • Resource paths
  • Creating a new space
    • Terrain Creation Settings
    • Terrain Types
  • Changing Space
  • Terrain LOD Settings
    • Geomorphing
    • Geomipmapping
    • Space.settings file

Resource paths

As of BigWorld Technology 1.8, the use of BW_RES_PATH environment variable to specify the resources path is deprecated.

Instead, the use of command-line arguments and/or paths.xml configuration files local to each tool is recommended. For details, see the document Content Tools Reference Guide, chapter Starting the Tools.

Creating a new space

A new space can be created as described below:

1 Open WorldEditor.

The executable worldeditor.exe is located in folder bigworld/tools/worldeditor.

2 Select the File → New Space menu item.

WorldEditor's File menu

3 The New Space dialog box will be displayed.

WorldEditor's New Space dialog box

4 To create a new space:,

• Specify a new space in a spaces folder.

• Specify the width and height in chunks of your new space (a typical chunk is 100 metres by 100 metres).

• Choose the appropriate Terrain Creation Settings for your space (see below for a description of each field)

• Click the Create button.

Clicking on use simple terrain determines whether or not to use terrain advanced features in the creation of the new space.

5 WorldEditor will automatically open with the new space.

Terrain Creation Settings

Height map res
Defines the number of height pols on one axis of a chunk. So a setting of 256 will result in the chunk having at least 65536 verts. That's allot of verts.
I would recommend using 128 or less for spaces over a few kilometers. Using 256 with large spaces will reduce performance.

Normal Map res
This is the resolution of the normal map used to disguise the lower resolution mesh used by the terrain in the distance.
In order to retain the more visually complex information held in the higher resolution chunks we apply a normal map of this information to the lower resolution chunks in the distance.
A setting of 128 adequately hides the lower resolution mesh for most spaces.

Hole map Res
This is the resolution of the Cut Terrain tool (scissors). If set to a low setting you will only be able to cut large holes in the terrain, set it to a high setting and you will be able to cut smaller holes in the terrain. If your not going to cut the terrain very often then I would suggest setting this to a low setting.

Shadow Map Res
Defines the resolution of the terrain shadow map. If you have a large space (anything over a kilometer) I would recommend using 64. Using 128 or 256 with large spaces will reduce performance.

Texture blend map res
This is the resolution of the map that blends between two different terrain textures. Put simply if you paint texture A and texture B beside each other, the texture blend map resolution determines the distance it takes for texture A to blend into texture B.

The best thing you can do is create several quick prototype spaces of the same proportions as your intended space and play with various settings. The lower you can get the settings without causing serious visual degradation the better your performance will be.

These are the settings for highlands which is a demo space built to run on high end machines. Highlands is a 10km x 10km (100x100 chunks) space.
<heightMapSize> 128 </heightMapSize>
<normalMapSize> 128 </normalMapSize>
<holeMapSize> 64 </holeMapSize>
<shadowMapSize> 64 </shadowMapSize>
<blendMapSize> 256 </blendMapSize>

Terrain Types

There are two terrain types available in BigWorld, Simple and Advanced terrain.

Property | Description
Simple terrain | Requires fixed function cards or higher Height poles fixed at every 4 meters Limit of 4 textures per chunk (100m) Texture blend resolution fixed at 4 meters Can be converted into Advanced terrain Only receives lighting from a single directional light (sun)
Advanced terrain | Requires minimum shader model 2.0 cards Configurable height pol resolution Unlimited texture layers per chunk Configurable texture blend map resolution Configurable shadow map resolution Each texture layer has independent UV projection Receives lighting from multiple lights sources Geomorphing Geomipmapping Can NOT be converted to simple terrain

World editor can convert simple to advanced terrain from the File → Convert To Advanced Terrain menu. Just remember to back up your simple terrain first as advanced terrain cannot be converted back into simple terrain.

Changing Space

To change from one space to another:

1 Open WorldEditor.

2 Select the File→Open Space menu item.

WorldEditor's File menu

3 The Browse For Folder dialog box will be displayed.

WorldEditor's Browse For Folder dialog box

4 Select the folder space that you wish to change to.

5 Click the Open Space button.

Terrain LOD settings

There are two terrain types available in BigWorld. Simple and Advanced terrain. This section explains how the complex terrain LODs and how those LOD settings can be adjusted to optimise performance.

Geomorphing

As you move away from the player, chunks of higher resolution terrain mesh are replaced by lower mesh resolution chunks. This reduces the number of polygons that need to be drawn by the game engine. To avoid a visual pop between chunks we first swap to a higher resolution chunk that mimics the shape of the lower resolution chunk, then slowly morph in the higher resolution details.

In order to retain the more visually complex information held in the higher resolution chunks we apply a normal map of this information to the lower resolution chunks in the distance.

At the bottom of this image you can see that the chunks closest to the player camera are high resolution (high poly count). As you move away to the top of the image, these higher resolution chunks have been swapped for increasingly lower resolution chunks.

Geomipmapping

Directly underneath the player the Adanced terrain allows an "unlimited" number of texture blends per chunk. There are of course performance implications. As you move away from the player these blends are slowly replaced by a simpler overhead projection photograph of the blends. During this transition both the terrain blends and terrain photographs are drawn.

Space.settings file

The LOD settings for each space's terrain are described in the space.settings file located in the relevant space folder

<space.settings>
    <timeOfDay>	system/data/sky.xml	</timeOfDay>
    <skyGradientDome>	system/data/sky.xml	</skyGradientDome>
    <bounds>
        <minX>	-48	</minX>
        <maxX>	47	</maxX>
        <minY>	-48	</minY>
        <maxY>	47	</maxY>
    </bounds>
    <terrain>
        <version>	200	</version>
        <heightMapSize>	128	</heightMapSize>
        <normalMapSize>	128	</normalMapSize>
        <holeMapSize>	64	</holeMapSize>
        <shadowMapSize>	64	</shadowMapSize>
        <blendMapSize>	256	</blendMapSize>
        <lodInfo>
            <startBias>	0.800000	</startBias>
            <endBias>	0.990000	</endBias>
            <lodTextureStart>	150.000000	</lodTextureStart>
            <lodTextureDistance>	80.000000	</lodTextureDistance>
            <blendPreloadDistance>	100.000000	</blendPreloadDistance>
            <lodNormalStart>	300.000000	</lodNormalStart>
            <lodNormalDistance>	100.000000	</lodNormalDistance>
            <normalPreloadDistance>	100.000000	</normalPreloadDistance>
            <defaultHeightMapLod>	2	</defaultHeightMapLod>
            <detailHeightMapDistance>	500.000000	</detailHeightMapDistance>
            <lodDistances>
                <distance0>	25.000000	</distance0>
                <distance1>	120.000000	</distance1>
                <distance2>	250.000000	</distance2>
                <distance3>	700.000000	</distance3>
                <distance4>	1100.000000	</distance4>
                <distance5>	1700.000000	</distance5>
            </lodDistances>
            <server>
                <heightMapLod>	2	</heightMapLod>
            </server>
        </lodInfo>
    </terrain>
    <farPlane>	1500.000000	</farPlane>
    <startPosition>	607.810730 211.184265 -206.891937	</startPosition>
    <startDirection>	0.000000 0.010000 0.009964	</startDirection>
    <oldClouds>	false	</oldClouds>
    <minimap>
        <mapName>	spaces/highlands/space.outdoors.dds	</mapName>
        <worldMapWidth>	3200.0	</worldMapWidth>
        <worldMapHeight>	-3200.0	</worldMapHeight>
        <worldMapAnchor>	00.0 00.0	</worldMapAnchor>
    </minimap>
    <skyDome>	system/models/clear_overhead.visual	</skyDome>
    <skyDome>	system/models/horizon_ring_cloud.visual	</skyDome>
</space.settings>

The green section of the space.settings file deals primarily with GeoMipMapping. This particular space.settings file defines that 100% blends should be drawn up to a distance of 150 Meters. The blends then fade out over a distance of 100M whilst the terrain photograph is blended in. After 250M ( <lodTextureStart> + <blendPreloadDistance> = 250) only the terrain photograph is drawn.

These Terrain Texture LOD Distances can be modified from within World Editors Environment Tab

The key thing to note here is that the blends are drawn up to 250M away from the player. Because blends require more resources to draw its a good idea to try to limit the distance that blends are drawn whilst maintaining visual appeal.

The blue section section of the space.settings file describes GeoMorphing. There are four distinct LOD distances, each distance defines when a higher/lower resolution chunk should be used.


Manage Resources

  • Letter Case
  • Reusing BigWorld art assets
  • Organising art resources
    • Sets
    • Characters - Avatars and NPC's
    • Non specific reources
    • Terrain Maps
    • Particles
  • Working with source creation files
  • Working with the Asset Browser
  • Customising the Asset Browser

When creating content for a game using BigWorld, you need to establish an efficient and safe way to handle potentially large amounts of generated data.

Optimising the resources folder structure, combined with effective version control software, should help any artist feel comfortable in negotiating the content creation process.

Letter Case

It is extremely important to maintain a consistent letter case (upper/lower) throughout development.

Although the BigWorld tools and Windows are case insensitive, the BigWorld server and its scripts run on Linux which is case sensitive. Problems may arise if there is a reference to an art asset within the servers scripts that has inconsistent case.

For this reason we recommend that lower case be used for the file names of all art assets.

In order to prevent case problems occurring we recommend that the source control software you are using be set up to prevent upper case files from being committed.

Reusing BigWorld art assets

For information regarding the reuse of BigWorld art assets please refer to licensing_information.html

Organising art resources

Sets

We have attempted to optimise the resource paths so that world building is simpler, requiring less navigation and allowing more time to be spent on enriching the game environment. The following describes the ways we have tried to organise common resources in a way more friendly to world builders. An empty file structure resembling the setup below can be found within the \bigworld\doc\tools_tutorial_examples folder under. It may be useful to copy this folder structure to your res folder.

Although the location of art resources is flexible (providing they lie within the res path), we have found the following structure to be useful:

Artist assets have been organised in folders representing similar environments called sets. In the example below the folder res/sets/temperate pertains to a warm outdoor scene.

Resource folder structure

Within each sets folder, the following sub-folders are found:

* flora - Contains the visual, model, primitive, and texture files of flora objects specific to the set.

* materials - Contains material *.mfm files used within the set.

* props - Contains the visual, model, primitive, and texture files of props that are specific to the set.

* shells - Contains the shell visual files, as well as the model, primitive, and texture files of shells specific to the set. (Shells will only be recognised by the engine if they are located in a folder named shells).

If the game world has a good deal of variety, then the props folder can become cluttered.
It is up to the user to determine the volume of objects that will eventually populate a particular set, and to devise a sub-folder structure to adequately categorise similar objects.
We recommend limiting the sub-folder categorization, in order to reduce the amount of time world builders spend navigating resource trees.

Below is an example of such a folder structure:

Example folder structure

Because animations and level of detail (LOD) models are not used by the world builders when placing objects, they can be organised within their own sub-folders animations and lods respectively.

Characters - Avatars and NPC's

Avatars (player-controlled characters) and NPC's (Non-Player Characters) are not specific to a set, and therefore are more complex than most BigWorld objects.
For this reason they are given their own folder structure.

Character folder structure

In this structure, the following sub-folders are found:

* res/characters - Common folder for character files.

* avatars - Contains one sub-folders for each avatar type. The folder knight in the example above contains the model, visual, primitives, LOD, and texture files for the knight avatar.

* animations - Contains animation files shared between characters.

* npc - Contains one sub-folder for each NPC type. The folder crow in the example above contains the model, visual, primitives, LOD, and texture files for the crow creature.

Non-specific resources

Assets not specific to a particular set are stored within sub-folders under res.

Non-specific resources folder structure

Examples include:

* res/flora - Contains the visual, model, primitive, and texture files of flora objects that are not specific to a particular set.

* res/maps - Contains texture files that are not specific to a particular set, or that are used within multiple sets. For example, a special alpha map used in both a particle system, and a special effect shimmer object, would be stored in this folder.

* res/maps/fx - Contains the visual, model, and primitive files related to special effects such as explosion debris that are not specific to a particular set.

* res/maps/particles - Contains maps used specifically within the particle system.

Terrain Maps

Terrain maps are placed in their own directory (res/maps/terrain) in order to avoid confusion with other texture maps, and to aid in world building. The World Editor will only display bitmaps that are placed in this directory. If you need to store your terrain maps in a different directory structure you will need to edit the Asset Browser.

Terrain maps folder structure

Particles

Particle system XML files are stored under the folder res/particles. No other files should be stored here.

ParticleEditor saves particle systems to this folder. Texture files used within particle systems can be stored under res/maps/particles.

Particle system folder structure

Working with source creation files

Source (or working) files are the actual content created using either a 3D package such as 3ds Max / Maya, or a 2D image program like Photoshop.

We suggest you follow these protocols when working with original source material:

* The source files are created locally, then copied to a network or committed to source control to be shared by other artists. Any modifications made locally first should always be updated on the network.

* Consider using a version control program, such as SVN, Perforce or CVS, to update the network content with the final working files for each asset. This is very helpful in tracking changes and retrieving past versions of the resources.

Working with the Asset Browser

The Asset Browser is a resource browsing facility built into all the BigWorld content creation tools (WorldEditor, ModelEditor and ParticleEditor). It can be accessed from the Assets tab in any of the content creation tools.

When using the Asset Browser it can be useful to move it to a second monitor or dock it on the other side of the screen. To move the Asset Browser simply select and drag the Assets tab to the new location.

Asset Browser panel's virtual folders

The Asset Browser's parent folders are filters, not directory structures. If you select the Models virtual folder, then the Asset browser will only show models located in those folders outlined in the tools ual_config.xml within your resource paths.

Likewise if you select Textures then the Asset browser will show all the textures located in those folders outlined in the tools ual_config.xml within your resource paths.

Asset Browser panel – Using the search field

The dynamic search field will further limit the displayed resources to those resources containing the text typed in the search field. In the example above the Asset browser is displaying all models (because the Models virtual folder is selected) with the text "ranger" in their model name.

If you want to browse a folder structure directly, then you can expand any of the virtual folders to display the directory structure inside your resource paths.

Asset Browser panel – Using the virtual folder's tree structure

The favorites folder can be used to collect frequently used assets. To add an asset to Favorites simply drag the asset from the browser window over the favorites folder. All types of assets can be added to the Favorites folder.

There are three ways to open/add an asset from the Asset Browser.

* In WorldEditor, assets can be added to the world by selecting the asset and pressing enter in the viewport.

* In all the tools, assets can be dragged directly from the Asset Browser to the tool's viewport.

* In ModelEditor and ParticleEditor, double-clicking an asset opens it in the tool's viewport.

Customising the Asset Browser

Although most of the virtual folders will point directly to the paths outlined in your resource paths there are some exceptions.

The Particles virtual folder for example will only look inside the res/particles folder.

The Textures virtual folder within WorldEditor will only look in the res/maps/terrain folder.

This behaviour can be modified by editing the ual_config.xml found in mf/bigworld/tools/BigWorldTool/resources/ual/ual_config.xml. XML files can be edited with Notepad (Right click Open - With).

Within ual_config.xml you will find a <Files> "FolderName" tag that instructs the Asset Browser to look in specific places for assets. The example below shows the tag outlining where particles can be found.

<Files> Particles
   <path>           particles                                </path>
   <disableFilter>  Models;Shells;Prefabs;Trees;Entities;XML </disableFilter>
   <folderExclude>  *CVS;*/spaces;*/.bwthumbs                </folderExclude>
   <extension>      xml                                      </extension>
   <thumbnailSize>  1                                        </thumbnailSize>
   <showSubfolders> true                                     </showSubfolders>
   <showFiles>      true                                     </showFiles>
</Files>

As you can see above, the Particles virtual folder is looking in the res/particles folder.

<Files> Particles
   <path>           particles                                </path>
   <path>           temperate/particles                      </path>
   <disableFilter>  Models;Shells;Prefabs;Trees;Entities;XML </disableFilter>
   <folderExclude>  *CVS;*/spaces;*/.bwthumbs                </folderExclude>
   <extension>      xml                                      </extension>
   <thumbnailSize>  1                                        </thumbnailSize>
   <showSubfolders> true                                     </showSubfolders>
   <showFiles>      true                                     </showFiles>
</Files>

It has now been modified to search in both res/particles and res/temperate/particles.


Create and Export a Static Object in 3ds Max and Maya

  • 3ds Max and Maya export paths
  • 3ds Max Unit Setup
  • Maya Unit and World Coordinate Setup
  • Object size restrictions
  • Avoiding Z fighting
  • Avoiding sorting problems
  • Problems with Scaling objects
  • Object pivot points
  • Applying BigWorld shaders directly to 3ds Max models
    • Setting up 3ds Max to use DirectX
    • Assigning BigWorld Shaders directly to models in 3dsMax
    • Previewing BigWorld UV-scrolling shaders
  • Fast material assignment
    • Create a BigWorld 3ds Max material library
      • Using the BigWorld 3ds Max material library
  • Referencing the object texture maps
  • Texturing outside UV coordinates to avoid compression artifacts
  • Multiple material types
    • Multiple material types within 3ds Max
    • Multiple material types within Maya
    • High cost of multiple material types
  • Exporting multiple UV coordiantes
  • Exporting vertex colour
  • Using the Edit Normals Modifier
  • Exporting static objects from your 3D application
  • BigWorld and Collada
    • Using the BigWorld 3ds Max exporter to export static objects
    • Using the BigWorld Maya exporter to export static objects.

Although this section primarily deals with getting static (non animated) models from your 3d package into the BigWorld engine, much of the information also applies to creating animated non-static objects such as characters and NPC's. Specific information regarding non-static models can be found in the section Create Low-Polygon Characters.

3ds Max and Maya Export Paths

Taking the time to set up export paths for your 3d package will minimise unnecessary directory browsing every time you come to export a Model or Animation. You will almost exclusively be exporting Models and Animations to a subdirectory of your_game/res, so point your 3d package to this location.

In 3ds Max go to Customise&rarr Configure User Paths. Now set the Export Path to the /res directory of your game.

In Maya you can set up a BigWorld Project and point the exporter directly to the path you wish to export to.

File - Project - New

Set the Project name to BigWorld and the BigWorldAsset line to the /res path of your game.

Note: The exporters must be installed before either the above setups can be performed. Please see the Content Tools Reference guide for exporter installation.

3ds Max Unit Setup

The BigWorld 3ds Max exporter recognises settings defined within 3ds Max's System Unit Setup.

If you have used BigWorld exporters before and want to use the previous BigWorld standards of 10 Generic Units = 1 Metre, then simply set the System Unit Setup to 1 Unit = 10 centimeters.

The unit setup can be used to scale models that were created at the incorrect size.

3ds Max Customize menu

3ds Max Units Setup dialog box

For internal development we set 1 Unit = 10 Centimetres.

3ds Max System Unit Setup dialog box

Maya Unit and World Coordinate Setup

The BigWorld Maya exporter recognises the Working Units type set in the Preferences dialog (invoked by the Window→Settings/Preferences menu item).

A model 1m tall in Maya will be 1m tall in BigWorld.

Because Maya has no way of changing the size of its generic units there is no way of scaling (on export) models made within Maya. It is therefore extremely important when setting up models that are going to be rigged and animated that they are modelled to the correct size. Scaling a model after it has been rigged is usually problematic: correct setup is highly advised.

If you have used BigWorld exporters before and want to use the previous BigWorld standards of 10 Generic Units = 1 Metre, then simply set Ignore maya units: preference to true within the advanced preferences of the Maya exporter.

Maya Preferences dialog box

The BigWorld exporters use World Coordinate System Up axis Y. In Maya set to Y axis up, an object facing the front view port will also face the front view port in Model Editor.

We do not support Z axis Up. Models exported in this manner will be facing the wrong direction.

Object size restrictions

Objects cannot exceed (BigWorld Coordinates) X =100m, Y = 200m, Z = 100m (100m wide and 200m tall).

If an object exceeds this size it becomes difficult for the engine to correctly cull the object as it will inhabit many chunks at once. This can result in the object disappearing whilst it is still in view of the camera.

The exporter will prevent the exportation of objects that exceed this size.

Avoiding Z fighting

Z fighting occurs when two triangles (surfaces) lie within close proximity of each other. The result is that the two surfaces flicker back and forth especially as the camera position moves.

When modelling it is always best to leave a gap between surfaces to prevent this problem from occurring.

This problem typically appears on character models' hair and clothing.

Z fighting in Action.

Avoiding sorting problems

Objects using alpha blend can only sort reliably if they are part of the same material. Therefore if you are going to use alpha blend on multiple parts of an object, ensure that those parts share the same material name.

Alpha-blended polygons are sorted before being drawn each frame. If two transparent objects are entwined but do not share a material then they will not sort relative to each other.

Some handy tips to avoid sorting problems:

1. Avoid large alpha blended objects.

2. Try to minimise self-intersection of objects using alpha blend as this can lead to artifacts
in the polygon sorting.

3. Consolidate a single objects alpha blended sections into a single material.

4. Be aware that alpha blended skinned models will not take advantage of GPU skinning. All transformations will be performed by the CPU.

Problems with scaling objects

Before you begin creating objects for BigWorld you should be aware of the problems which scaling can cause.

Scaling an object usually results in the object's "node" retaining the scale information. Any mathematical operations performed on that object in the BigWorld engine will then inherit the scale information, resulting in unwanted visual artifacts.

For example, if an artist creates a hard point that has been scaled during its creation, any object linked to that hard point would inherit the scale information of that hard point. This could result in the character pulling out his sword, only to find that it has shrunk to half its size.

There are several things you can do to avoid such problems.

Limit Scale to sub components

In 3ds Max, scale the object whilst in sub object mode.

In Maya, choose one of the objects sub components and scale from there.

Although most scale problems can be fixed using the reset/freeze transform technique described next, it is good to get into the habit of scaling whilst in sub object mode.

Reset/Freeze the objects Xform/Transform

Once modelling is complete, and previous to rigging, you should always reset the object's transforms. This will remove any scale that has been placed on the object's node.

To reset an object's transforms in 3dsMax use the Reset Xform option.

To reset an object's transforms in Maya use the Freeze Transform operation.

Scaling a Rigged/Animated object

Do not scale a rigged/skinned model. This will undoubtedly result in problems further down the art pipeline. Animated characters that have been scaled within a 3d Application may look correct within their 3d App, but once brought into BigWorld problems can arise. For example, scale hidden within nodes can suddenly appear when a sword is attached to the player's hand. The sword inherits the node's scale resulting in a character wielding a disproportionately enormous sword.

If you must change the scale of an object imported into BigWorld do it by altering the Unit Setup within 3ds Max. Unfortunately Maya only offers quantised changes to its unit setup. Correct setup is strongly advisable. This will prevent problems where multiple interacting files have different unit sizes. It is always prudent to import the model into BigWorld before rigging just to check that the size is correct.

Object pivot point

The world origin coordinates (0,0,0) of your 3D application are used as an object's pivot point when exported to the BigWorld engine.

1 Objects should be positioned so that the pivot point will lie within the object's bounding box. Because the engine uses the pivot point of the object to identify its position, placing the pivot point a sizable distance away may cause problems with chunk lending (the process of sharing objects between two chunks) or culling.

2 BigWorld World Editor uses the pivot point of objects to place them via snap-to-terrain and snap-to-object modes. It is therefore important to consider the origin position when exporting an object.

This consideration can make the work of world builders much easier. For example, in the tree below, the bottom row of vertices at its base is lower than the world origin (0,0,0). This will ensure that the base of the tree is below the terrain when the tree is placed using WorldEditor's terrain snap feature.

World origin is used as object pivot point

Applying BigWorld shaders directly to 3ds Max models

In 3ds Max you can apply BigWorld shaders directly to your model. This allows you to bypass the creation of materials within Model Editor (a process to be covered in later chapters), and gives you from within the 3ds Max viewport an accurate representation of what the model will look like in-game.

* DirectX 9 materials are only supported in 3ds Max 7.0 and above. If DirectX 9.0 viewport support is required, then we recommend using 3ds Max 7.1 or above.

For optimal performance, we suggest using the latest DirectX end-user runtimes. They can be downloaded from Microsoft's web site.

Unfortunately, at the time of writing this guide there was no way to directly assign BigWorld DirectX 9 shaders to objects within Maya. It is therefore advised that you use the technique described in lesson Modify a model in Model Editor to assign BigWorld shaders to your model.

Setting up 3ds Max to use DirectX

Before you get started, you should ensure that 3ds Max is using DirectX. Please follow the steps below:

1 Open 3ds Max.

2 Select menu item Customise→Preferences.

The Preference Settings dialog box will be displayed.

3ds Max Preference Settings dialog box

In the Preference Settings dialog:

A Select the Viewports tab.

B Click the Choose Driver... button.

The Direct3D Driver Setup dialog will open.

Direct3D Driver Setup dialog

In the Direct3D Driver Setup dialog:

* In the Direct3D Version group box, select the DirectX 9.0 option button.

* Click the OK button.

* If your drivers are not set up to use DirectX, then the Material Editor will not display the material.

C Click the OK button.

Assigning BigWorld Shaders directly to models in 3ds Max

To assign BigWorld shaders directly to models within 3ds Max:

1 Select menu item Rendering→Material Editor.

The Material Editor dialog will open.

3ds Max Material Editor dialog box

In the Material Editor dialog:

A Click the Get Material - [image] -button.

The Material/Map Browser dialog will open.

3ds Max Material/Map Browser dialog box

In the Material/Map Browser dialog:

* In the Shaders list, select DirectX 9 shader.

* Click the OK button.

The Replace Material dialog box will open.

3ds Max Replace Material dialog box

In the Replace Material dialog box:

+ Select the Discard Old Material? option button.

+ Click the OK button.

B Material Editor will display the rollouts DirectX 9 Shader, Default .fx parameters, Technique, and Software Render Style.

3ds Max Material Editor dialog box, after selecting DirectX9 shader

C In the DirectX 9 Shader rollout, press the Shader button (in this case, labelled C:\3dsmax8\maps\fx\Default.fx).

The Choose an FX File dialog will open.

3ds Max Choose an FX File dialog box

In the Choose an FX File dialog:

* Browse to the BigWorld shader directory located in \bigworld\res\shaders\std_effects\

* Click the Open button.

D Material Editor will display rollout with parameters for the selected shader/FX file.

3ds Max Material Editor dialog box displaying parameters for the selected shader

For a detailed list of available BigWorld shaders and their properties see the BigWorld shader and Materials section.

E Close Material Editor.

4 The viewport should now display the shader applied to the object.

3ds Max Viewport with BigWorld shaders applied to object

When you export the object and open it in Model Editor, the BigWorld DirectX 9 Material will be already assigned to it.

note To see the interaction of a light source with the shader, place a single directional light into the scene.

Previewing BigWorld UV-scrolling shaders

When previewing the effect of a BigWorld shader using scrolling UV's within the 3dsMax viewport you must turn off incremental scene updates within 3dsMax.

To do this go to Customize - Preferences - Configure Direct3d - Use Incremental Scene Updates and turn the option OFF.

Because the scrolling UV effect occurs over time, the effect can only be viewed when the Play Animation button has been pressed.

Fast material assignment

Repeating the above process for every object that requires a material can be tiresome and inefficient. You can speed up the process by creating a material library within 3ds Max.

Creating a BigWorld 3ds Max material library

This process requires a single artist to set up a template scene containing each of the BigWorld materials. This scene is then shared between artists and used as a material library, allowing artists to quickly apply BigWorld materials directly to objects within 3ds Max.

1 Open 3ds Max.

2 Create a new scene.

3 Create several sphere objects, one for each BigWorld shader type.

4 Using the technique described in this lesson's topic Applying BigWorld shaders directly to 3ds Max models, apply a different BigWorld shader to each of the objects in the scene.

5 Be sure to correctly name the 3ds Max material - a good rule is to use the name of the FX file.

3ds Max Material Editor dialog box – Naming the material

6 Save the scene as BigWorldMaterialLibrary.max.

This file can now be distributed to your art team to be used as a BigWorld material library.

Note: BigWorldMaterialLibrary.max can also be found at \mf\bigworld\doc\tools_tutorial_examples.zip

Using the BigWorld 3ds Max material library

To use this BigWorld material library simply:

1 Open 3ds Max.

2 Select menu item Rendering→Material Editor.

The Material Editor dialog will open.

3ds Max Material Editor dialog box

3 Click the Standard button.

The Material/Map Browser dialog will open.

3ds Max Material/Map Browser dialog box

In the Material/Map Browser dialog:

A In the Browse From group box, select the Mtl Library option button.

B In the File group box, click the Open button.

The Open Material Library dialog will open.

3ds Max Open Material Library dialog box

In the Open Material Library dialog:

* In the Files of Type combo box, select 3ds max (*.max).

* In the file list, select BigWorldMaterialLibrary.max.

* Click the Open button.

C A list of BigWorld shaders will be displayed in the dialog.

3ds Max Material/Map Browser dialog box displaying BigWorld shaders

Now you have the entire list of BigWorld shaders easily accessible via 3ds Max's material editor.

Referencing the object texture maps

All art assets to be used in the BigWorld engine must reside in the resource folder your_game/res or one of its subdirectories. This includes bitmaps referenced by any models you may create. If your 3d model is referencing bitmaps from another location other than the /res directory, you must move those bitmaps into the resource folder (or one of its subfolders).

As an example we will reassign the bitmaps used on the ranger model in 3ds Max to the \res\characters\avatars\ranger\ folder.

1 Open Windows Explorer.

2 Create the following file structure within your game directory.

Our example is \res\characters\avatars\ranger\

3Copy the final texture maps from your working drive to the new /ranger folder.

4 Open 3ds Max.

5 Using the Bitmap/Photometric Path Editor utility, or the Asset Tracking Dialog, reassign the materials to the folder used in your game.

3ds Max Bitmap/Photometric Path Editor dialog box. A utility for reassigning bitmaps

Now that the bitmaps have been sourced to the /res folder or one of its subdirectories, the BigWorld engine can access them.

Texturing outside UV coordinates avoids compression artifacts

The BigWorld engine automatically compresses textures and uses a process called mipmapping. Mipmapping creates a series of smaller resolution textures from the original texture. This helps keep texture memory use to a minimum and thus improves performance. For more information on automatic texture compression see the section Defining texture compression settings

Example mipmap

When a bitmap is resized via mipmapping it samples pixels from the surrounding area to create the new pixel. If the neighbouring pixel is black then the newly created pixel will be darker than it should be. This results in the compression artifact seen on the right side of the image below.

When viewed from afar (right), the model is rendered
with a line in the middle

To avoid mipmapping compression artifacts, extend the painted area outside the UV coordinates by several pixels

Multiple material types

Not all objects are made of a uniform material. For instance the character in this picture is made of several different material types yet remains a single mesh.

BigWorld character displaying multiple material types

The table below describes the meaning of each colour:

Colour | Material type
Pink | Skin
Yellow | Hair
Blue | Eyes
Red | Fabric type 1
Maroon | Fabric type 2
Grey | Metal

Material type per colour

This material heterogeneity can be replicated within the BigWorld engine by assigning different shaders to parts of a single object. For example, a chrome shader with reflection maps could be used on the metal sections, while a sub surface shader would be better assigned to skin areas.

For the BigWorld exporters to recognise multiple material types it is important that you set up your character correctly within your 3d application.

Multiple material types within 3ds Max

To assign a single object multiple materials from 3ds Max:

1 Go to sub object Polygon selection mode.

2 Select the parts of the model that consist of a particular material type. In this example, I have chosen the steel plates on the character's glove armour.

Select the polygons to which you wish to give a specific material

3 Assign it material with a unique name from the Material Editor – essentially this is the same as using a multi/sub-object material on your object.

Apply the materials either separately or as part of a Multi/Sub-Object.

4 When the character is exported and brought into ModelEditor, it will have the same material types and names as assigned in 3ds Max.

ModelEditor's Materials Settings dialog box

The image above shows how materials are displayed in ModelEditor. Note that the suffix _skinned has been automatically added to the material names.

Multiple material types within Maya

To assign multiple materials to a single object from Maya:

1 Select the region of your model to which you will assign a material. I'll do this by going to Face mode. Right click - Face.

Select the regions to which you wish to assign a specific material.

2 Select the faces of the model that consist of the material you wish to add. Here, again, I have chosen the steel plates on the character's glove armour.

3 Assign this area a unique shader. This can be done multiple ways; I prefer to use Maya's Render tab as it is fast and easily accessible.

Maya's Rendering tab

4 You should re-name the default materials with a sensible name. These names will be used in the BigWorld engine to define the models material groups, and programmers might not be happy if you have called something Blinn04.

5 One of the best ways to manage your materials in Maya is to use the Hypershade editor. From here you can see materials, rename materials, and select areas on your model that use a specific material.

Maya's Hypershade editor

The only information exported from Maya's materials is the diffuse texture. Unlike 3ds Max, Maya does not support direct assignment of .fx files. For Maya users, shader assignment must be done in Model Editor.

High cost of multiple material types

The more material types you have on an object the more draw calls have to be performed by the graphics card. This will slow down your game's performance, so it is best to limit the number of objects that have multiple material types.

There are several things you can do to improve game performance.

1 Minimise the use of multiple material types.

If an object is made of a single material type, then only use a single material. Take for example the cargo crate, centrepiece of all game designer's dreams. The crate is made of a single uniform material. The worst possible thing you could do is give each side of the crate a different material type. Leave separate materials for important things like player characters, and if you must use multiple materials, LOD them away to a single material type.

2 LOD away material types.

At further distances, effects of numerous complex shaders become negligible, and only serve to weigh down the performance of the engine. It is therefore advisable to apply a reduced set of simple shaders to distant LOD models.

For example, the first LOD model of a character, displayed closest to the camera, may have 3 separate material types: metal, skin and hair, each using a different shader and referencing several texture maps (Diffuse map, Normal map, Reflection map). At LOD3, because the character will only be represented by a few hundred pixels on screen, the character may only require a single simplified shader that references the diffuse texture only, therefore reducing the load on the graphics card.

3 Single Texture sheet.

If parts of an object use different shaders they do not have to use different texture sheets. It is best if an object uses a single texture sheet. This will save on texture memory D3D state change costs. In the example below the same texture sheet is applied to all parts of the model regardless of its material type. Note that every mesh part that uses a unique FX shader will require a separate draw call.

A single texture sheet can be accessed by multiple materials.

Exporting multiple UV coordinates

BigWorld supports multiple UV coordinates exported from both 3dsMax and Maya

To create a second uv channel inside 3dsMax simply add another UVW Mapping modifier and set the map channel to a different number

To create a second uv channel inside Maya simply Create a second UV Set

Multiple UV's will only work with a shader that supports a second UV channel, see shader "lightonly_dual.fx" for shaders compatible with multiple UV's

Exporting vertex colour

BigWorld supports vertex colour exported from both 3dsMax and Maya

To create vertex colour in 3dsMax simply add a VertexPaint modifier to the stack and paint each vertex

To create vertex colour in Maya select Colour - Paint Vertex Colour Tool

Vertex colour will only work with a shader that supports vertex colour, see shader "lightonly_vertexcolour.fx" for shaders compatible with vertex colour.

Using the Edit Normals Modifier

BigWorld supports changes made to the vertex normals via 3dsMax's Edit Normals modifier

The Edit Normals mofier is selected on export

Importantly, the Edit Normals mofifier must be selected on export for the normals modification to be valid in game.

If multiple objects require exporting, each with edited normals then a single edit normals modifier should be used.

Exporting static objects from your 3D application

Using the BigWorld 3ds Max exporter to export static objects

To export a static object as a Visual file, follow the steps below:

Firstly, ensure that the exporter plug-in for your 3d application is installed. Instructions for installing the exporter plug-ins can be found in the Tools Reference Guide, chapter 3ds Max and Maya Exporters.

1 Open 3ds Max.

2 Select menu item File→Export.

3 In the dialog Select File to Export, drop-down list box Save In, locate the resources sub-folder where you would like to store the file.
In this case use res\sets\trees:

Resource sub-folder

4 In the field File Name, type oak_tree.

5 In the drop-down list box Save As Type, select Visual Exporter (*.VISUAL).

Save As Type options

6 Click button Save.

7 In the dialog Visual Exporter:

Set Visual type to Static.

Static objects are non-skinned (no bones), non-animating objects. For a description of how to get an animating character or NPC into the BigWorld engine, see the lesson Create Low-Polygon Characters.

* Clear the Allow scale check box.

This option only applies to the export of animated objects. When you are exporting an object with scale animation, check this option. Otherwise clear it.

* Select the Normal mapped check box.

This option should be checked if you are using a normal map on your object.

* Select the Keep existing materials check box.

This option prevents the exporter overwriting any changes that were made to the material properties post export. For example, if you exported a crate with a wooden texture then later change its texture to a metal texture in Model Editor, re-exporting this crate would result in the loss of the metal texture (the box reverting back to the assigned wooden texture). If you tick Keep existing materials then you will avoid this problem.

Visual Exporter dialog box

* Click OK.

8 Located in the folder you selected, there will now be the following files:

* name.model

* name.primitives

* name.visual

Using the BigWorld Maya exporter to export static objects.

To export a static object as a Visual file, follow the steps below:

Firstly, ensure that the exporter plug-in for your 3d application is installed. Instructions for installing the exporter plug-ins can be found in the Tools Reference Guide, chapter 3ds Max and Maya Exporters.

1 Open Maya.

2 Select menu item File→Export All→

Maya's File menu

3 In the Export All Options dialog box:

* Select Export Type group box's Visual radio button.

* Select Visual Type group box's Static radio button.

Static objects are non-skinned (no bones), non-animating objects. For a description of how to get an animating character or NPC into the BigWorld engine, see the lesson Create Low-Polygon Characters.

* Clear the Allow scale check box.

This option only applies to the export of animated objects. When you are exporting an object with scale animation, check this option. Otherwise clear it.

* Select the Bumpmapped check box.

This option should be checked if you are using a normal map on your object.

Maya's Export All Options dialog box.

4 The Export dialog box will be displayed.

In the File Name field, type the name of the object that you are exporting.

Maya's Export dialog box

5 Click the Export button.

6 Located in the folder you selected, there will now be the following files:

* name.mode

* name.primitive

* name.visual

BigWorld and Collada

Exporting Collada .dae files to BigWorld

The Collada to Bigworld converter located in bigworld\tools\collada_converter\dae2bigworld.exe allows users to convert collada (.dae) files into BigWorld .model files.

The converter can be run from the command prompt.

The syntax for the converters use is as follows.

dae2bigworld.exe infile.dae [-o outfile.model] [-a] [-n] [--res respath;otherrespath]

Only infile.dae is required when you run the converter, this will convert your .dae file to infile.model, as a static model. This requires your .dae file to be in the bigworld res tree..

It requires the resource paths to be set up, the easiest way of setting this up is to add a paths.xml file to the folder where you keep dae2bigworld.exe, that way you don't have to add the paths to the command line.

The options are:

* -o outfile - specify the output file, if this is not specified the output filename will be the same as the input filename with .dae extension

* -a to create an animated model

* -n to force the nodes to be included in the model .visual file (for static models with nodes, if -a is specified, the nodes are already included)

* --res to specify the res path to use.

* -static - output a static model, all parts of the model will be combined to
one model.

* -animated - output an animated model that can have an animation applied.

* -shell - output a shell model, similar to a static model but with portals and hulls.

* -static_with_nodes - output a static model with the node hierarchy in tact.

* -animation - output a .animation file.

* -bone_limit ## - number of bones allowed per mesh piece (default is 17).

* -no_bump - do not generate bump mapping information, by default tangents and binormals are generated.

* -ignore_materials - clear the existing materials from the model and visual.

* --res respath;otherrespath - override the res path used by the model

The converter is built using the opencollada framework (http://www.opencollada.org)
It is not fully compatible with the fbx collada exporters for 3ds max (and possible the maya one) as they do not adhere to the collada spec. It should work as long as you don't have any materials assigned to your objects though.
If using 3ds max or maya it is probably better to use the free exporters available from opencollada.org.

Materials are not converted (only material names are included), so you will need to apply them in ModelEditor after conversion.
Bsp tree for collisions will be generated for static models.
Vertex data that is supported at the moment: positions, normals, uvs, skinning information.

The converter requires the february 2010 directx runtimes or later, these can be installed from:
http://www.microsoft.com/downloads/en/d ... laylang=en

An easy way to use the exporter is to create create 5 shortcuts of the dea2bigworld.exe file and named them as follows Animated

* Animation
* Shell
* Static
* Static With Nodes

I then modified the properties (right click - properties) of each file to add the following arguments to the Target:

* Animated ---- "F:\mf_20\bigworld\tools\collada_converter\dae2bigworld.exe -animated"
* Animation ---- "F:\mf_20\bigworld\tools\collada_converter\dae2bigworld.exe -animation"
* Shell ---- "F:\mf_20\bigworld\tools\collada_converter\dae2bigworld.exe -shell"
* Static ---- "F:\mf_20\bigworld\tools\collada_converter\dae2bigworld.exe"
* Static With Nodes ---- "F:\mf_20\bigworld\tools\collada_converter\dae2bigworld.exe -static_with_nodes"

These shortcuts can now be placed anywhere you wish (I have them on my desktop).

From Maya/Max/3dTool export or save a .dae collada file to the location you want the final BigWorld file (within your res path). To convert the .dae collada file into a BigWorld file all you need to do is drag the .dae file from the res path location on top of the appropriate exporter shortcut.

Using the BigWorld (Visual) to Collada converter

If an original art asset is lost it can sometimes be necessary to convert BigWorld assets back into 3d models so that further changes can be made within your modelling package of choice.

The VisualToCollada.py script located in \bigworld_pssm\tools\misc\visual_to_collada\VisualToCollada.py can convert static BigWorld .model files into .dae collada files.

* To use the VisualToCollada.py script you will need python 2.6 installed.

* Then from the command prompt, navigate to the location of the VisualToColladay.py script

* Include the relative path of the .visual asset you wish to convert.

* Once executed the .dae file will be located in the same location as the .visual file.

Note: This tools is in its extreme infancy. It will only convert static models, it does not retain material information.


Modify a Model in ModelEditor

  • Importing an object
  • Manipulating the camera
  • Changing a model's shader/material
  • Changing a model's texture
  • Using MFMs
    • Create an MFM
    • Apply an MFM to a model
  • Exposing a material parameter to Python
  • Enabling a texture feed
  • Changing the model's thumbnail

ModelEditor allows artists to:

* associate animations with models,

* create actions, LOD trees and tints, and

* modify materials and properties.

This section of the content creation manual covers material editing.

Importing an object

To import an object in ModelEditor, follow the steps below:

1 Run ModelEditor.

The executable ModelEditor.exe is located under folder \bigworld\tools\modeleditor\.

2 Load the model file that was exported from your 3d package in the previous lesson.

Select menu item File→Open (Ctrl+O.)
-or-
Use the Asset Browser’s dynamic search field to find and select the object you wish to edit – from the Asset Browser, choose the Models virtual folder, then either double-click a model or drag it to the viewport.

Asset Browser with model filter folder selected displaying available assets named "rock".

Manipulating the camera

There are two camera modes to choose from.

1. Orbit Camera toolbar button – [image] –, which can be toggled ON and OFF

* To rotate the view (look around), hold the right mouse button and drag.

* To automatically rotate the camera left, press A.

* To automatically rotate the camera right, press D.

* To move in, press W.

* To move out, press S.

* To move up, press Q.

* To move down, press E.

2. Free camera mode

* To rotate the view (look around), hold the right mouse button and drag.

* To move left, press A.

* To move right, press D.

* To move in, press W.

* To move out, press S.

* To move up, press Q.

* To move down, press E.

Changing a model's shader / material

The first time you load your model in ModelEditor it will be displayed with the same texture maps you applied in your 3d application. If you did not specify a BigWorld shader from 3ds Max, or if you are a Maya user, the exporter will have automatically assigned a BigWorld shader to your model.

To alter the type of shader used by your model, follow the steps below:

1 Click on the tab Materials to display the material list with associated properties.

Materials tab displaying list of assigned texture maps

At the top of the material tab you will see the list of materials applied to your model. These materials derive their names from the material name in your 3d package.

2 Select the material you wish to edit from the material list.

The properties of that material will be displayed in the properties box below the material list.

Different material properties will be displayed depending on the type of BigWorld shader assigned to your model. These parameters may include such things as:

* Collision Flags (Does your object need a collision volume?)

* Double Sided (Whether your model is rendered double sided or not)

* Diffuse Map (The colour map assigned to your model)

Further information about material properties can be found in the lesson BigWorld Shaders and Materials.

The Effect field allows you to choose the BigWorld shader to be applied to the active material type.

3 The current shader can be changed several ways:

* Click the [image] button to display a list of BigWorld shaders.

* Drag an effect from the Asset Browser into the above field.

* Assign the object an MFM (explained below).

Choose a new shader in the dialog box.

A complete list of all BigWorld shaders (and their properties) can be found in the lesson BigWorld Shaders and Materials.

.

Changing a model's texture

A model's texture is specified in the Materials Settings panel, and can be changed in three different ways: via the [image] button, via copy-and-paste (from the Asset Browser panel's Textures virtual folder to the field), or via drag-and-drop. The methods are described below:

* Via the [image] button:

1 Select the Materials Settings panel.

2 Click the field whose texture you wish to change. (In the example below, we change the Diffuse Map field.)

3 Click the [image] button – the Open dialog box will be displayed.

4 In the Open dialog box, select the texture that you want to be applied to the field, then click OK.

Specifying a texture via the [image] button

* Via copy-and-paste:

1 Select the Asset Browser panel.

2 Select the Textures virtual folder.

3 Right-click the texture that you want assigned to the field, and in its context menu, select the Copy Path To Clipboard menu item.

4 Select the Materials Settings panel.

5 Right-click the field whose texture you want to change (in the example below, we change the Diffuse Map field), and in its context menu, select the Paste menu item.

Copy the name of desired texture
in the Asset Browser panel

Paste the name of desired texture
in the Material Settings panel

* Via drag-and-drop:

1 Select the Asset Browser panel.

2 Drag the panel's title bar and drop it in a location such that you can view both Asset Browser and Material Settings panels at the same time.

3 In the Asset Browser panel, select the Textures virtual folder.

4 Drag the desired texture and drop it in the field in the Material Settings panel to which you want it assigned.

Drag the desired texture from the Asset Browser panel, and
drop it in the field in the Material Settings panel.

Using MFM's

Material files (.mfm) contain BigWorld material information such as shader type, bitmap paths, and property setting.

When a .mfm file is referenced in ModelEditor, the contents of that material file are stored within the model's visual file. You do not need to use MFM files, but they can be a handy way of storing and transferring complex material property settings.

Create an MFM

To create an MFM file, follow the steps below:

1 Select the Materials Settings panel.

2 Click the [image] button – the Save As dialog box will be displayed.

3 In the Save As dialog box, specify the folder and a name for your new MFM file.

4 Click the Save button.

Apply an MFM to a model

1 Select the Materials Settings panel.

2 Click the [image] button – the Open dialog box will be displayed.

3 In the Open dialog box, select the MFM file that you want applied to your model.

4 Click the Open button.

The data in the MFM file is written to the model's .visual file – once the model is saved, any changes made to the MFM will not affect the model's materials.

Exposing a material parameter to Python

If you wish to change a material property in-game (for example increasing the self-illumination) then you must expose that property to Python so that the programmers have access to the material property from code.

Any material parameter that can be represented as a Vector4, and is part of a material tint can be exposed to Python scripts for use within the game.

This means that any of the examples below can be altered from script within the game providing you expose them to Python.

Data Type
Floating-point
Boolean
Slider
Vector4

Types of material property exposable to Python

To expose a material parameter to Python, simply right-click it, and in its context menu, select the Expose to Python menu item. After that, the game programmer will have access to that material parameter from script.

Exposing a material property to Python

Exposed parameters must be part of a material tint.

Enabling a texture feed

Textures generated from script in-game, such as a render to texture can be set up within Model Editor to be fed into a particular texture path.

For example, the bone TV in the fantasy demo is displaying a texture feed directly from a camera placed in another part of the world.

This is set up by enabling a texture feed into the TV's diffuse slot. To do that, follow the steps below:

1 Right-click the texture field that you wish to texture feed, and in its context menu, select the Enable Texture Feed menu item – the Texture Feed Name dialog box will be displayed.

2 In the the Texture Feed Name dialog box, type the name of texture feed, then click the OK button.

3 Give this name to the programmer, so that he can match the texture to the feed via script.

Enabling a texture feed (left), and its final in-game result (right)

In the example above I have put the texture feed on a material tint (tv2) of the bone_tv model. But it is not necessary to create a tint for a texture feed – I only used tints in this case because there are multiple channels that feed into the TV, thus requiring multiple tints.

Changing the model's thumbnail

The thumbnail used in the Asset Browser is automatically created, but you can manually change it via the [image] button.

This button replaces the existing thumbnail with a thumbnail version of what appears in ModelEditor's 3d viewport.


Add Models to the World

  • Locating models in the Asset Browser
  • Navigating the WorldEditor viewport
  • Placing models on the terrain
  • Manipulating the models
  • Using the clone feature
  • Creating invisible barriers
  • Finding missing Assets

Locating models in the Asset Browser

To locate a model in the Asset Browser, follow the steps below:

1 Run WorldEditor with an existing world, such as the world space created in the lesson Setup a New Project.

The executable worldeditor.exe is located in folder bigworld/tools/worldeditor.

2 Select the Asset Browser.

3 Select the appropriate search filter folder – in this case we want to place a model, so choose the Models virtual folder.

4 In the Asset Browser’s [image] field, type the name of the model you wish to place – the Asset Browser will search the entire /res folder to find any assets that match the file name.

Specifying search of models with the string rock on their names

5 The thumbnails of matching model files will be displayed on the file browser. (If you cannot see the thumbnails, then right-click on any of the model files, and in the context menu choose the List view styles→Big icons menu item.)

When placing organic objects like trees and rocks,make sure that Object Panel’s Placement Control group box’s Setting drop-down list box is set to Yaw+Scale.

Specifying random rotation and size for items placed in WorldEditor

This adds random yaw (rotation) and scale (size) to the objects you place in WorldEditor.

There are several preset random placement types, and you can also create your own. For more details, see the document Content Tools Reference Guide, chapter WorldEditor, section Panel Summary, sub-section Object Panel.

Navigating the WorldEditor viewport

To navigate the WorldEditor viewport, use the viewport keyboard controls, or click-and-drag with the right mouse button:

* To rotate the view (look around), drag with the mouse right button.

* To move left, press A.

* To move right, press D.

* To move forward, press W.

* To move backwards, press S.

* To move up, press Q.

* To move down, press E.

To speed up the movement of the viewport camera, you can turn on Caps Lock, or change the camera speed – either via the toolbar buttons [image], [image], [image], [image] or via their respective keyboard shortcuts (cntrl + 1, 2, 3, 4).

Placing models on the terrain

To place a model on the terrain, follow the steps below:

1 From the Asset Browser, select the thumbnail of the file you wish to add.

Selected tree model

2 Move the mouse over the viewport and press Enter, or drag the object from the Asset Browser and drop it in the viewport.

3 For a more precise control over model placement, make sure to select Object Panel’s Locking Mode group box’s Terrain option button.

Specifying that new placed items will be locked to terrain

4 Position the mouse pointer over the viewport.

5 The cursor pointer changes to a yellow placement icon, indicating where the model will be placed.

Yellow placement cursor

6 The cursor will follow the terrain contours, and snap to an invisible grid, the dimensions of which are specified in Object Panel’s Object Grid Snaps group box.

Snap settings

7 Press Enter.

8 The tree model and its bounding box will appear on the terrain landscape.

Model with bounding box in the viewport

Manipulating the models

To manipulate a model, follow the steps bellow:

1 Object Panel’s Selection Filter isolates the various scene contents, allowing for easier selection of models in cluttered worlds.

Selection Filter drop-down list box

2 Set the value to either All or Models for the remainder of this lesson.

3 Just like in 3ds Max, the viewport manipulator allows for control of the movement, rotation and scaling of the model using alternate keyboard commands.

* To display the Movement gizmo [image] Select the model.

* To display the Rotation gizmo [image] Select the model, then hold Shift.

* To display the Scale gizmo [image] Select the model, then hold Alt.

Movement gizmo

Rotation gizmo (Shift)

Scale gizmo (Alt)

Each gizmo type has three coloured handles that can be used individually, by simply clicking them.
You can also select two handles at once, for both the Movement and Scale gizmos, by using the outer tags shown as cyan, magenta, and yellow.

The blue axis (up, down) handle is disabled when Object Panel’s Locking Mode group box’s Terrain option button is selected.

When Locking Mode is set to
Free or Obstacle, the Movement
gizmo’s blue axis is enabled

When Locking Mode is set to
Terrain, the Movement gizmo’s
blue axis is disabled

Using the clone feature

To make a copy of a model in the world, follow the steps below:

1 Select the model.

2 Move the mouse cursor to the position where you would like the new model to appear, then press C.

3 The message "Cloned Selection" will be displayed at the bottom of the viewport, to indicate successful cloning.

Tree model cloned once

4 Click and drag an area in the viewport, selecting both tree models.

Both trees selected

5 Clone the selection again by pressing C to create two more trees.

Four tree models cloned

This method provides a very quick way of populating the world with scenery.

Creating invisible barriers

Most game environments require invisible barriers that prevent the player from navigating through certain zones.

To create an invisible collision object:

1. Export the collision volume from your 3d application, I'm using a cube, but it could be any shape you like.

Using a cube as an invisible barrier

2. The invisible barrier model is given a Do Not Render material and its Collision Flags are set to Camera Off Player On

Give the invisible barrier an empty material and set its collision to Camera Off Player On

3. Because, the object is going to be set to invisible we also need a proxy model to visualise the barrier in World Editor. It is best that our proxy model is exactly the same size and shape as our invisible wall, so in this case I export the same object twice. One to be used as a barrier and then as a proxy. In the diagram below I have assigned the proxy model to the invisible barrier.

Define the proxy object from the Object Properties tab in Model Editor

4. The proxy model is given a material that clearly indicates its use as a barrier.

5. When placing your invisible barrier in the world you will need to use Editor Proxies in World Editor's Options tab. Also ensure the barrier is not casting terrain shadows,

set its cast shadow property to False.

Note: There is already a default collision object available in bw/res/helpers/models/invisible_wall.model. It can be scaled to suite your needs

Finding missing Assets

If an asset is removed from the resource directory without first being removed from the space you will receive a missing resource error in world editor.

To locate the position of the missing resource open the Message tab and double click on the missing asset

This will take the camera to the location of the missing asset, which will be replaced by a red cube "standin.model".

Simply delete the cube if you wish to remove the missing asset reference.


Sculpt Terrain

  • Changing the surface height
  • Average brush
  • Adding refinement filters
  • Removing terrain

Changing the surface height

To change the height of a surface, follow the steps below:

1 WorldEditor uses a 3D brush to sculpt the terrain.

To access it, click the [image] toolbar button – this activates the Terrain Height panel. The Size and Strength fields in the panel determine the magnitude and speed of the change.

Terrain Height panel

The limits of each slider can be set by pressing the [image] button next to it (this will invoke the Set The Slider Limits dialog box.

Dialog box used to set the limits of a slider

2 The brush will be displayed in the viewport as a 3d dashed ring that defines the area of influence.

Brush cursor in the viewport

3 Drag the Size slider, or use the shortcut keys [ (left square bracket) and ] (right square bracket) to alter the brush diameter, thereby changing the influence area.

The Strength field can be increased or decreased via keyboard shortcuts ALT+[ and Alt+] respectively. It will not cause any visual changes to the brush icon, only to the speed at which it affects the underlying terrain.

4 To apply the brush, simply hold down the left mouse button and drag over the desired area.

The terrain will rise up in the center of the cursor. If you do not notice any changes in the height of the terrain, then increase the value of the Strength field.

The Brush Falloff group box determines the shape of the terrain around the outer edge of the brush, with three options provided – Linear, Curve, Flat and Average.

Terrain raised using the three options Linear, Curve, and Flat brush

You can undo the brush operation at any time, via the [image] toolbar button or the Ctrl+Z keyboard shortcut, both of which can be applied multiple times.
Note that one undo operation is based on a single mouse click. This means that if you apply a brush operation by holding down the mouse button, and then undo it, the result of the entire change will be removed.
To avoid losing too much progress, it is recommended to paint in shorter dabs, instead of using longer brush stroke periods.

5 To lower the terrain, drag over the desired area with the middle mouse button.

Terrain lowered under brush cursor

6 The Left Shift key can be used to toggle between Filter and height mode.

7 Using the Explicit Height field, you can snap the terrain to a specified height in metres.

To set an explicit height for a particular area of the terrain, follow the steps below:

A Set the value of Explicit Height field to the desired value (in metres) – the terrain height can be sampled using the Alt key.

B While pressing Ctrl, drag over the desired area – the terrain under the brush cursor jumps to the specified height.

Explicit Height field

Terrain height raised to explicit value

You must click and drag the cursor over the desired area to change its height – just clicking while holding Ctrl only changes the height of the point clicked.

The Explicit Height value can be added in two ways: Absolute (where terrain height is set to the value of Explicit Height) and Relative (where value of Explicit Height is added to the height of terrain).

8 There are three ways to visualise the terrain mesh:

A by selecting General Options panel's Show list box's Terrain→Wireframe entry;

Terrain→Wireframe option in General Options panel

B by clicking one of the Chunk Visualisation toolbar buttons: (Normal mode), [image] (Chunk borders mode), [image] (Pole markers mode), or [image] (Wireframe mode); or

C by pressing F6 keyboard shortcut to cycle through the Chunk Visualisation modes (in the order in which they appear in the toolbar).

Average brush

The Average brush is great for creating quick paths and roads. It works by taking a sample of all the height positions under the cursor and then averages them.

To use the average brush;

A click the [image] toolbar button to activate the Terrain Height panel;

B Select the Average Radio button

C Adjust the Size and Strength

Here you can see an examples of what the average brush can achieve.

Adding refinement filters

To refine the terrain using filters, click the [image] toolbar button or use the shortcut key "4" – this activates the Terrain Filtering panel.

1 Filters apply an algorithm to the area you paint. That algorithm can smooth, sharpen or add noise to the terrain.

Terrain Filtering panel

Smooth filters are ideal for ironing out any imperfections caused by manually brushing with the height tool.
Sharpen filters are ideal for increasing small differences in the terrain.
Noise filters can break up flat areas and give the terrain a more natural appearance.

2 Apply the desired filter.

To use filters on the terrain, follow the steps below:

A click the [image] toolbar button to activate the Terrain Height panel;

B adjust the Size, Strength, and Explicit Height fields to the desired values;

C select the desired Brush Falloff;

D click the [image] toolbar button to activate the Terrain Filtering panel;

E select the desired filter in the Filters list box;

F apply the selected filter in the viewport, using the click-and-drag method.

Filter effects

Removing terrain

The [image] toolbar button activates the Terrain Mesh Cut/Repair panel, which gives you access to the cut and repair actions, allowing you to remove or replace entire sections of terrain.

Terrain Mesh Cut/Repair panel

To remove the terrain, follow the steps below:

1 select the Cut option button;

2 set the Size field to the desired value – this will set the size of the brush, which is represented as a green square;

3 navigate the camera to an overhead view, in any of the following ways:

use the movement keyboard shortcuts Q, W, E, A, S, and D.

drag the mouse to change the camera angle;

click the [image] toolbar button to turn Orthographic View on.

4 Cut the terrain:

click the mouse to cut terrain of the specified size; or

* click and drag the mouse over the desired area to cut it – the terrain will be cut as you move the mouse over it.

Terrain removed with Cut action

5 The Repair action replaces the terrain that has been removed, based on the size specified for the brush. The Left Shift key will toggle between cut and repair mode

Terrain replaced with Repair action


Create an Internal Shell

  • What is a shell?
  • Components of a shell
    • Portals
      • Standard portals
      • Exit portals
      • Heavenly portals
      • Portal Rules
    • Custom Hull
      • Custom Hull Rules
    • Game Geometry
      • Game Geometry Rules
  • Shell snaps within WorldEditor
  • Tutorial: Modelling a room as a shell
    • Tutorial: Creating ceiling height variation
  • Tutorial: Creating portals
  • Labelling portals
    • Standard portals
    • Exit portals
    • Heavenly portals
  • Shell planning - dividing up an internal space
  • Shell navigation constraints
  • Town planning - using portals to create cities and towns
    • City type 1
    • City type 2
  • Portal creation: using materials on custom hulls
  • Prevent sparkles and improve culling
    • Shell flanges
    • Plugs
      • Tutorial: Plug for the standard portal
      • Tutorial: Plug for the exit Portal
  • Creating an undercover area
    • Shell flanges
    • Plugs
    • Plug for the standard portal
    • Plug for the exit portal
    • Outside only: lighting properties
  • Outside only
    • Shell flanges
    • Plugs
    • Plug for the standard portal
    • Plug for the exit portal
    • Outside only: lighting properties
  • Referencing the room and plug texture maps
  • Exporting shells
  • Exporting the plugs

What is a Shell?

Shells are modularised objects built in a 3d application that are designed to snap together in WorldEditor.

Their main purpose is to exclude geometry (including the terrain) from being rendered by the game engine when the player is inside a room, thereby potentially increasing the frame rate performance.

Using shells will improve the performance of your game.

Shells also provide an efficient method for level building, since you can simply auto-snap them (middle click) together to create entire rooms, streets or corridors.

Shells don't have to be inorganic and square. The 3D geometry that defines the explorable space within the shell can be any shape you wish, providing it stays within the bounds of the shell’s custom hull (if a custom hull is used) or bounding box.

The diagram below illustrates one such implementation of shell design. The explorable space (white) can be any shape. The custom hull (red) must be convex.

The shells will automatically snap together in WorldEditor at the portals (blue). It is important that you make the explorable areas at the portal boundaries match each other, otherwise there will be an obvious transition between shells.

Shells also allow for a more customisable lighting environment than the outside world. For more information on lighting shells see the lesson Add Lights to the World.

Components of a shell

Shells consist of up to three unique parts:

portals

custom hull (optional)

game geometry

Portals

Portals are basically windows into a shell – they tell the game engine when it can see into the next shell.

There are three types of portals, each allowing the engine to see in a different direction:

The type of material or texture assigned to each portal is irrelevant. The textures assigned to the portals are there for visual identification purposes only (they can be found in bigworld\doc\tools_tutorial_examples within the path helper_maps

Standard portals

Standard/inter-shell portals allow the direct connection of one shell to another, providing a two-way passage for the player to move through. When two shells are connected (or resolved), the inside of one shell can be seen when viewed from the other, and vice-versa.

In 3ds Max, the tag line "portal=true" must be added to the Properties dialog box under the Object Properties→User Defined tab for that portal. To add a Standard portal flag to your portal geometry in Maya, use the BigWorld Shelf's Add Portal button ( [image]).

Exit portals

Exit portals allow a two-way passage from the inside of a shell to the outside terrain. When the player is inside the shell, the terrain (outside) will be visible to the player, and vice-versa.

In 3ds Max,the tag line "portal=true" followed by "exit=true" on a new line must be added to the Properties dialog box under Object Properties→User Defined tab for that portal. To add an Exit flag to your portal geometry in Maya, use the BigWorld shelf's Add Exit Portal button ( [image]).

Exit portals (green) must be used whenever there is an indoor-to-outdoor transition.

Heavenly portals

Heavenly portals are essentially one-way Exit portals. They allow all external objects to be rendered from the view of the internal shell. They do not allow the internal shell to be rendered when viewed from outside. Heavenly portals also have the unique feature that they let the sunlight in.

The tag line "portal=true" followed by "heaven=true" on a new line must be added to the Properties dialog box under Object Properties→User Defined tab for that portal. To add a Heavenly flag to your portal geometry in Maya, use the BigWorld shelf's Add Heavenly Portal button ( [image]).

Portal Rules

1 Portals must lie on the surface of a bounding box, or of the custom hull (if one is used).

2 Portals must be convex. They cannot be concave.

Portals must be convex

Custom Hull

Hulls are a way of defining an artificial bounding box of a shell. The shell's bounding box or hull defines what objects lie within it, and is used to cull outside objects. Hulls are not a requirement of a shell – if a shell model is exported without a custom hull, then the model's bounding box is used.

Using custom hulls simplifies the work of making building shells. If you define a custom hull then it is very easy to ensure that your portal lies on its surface. If you use the object's bounding box, a single stray vertex on the shell could offset the bounding box, making it difficult to place the portal on the bounding box's surface.

Below are two instances where a hull would be useful.

In the example above, the shell's bounding box (red) cannot be used as the hull, because the blue portal would not be on the boundary of the shell. In this case a custom hull matching the surface of shell1 is required.

In the example above, the shell1's bounding box (red) defines the blue object within Shell2 as belonging to Shell1. If a hull was used (green line), then the blue object would clearly not belong to Shell01.

Hulls must be convex geometry, so the yellow line cannot be used as a hull boundary.

When exporting a shell with a portal that is not aligned to an axis (as in the example above) you may need to turn the exporter option Snap vertices to OFF.

The Snap vertices option will force a portal's vertices to snap to the nearest tenth of a millimeter. This is usually a desirable feature when creating portals that are aligned to an axis. However, when a portal is not axis-aligned it can cause the portal to be pulled off the surface of a hull or bounding box resulting in the following error.

If you get the following error, try turning Snap vertices to OFF. If the error persists, your portal is probably positioned incorrectly on the surface of your shell.

Custom Hull Rules

1 Custom hulls must be convex. They cannot be concave.

2 Custom hulls are identified by the suffix "_hull", for example "insertname_hull"

Custom hulls must be convex.

Game Geometry

The geometry of the shell makes up the artistic content of the shell; its walls, floors, archways and pillars.

Just remember that if you haven't used a custom hull, altering the game geometry can affect the bounding box position, which may result in portals being lost because they no longer lie on the surface of the bounding box.

Game Geometry Rules

1 The explorable space of the shell should lie within the bounds of the custom hull (if one is used). In the diagram below, the player P (red) in the right image would probably experience strange culling anomalies because he has moved outside the bounds of the custom hull (black).

Keep the explorable space within the custom hull.

Shell snaps within WorldEditor

A shell's movement within World Editor is quantised to 0.01-metre translations and 0.1 degree rotations. Sometimes it can be useful to move set dressing items with the same snap restrictions as shells. In such cases you can use the preset snap setting Shell Snaps within World Editor. This will force any object you move to snap to 0.01-metre translations and 0.1 degree rotations.

Modelling a room as a shell

Although the following tutorial was performed in 3ds Max, the same principles apply for those creating shells in Maya. If you are a Maya user, please take the time to read through the tutorial.

To model an example room, follow the steps below:

1 Open 3ds Max.

2 Load the example file room_shell.max from the bigworld\doc\ools_tutorial_examples folder

The file can be found in tools_tutorial_examples\working_files\sets\shells\Room_shell.max.

3 Create a box at the origin in the perspective viewport, with the following size (in generic units):

125 length x 110 width x 40 height (in generic units).

Segments of 3 length x 3 width x 1 height.

4 Change to a user viewport to see the home grid in an isometric view.

Created box with its segments

5 Convert the box to an Editable Poly.

6 In 3dsMax, use the Move tool to translate it 27.5 units in the Y-axis.

Box after translation in 3ds Max

7 Create the first portal – a rectangle object will be used to represent the portals that the BigWorld engine uses to snap together different shells.

A In the front viewport, create a rectangular shape of 40x40 units using 3d grid snap.

B Apply an Extrude modifier to it, with a height value of 0.

A 40x40 rectangle

B Extruded rectangle

C Using the grid snaps, move the shape to the box position just beside the middle segments.

Moving the shape near the box, using grid snap

D Select box's middle-left row of vertices.

A Select the box.

B Enter Sub-Object mode.

C Select the middle row of vertices on the left.

Middle-left row of vertices selected

E Set the reference coordinate system to Pivot Point centre.

F Align middle-left row of box vertices to shape.

A Using the Align tool, click on the shape.

Aligning the vertices to the shape's left edge

B In the Align Sub-Object Selection dialog box, select the X Position check box, and in the Target Object group box, select the Minimum option button.

Align Sub-Object Selection dialog box

C The vertices should move in the x-axis, to the left edge of the shape, as shown below in Top view.

Top view showing vertices aligned

G Align the middle-right row of box vertices to shape.
Follow the same procedures as in step F with the right row of vertices, so that they also lie on the grid, but this time select the Maximum option button in Target Object group box.

Middle-right of vertices selected

Top view showing vertices aligned, using the right side of shape as the target

H Both rows of the middle vertices of the box should now lie on the home-grid.

Top view showing vertices aligned to the grid

8 Create second portal

A Exit Sub-Object mode of the box.

B Select the shape.

C While holding Shift, click the shape, to make a new copy of it.

D Move and snap the copied shape to the adjacent side of the box, to absolute position [X: 60, Y: 40, Z: 20].

Shape copied and offset to absolute position

E Rotate the shape's orientation by 90 degrees in the z-axis using Angle snap.

Rotating shape by 90 degrees

F Select the box.

G Enter Sub-Object mode.

H Align the middle-left row of box vertices to shape.

A Select the middle-left row of vertices in line with the second shape.

B Align the box's vertices to the shape.

In the Align Sub-Object Selection dialog box, select the Y Position check box, and in the Target Object group box, select the Minimum option button.

C The vertices should move to the left edge of the shape.

A Middle-left row of vertices is selected | B Align Sub-Object Selection dialog box | C Vertices moved to left edge

I Align the middle-right row of box vertices to shape.

A Select the middle-right row of vertices.

B Align the box's vertices to the shape.

In the Align Sub-Object Selection dialog box, select the Y Position check box, and in Target Object group box, select the Maximum option button.

C The vertices should move to the left edge of the shape.

A Middle-right row of vertices is selected | B Align Sub-Object Selection dialog box | C Vertices moved to left edge

J From the top view, both rows of vertices should now lie on the grid in line with the second shape.

Top view showing vertices aligned to the grid

At this point the room only needs an entrance, some sockets, plugs, and portals.

The walls in this example have been spaced a minimum of 0.5 metres away from the bounding box (outside edges) of the shell – this is to allow room for doors to open inside walls, and prevent zero-thickness walls in corners of shells.

Objects must be no larger than 100 metres (1,000 generic units) on any axis – this is the limit of object size inside the BigWorld engine.

Creating ceiling height variation

To create a ceiling height variation for the room, follow the steps below:

1 Enter Poly Select mode.

2 On top of the box, select the six polygons opposite the second shape.

3 Using the Inset tool, scale the polygons inwards, to create additional edges inside the original selection.

4 Using the Extrude tool, slightly raise the height.

5 Using the Bevel tool, slightly scale the polygons up and out.

6 Using the Extrude tool, raise an edge on the rooftop, to complete the ceiling height variation.

7 You can now UV Unwrap the object and apply texture maps to it.

Creating portals

To create a socket for an exit hole, follow the steps below:

1 Enter Sub-Object mode for the "shell_room".

2 Create first portal

A Select the polygon next to the first shape.

B In the Extrude Polygons dialog, set Extrusion Height to -5.0.

Original polygon

Extrude Polygons dialog box

Extruded polygon

C Completely detach the polygon, and name it "portal_01".

3 Create second portal

A Rotate the view so that the polygon next to the second shape is visible.

B Select that polygon and apply the same Extrude Polygon settings as before.

Extruded polygon

C Detach this polygon and name it "portal_02".

4 Create third portal

A Rotate the view back to see the opposite wall.

B Select the polygon directly opposite "portal_02"

C Apply the same Extrude Polygon settings as before.

Opposite polygon extruded

D Detach the polygon, and name it "exit_portal".

5 Exit Sub-Object.

6 Delete the two rectangle shapes previously created.

7 Assign textures to the portal objects

A Select the two portal objects named "portal_01" and "portal_02".

B Assign a portal texture to the selected portals.

Inter-shell portal texture

C Select the "exit_portal" object.

D Assign an exit portal texture to it.

Exit portal texture

8 Assign properties to the portal objects

A Select the "portal_01" object.

B Right-click the selected object, and in the quad menu select Properties.

C In the User Defined tab, type "portal=true".

3ds Max's Object Properties dialog box – Setting portal_01

D Select the "portal_02" object.

E Set the same properties as for "portal_01".

F Select the "exit_portal" object.

G In the User Defined tab, type "portal=true" and "exit=true".

3ds Max's Object Properties dialog box – Setting portal_02

Labelling Portals

Portals can be labelled so that they can be accessed via game script. This might be used by programmers to close off a portal so that entities cannot navigate their way through.

In Maya an empty label is created in Extra Attributes when you click any of the add portal shelf buttons [image] [image] [image].

In 3dsMax, labels are added to portals by adding the line "label=your_name" to the User Defined properties tab of the portal geometry. "your_name" is replaced with what ever label name you chose.

Shell planning - Dividing up an internal space

Before you begin converting your model of a room into a shell it is a good idea to sit down with a bit of graph paper and plan out the best way to divide up the room.

Imagine we have a top down view of our room, as in the image below.

1. The first thing you might notice is that in these circumstances, we are forced to use a custom hull because the portal doesn't lie on the surface of the bounding box.

2. Because custom hulls must be convex, simply adding a custom hull around our object will not suffice, because, again, the portal is not on the surface of the custom hull/bounding box.

3. The only way to convert this space into a shell successfully (without artifacts) is to divide the space in two, and surround each section with a custom hull. The point at which the division occurs will require a portal.

Shell navigation constraints

Due to limitations of entity navigation, shells should not be made with more than a single portal connecting two shells. If two doorways are required between two shells it is better to either split the shells or to use a single portal and object blockers.

Town planning - Optimising portal culling

Portals can be used to increase the rendering performance of geometry-rich areas such as towns and cities. When designing a city it is important to take into consideration how portals can be utilised.

It is important to understand how portals work in order to maximise their effectiveness. In Image 1 in the examples below, player P (red) is rendering the final shell (Shell3) because all the portals (blue) are aligned.

A better design choice would be to include a second portal (as in Image 2). In this example the player will not render shell4.

Shell geometry is not used to cull portal tests.

Umbra software can use shell geometry to occlude portals.

City type 1

This type features narrow streets with high buildings and surrounding walls. The high walls and tall buildings of this city type occlude vision into neighbouring areas, making it ideal for using shells.

Sections of the city can be created as shells. Portals can be placed at the end of streets and in archways.

Considerations

If the city contains tall buildings that are to be seen from multiple shells, then these shells must use heavenly portals as their ceiling.

Heavenly portals allow the outside world to be rendered. Therefore the tall buildings must be outdoor objects and not belong to any shell.

Because heavenly portals do not allow players to see into a shell, players cannot look down into the city from a high viewing position, such as a skyscraper – the heavenly portals allow rendering one way (out), but not in.

This type of city should be surrounded with a high wall, to prevent players looking into the city.

Shells can be snapped together in WorldEditor, making town- and city-building fast.

Terrain geometry under the city can be deleted to further increase rendering performance and prevent Z-fighting.

City type 2

This type features large streets with open areas such as markets and parks, with mostly small buildings in which you can enter.

Shells can be used to create the interior of houses and buildings.

It is very important to create at least two shells for each building.

The first shell (an entrance hallway, set of stairs, or reception room) allows the second more important and highly detailed room to be culled using the portal method.

The longer the hall (and hence the further the two portals are from each other), the bigger is the chance that the room will be culled from outside. Most game designers will use a bent "L" shaped entrance way to maximise portal culling. Multiple shells will help increase the probability of culling the main internal shell.

Portal and shell visibility considerations

The outside of a shell (brown) is a standard model which we refer to as a façade.

Even though the façade geometry does not overlap the shell, its pivot point might. This results in the 3d engine mistaking the façade for an internal object belonging to that shell, and lighting it as such. To ensure that façades light correctly, in WorldEditor's Properties tab, set the outside only property to True.

WorldEditor's Properties tab

Minimise the size of each portal

Because portal culling depends on portals lining up with each other and the camera, the smaller the size of each portal, the greater the chance that culling will occur. For this reason, it is best to make the portal dimensions extend just beyond the size of the geometry defining the doorway, window or entrance, and no further.

Portal creation: Using materials on custom hulls

Creating a piece of geometry to represent a portal is not the only way you can create a portal. When using a Custom Hull you can create a portal by assigning a specifically named material to the surface of the custom hull.

To create portals by assigning materials:

1 Make sure the name of your Custom Hull has the suffix "_hull" – this allows the exporter to choose this object as your custom hull.

Creating a custom shell hull

3 Assign a material with the name standard_portal , exit_portal, or heaven_portal, to one of the surfaces of the custom hull. This will create a portal at that position.

The type and name of texture applied to the hull is irrelevant, but for viewing purposes we use three easily identifiable textures that you can find in bigworld\res\helpers\maps.

Creating a portal on a custom hull

The alternative method for creating portals (using geometry) still works with custom hulls.

Preventing Sparkles and improve culling

Sometimes no matter how carefully you make shells they do not resolve together closely enough in WorldEditor to prevent players from seeing a small line of "sparkles" between shell boundaries. This is due to floating point inaccuracies from asset creation to display. The sparkly line visible in the picture below is a result of the outside world being visible between two shells.

These sparkles are not only visually unappealing, they can result in decreased game performance due to bad culling. See the section on how to create assets when using Umbra

There are two ways to solve this problem:

add a flange to your shell that extends past the boundaries of your shells, or,

use an object to fill the gap between shells – we call these objects plugs.

Shell flanges

To prevent sparkles (light from outside penetrating gaps between shells) a flange can be added to each shell. The flange should be wider than the visible interior of your shells and overlap with flanges on connecting shells.

Because the flange sits outside the portal (blue), you will need to create a custom hull (yellow). This is because the exporter will not recognise portals unless they are on the shell's bounding box, and the creation of the flange would move the bounding box, preventing the portal from being recognised.

Side view of the fantasy demo asset dun_highpassage_4x.visual designed with a flange (inset)

Plugs

The other way to prevent sparkles (gaps) between your shells is to hide the gaps with objects. We call these objects "plugs". Plugs are just standard models that hide any visual gaps between shells. They do not have any special specifications and are not a requirement for shell design.

In this part you will create plugs for the standard portal and the exit portal created earlier in this lesson.

Plug for the standard portal

To build a window plug that fits the standard portal socket, follow the steps below:

1 Create a rectangle shape of 40x40 units over "portal_02" in the left viewport.

Rectangle shape created over portal

2 Create archways.

A Inside the rectangle shape, create an archway shape for the window.

B Make a copy of the archway shape, so that two windows occupy the rectangle shape.

C Collapse the rectangle shape to an editable spline.

D Use Attach on the rectangle and on both archways, to combine them all into one shape.

E Weld all the vertices.

Rectangle shape with archway windows

3 Apply an extrude modifier to the window shape with a height value of units.

Extruded window shape

4 Remove polygons outside the object.

A Collapse the window plug to an editable poly.

B Enter Sub-Object mode.

C Select and delete the polygons around the outside of the extruded object.

Outside polygons in red

Object with outside polygons removed

D Exit Sub-Object mode.

5 Name the object "plug_windows".

6 Using 3D snap with vertex mode, move the plug_windows object over portal_02 and inside the socket you created previously in the lesson.

Plug object moved into position using vertex snaps

Plug for the exit portal

To build a window plug that fits the exit portal socket, follow the steps below:

1 Create a rectangle shape of 40x40 units over exit_portal in the left viewport.

Rectangle shape created over exit portal

2 Create archways.

A Use the line shape tool to draw an archway shape over the rectangle that you just created, using the grid snaps as a guide.

B Attach the line shape to the rectangle and trim the segments at the bottom to close the shape.

C Weld all vertices.

Archway with vertices attached and welded

3 Apply an extrude modifier to the shape with a height value of 5 units.

Extruded window shape

4 Remove polygons outside the shape.

A Collapse the shape to an editable poly.

B Enter Sub-Object mode.

C Select and delete the polygons around the outside only.

Outside polygons in red

Object with outside polygons removed

D Exit Sub-Object mode.

5 Name the object plug_doorway.

6 Turn on the 3D vertex snaps.

7 Move the plug_doorway object over the exit_portal to fit neatly into the socket created.

Plug object moved into position using vertex snaps

8 UV unwrap and apply texture maps to both plug_windows and plug_doorway objects.

Texture-mapped window and doorway plugs

9 Build an entrance object to cover the outside doorway.

A Create a box next to the exit_portal with the following settings:

* World position: x=-65, y=40, z=0.

* Dimensions (in units): length=60, width=10, height=50.

* Segments: length=3, width=1, height=2.

Box created with specific world position coordinates

B Rotate the view until you see the exit_portal object.

C With the box still selected, convert it to an editable poly.

D Enter Sub-Object mode.

E Enlarge the slot for the opening.

1 Enlarge frame to the right.

Select the middle-right vertical row of vertices.

Using 3D vertex snap, move them to the outside right corner of the exit portal socket.

Vertices snapped to the socket's right corner

2 Enlarge frame to the left.

Select the middle-left row of vertices.

Using 3D vertex snap, move them to the outside left corner of the exit portal socket.

Vertices snapped to the socket's left corner

3 Enlarge frame upwards.

* Select the middle-horizontal row of vertices.

Using 3D vertex snap, move them up, to the top of the exit portal socket.

Vertices snapped to the top of socket

F Enter polygon mode.

G Select the bottom and inside polygons, and delete them, including any isolated vertices.

Inside and bottom polygons selected

Inside and bottom polygons deleted

H Enter vertex mode.

I Select the inside border vertices and move them 5 units relative in the X-axis.

Before moving

After moving

J Create the opening.

1 Rotate the view to the front of the entrance.

2 Enter polygon mode.

3 Select the middle polygon and extrude it inwards -10 units.

Before extruding

After extruding

4 While pressing Ctrl, select the bottom polygon.
Now both the middle polygon and bottom polygon are selected.

5 Delete the selected polygons.

Middle and bottom polygons selected

Middle and bottom polygons deleted

6 You can now UV unwrap and apply texture maps to the entrance object.

Texture-mapped entrance object

The finished 3ds Max scene should now contain a room object, a windows plug, a doorway plug, and an entrance object for outside the shell.

Creating an undercover area

This awning is typical of an outside area that rain should not penetrate. In the Urban demo this was achieved using a shell.

Shells can be used to create an outside area that is sheltered from the weather.

The outside only tag in Particle Editor will prevent particles from being rendered when inside a shell.

If you create a shell with exit portals on all sides of the shell and a heavenly portal it will appear as if the shell is an outside space yet it will still prevent particles tagged with Outside only from being rendered.

IMPORTANT: The heavenly portal will allow sunlight and time of day changes to effect the insides of the shell. The location of the heavenly portal is not important, it simply acts as a switch to allow light into the entire shell or not.

This image shows the portal setup used in the shell office_exit.visual

IMPORTANT: The base of the shell must have some geometry or a custom BSP. If no bsp is used an entity will not be able to navigate through this shell.

Note the custom bsp. Without this entities would fail to navigate the shell

Outside only: lighting property

Sometimes, objects that exist on the border of exit portals (usually exit plugs, and building facades) think they belong to the inside of a shell. These objects will not light correctly and may appear dark during the day. This can be fixed by forcing an object to be lit by outside lighting only, from the Properties tab in WorldEditor.

Outside only property

Before and after setting the outside only property in WorldEditor

Referencing the room and plug texture maps

All art assets to be used in the BigWorld engine must reside in the resource folder your_game/res or one of its subdirectories. This includes bitmaps referenced by any shells or plugs you may create. If your shell or plug is referencing bitmaps from another location other than the /res directory, you must move those bitmaps into the resource folder (or one of its subfolders).

To reference the room and plug texture maps, follow the steps below:

1 Open Windows Explorer.

2 Navigate to your game's resources folder res/sets/town.

3 Under folder town, create folder shells and another folder for plugs.

Folder shells contains copies of the finished bitmaps

Folder plugs contains copies of the finished bitmaps

5 Open the 3ds Max Bitmap/Photometric Path Editor or the Asset Tracker utility.

6 Reassign the materials to the folders just created.

3ds Max utility for reassigning bitmaps

Exporting Shells

For shells to export correctly all portals must exist on a 0.1 Metre (1 standard 3ds Max unit) grid. Otherwise the shell will not comply with the exporter's visual rules.

To export "shell_room", follow the steps below:

1 Hide all plugs.

2 Hide the entrance.

3 Make sure that all portals are visible in the scene.

4 Select menu item File→Export.

5 In the File Browser dialog:

* Navigate to the new folder shells.

* In the File Name field, type "shell_room_exit".

* In the Save As Type drop-down list box, select the entry "Visual Exporter (*.Visual)".

* Click Save.

File Browser dialog

6 In the Visual Exporter dialog:

* In the Visual Type group box, select Static option button.

* Clear the Allow Scale check box.

* Check Bumpmapped if your shell is going to use normal maps. Otherwise leave it unchecked.

* Click OK.

Visual Exporter dialog

Exporting the plugs

To export the plugs, follow the steps below:

1 Centre the plugs to the origin, for proper grid snapping with the shell.

2 Hide all visible elements in the scene.

3 Unhide the "plug_windows" object.

4 Make sure that the home-grid is displayed.

5 Select the plug object and centre it to the world origin using absolute coordinates, but keep the base of the object flat on the grid.

Original plug object

Plug object centred to the origin

6 In the Hierarchy panel, under Adjust Pivot, activate the Affect Pivot Only option.

7 Centre the pivot point at the world origin.

Affect Pivot Only option

Original plug object

Plug object pivot-point-aligned to the origin

8 Select menu item File→Export....

9 In the File Browser dialog:

* Navigate to the new folder plugs.

* In the File Name field, type "plug_windows".

* In the Save As Type drop-down list box, select the entry "Visual Exporter (*.Visual)".

* Click Save.

File Browser dialog

10 In the Visual Exporter dialog:

* In the Visual Type group box, select Static option button.

* Clear the Allow Scale check box.

* Clear the Bumpmapped check box.

* Click OK.

Visual Exporter dialog

11 With the "plug_windows" object selected, select menu item File→Save Selected.

12 Save the object to its own 3ds Max file.

13 For the "plug_doorway" object:

* Repeat the process above (steps 1 to 12).

13 For the "entrance" object:

A Unhide, then select the "entrance" object.

B Edit the pivot point and offset it by 5 units in the X-axis relative.

entrance object's original pivot point

entrance object's pivot point offset

C Using absolute coordinates, centre the object to the world origin on the home-grid.

entrance object's original position

entrance object centred at the world origin

D Export the "entrance" object.

* Follow steps 8 to 10, saving the object in the same folder as the plug objects.


Create an Internal Area in WorldEditor Using Shells

  • Placing shells in the world
  • Shell snaps
  • Integrating plugs with shells
  • Creating templates and prefabs
    • Templates
    • Prefabs

1 Open WorldEditor with an existing world such as the fantasy world-space created in the lesson Setup a new project.

2 Use the Asset Browser to find your newly exported shell.

Select the Shells virtual folder and type shell_room into the dynamic search field – the browser will display your shell. If you select the shell, the path name at the bottom of the browser should read c:\<mf_root>\fantasydemo\res\sets\towns\shells.

You should now be able to see the exported shell_room_exit.model as an icon in the second white box area of the browser.

Room shell icon in the Asset Browser

Placing shells in the world

1 There are two possible ways to place a shell (or any other item for that matter) in the world using WorldEditor:

A In the Asset Browser panel, select the item that you want to place in the world, then move the mouse to the viewport, and finally press Enter; or,

B Drag the desired item from the Asset Browser panel, then drop it in the viewport.

Shells will always conform to the grid and rotational snap settings specified in the Object panel.

WorldEditor's Object panel

Shell shell_room_exit.model will appear black within WorldEditor, because no lights have been placed within the shell. (Lights will be added later.)

If the model is not displayed in the editor, then make sure that the General Options panel's Shells→Game Visibility check box is selected.

WorldEditor's General Options panel

Sometimes the terrain may intersect with the floor of the shell. To fix this, simply apply a very small amount of terrain brush to lower the terrain level slightly. Alternatively you could raise the shell itself or, as explained in the lesson Sculpt Terrain, you could remove the terrain by using the Cut option under the Mesh tab.

Terrain slightly lowered to reveal shell floor

2 Place another shell in the viewport by positioning the cursor and pressing the Enter key.

Two shells placed in the viewport

3 The portals that were exported with the shell will show up transparent blue in the viewport. This enables you to snap shells together by using the blue portals as position connectors. To auto-snap the shells – click on one shell to select it…

One shell selected

4 Using the middle mouse button, click on the other shell. The selected shell will move and rotate, to line up one of its portals with a portal on the other shell.

Result of middle click

4 With the mouse wheel, roll the wheel up a little to rotate the shell 90 degrees clockwise

5 Resolve the portals using the middle mouse click again on the other shell to snap the two together.

Selected shell in position

The two joining portals should ‘resolve’ and disappear, leaving a passageway from one shell to the other – as shown below circled in red.

Passageway created by the two resolved portals

Shell snaps

Shells can only be moved in increments defined by the shell snaps settings. The shell snap settings are defined within the WorldEditor's options.xml file, at bigworld\tools\worldeditor\options.xml.
The default settings (below) will allow you to move shells on a 0.01-metre grid and rotate them in increments of 0.1 degrees. This default setting is set to the highest fidelity possible for shells. If you customise these settings do not increase the fidelity of the snaps, for example a grid snap of (1, 1, 1)-metre is OK, whilst a setting of (0.0001,0.0001,0.0001) may cause issues.

<shellSnaps>
   <movement>  0.01 0.01 0.01 </movement>
   <angle>    0.100000                   </angle>
</shellSnaps>

Integrating plugs with shells

Plugs can be inserted between shells to provide more interesting architecture and to cover the transition from one shell to the next. To place a plug in the scene, follow the steps below:

1 In the Asset Browser panel, select the Models virtual folder.

2 Locate the desired plug by typing its name in the search field – the plug's thumbnail will be displayed in the browser.

Plug icons in the selection panel

3 Click the plug_doorway.model icon to highlight it, then place it in the scene.

Doorway plug placed in scene and out of position

4 Click the Object Tool toolbar button – [image] –, which activates the Object panel.

5 In the Object panel's Object Grid Snaps group box:

A Select the Enabled check box.

B Click the Shell Snaps button – it will set the x, y, z, and angle fields to the optimum values for shell placement.

Snaps setting changed

6 Move the doorway plug into position over the socket to cover the hole.

Doorway plug moved to the correct position

7 You can now apply this same process to the other plug models as well.

8 For the entrance model, simply place it in the scene and position it over the doorway plug on the outside of the shell.

Doorway placed

Doorway snapped into position

Creating templates and prefabs

Templates

It is best to avoid having to create a basic lighting setup every time you place a shell in the world. Templates allow you to save a basic lighting setup for each shell, which is then automatically placed with each new shell.

To create a template, follow the steps below:

1 Place a shell in the world and set it up with the basic lighting setup to be used in all future placements.

2 Select the Edit→Save Chunk as Template menu item.

This option will create a *.template file in the same directory as the shell object.

To remove the template effects in order to place empty shells, you must delete the associated *.template file.

Prefabs

The shell above contains two objects (a torch and table) and two lights (ambient and dynamic). Saving as a template will save only the lighting setup and ignore the objects.

If you want to save both lighting and object setup you must select the File→Save Selection as a Prefab menu item.

Prefabs are slightly different to templates. Firstly they save both objects and lighting setups. Secondly they do not override the existing shell objects in WorldEditor.

Once a template is created, all future placements will contain the template information. Prefabs are saved as a separate prefab. To place prefabs go to prefab tab in WorldEditor and select the prefab file.

Asset Browser panel's Prefabs virtual folder


Create Low-Polygon Characters

  • Character Orientation
  • Node/Bone Limit
  • Order of Modifiers and History
  • Orientation of nodes for use with the Head Trackers
  • Rigging the character with Biped
  • Skinning
    • Skinning the character using the Skin modifier
    • Skinning the character using Physiquer
  • Hard Points
    • Placing hard points on your character for attaching items
    • Placing hard points on your items
  • Referencing the character texture maps
  • Exporting the character

Before you begin creating your character, make sure you have read the lesson Create and Export a Static Object in 3ds Max and Maya

Character Orientation

Characters and NPC's should be modelled so that they are facing away from the Front Viewport.

So if you select Views→Front in 3ds Max, or View→Predefined bookmarks→Front in Maya, the model will be facing away from you. This setup will make more sense when the animations are created. Animations will be moving away from the front view, just as they are visualised in the game.

It is very important that you create your characters like this. It will save significant time, and minimise problems when it comes to incorporating animation into the game.

Although correct setup is highly advisable it is possible to get animations that are moving in the incorrect direction to work within the BigWorld engine. To do so, please see the section on Opposite Facing Direction .

In Maya and 3ds Max, when looking at your character from the front viewport, the character should be facing away from you.

If you are familiar with modelling in the front viewport, and find it difficult adjusting to modelling in the back view, then try re-mapping your shortcut key for front view to load up the back view.

Node/Bone Limit

The exporters have a bone count limit of 256 bones per skin modifier. Rigs can have more than this number of bones, but a single skin modifier can only use a maximum of 256 bones.

Order of Modifiers and History

The order in which modifiers (Max) and history (Maya) are applied is extremely important in getting a correct result.

Mesh modifiers should be applied first, then morph modifiers and blend shapes and finally skin modifiers.

1st: Edit poly, Edit Mesh, Xform, bend, etc.

2nd: Morpher modifier (max) Blend shapes (maya)

3rd: Skin, Physique, Skinwrap (Max) softskin (Maya)

Orientation of nodes for use with the Head Trackers

The Bigworld engine contains a simple IK system for pointing the head bone towards a certain direction.

In order for this to work correctly the bone must be correctly oriented within the 3d package in a certain orientation.

In 3ds Max, the head tracker will point the bone's positive Y (local coordinates) direction towards the tracker direction. This is the default orientation of a Biped head.

In Maya the head tracker will point the bone's negative Z (object coordinates) axis in the direction of the tracker. This cone will point in the direction of the object being tracked.

Trying to rotate a bone's orientation after it has been skinned and animated is usually problematic. Correct setup is strongly advised.

Rigging the character with Biped

In the example below Character Studio's Biped was used as a rig for the character. Using Character Studio's Biped is not a requirement; most custom rigs will work with the BigWorld engine.

For the purposes of this tutorial we will use the warrior_model.max example found in the tutorial files.

In the front viewport create a Biped inside the mesh_warrior.

Note: In 3ds Max 9.0,Bipeds are set to renderable by default. This will cause the Biped to be exported along with your character mesh. To prevent this simply deselect the Biped's renderable flag (right click - Properties).

Skinning

Skinning the character using the Skin modifier

The BigWorld engine supports 3ds Max's Skin and Physique Modifier for skinning purposes. The following is a description of how to use the Skin Modifier. We recommend the use of the Skin- rather than the Physique Modifier, due to the more robust skinning tools of the former.

BigWorld skinned shaders allow each vertex to be affected by a maximum of three bones. When you skin a vertex in 3ds Max the skin modifier will default to 20 bones influencing a single vertex. The BigWorld engine will take the top three strongest-weighted bones and normalise them, effectively ignoring the rest.

If you want to get an accurate view of how your model will look within BigWorld from within the 3ds Max viewport it is important to set the Bone Affect Limit within the Advanced Parameters of the Skin Modifier rollout to 3.

1To skin your character, select the mesh you want to skin and apply the Skin Modifier to it.

2 Select the Add Bones button to add bones to be used by the skin modifier.

3 In the example below I split the model up into head, torso, and legs. The leg mesh will only require the lower body's bones to be added to the Bone list as we do not need the upper body's bones to affect the leg movement.

4 Select the Edit Envelopes button within the Skin Modifier's parameters rollout. This will display the envelope of the bone selected within the Skin Modifier bone list.

5 Alter the envelope's field of effect by selecting and moving the dark grey control points of the envelope.

6 Individual vertex weights can be altered by manually selecting vertices.

7 Select the Vertices tick box and select the vertices that you would like to weight, then select the bone for which you want to change the vertex weights.

8 Change the Abs. Effect to alter the selected vertices' weighting.

9 Vertex weights can also be painted onto the model using the Paint Weights button.

Vertex weights can be mirrored using the skin modifier. If your model is symmetrical, then it is best to adjust the vertex weights on one side of the model and then use the mirror weights function to weight the other side of the mesh.

Skinning the character using Physique

The BigWorld engine supports 3ds Max's Skin and Physique Modifiers. We recommend the use of the Skin Modifier over the Physique Modifier as the Physique Modifier has had very few updates in the latest revisions of 3ds Max whilst the Skin Modifier is constantly refined and improved. The addition of the Skinwrap Modifier (see 3ds Max help) has made the Skin Modifier even more powerful. The following is a description of how to use the Physique Modifier.

1 Select the mesh_warrior again, and apply the Physique Modifier to it.

2 Set the Physique Modifier Skin Update to Deformable.

The BigWorld engine does not support dynamic blending for skinned meshes, nor joint intersections, bulges, tendons, and skin sliding. This option is only ticked on to allow us to select envelopes in a later part of this tutorial. It will be turned off at the end of skinning.

3 Use the Biped's Pelvis as the attachment node. Select Deformable and choose the Biped centre node.

Selecting Deformable for joint intersections, bulges, tendons and skin sliding is only temporary, allowing us to edit the physique envelopes. At the completion of skinning, this setting will be changed back to Rigid + Link Blending.

4 Set the Blending Between Links drop-down list box to 3 Links – the BigWorld engine supports only 3 bone weights per vertex.

5 Enter sub-object mode of Physique, and select all the envelopes, then change them from Dynamic (red) to Rigid (shown as green) using the Active Blending checkbox options.

Active Blending section in Physique panel.

All envelopes made rigid

6 Increase the envelopes' size slightly to make sure any stray vertices are included in the influence areas.

You can check this by going to Vertex mode and using Select by Link with the Root Vertices option (blue cross) in Vertex Type. Any unassigned vertices will show up as blue in the viewport.

Check for stray vertices

Unassigned vertices displayed in blue

7 Once all envelopes have been scaled to influence their local vertices, you can refine the associations on a per link basis.

Enter Vertex mode and use Add to Link to include selected vertices or Remove from Link to exclude selected vertices from nearby links as needed. You will need to toggle between Select and Select by Link to accomplish this successfully.

8 Now go to Select mode in the Vertex Operations and highlight all vertices in the viewport; then use Lock Assignments on them to give you access to weight blending.

9 Create a simple test animation or rotate each link to help you see how the vertices stretch and move around the joints.

Use the Type-In Weights blending feature to refine the influence of the parent and child links in order to get the best deformation.

Only locked vertices can access the Type-In Weights blending feature in Physique.

Type-In Weights dialog box in Physique

10 Follow this same process again (steps 3 to 8) for the mesh_arms object.

11When complete, it is important to reset the mesh to Rigid + Links Blending.

Note: Non-uniform scale of physique skinned bones is not supported by BigWorld.

Skinning the character in Maya

When skinning an object in Maya use the Smooth Bind skin option. To do this, select your character mesh and shift + add select the character rig, choose Skin - Bind Skin - Smooth Bind.

Because BigWorld shaders limit the influence of vertices to a maximum of three bones, you may want to set the Max influence setting to 3. This will give you a more accurate representation of the way vertex weights function within BigWorld from the Maya viewport.

Setting Max influence to 3 will more accurately represent the way skin weights function within BigWorld

Hard points

Placing hard points on your character for attaching items

Hard points are extra nodes within your skeletal hierarchy which are used in the BigWorld engine to attach interactive objects to the skeletal structure so characters can carry items on their body or in their hands.

Hard points are defined by their naming convention. If a node contains the prefix HP_, it is recognised as a hard point.

1 To create a hard point, simply create an object in your 3d package out of geometry, then link it to the object's hierarchy. It is crucial that the Hard Point is geometry-based, as other object types are not supported.

For hard points, we like to use an object that represents the x, y, and z-axes, and is textured in a bright and obvious manner. This makes aligning the object easier in your 3d package. However, the type of object you use and its texture map are unimportant – the only thing recognised by the exporter is that the node has the prefix HP_.

Hard point with pivot-point aligned

2 Name the first hard point HP_right_hand.

3 Hide Biped, and position the hard point so that it just touches the inside of the Biped R Hand in the location and orientation that would be suitable for attachment of items.

Hard point positioned at right hand

4. Now link the hard point directly to the right hand of Biped.

Hard points on characters must be linked to the skeleton

5 For additional hard points, create copies of this hard point and position them around other areas of the body. Rename them accordingly, then link them to their nearest Biped part.

Hard points are not counted towards any bone count limitations imposed by the exporter.

Placing hard points on your items

To link an object, such as a sword, to your character, both the object and the character must share a hard point with the same name. For each attachment point on the character, you will require a unique hard point. So if you wish to attach a sword to your character's right AND left hands, then you will need an HP_righthand and an HP_lefthand on both the sword, AND on the character.

The simplest way of creating a perfectly aligned hard point for an object is:

1 Merge/import the character model with all its hard points into the item's scene.

2 Position the item so that it sits perfectly in the characters hand/holster etc.

3 Make a copy of the characters hard point and link it to the item.

4 Hide, or delete the character.

5 Move the item (now with its attached HP) to the correct position for export (probably near the origin).

6 Detach the hard point (break the hierarchy), and export as Static with Nodes.

If during production an item's position when attached does not correctly align, only adjust the position of the HP on the item; do NOT alter the position of hard points on your characters as this will then affect the alignment of all the other items that will be attached to your character.

Referencing the character texture maps

All art assets to be used in the BigWorld engine must reside in the resource folder <your_game>/res or one of its subdirectories. This includes bitmaps referenced by any models you may create. If your character is referencing bitmaps from another location other than the res directory, then you must move those bitmaps into the resource folder (or one of its subfolders).

As an example we will reassign the bitmaps used on the ranger model to the res/characters/avatars/ranger folder.

1 Open Windows Explorer.

2 Create the following file structure within your game directory res/characters/avatars/ranger.

3 Copy the final texture maps from your working drive to the new ranger folder.

4 Open 3ds Max.

5 Using the Bitmap/Photometric Path Editor utility, reassign the materials to the folder used in your game.

3ds Max utility for reassigning bitmaps

Now that the bitmaps have been sourced to the res folder or one of its subdirectories, the BigWorld engine can access them.

Exporting the character

1 Make sure that Biped is in Figure Mode in the General rollout.

Figure Mode on

2 Select and hide all of the Biped structure (including the Biped Footsteps, which may be frozen) and unhide the character mesh object and ALL its linked hard points.

Character with multiple hard points

Hard points must be unhidden in the 3ds Max scene for exporting.

3 Select the File→Export… menu item, then select the (*.visual) extension from the drop down list.

Note: if you have multiple rig controller objects you may want to try selecting your character's mesh and using File→Export Selected instead. This will prevent the controller objects being exported along with your character.

BigWorld proprietary 3ds Max plug-in selected

4 Locate the resource subfolder to which you would like to export your character file (in this case use res/sets/characters/avatars/warrior), then type the name warrior in the field and click Save – this will bring up the Visual exporter dialog box.

Visual Exporter dialog box

5 Make sure the Visual type option is set to Animated, and make sure the checkboxes are cleared.

6 Click the OK button.

There will now be a warrior.visual file located in the resource structure under the warrior folder.


Create Character Movement Animations

  • Translation of the root node for animations
  • Linear movement of the root node
  • Synchronising blend transitions
    • Starting position
    • Locomotion animations
    • Turn Animation
  • Falling animations
  • Death animations
  • Animation frame rate
  • Animation range
  • Exporting character animation with BigWorld Exporter
    • Exporting animation from 3ds Max for use in the BigWorld engine
    • Exporting animation from Maya for use in the BigWorld engine
  • Opposite Facing Direction
  • Designing rigs for customisable models
    • Supermodel
    • Driving Hard Point attached items with the parent models action matcher
    • Fixing vertex normal seams
  • Reference hierarchy/custom node hierarchy
    • Using the Reference Hierarchy feature to remove unwanted controllers
    • Animating HP using a reference hierarchy
  • Adding note tracks to trigger events and sounds

Characters to be used in the BigWorld engine should be modelled and animated facing the BACK view. So, if you look at your model from the front viewport your character will be facing away from you. This applies for both 3ds Max and Maya.

It is very important that you create your characters like this. It will save significant time, and minimise problems when it comes to incorporating animation into the game.

Trying to rotate or scale a model/rig after it has been skinned and animated in the wrong direction is usually problematic. Correct setup is highly recommended.

Characters modelled facing the back view in Maya, 3ds Max and in FantasyDemo

If your modelers have problems modelling characters facing away from the front viewport, simply reverse the mapping of your front and back viewport keys.

If you have pre existing assets that are rigged to face towards the front view you can use them within the BigWorld engine by using the Opposite Facing feature of the exporter

Animations must translate the root node

The translation of the root node in 3ds Max and Maya is used to determine the playback speed of an animation as it translates in the game so as to prevent foot sliding. Without movement translation the Action Matcher will not be able to scale the playback speed of the animation to prevent foot sliding.

Characters must move when animating

Bipeds and other rigs must move off the origin for exporting – Do NOT animate in place. Do not animate foot sliding.

Do not animate on the spot

If the root node does not move, then the character will not move in the BigWorld engine.

Linear movement of the root node

In the BigWorld engine, objects derive their speed from the translation of the object's root node. Due to optimisations on the BigWorld server it is important that the root node moves at a linear rate for each animation. If non linear translations are used, discrepancies between the position of the client model and server entity will cause animation glitches or even game play problems (e.g. targeting discrepancies).

Take the following example.

Linear forward movement of the root node ensures model position matches entity position

When the root node's forward movement is not linear discrepancies between avatar and entity position occur.

This means that an object such as a biped can only have two keys for its horizontal movement: a start key frame, and an end key frame. Any number of keys is allowed for non-translational keys. For example, the root node may move side to side, and up and down.

Permissible biped centre movement – only vertical and horizontal sideways

To ensure that a 3ds Max biped is moving with linear movement, delete all the horizontal keys in between the first and last key.

Select and delete the middle Horizontal body movement keys, leaving the start and end keys remaining.

Middle horizontal keys are deleted leaving only a single beginning and end key.

This will make the biped's forward movement linear from start to finish, so that the avatar's perceived position mimics the position of the avatar on the server.

The only variable movement allowed for the biped centre between the start and finish is either vertical (Z-axis) 'bobbing' movement, or sideways horizontal (X-axis) movement for pelvic weight shifting.

The same rules apply to non-biped rigs. The root node must have a linear rate of movement from its beginning position to its end position.

This type of movement for the root node is NOT allowed. The character will clip through the ground,
and its position indicated by the model will not match that of the position of the entity on the server.

This movement is allowed for the root node. The position of the model matches that of the entity on the server.

The same goes for animations in Maya. A character's root node must move linearly along the direction of intended travel.

Just remember that the centre node must translate with linear tangents between two keys at the start and finish.

Synchronising blend transitions

Starting position

Its always best to ensure that the root node of the model is centered to the world coordinates (X=0 Y=0 in 3dsMax and X=0 Z=0 in Maya) for the first frame of most animations. This makes the task of synchronising animation blends simpler.

Locomotion animations

When an action tagged as IsMovement blends into another IsMovement tagged action the BigWorld engine will synchronise the point at which the two animations blend.

Example 1. In the image below demonstrates a 30 frame walk animation (Blue) transitioning into a 30 frame run animation (Red). The walk animation just happens to complete its entire cycle before the run animation is blended in. Such an example would have perfect blending providing the position of the feet match during both walk and run cycles.

Example 2. This transition occurs as the walk animations is half way through its cycle (frame 15). The BigWorld engine cleverly blends in the new run animation at half way through its cycle (frame 16) to maintain perfect blending.

Example 3. Even when the run animation is half the number of frames as the walk animation, the BigWorld engine maintains perfect blending by finding the half way point of the run animation (15/2 = ~8) and uses this point to blend.

The conclusion to all the above examples is that the animator only needs to follow one simple rule when creating an animations.

Ensure that each animation is a single cycle of movement, and all animation cycles that need to blend with one another should start and end at the same pose.

So if frame 1 of the walk animation starts with left foot forward, then frame 1 of the run animation should also start with left foot forward.

How to position the first frame of Idle, Walk, Jog, Run to ensure a nice blending between actions.

Turn Animations

When creating Turn_left and Turn_right animations it is best to get the initial pose from the first frame of the idle animation and duplicate it. That first frame of the Idle animation should be the first frame of the turn animation.

The last frame of the turn animation should also be the same frame as the first frame of the Idle animation with the root node turned 90 degrees. There should be no forward or backward translation of the models root node.

Model position:
Its always best to ensure that the root node of the model is centered to the world coordinates in X=0 Y=0 in 3dsMax and X=0 Z=0 in Maya.

Falling animations

When creating falling animations, do not translate the root node of your character in your modelling package. The model should remain in place and flail its arms around as if falling. The avatar model will be translated by code in-game. The corresponding action for a falling model should use the model is falling tag.

Death animations

Death animations are usually broken up into at least two sections: the death animation playing in its entirety, and a repeat of the last frame of the death animation.

Create a single animation of the character's death in your 3d package, then in ModelEditor import the animation twice into the animation tab. Name the second import something identifiable such as death:endframe.

The first animation should be set to play in its entirety.

The second animation should be set to play only the last frame of the animation.

Create two death actions, one for the entire animation and one for the repeated last frame.

Animation frame rate

We suggest using a frame rate of 30 frames per second or higher for animations to be used in the BigWorld engine.

Using a frame rate lower than 30fps does not give a visually appealing result. Remember, animations are automatically compressed by the BigWorld engine, so you are better off creating your animations at a higher frame rate and then adjusting the compression in ModelEditor.

To set frame rate in 3ds Max, open the Time Configuration dialog box via the [image] button.

In the Frame Rate group box, select the Custom option button.

Set the FPS field to 30.

To set frame rate in Maya, open the Animation Preferences dialog box via the [image] button.

Set the Playback Speed to Other, and enter 30 in the Other Speed dialog box.

Animation range

In 3ds Max the range of animation exported is defined by setting the Start Time and End Time within the Time Configuration dialog box.

For example, if you wanted to export only the animation between keys 75 and 105, you would set the following in the Animation group box:

Set Start Time to 75.

Set End Time to 105.

In Maya, the exporter will read from the Playback Start Time to the Playback End Time.

Any animation keys outside these extents will not be exported.

Only information stored from frames 1 to 10 will be exported

Exporting character animation with BigWorld Exporter

Exporting animation from 3ds Max for use in the BigWorld engine

1 Select the File→Export menu item.

2 In the dialog box that appears, select the Animation Exporter (*.ANIMATION) entry in the Save As Type drop-down list box – this will select BigWorld's proprietary 3ds Max plug-in.

3 Enter the name of the animation in the File Name field.

4 Click the Save button – this will open the Animation Exporter dialog box.

The following check boxes are available:

Allow Scale: determines whether mesh scale animations should be exported along with the animation. If you do not scale a mesh in your animation, then do NOT select this option.

Export morph animation: determines whether 3ds Max morph target and Maya blend shape animations should be exported. See the Morph Target and Blend Shape section for further information.

Export node animation: determines whether skeletal node animations should be exported.

Use reference hierarchy: determines whether another hierarchy should be used to animate the character – see below for explanation.

For a character animation such as a walk cycle:

Make sure that only the Export Node Animation check box is selected.

Click OK.

There will now be a walk.animation file located in the resource structure to which you exported the animation.

Exporting animation from Maya for use in the BigWorld engine

1 Select the File→Export All menu item.

2 In the File Type Specific Options group box's Export Type group box, select the Animation option button, then click the Export All button.

3 Specify the location in which to save your *.animation file, then click the Save button.

Opposite Facing Direction

Characters and NPCs should be modelled so that they are facing away from the front viewport. If a character has been rigged with the incorrect BigWorld setup (i.e.. facing forward) it can be fixed using the Opposite Facing Direction option within the exporter.

Let's suppose we have a character that has been rigged facing the front viewport (the incorrect way). Simply rotating this character will result in what appears to be a fix. However, when this character is implemented into the game the rotation of the root node will cause irregularities with its animations.

To correctly fix an character facing the wrong way:

1 Export the .visual using the advanced option Opposite Facing Direction;

2 Export the .animation using the advanced option Opposite Facing Direction;

The model should now face the correct direction within BigWorld and its animation data will also move in the correct direction.

Designing Rigs for customisable models

Many games require highly customisable player and NPC models. This section deals with some of the possible techniques you can use to customise your model.

Supermodel

A supermodel is a model made up of several separate model files that are all rigged to the same skeleton. A good example of this is the Female Warrior character in the Fantasy Demo. Each piece of the warrior's armour is rigged to the same skeleton that the warrior's base mesh is rigged to. The BigWorld engine simply loads both models and deforms them with the same skeleton. The image below shows the large number of separate models that can go together to make the final supermodel.

For character customisation purposes supermodel pieces are best used if the piece to be attached is meant to deform with the characters animation. If the piece being attached is static or animates in an unrelated/unsynchronised manner to the characters animation then a Hard Point attachment should probably be used.

When creating a Super Model in your 3d application simply skin multiple objects into the same skeleton and export each one individually.

Parts of a supermodel can be viewed together in Model Editor by using File - Add Model or Ctrl + drag from Asset Browser. Note this is only for preview purposes.

Driving Hard Point attached items with the parent models Action Matcher

Although Hard Points usually have static objects attached to them, it can sometimes be desirable to attach fully animating objects to the player model via Hard Points.

Items attached via Hard Points can have their actions automated "revved" via the parent models action matcher. Put simply, you can attach a model via a Hard Point and have its actions driven by the parent models action matcher.

The types of animating models best attached via Hard Points are those who's animations do not have to be synchronised with the base models animations.

For example, a pinwheel stuck in the players hat would be very suitable for an action matcher driven Hard Point attached item. Clothing, A cape, or ponytail need to be synchronised with the base models animations and would be best done using supermodel.

Several changes have to be made to the python code in order to enable action matcher driven attached objects. If you want to use this feature ensure that a programmer has made these changes.

1. Add an action matcher motor to the attached model (e.g. the staff), and set its useEntityModel property to True.
2. Set $p.model.moveAttachments to True

To see this work in Fantasy Demo (the FD scripts currently aren't setting this
up automatically), take out the staff and enter these commands into the Python:

am = BigWorld.ActionMatcher( $p )
am.useEntityModel = True
$p.model.right_hand.addMotor( am )
$p.model.moveAttachments = True
$B.debugAQ( $p.model.right_hand )

You should then see the actions being triggered on the staff as you move the character around.

Note: That if you need to scale the playback speed of a movement animation then the animation of the HardPoint attached item will also require translation in its animation. Please see the staff.model animation staff_item_locomotion_world_transform.animation as an example.

The staff.model used by the player character in FantasyDemo has its actions driven by the player model.

To view the actions on the staff model type the following into the python console (~tilde +P)

$B.debugAQ($p.model.right_hand)

Note that the staff model actions react to the players movement.

Fixing vertex normal seams

When creating a supermodel it is common to want two separate meshes to share a common boundary. When meshes are cut into separate pieces they each get their own new vertex normal which unfortunately does not match the vertex normal of the neighbouring mesh. The result is a lighting seam which can be seen in the image below along with the two newly made vertex normals

Lighting seam resulting from split mesh

Fortunately these normals can be consolidated using the Edit Normals modifier in 3dsMax or the Vertex Normal Edit tool (Lock Normals) in Maya

Vertex normals being consolidated using the Edit Normals Modifier

For 3dsMax:

Note: Editing a models vertex normals only works when the model is skinned.

1. Select both assets you wish to consolidate vertex normals

2. Give them a shared Edit Normals modifier

3. Select by Normals

4. Average the Selected normals

5. Make modifier unique

6. Ensure that each part of the model is exported separately using export selected and the model is exported with Normal mapped selected

For Maya:

1. Lock Normals neighbouring normals using the Normals > Vertex Normal Edit Tool

2. Ensure that each part of the model is exported separately using export selected and the model is exported with Normal mapped selected

Reference hierarchy/custom node hierarchy

The Reference Hierarchy option allows animators to animate a model using a different hierarchical setup to the default setup exported with the model.

For example if you decided for a specific animation it would be easier to animate the character if the root node was the hand (hanging from a tree) rather than the default root node being in the hips, then you could use the Reference Hierarchy option. Sound strange?, well this is exactly what occurs when you create an IK target for a limb. The hierarchy becomes reversed and the limb rotations are solved by the IK controller. In such a case the reference hierarchy solution is essential.

To use the reference hierarchy option:

1 The default hierarchy (hip as root) visual should be exported without any modifications to the hierarchy. This visual will be used as the reference hierarchy.

2 The 3d file should be saved as a separate backup file.

3 The 3d file is altered so that a new hierarchy exists (hand as root).

4 The model is animated with the new hierarchy (hand as root).

5 Export the animation selecting the Use reference hierarchy option. When you select the option it will bring up a dialog asking for the location of the reference hierarchy. Simply select the original visual exported in point 1.

Using the Reference Hierarchy feature to remove unwanted controllers

The aim of this example is to export animations to BigWorld without exporting unnecessary objects like animation handles & controllers which may get exported along with the rest of the skeleton. In order to achieve this, we will need to export a .visual file without the controller objects, this will be our reference hierarchy visual.

  • The example scene contains dummy /controller objects which we do not want exported when we save out a .visual file.
  • Save the original rig and in a new copy delete the controller objects within the scene that should not be included in the exporting process.

  • Save out this basic scene with just the skeleton and blendshape as a different scene.
  • Export this model File/Export All - Bigworld Asset as a .visual animated,skinned. This is our reference hierarchy model.
  • Open up the previous scene with the controller objects and go to File/Export All options and this time, export the scene as "Animation". Be sure to check "Use Reference Node".
  • A new window will pop up asking you to select the clean base scene. Browse for the .visual file you saved out previously and click " OK".
  • Load up Model Editor and load in the .visual and .animation files that you exported. if you have followed the proper steps, you should end up with a clean animated scene, without the controller objects.

Animating HP using a reference hierarchy

In a conventional rig the Hard Points of the characters hands will be children of the Hand Node.

This works perfectly and is easy to animate providing those hard points remain in exactly the same place relative to the hand (i.e. they don't move).

Problems arise if you want to animate those hard points, for example if the player throws his weapon into the air and then catches it. It becomes very difficult to animate the hard point whilst it is attached to the players hand node.

In such a case you may want to detach the hard point and animate the HP directly (or attach it to another object like the weapon and animate that object).

If a rig hierarchy is modified as above for an animation purpose, and it differs from the default rig exported with the primitive file. then the "use reference hierarchy" feature must be used.

In the case where a HP is detached from the hand and then attached to a weapon the following should be performed.

1. Export the model, visual, and primitive file with the conventional rig (HP attached to hand)

2. Export all conventional animations (HP attached to hand) as normal

3. Export all non conventional animations (HP detached from hand) using the "use reference hierarchy" feature. When prompted for a reference visual refer to the conventional .visual file exported with 1.

Adding Note tracks to trigger events and sounds

Note tracks are only supported from 3dsMax. If you use Maya please refer to the section on splitting up actions

Note tracks are a way of inserting information at specific times into animation so events like sounds and special effects can be triggered.

In order to add a note track, select the node you wish to add the track to in the 3d viewport.

Open the Graph Editors - Dope Sheet

The node you selected in the 3d Viewport should be visible.

It is essential that note tracks be added directly to a node. Note tracks added to the global scene or deep with a nodes parameters (such as its transforms or materials) will be ignored.

Once the node is selected chose Tracks - Note Track - Add

Edit the notes parameters by right clicking on the note on the dope sheet.

BigWorld will recognise the following inputs

cue:name

sound:name

Replace name with the event you wish to trigger. It is essential that no spaces or carriage return be entered after the note

For example, sound:ui/boop will trigger the sound event named "ui/boop".

When you export your animation tick the box "Export cue track"

These notes will trigger a callback which a programmer can use to set up special effects.


Add Animations to Characters

  • Importing a new character
  • Adding an animation to a model
  • Viewing the animation and altering its frame rate
  • Per-node animation blending
    • Blend bones
  • Compressing animations

Importing a new character

To export a model from 3ds Max or Maya into ModelEditor, follow the steps below:

1 Open ModelEditor.

2 Select the File→Open Model menu item, or use the Ctrl+O keyboard shortcut, to display the file browser.

3 Specify the model that was exported, then click the Open button.

Ranger model file chosen in the file browser

Alternatively, you can use the Asset Browser panel. Select the Assets tab, then enter the name of the model in the search field. Use the virtual folders to filter between things like shells, particles, and models. Once you have located your asset, double-click or drag it to the viewport.

4 The chosen model will be displayed in ModelEditor's viewport.

Ranger model in the viewport

5 You can overwrite the model's thumbnail via the Create Thumbnail ( [image]) toolbar button.

The thumbnail image is stored with the visual file in the same folder, and saved as a JPEG.

Adding an animation to a model

To add an animation to a model in ModelEditor, follow the steps below:

1 Select the Animations tab.

2 Click the [image] button.

In the example above, all animations have been added to a LOD model used by the ranger. Models can share animations by sharing a common LOD model containing those animations. For details on sharing animations via LODs, see the section Animation tree – Using LOD models to share animations.

3 In the Open dialog box, specify the desired .animation file.

Providing that the skeletal hierarchy and naming convention are the same as the hierarchy of your model, the animation should play.

Alternatively, you can add animations to a model by dragging animations from the Asset Browser to the animation window.

Dragging animations from the Asset Browser panel to the Animations panel

Viewing the animation and altering its frame rate

The controls for play and stop affect only the currently selected animation. The way the animation plays will be determined by the various other settings found in the Animations panel.

The Current Frame slider allows you to inspect the frames individually, much like the time slider in 3ds Max. There is also the Frame Rate slider, which adjusts the playing speed for the animation. Frame rate changes can be saved to the animation, so that changes are reflected within the game. To do that, click the Save Frame Rate button, then save the model.

The Loop Animation button ( [image]) plays the selected animation continuously, and is a helpful device for inspecting your animations. Please note that it does not affect how the animation is played in the game – it is only a preview feature.

You can also set the initial and final frames to include in the animation via the Include Frames fields. This is handy for determining whether frames can be cut out of the sequence.

Per-node animation blending

In the BigWorld engine, multiple animations can be blended over the top of each other and played at the same time. In order to blend animations successfully, blend values must be given to each node (bone) within the animation. Node Blend values are set within the Animations tab in ModelEditor.

Let us compare the two animations: holddrink_stand.animation and m_walk.animation, which are successfully blended in the FantasyDemo when a character walks whilst holding a cup.

As you can see from the diagram below, the important nodes in the holddrink_stand.animation are the ones in the right arm. If you did not use those nodes, then you would drop the drink. To signify the importance of these nodes, all nodes from biped R Clavicle down the right arm are given a weighting of 1.0, while the nodes in the legs (that play no part in the holddrink animation) are given a weight of 0.0.

The m_walk.animation however, requires that almost every node be given some weighting. When a character walks, nearly all bones in the body move.

Node Blending values do not effect the strength of an animation when only a single animation is being played. So if a particular node within an animation is given a Node Blending value of 0.01, then it will play exactly as it is seen in your 3D package, providing no other animation is being played at the same time. However, as soon as another animation is introduced, the node blend values of the combined animations are determined, and a blended animation will result.

A Node Blend value of 0.0 is a special case – when a node is given a blend value of 0.0 it will not animate, even if it is the only animation playing at the time.

Node Blend values for holddrink_stand.animation

Node Blend values for m_walk.animation

Not all animations can successfully be blended together to give a visually appealing result. Our artists tried, unsuccessfully, to get a Stand_Shoot_gun.animation to blend with a Run.animation, until someone pointed out that a person shooting a gun whilst running looks nothing like a person standing and shooting a gun, or a person running. In this case a new Run_withgun.animation had to be created.

The settings in the Actions panel determine which animations can play at the same time. For further information on this panel, see section Modify Animations with Actions.

Blend values greater than 1.0 can be assigned to a node to give it more weight when blending by manually entering a higher value in the blend value dialog.

Its important to recognise that strong node blend values will effect the blend in and blend out times between actions. In the diagram below a node with a strong blend weight in Action A will still be the strongest influence at the time marker [image], if blending with a significantly less weighty node.

If you are previewing a skinned object, then you will probably see a series of BlendBones listed in the Node Blending display. These are required by the engine for animating skinned objects and can be ignored by the artist.

Blend bones

In the Node Blending panel of the Animation tab you may see extra bones in your rig with the prefix "BlendBone"

Blend bones are used by the engine to handle vertices influenced by multiple bones (Soft Skinning). Each bone is converted from world space into skin space, creating a blend bone. Blend bones do not contribute to the visual splitter's 17 bone limit or the 256 bone maximum for hardware skinning so their contribution can be safely ignored.

Compressing animations

The BigWorld Engine automatically compresses animations. The animation compression facility within ModelEditor allows animators to adjust these compression settings using a visual tool that shows changes to compression in real time.

Animation compression is important as it improves game performance. It also allows animators to import animations that use more key frames and more precision.

When animations are loaded into ModelEditor they will have a default amount of compression applied to them. This compression value has been optimised to give maximum compression without visual artifacts. Up to 80% compression is performed automatically by this automated process.

Although the automatic compression has been highly optimised, we suggest going through each animation manually and adjusting the values using the visual feedback tool (described below). Nothing beats the eye of an animator. This way you might reduce the file size slightly, improving game performance.

To compress an animation, follow the steps below:

1 Open the model in ModelEditor.

2 In the Animations tab, select the desired animation to be compressed.

3 In the Compression Settings group box, click the [image] to view the real time compression.

4 Increase the compression with the sliders, and you will notice that a wire frame representation of the model maintains the 0% compression, while the shaded model displays the animation as it would appear after compression. This allows the animator to choose the appropriate level of compression. Simply play with the compression percentage until the compression is satisfactory, usually when the wire frame model is just visible under the shaded model.

Do not worry about losing animation data by using the compression facility. This compression does not write over the original animation file – all compressed animation data is written to a separate .anca file, leaving the original .animation file intact. So if you decide at a later date that 80% compression on a run animation is too much, you can easily reduce it to 70% without having to re-export your animation.

A display at the bottom of the compression rollout indicates how many keys have been compressed and the difference in file size.


Modify Animations with Actions

  • Creating actions
  • Actions' tags and tracks
    • Animation tracks
  • Blending actions
  • Player movement
  • Speed Trigger Values
  • Action order and LODs
  • Using Actions with flying entities
  • Viewing and Debugging actions
    • From Python console
    • Using Action Matcher debugger
    • Debug actions from CAT
    • Debug actions from within ModelEditor
      • How to preview blending in ModelEditor

An action contains an animation file and a set of data describing when and how that animation should be played within the BigWorld engine. The engine's Action Matcher uses the actions' descriptions to decide which animation should be played on the model.

Animation data does not drive player movement. The player entity (representation of the player's position in code) will move and the action matcher will choose an animation that most likely describes that movement.

For example, a run action will contain a run.animation file and information related to what speed the model needs to be travelling at in order to use the run animation. When originally exported from the 3d application the run.animation may have covered 10 m per second. If the action matcher was set up to match this animation when the character is running 5 m per second, the animation would play back at half the speed to avoid foot sliding.

Creating actions

To create an action, click the Actions panel's Create Action button ( [image]).

The Create Action dialog box is displayed, prompting for an action name.

Pressing OK will add your new action to the action list.

Modifications can be made to existing actions simply by altering any of the action fields.

If you need to remove an action, then select it from the list and click the Delete Action ( [image]) button.

The order in which actions appear in the action list is important (see below), and can be altered via the [image] and [image] buttons.

Actions' tags and tracks

Actions include information that help the Action Matcher select the appropriate animation to play. You need to select the appropriate settings using the check boxes in the panel. These are toggled according to the type of animation currently selected in the list.

The table below describes the fields illustrated above:

Field | Description
Looped | Required for any non-movement looping animations, such as an idle sequence. It will cause the animation to jump back to the start and repeat the sequence again continuously, until interrupted by another sequence.
Is Movement

Used for animations that move off the world origin in your 3d application, and are linked to the Action Matcher for camera translation. These include the basic movement animations (such as walk, run, side-stepping) that the player will control in the game.

In order to move an avatar using this setting, the change in transform of the root node from the beginning to end of the animation is recorded. The distance moved by the root node will be used to scale the speed of the animation as it is played back in order to prevent foot sliding.

This check box should be selected for linear animations with regular linear movement. For irregular movements, select the Is Impacting check box instead.

Is Impacting

Used when animation data should impact (change) the entity position and yaw. When a non IsMovement animation ends in the 3d application in a position or orientation that is different from the start (usually the world origin) and does not loop, the IsImpacting tag should be used.

Animation data is not stored or used by the BigWorld server, thus non linear entity movement needs to be sent to the server each frame.

The image below describes such an event where a character starting at position (1) takes a complicated path to eventually arrive at point (3). Because the path taken by the model is so complicated its necessary to send the position of the entity to the server each frame.

Note: The direction cursor (looking direction) by default, is not effected by this motion and thus a change in yaw at position 3 will probably trigger a turn animation, you may need to take control of the direction cursor to prevent this from happening.

Examples of animations that may require the Is Impacting tag: jumping over objects, turn animations, complex game object interactions, combat or knockdowns.

Is Coordinated Used for animations that do not start at the world origin in 3ds Max (e.g., interactions) and are exported from this offset position.

This is used for animations that involve a non-player character (NPC), which needs to be positioned relative to the player's character for the purpose of matching contact points. For example, take a look at the "handshake" set of animation on the Ranger model. The animations allow a player and an NPC to shake hands. The player (PA) was exported from the origin of the 3d Application whilst the NPC was exported offset from this position.

All of player B's actions will use the Is Coordinated tag, allowing the engine to use the offset position to correctly position the player character for a perfectly matched handshake.

The offset position is available to script so that models can be perfectly positioned and have their animations played back exactly as they were exported.

Track No. Animations play on tracks. Only one animation can play on a track at a time, therefore animations will override previous animations that play on the same track. Animations playing on different tracks will blend with each other using their per-node blending values defined in the animations tab.

If you want an animation to always have a unique track, then select the Own Track checkbox.
Own Track

Causes the given action to always have its own track.

An animation always on its own track always blends with other animations playing at the same time.

For more details, see Animation Tracks.

Action Panel's fields

Animation tracks

Tracks can be thought of as regions of the body. For example, the lower body might be defined as Track 1, and the upper body as Track 2. Animations involving mostly the lower body, such as walk.animation and run.animation will therefore not play at the same time. An animation involving the upper body, such as a wave.animation will play at the same time as a walk.animation.

For example, consider the diagram below:

The diagram above implies the following:

A walk animation playing on Track 1 is cancelled when a run animation that also plays on Track 1 is called (the two animations cannot play at the same time). However, there will be blending out of the walk animation and blending in of the run animation.

A walk animation playing on Track 1 will continue to play and blend with a wave animation playing on Track 2 so that the final animation will be a combination of a walk and shoot animation.

The recoil animation is set to Always on own track which ensures it exists on its own unique track. This animation will blend with any other animations, and it will not be cancelled by another animation, allowing it to play in its entirety.

Blending actions

When two animations have the same track number, the most recently played animation will cancel the previous one. The Blend In and Blend Out fields determine how many cross-over frames are used between blending from one animation to the next.

Values around 0.3 are usually ideal for most animation blends.

When blending two actions with different blend times, the blend values are normalised.

Note: Per node blending values can effect the weight of each node as it blends in and out.

Player movement

The player character's movement is controlled by a system called the Action Matcher, which receives information about the model's world position, rotation and translation and automatically selects the most appropriate animation to play.

The translation is based on the root or centre node of the skeletal structure.

Action Panel's fields for a Walk Backward Action

The table below describes the fields illustrated above:

Field | Description
Trigger | Defines the entity movements that trigger a particular action to play.
Cancel | Defines the entity movements that stop a particular action.
Speed Each animation for movement will have a Minimum and Maximum speed range assigned to it in the model file – this means that the translated distance of the centre node must fall within this range for the animation to be used.

For example, a walk cycle with a Minimum value of 1.0 and a Maximum value of 2.0 units means that the centre node will need to cover a distance anywhere between these two values for the walk to be used by the Action Matcher (e.g., 1.6 units).

Turn Defines the entity's head position in relation to the direction of the body.

Because the head follows the mouse cursor and has a certain range of freedom before the body starts to turn after it, this setting is mainly used to trigger turning animations.

For example, a turn right animation might be triggered when the head reaches a angle between -180 and -80 (see the green line in the diagram below). The turn right animation is then cancelled when the head position reaches +45 degrees (red line) relative to the direction of the body.

Model Is Falling When selected, the Trigger and Cancel group boxes' Speed, Turn and Direction values will only match if the model is also falling.

Direction

Triggers actions dependent on the translation relative to the entity's facing direction.

A walk forwards action would require values between - 90 and +90 in order to trigger the walk forward action.

A walk backwards action would require values between 94 and 266 in order to trigger the walk backwards action.

Caps On

Capabilities can be used to trigger a different set of animations during different conditions. For instance, a completely different set of animations could be used when under water or flying.

Take a look at the Ranger's staff actions. When holding the staff we wanted the Ranger to walk/run differently so we created a unique set of actions using the CAPs system. Now when the Ranger is in the HoldingStaff state it will use the CAPs ON HoldingStaff set of animations.

CAPs ON are not exclusive, which is why a CAPs off tag is required. Without CAPs OFF the action matcher would match a hold_staff_walk action to a character not holding a staff but walking.

Capabilities are defined in mf/fantasydemo/res/scripts/common/capabilities.xml. It is possible to customise this list.

Caps Off
One Shot Determines whether the animation should be played only once.

For example a turn left animation need only play once, otherwise the player will continue to turn on the spot.
Scale Playback Speed

Used in conjunction with the IsMovement tag, Scale Playback Speed determines whether the animation playback speed should be scaled as a function of the entity's speed.

For example, a walk animation in your 3d application may translate at 2 metres per second. If this field is checked, and the entity is moving at 1 metre per second, then the animation will be played at half the speed.

When an action set to IsMovment blends into another IsMovement action the BigWorld engine will synchronise the blend times.

Feet Follow Direction Determines whether the model should turn to face the direction of the entity.

Action Panel's fields

Speed Trigger Values

When deciding upon speed trigger values for your actions. it's best to have a detailed understanding of the common speeds used by your avatar or NPC.

Be on the lookout for transition jitter caused by the action matcher swapping between different actions whilst the avatar moves around the world. This will most likely occur when traveling over undulating terrain.

The following image illustrates such situation, as the avatar moves down hill the avatar speed increases. As a consequence the action matcher will match the "Run" action. When the avatar starts climbing a hill the action matcher will match for Jog.

This swapping and changing between actions can cause some transition jitter. Testing for this is quite easy, simply use the DebugAQ

A typical speed trigger value for a run action

This avatars will transition from jog to run every time it goes down hill.

Avatar with action matcher set incorrectly so as to cause transition jitter. DebugAQ used to view actions being played.

Of coarse, all this assumes you are using some kind of physics like the one implemented in FantasyDemo that alters the avatar speed with terrain gradient. If your avatar always moves at a fixed speed regardless of terrain such considerations are probably irrelevant.

Action order and LODs

Actions are tested for validity from top to bottom within the action list on the currently rendered LOD model.

In the example above, if a match was found for both ranger_walk and WalkForward, then the action called would depend on the currently rendered model. If the ranger_body was rendered, then the ranger_walk action would be triggered. If base was rendered, then WalkForward would be triggered.

If the ranger_body is currently rendered and an action is called that has no match within the ranger_body action list (TurnRight, for example), then the Action Matcher will look for a matching action in the Ranger's LOD list from top to bottom.

If multiple actions are found to match, then the Action Matcher will choose the topmost one. For example, considering the action list above, if both WalkForward and WalkForward2 were found to match, then WalkForward would be used.

Using Actions with flying entities

There are a few key differences between creating an action set for flying entities and their ground based cousins.

Flying Idle to Movement transitions

In the case of ground based entities, idle animations are typically not tagged as IsMovement. In such cases transitions from Idle to Walk are not synchronised. This is acceptable because it doesn't matter what stage of the idle animation the model is in as it transitions into the first frame of the walk animation. The case is different when we consider flying entities. A flying entity's idle animation has an inherent cycle (flapping wings). If you were to pick a random point in this idle animation and transition into a flyforward animation it is quite likely the wing cycle will not match. Solving this problem is as simple as giving the Idle action the IsMovement tag.

Idle action setting for flying entity's fields

Scale playback speed

Scaling the playback speed on a walk animation makes sense for a ground based entities as it prevents foot sliding. However, for a flying entities scaling playback speed only makes sense in one direction, as you fly faster you want to flap your wings more, but if you slow down past a certain point your wing flap animation will stop which of course looks incorrect. A simple solution to this problem is to ensure that the idle action is matched at low speeds. Note in the above diagram that the idle animation actually matches speeds ranging from 0.0 to 3.5. Also, the action is not tagged as Scale Playback Speed.

I do not have turning actions for this particular flying entity so Feet Follow Direction has been tagged, If turning actions were required it would be essential to turn this tag off.

Viewing and Debugging actions

The results of the currently selected action can be previewed, by clicking the Play button at the top of the panel.

If player animations are not working as expected, then they can be debugged within the game, either through the Python console or through the Client Access Tool (CAT).

From Python console

To access the Python console when in-game, bring up the console via the ~(tilde) + P keyboard shortcut.

To debug the player model, type BigWorld.debugAQ(BigWorld.player().model)

To debug a model targetted (looked at) by the player model type BigWorld.debugAQ(BigWorld.target().model)

This useful debugging GUI lets you see which animations are playing at a particular time, allowing you to identify the incorrect animation within the game.

In the above picture the Idle animation blends into the Turn Left animation, then back to the Idle one. In a more detailed way, the following takes place:

At position A, 100% of the Idle animation is playing.

At position B, 50% of the Idle animation is playing, and 50% of the TurnLeft animation is playing.

At position C, 100% of the TurnLeft animation is playing.

Using Action Matcher debugger

There is an Action Matcher debugger module that can be imported to help debug actions

To access the Python console when in-game, bring up the console via the ~(tilde) + P keyboard shortcut.

type

from Tests import ActionMatcher

type

ActionMatcher.test()

This debugger shows you some useful informaiton.

1. The current action

2. The model direction (red arrow)

3. The direction cursor direction (orange arrow)

4. Cancel and Trigger volumes (green and red circles in right picture)

5. Entity speed (Yellow arrow) and currently matched IsMovement speed extents (green block)

Debug actions from CAT

Alternatively, you can use the Client Access Tool (CAT).

CAT allows you to execute Python scripts from an easy-to-use GUI. It can be found in bigworld/tools/cat/cat.bat. Simply run this program after running the client (game).

In the script tree, select the Control Menu→Debug→Animation Blend Graph – this will give you access to action debugging tools for the current player, and whatever the player is targeting.

Debug actions from within ModelEditor

The Actions tab in ModelEditor can be used to directly debug actions within the tool.

It is a good idea to turn on the [image] button to show which combinations of actions are currently playing on your model.

In the picture below, the WalkForward action has just blended out to the WalkBackward action. Meanwhile, the HoldUpright action has blended with both.

There are several rules governing how the actions are played on the model. These rules simulate what occurs within the game environment, allowing you to debug the action settings. The rules are described here, with examples from FantasyDemo's Ranger character.

If an action does not contain any trigger condition, then it will play only once, unless set to looping.

Example: The Recoil action, which is called by script within the game environment.

If an action contains cancel conditions, then it will play only once.

Example: The TurnRight action, which is called by the Action Matcher and then cancelled once the cancel conditions are met.

If the One Shot check box is selected, then the action will play only once.

Example: The TurnRight action.

If the current action has the same Track No. value as the newly triggered action, then it will blend out to the new action using the values in the Blend In and Blend Out fields.

Example: The RunFoward and WalkBackward actions.

If the current action has a Track No. value different from the newly triggered action, or has the Own Track check box selected, then both actions will be played together, using the animations' per-node blending to weigh each animation.

Example: The WalkFoward and HoldUpright actions.

How to preview blending in ModelEditor

Follow the steps below:

1 Select the Actions tab.

2 Select an action in the Actions list box – the action is immediately applied to the model.

For example, select the WalkForward entry.

3 Select another action in the Actions list box – the rules defined above will determine how that action is applied to the character.

For example, select the RunForward entry – this causes the character to blend out of the WalkForward and blend into the RunFoward action.

To play an action twice, either select it again in the Actions list box or click the [image] button.

To remove all actions currently playing on the model, click the [image] button.


Create Level-of-Detail Mesh for Characters

  • Mesh LOD Theory
    • Optimising the object density
  • Material LOD Theory
  • Node LOD Theory
    • Skinning with reduced links
  • Exporting the LOD components
  • Implementing the LOD

Level of Detail (LOD) can be used on models in BigWorld to increase game performance.

The biggest improvement in performance can be achieved by decreasing the number of draw calls performed by the engine. That means replacing a model that has multiple materials with a simplified single material model as it moves away from the camera. If your highest LOD model is already using a single material, then it is probably not worth adding a LOD unless its polycount is extremely high (>3500).

The LOD process involves directly swapping more complex models with simplified versions, and is handled automatically by the game engine based on the model's distance from the camera. SuperModel, the part of the engine responsible for drawing complex models, preserves animations and tints down the LOD chain.

The BigWorld engine can benefit from material, mesh and node LOD:

Material LOD – requires the artists to reduce the number of different shaders applied to the lower LOD level models. (This is the most important LOD.)

Mesh LOD – involves the artist creating a simplified version of the model by reducing the polygon count. This should only be performed when polycount is extremely high or Material LOD is performed.

Node LOD – achieved by removing the influence of chosen nodes from the further LOD model. This should only be performed when polycount is extremely high or Material LOD is performed.

Mesh LOD Theory

A good guideline is to halve the number of polygons on each LOD level, until you reach less than a thousand polygons. Any further reductions can actually harm game performance.

This will not work for all models, but is a good place to start.

For example:

LOD | Polygon count | Distance (in metres)
0 | 7,000 | 0 - 20
1 | 3,500 | 20 - 60
2 | 1,500 | 60 - 140
3 | 750 | 140 - 300

Example LOD settings

Optimising the object density

To optimise object density, follow the steps below:

1 Load the Warrior_LOD.max example file.

2 Unhide and select the mesh_torso component from the previous lesson, then in the Modifier List, clear the Physique modifier.

Physique deactivated

3 Make a clone copy of it, called mesh_torso_LOD, then select the original mesh_torso again and activate its Physique modifier. Keep the copy in the scene and hide the original mesh.

The reason for turning off Physique first is that copying a mesh while this modifier is activated will cause parts of the mesh to collapse.

4 Delete the Physique modifier completely from the copied mesh, using the Remove Modifier From The Stack ( [image]) button.

5 Enter Sub-object mode and begin reducing the mesh detail of the copy until about one-third the polygon count of the original mesh remains.

You can do this by using the polygon editing tools in either editablepoly or editablemesh modes – by welding and collapsing vertices together, thereby simplifying the mesh detail.

You can also use the multires modifier if you are using 3ds Max 4 or later.

Reduced density in torso for LOD

As you reduce vertices, the texture mapping coordinates will adopt the new mesh form, and may look wrong when viewed up close. This is OK as long as it is not too obvious in the size at which the LOD is intended to be viewed. Otherwise you may have to readjust the mapping to fit the new shape.

Zoom the viewport out periodically as you work, to assess whether the mesh detail is obvious or not. The idea is to keep the overall shape of the object intact, especially the silhouette or profile. Remove any minor detail areas that are not noticeable when viewed from a distance.

6 Unhide the mesh_legs, and again make a copy, with the Physique modifier deactivated, and name the new copy mesh_legs_LOD.

7 Remove the Physique modifier from the copy, and in Sub-object mode, reduce the density to about one-third the original polygon count.

Reduced density in legs for LOD

8 Repeat this process again for the arms and head components, naming the copies mesh_arms_LOD and mesh_head_LOD, respectively.

Reduced density in arms for LOD

Reduced density in head for LOD

9 Depending on your requirements, you may wish to repeat the process for a number of different LOD distances. Ideally, LODs should reduce the number of polygons by half. So, a 3,000-polygon character should have 1,500-, 750-, and 300-polygon LOD versions.

Material LOD Theory

At further distances, effects of numerous complex shaders become negligible, and only serve to weigh down the performance of the engine.

It is therefore advisable to apply a reduced set of simple shaders to distant LOD models.

For example, the base LOD (LOD0) of a typical character may have three separate material types, say metal, skin and hair, with each using a different shader and referencing several texture maps (Diffuse map, Normal map, Reflection map).

At LOD3, the character may only require a single simplified shader that only references the diffuse texture, therefore increasing engine performance.

Node LOD Theory

When removing the influence of bones from your lower-polygon LOD models, it is best to remove those bones that will not be providing any visible benefit at a distance.

For example, the vertices within the fingers, which at higher LODs would be controlled by several finger nodes, can be reduced to a single hand node when viewed from a distance.

This provides a performance boost for the engine, because it no longer has to transform all those vertices when the fingers animate.

Although the lower-polygon model still uses the same animations as the parent LOD, it still provides a boost to the engine. That is because the vertices of the fingers in the child LOD are not being influenced by finger bones.

Node LOD can be taken to extremes: the furthest LOD model of a character may only be represented as ten or so pixels on the screen - at this distance, the model needs as few as three bones to convincingly reproduce the leg movement action when walking.

Skinning with reduced links

Follow the steps below:

1 Unhide all LOD meshes that you created, and save them to separate 3ds Max files along with the biped structure.

For the purpose of this lesson, it is possible to rig the character only using certain bones. In not assigning any vertices to a bone, the engine will ignore it – this is useful in conserving memory when LODing out a character.

Biped at highest LOD

Reduced links in the Biped structure for
LOD – unused bones are shown in grey

You may also wish to attach some of the segmented parts as one piece at the furthest LOD. Since you are using fewer bones to rig the mesh, more of the mesh can be incorporated into the 17-bone limit.

2

At this level of detail, you should not need to bother using the vertex weights feature for blending.

Exporting the LOD components

Follow the steps below:

1 Make sure the hard points are attached to the appropriate links on the reduced biped structure.

2 Export the model to somewhere appropriate – in this example we have chosen res/characters/avatars/torsos.

Export each component separately (with its own hard points) to the correct folders, using the prefix name lod_.

For example, name the exported mesh_torso_LOD component as lod_torso in the torso folder.

LOD components and hard points exported

Implementing the LOD

Follow the steps below (make sure you have exported all the LOD versions that are going to make up your LOD tree):

1 Open ModelEditor.

2 Use the Asset Browser to load your LOD0 model (the model to be used at closest camera distance). For demonstration purposes, we will use the torso.model made in the previous lesson.

3 In the LOD panel, select torso.model in the Model list.

4 Click the Add New LOD ( [image]) button – the Open dialog box will be displayed.

5 In the Open dialog box, select the lod_torso.model file, then click the Open button.

The new LOD lod_torso.model will then appear in the model list, and an initial Extent value of 10 will be applied to the torso.model.

6 If you drag the Camera/LOD slider back and forth, the camera distance changes, and the model swaps from torso.model to lod_torso.model.

The LOD Dist field represents the distance between the model and the game camera. The model will remain in use until the value for that model is reached, then the next LOD model is loaded. If the model is closer to the camera, a more detailed model is loaded. Similarly, if the model moves away then a less detailed model is loaded.

7 Select the torso.model entry in the Model list, then zoom the viewport out until the model is about half the size, and finally click the Use the current camera distance ( [image]) button to set the value.

Readjust the value to 50 using either the slider or the LOD Dist field.

There are many ways to adjust the minimum and maximum values of LOD models. We indicate a number of them below.

8 Now do the same for the lod_torso.model, with a value of 100.

9 In the viewport, zoom in and out. You should see the model swap from the highly-detailed version to the low LOD version.

Model swapping to less detail

When the viewport is zoomed out past the lod_torso.model's distance of 100 metres, the model disappears – this is because there are no child models below it in the model list. Because torso.model is above lod_torso.model in the model list, it is considered to be the parent LOD model. If you do not want lod_torso to disappear at 100 metres, then set the maximum distance to a higher value.

10 Save the model file for the torso, to add the LOD torso using the current distance extents.

11 Repeat this process for the legs, arms and head LOD models, starting with the high-detail versions as the parent models.


Create Animated or Interactive Entities

  • Creating animations for a door entity
    • Create multiple door animations from a single .animation file
    • Create door actions
  • Attaching a hard-point to an object

Creating animations for a door entity

Load the Cave_entrance.max and Doors_entity.max files.

Build a cave entrance doorway model for placing over the exit portal of a cave shell.

Entrance doorway model

Create two doors that will fit into the doorway and move their pivot points to the hinge positions located on the outer edges.

Doors with rotation pivots positioned

Animate the doors so that they open and shut in the 30-frame long sequence – with them fully open at frame 15.

Doors opening – frames reduced for documentation purposes

Create multiple door animations from a single .animation file

Several separate animations are required for an opening door.

* DoorClosed: A single frame looping animation where the door is closed

* DoorOpening: A multi frame animation of the door opening

* DoorOpen: A single frame looping animation where the door is open

* DoorClosing: The DoorOpening animation played in reverse.

Rather than export each animation individually from your 3d app, you can export a single DoorOpening animation and cut it into sections from within ModelEditor.

Simply drag the same DoorOpening animation into the Animation tab multiple times and ModelEditor will created multiple DoorOpening animations. These individual animations can then be split up into pieces by modifying the start and end frame

The Included Frames setting allows users to create multiple animations from a single animation file.

Create door actions

The example door entity in the Fantasy demo scripts fantasydemo\res\scripts\common\GameData\DoorData.py expects several actions with distinct naming conventions.

For doors to open inward and outward based on where the opener is
the following actions must exist:

* DoorOpeningInward
* DoorOpeningOutward
* DoorOpenInward
* DoorOpenOutward
* DoorClosingInward
* DoorClosingOutward
* DoorClosed

Otherwise, for doors that only ever open in one direction must have
the following actions:

* DoorOpening
* DoorOpen
* DoorClosing
* DoorClosed

Take a look at the fantasy demo asset fantasydemo\res\sets\temperate\props\tower_door\model\tower_door.model as an example.

Note: Your particular door implementation may differ.

Attaching a hard-point to an object

1 Load the Warrior_sword_position.max and Sword_item.max files.

2 First you need to build an object that can be used by the player character as an item to carry – in this lesson, it will be a sword.

Sword weapon item

3 To allow the player character to pick up interactive items in the game, you will need to attach hard points to them that correspond to the same hard points on the biped.

The hard point on the right hand of the biped is called HP_right_hand, and this will be where the sword attaches. Make sure this hard point exists in your warrior character file, and that it is linked to the biped R Hand.

Hard point on right hand of biped

4 In the case of the sword object, you need to establish exactly where the biped hand will grasp the item. As it is a sword, the obvious place would be the handle.

The easiest way to make sure that the hard points line up is to position the item in the hand, as though the character is already holding it (as in Warrior_sword_position.max). Merge the sword into the same scene as the warrior character, then unhide the hard points called HP_right_hand, HP_left_hand, HP_right_hip, HP_shoulder, and the biped structure.

Sword merged with the warrior character

5 Align and position (in local coordinates) the sword object to the biped right-hand position, as though it is being carried by the warrior character at the handle.

Sword in position on the right hand

6 Clone the right-hand hard point, and name it HP_sword (already done for you in Warrior_sword_position.max). Unlink this new copy from the biped right hand. HP_sword is only a temporary name used to differentiate this new hard point from the hard point attached to the biped.

Hard point cloned with a new name

7 With the first hard point already linked to the biped's right hand, you can now link the sword to the HP_sword hard point.

You should now have two separate hierarchies established – one for HP_right_hand→biped R Hand, and the other for Sword→HP_sword.

Two separate hierarchies

This linkage setup is designed so that when the biped's right hand moves, the hard point linked to it will follow. However, when the hard point for the sword is moved, the sword object follows it instead. When the right hand is positioned over the sword in the game (during a pick up animation), the two hard points will be matched based on their names, and if they are the same, they are then linked using a programmed script toggle to indicate that contact is made.

Sword follows its own hardpoint

8 For the purpose of exporting the sword at a position more suitable for world placement, start by unlinking the sword from its hard point, then linking the hard point to the sword.

9 Realign the sword to the origin in a position above the home-grid, to make it visible in the scene when exported – the hard point will follow the sword as you move into position.

Sword centred at the origin with hard-point linked)

10 Rename HP_sword to HP_right_hand.

Now you have two copies of HP_right_hand – one for the biped attached to its right hand, and one for the sword located on its handle.

11 Repeat the above process from steps 5 to 10 for the hard points HP_left_hand, HP_right_hip, and HP_shoulder, so that the sword will be positioned at the origin with all its duplicated hard points located near it.

The 3ds Max file should have two of each of the following hard points: HP_right_hand, HP_left_hand, HP_right_hip, and HP_shoulder. One set should be attached to the biped, and the other should be located near the sword.

12 Select the sword and its newly created hard points, then save them to a separate 3ds Max file.

13 Open the sword object's 3ds Max file.

14 Export both the sword and its hard points.

In the Visual Exporter dialog box, select the Visual Type group box's Static with nodes option button.

14 Save the exported sword (with texture maps properly referenced).

Under the game resource folder's sets/items structure, create the sub-folder weapons, then save the file in this new folder, with the name sword.visual.

Weapons folder created


Animate Character Interactions

  • Positioning characters for interaction with an entity (IsCoordinated)
    • Animating the contact point for attachment
    • Exporting character animation segments
    • Exporting the entity object
  • Two characters interacting (IsCoordinated and IsImpacting)
  • Animating HardPoints

Positioning characters for interaction with an entity (IsCoordinated)

Follow the steps below:

1 Load the Warrior_pull_sword.max file.

2 To construct an interactive sequence between the player character and an entity, you should create the animation with all interactive objects in the same scene.

This will help you to coordinate the animation and accurately position the character in relation to the objects.

Character and entities for interaction

In the animation above, the character is about to approach the stone and pull out the sword, then return to the exact same start position when finished.

3 With the home grid turned on, you can see the biped is offset from the origin in the default pose (in this case an idle posture).

Idle as the default pose

The idea for this is that during the game, the player will approach the entity and activate the interactive sequence when in a range close enough to trigger the animation. The character will automatically move into the correct position (before the start of this animation), then play the animation all the way through, finally returning to the offset idle position at the end of the sequence. The reason for the offset is to close the remaining distance within the animation itself, so that the player does not need to stand right over the entity in order to interact.

The action for this animation will use the Is Coordinated tag. This tag makes the offset distance available to scrip so the programmer can correctly align the player before triggering the animation.

Animating the contact point for attachment

1 Load the Warrior_pull_sword.max file.

2 Using the pull sword animation as an example, look closely at the point of contact where the hand grasps the sword.

The two hard points meet in exactly the same position. The animation for the right hand was deliberately designed this way to conform exactly to the position of the sword handle, so that the two hard points match each other at their pivot axis.

Exact position match at the hard points determines the contact point

During the game, the HP_sword at the contact point on frame 38 would be linked via script to the HP_right_hand hard point, thus allowing the sword to be pulled out of the stone and carried by the player or character.

Note that it is only linked here in 3ds Max for the purpose of demonstrating the effect. You should not actually link the entity or item to the character when exporting.

3 This method of matching the animation to existing hard points can be difficult. Another way to approach the problem of getting hard points in sync is to create the animations first, then add the hard points at the contact point afterwards. You would then need to re-export the mesh and any other animations again with the attached hard points.

4 Another hard point will also need to be created, so that the sword can be attached to the stone. The easiest way to do this is to select the existing hard point for the sword and make a cloned copy of it. Name this copy HP_stone, then link it to the stone object, which will act as a temporary anchor for the sword until the player pulls it out.

Exporting character animation segments

The animation for pulling out the sword will need to broken up into segments for exporting. There will be two animation segments exported – an approach segment and a return to idle segment.

This is done so that the programmers can determine the contact point at which the item (sword) is attached to the character (right hand) using the two hard points.

1 Hide (or delete) the stone entity and the sword item along with their hard points.

Only the biped and all its attached hard points should be visible in the scene.

2 In the Time Configuration dialog box, change the Start Time field to 0, and End Time to 38 – this will be the approach segment, with frame 38 being the contact point which then lets the game engine know when to attach the sword to the hand.

Idle position

Right hand makes contact

3 Export this segment of animation in the warrior/animations as warrior_pullsword_approach.animation. Choose Export node animation.

4 For the return to idle segment of animation, change the Start Time field to 39 and End Time to 85, then export this to the same folder as warrior_pullsword_return.animation.

Inside the game engine several events must be coordinated to create a smooth sequence in which the player pulls his sword from a stone. Here is a list of the component events.

1. The player targets the sword.

2. The Script recognises the player wants to pull the sword from the stone and uses the offset distance ( Is Coordinated) in the warrior_pullsword_approach.animation. to correctly position the character for a warrior_pullsword_approach.animation.

3. The warrior_pullsword_approach.animation is played. At the end of this animation, the player's hand has contacted the sword and the two Hard Points are perfectly matched.

4. The programmer uses the end of the warrior_pullsword_approach action to attach the sword HP_right_hand to the player character's HP_right_hand. (Remember the programmer can only time an event at the beginning or end of an action.)

5. Once the hard points are linked the game will play the warrior_pullsword_return.animation with the sword now linked to the player's hand.

Exporting the entity object

1 Load the Stone_entity.max file.

2 Before exporting, the entity object should be centred at the origin to make placement in WorldEditor easier.

To centre the stone object, select and move it to the origin with the hard point still linked to follow. Align the pivot point of the stone to the origin. The object mesh should sit naturally on the home-grid as though the grid itself was the terrain level.

Stone and hard point centred

3 Leave the hard point linked to the stone in its relative position and save both objects to a separate 3ds Max file.

4 Export this as a Static with nodes object to a new stone sub-folder, under the name stone.visual, and reference any texture maps.

Static Visual type

Stone entity folder created

Two characters interacting (IsCoordinated and IsImpacting)

In this scenario, two characters are about to interact (fight). Player A character is centered at the origin, and player B (Usually the NPC) is already offset.

Player at the origin with NPC offset

1 Load the Warrior_attack.max file.

As the animation plays, the two characters move from their original positions, and both end up offset from the origin at the end of the sequence.

Player and NPC both offset from the origin

The main point illustrated here is that a character (or animated object) can move off its original position during an interactive sequence and end up in a new position. Compare this to the previous example above using the stone and sword, where the player character returned to its original position at the end of the animation. This distinction will become important after the animation has been exported and the actions are applied – see the next step.

2 Because the player has moved in a non-linear motion from its original position to the last frame, it must have an action assigned to it in ModelEditor, with the IsImpacting check box selected. Also because it is coordinated with player B it must use the IsCoordinated tag. This option will recognise the offset in the game, and update the entity's position at the completion of the animation.

3 In summary player A is going to be using both IsCoorinated and IsImpacting. Whilst player B will use the IsImpacting tag

Animating Hard Points

Hard points can be animated. You could use an animated hard point to move a particle system source, or to animate attachments.

Here is how I would create an animation where the character throws a weapon from one hand to the other, spinning it in the air. All I will do is animate the character's HP_right_hand so that any object attached to it will follow its movement.

1 First, import both the character and its item into your 3d Application.

2 Rearrange the sword's hierarchy as shown. Now, if we move the sword's HP_right_hand, the sword will follow.

3 [image] Align the sword's HP_right_hand with the character's HP_right_hand to start the animation.

4 Animate the sword (using the swords HP_right_hand) flipping through the air and landing in the left hand. Make sure the last frame of the animation the swords HP_left_hand matches the characters HP_left_hand.

5 For every frame that the sword HP_right_hand is in the air, use align [image] to move the characters HP_right_hand to the swords HP_right_hand and set a keyframe.

6 Alternatively if animating the hard point whilst it is attached to the players hierarchy is too difficult you could use the Use Reference Hierarchy feature to temporarily break the hierarchy to make animation easier.

7 Hide or delete the sword and its HardPoints and export the characters animation. Create an action for the animation, the programmer will use the end of the action swap the swords attachment in code so that in successive animation the sword will be attached to the left hand.


Tints

  • Creating a material tint
  • Increase world variation - Using tints in WorldEditor
  • Level Of Detail LOD and Tints

Creating a material tint

Tints are an efficient way of creating multiple material variants of a single model. Tints are also the only way of making material properties accessible to game programmers. For example if you wanted to

change materials in-game,

* change texture in-game,

* alter a material property (such as a Self Illumination amount)

then you must add a tint to the material property.

Once a tint is added then the specific property you wish to change must be exposed to Python to allow programmers access to the property via code.

In the example below, we needed two types of chimneys. The one to be used in the township has a bitmap and effect file different to the second one, which is used outside the town.

This could be achieved by re-exporting a duplicate of the original model, but a more efficient way would be to create a tint from the existing model. This reduces the number of models that the game engine needs to load into memory.

Before creating a tint, you should create a material file (.mfm), which will act as the new tint. This procedure is outlined in this manual, in the section BigWorld shaders and Materials – Creating a material MFM file. The MFM will be selected later during the tint creation process.

To create a tint:

1 Open ModelEditor.

2 Load the model to which you want a tint applied.

3 In the Materials Settings panel, select the primary material (in the example below stonewall_natural_a), then click the Add Tint ( [image]) button – the New Tint dialog box will be displayed.

4 In the New Tint dialog box, specify the name for the new tint, then select the MFM option button and select the .mfm file you have created previously.

The new material (tint) will be added under the primary material. You can preview the effect by clicking the tint.

This tint is now open to game programmers to change during the game.

Increase world variation - Using tints in WorldEditor

Single models, primitives, and visual files can have multiple tint variations, allowing world builders to increase the variation of the game world without having to increase the number of models that need to be loaded.

In the example above, a chimney was created with two available materials (the default stonewall_natural_a and the tint brickChimney).

When this object is placed in the world, it will default to the stonewall_natural_a material. To use the object's tint, simply activate the Properties panel, then in the object's dye entry, select the desired tint.

Level Of Detail (LOD) and Tints

Tints are automatically maintained throughout a LOD tree.

If both the LOD0 and LOD1 models share material and tint names then the BigWorld engine will automatically chose to display the same tint on the LOD1 model that is displayed on the LOD0 model.

So if your avatar has 2 different tints (red, and blue) and it is currently set to the "red" tint then the second level LOD model will automatically display its red tint providing it has the same material name and tint name.


Texture Maps

  • Texture formats and compression settings
    • Texture detail levels - texture compression
    • Texformat - texture compression
  • Animated texture maps
    • Creating the texture animation file
    • Applying animated texture map to a material
  • Creating Cube Maps
  • Authoring textures for re sizable GUI windows

Texture formats and compression settings

BigWorld supports the following texture formats

"dds", "bmp", "tga", "jpg", "png", "hdr", "pfm", "dib", "ppm"

These formats are compressed automatically at runtime into .dds files.

TGA (targa) files are converted to the DXT3 format, all other file formats are converted to the DXT1 format.

Because DXT3 uses twice the disk space than DXT1 you should only use tga when you require an alpha channel.

Any file with the suffix _ norms or _normal will be converted to an A8R8G8B8 texture. This is to prevent compressing BigWorld's normal maps.

Texture detail levels - texture compression

The texture_detail_levels.xml file found in fantasydemo/res/maps is used to globally define the texture compression of multiple textures either by folder or by file name.

For example, if all the GUI images in your project were being over-compressed, causing undesirable visual artifacts, you could define the following within the texture_detail_levels.xml to prevent them from being compressed.

<detailLevel>
<! -- Defines the directory which compression rules should be applied -->
<prefix>gui/maps</prefix>
<! -- Files including the word "gui" -->
<contains> gui </contains>
<! -- Defines what file type should be compressed. Alternatives include tga -->
<postfix> bmp </postfix>
<! -- Defines what compression the defined file should use. Alternatives include DXT1, DXT3. DXT5 -->
<format> A8R8G8B8 </format>
<lodMode>1</lodMode>
</detailLevel>

Texformat - texture compression

Alternatively, if you find a texture is being over-compressed by the Direct X standards, then you can force it to remain 8-bits per channel (A8R8G8B8) by including a .texformat file with the same name in the same folder. (Such .texformat files can be created in any text editor, such as Notepad, for example.) It is usually a better idea to use the texture_detail_levels.xml file described above, as this can be tied in with graphics settings. However, in some cases it is easier to use a .texformat file.

So, for the following example, let's say that sky_gradient.tga was being over-compressed, resulting in compression artifacts. The file sky_gradient.texformat would then be created and added to the same folder as sky_gradient.tga, thus preventing its compression. The contents of the sky_gradient.texformat file would be the following:

<sky_gradient.texformat>
   <format> A8R8G8B8 </format>
</sky_gradient.texformat>

You can prevent mipmaps from being created entirely if you add the following tag <noResize> true </noResize> to a texformat file. In fact, this will force the engine to simply use the file provided, and not generate a .dds. This should be used sparingly.

Animated texture maps

Creating the texture animation file

To create an animated texture map, follow the steps below:

1 Create a sequence of animation frames in your preferred software. For this example we will use six frames of an electric field.

2 A text file has to be written to play the sequence.

Open a text editor like Notepad and write the following lines (which will later be saved as a .texanim file):

    <root>
       <frames>abcdef</frames>
       <fps> 30 </fps>
       <texture>texturepath/electric1.bmp</texture>
       <texture>texturepath/electric2.bmp</texture>
       <texture>texturepath/electric3.bmp</texture>
       <texture>texturepath/electric4.bmp</texture>
       <texture>texturepath/electric5.bmp</texture>
       <texture>texturepath/electric6.bmp</texture>
    </root>

The syntax of the .texanim file is described below:

The <frames> tag determines the order in which the frames will be played – in this example, six frames (a-f) in sequence.

If you wished to swap frames 2 and 5, the line would read: <frames>aecdbf</frames>.

If you wished to play frame 4 twice to draw out the animation, the line would read: <frames>abcddef</frames>

If you want to use more than twenty-six frames in a texanim, you can leave out the frames section and the textures will be played back in the order they are defined in the .texanim file.

The <fps> tag determines how fast the animation will be played – in this example, thirty frames per second.

The texture tag determines the file to be played – the files have to be numbered and written in sequence.

The texture path should be relative to the resources path. For details on how to set up your texture paths, see the lesson Manage Resources.

When saving the file, name it the same as the first frame in the sequence (but with a .texanim extension) within the same folder as the frames – in this example, it would be electric1.texanim within folder texturepath.

Applying animated texture map to a material

To apply an animated texture map to a material, follow the steps below:

1 Open ModelEditor.

2 Load the model to which you want to assign an animated texture.

3 In the Material Settings panel, select the material that you want to change.

4 In the Properties table, select the Diffuse Map row, then click the Browse ( ) button next to it – the Open dialog box will be displayed.

5 In the Open dialog box, navigate to the folder where the animated texture file is (in our example <res>/texturepath), then specify the file name (in our example, electric1.texanim).

6 The selected animated material can be previewed in a variety of stand-in objects.

To preview it in such a away, select the Preview check box, and choose an item in its drop-down list.

7 Save the modified model.

Creating Cube Maps

A cube map is composed of six separate images which combine to create a 360 degree panorama. Cube maps are generally used in Bigworld for environment reflection purposes. Cube Maps allow you to do " fake reflections " versus the more processor intensive " raytraced " reflections. Cube maps can be applied to the reflection map channel of BigWorld shaders.

Creating a Cube Map:

Make 6 screen shots of the environment around you ( e.g.. Top, Bottom, Left, Right, etc ). It would be best to have the images tile together to form a seamless panorama.

There are many 3rd party tools available that make this a task a piece of cake.

Use an image editing program to ensure that the images are square and to the power of 2 (ie. 256, 512, 1024 etc ).

Download CubeMapGen by ATI. ( http://www.ati.com/developer/cubemapgen/index.html ). This is a great little software that makes creating Cube Maps easy. Below is a quick tutorial on how to create simple Cube Maps.

0 Select the "Skybox" checkbox so you can see your cube map faces in the background as they're loaded.

1 In the green section on the right, set "Select Cube Face" to +Y (the up direction). Select the "Load CubeMap Face" button.

From your set of 6 images, choose the image that's in the up direction.

2 Set "Select Cube Face" to -Y (the down direction). Hit the "Load CubeMap Face" button. Select the image that's in the down direction.

3 Set "Select Cube Face" to +Z (the forward direction). Hit the "Load CubeMap Face" button. Select the image that's in the forward direction.

4 Set "Select Cube Face" to -Z (the back direction). Hit the "Load CubeMap Face" button. Select the image that's in the back direction.

5 Set "Select Cube Face" to +X (the right direction). Hit the "Load CubeMap Face" button. Select the image that's in the right direction.

6 Set "Select Cube Face" to -X (the left direction). Hit the "Load CubeMap Face" button. Select the image that's in the left direction.

7 Now that all six of your panels are loaded, switch the "Display CubeMap" drop-down to "Output".

The sphere in the center will turn black because you haven't generated any output yet.

8 Hit the "Filter Cubemap" button toward the bottom.

CubemapGen will work for a few seconds and then your sphere will display the filtered version of your cubemap.

9 To save out your cube map, Hit "Save CubeMap (.dds)" toward the top and give your cube map a name.

You can now load the resulting .DDS file into an FX shader as a cube map in Model Editor.

Authoring textures for re sizable GUI windows

When creating textures for re sizable GUI windows it's important to follow a few rules so as to decrease the number of draw calls. The two textures below are for the "GUI.Frame2" GUI components (the python code framework for creating GUI in BigWorld). This Frame2 is a re sizable window frame for GUIs such as tool tips, chat window etc.

Example texture, used to create re sizable GUI window.

The resulting GUI window

Frame2 draws the entire gui component 1 draw call. To do this, the elements of the frame need to be packed into one .tga file in a specific way

The first texture is a debugging bitmap, which demonstrate how to author the file (frame2_example_source), the second texture is the resulting window (frame2_example.bmp).

The coloured dashes indicate 2 things
1. Which side of the frame's edges are which (this is especially for the bottom
half of the source image) - you can see therefore that the four edges go top,
bottom, right, left
2. How the tiling occurs. You can see the corners are displayed only once, and
the edges are tiled to produce the correct sized frame.

The final piece of this puzzle is the background of the frame, this is tiled
from a single pixel at uv (0.5, 0.125). Note the white dot at the top of the first image.

The original source files in their correct formats can be found in the Bigworld/doc/tools_tutorial_examples/helper_maps/example_GUI_textures/


Create and Apply Terrain Texture Maps

  • Painting the terrain
  • Using masks to texture the terrain
    • Using imported masks to rapidly texture terrain
  • Terrain texture management
  • Terrain texture projection
  • Terrain texture tiling
  • Specular lighting on terrain
    • Adjusting terrain specular properties via watchers
  • Terrain texture material type
  • Cloud shadows
  • Creating terrain textures
    • Removing small frequency tiling
    • Removing large frequency tiling

Depending on the style and look of the area you would like to create in your world, you should consider the types of terrain textures that you would like, and how they might best work together. For example, if you are creating a grass-covered plane, you might like to have two types of grass, and something to offset this grass into paths – dirt, for example, which might clear away into rocks, etc.

Painting the terrain

To paint the terrain, follow the steps below:

1 Open WorldEditor.

2 Click the Terrain Texture Tool toolbar button ( [image]) or use the shortcut key 2 .

3 Select the Asset Browser panel.

4 Select the Textures virtual folder.

5 In the file list, double click the desired texture – it will be automatically displayed in the Terrain Texturing panel's Active Texture group box.
You can also drag the texture onto the active texture slot from the Asset Browser.

6 Adjust the brush settings before painting the terrain.

The Size field determines the diameter of the terrain paint brush. It can be changed by typing a new value, by moving the slider with the mouse, or via the [ (left square bracket) and ] (right square bracket) shortcuts (which decrease and increase the value, respectively).

The Strength field defines the "flow of ink" onto the terrain. A high setting will cause the terrain to quickly adopt the texture you are painting. The strength can also be changed by typing or by using the slider, but has a different keyboard shortcut: Shift+[ (left square bracket) and Shift+] (right square bracket) to decrease and increase the value, respectively.

The Opacity sets a maximum percentage at which the current texture will be applied to the terrain. This field can also be changed by typing or by using the slider.

7 Drag the mouse over the terrain to paint it with the active texture.

The Sample Texture feature (indicated by the [image] icon) is activated by the Alt keyboard shortcut, and chooses the strongest texture under the cursor, making it the active one (automatically updating the Active Texture group box's panel).

Alternatively you can right click on the terrain whilst in terrain-painting mode, and choose Select Texture for Painting. This will give you access to all the textures underneath the cursor.

There is also an option to Select Texture and Opacity for Painting

Alternatively, you can right click the Chunk Textures panel to select a texture for painting.

Using masks to texture the terrain

Just as with masks in Photoshop, you can use a number of masks to select or deselect areas of the terrain you wish to paint. When using multiple masks they multiply together to mask out the terrain.

All masks can be previewed actively on the terrain whilst painting by ticking the Show Overlay tick box. The mask will be displayed as a red area (masked off). In the example below a height mask was used to enable editing between the heights 250m and 300m.

Masks can be saved as brushes to be used at a later date

Once saved they will appear in the Asset Browser under the Brushes filter folder

The available masks include:

Height: selects a minimum and maximum height for which terrain painting is allowed. (Fuz adds a blur around the borders of this selection.)

Slope: selects a minimum and maximum slope for which terrain painting is allowed. (Fuz adds a blur around the borders of this selection.)

Texture: selects a texture currently on the terrain to be used as a mask. This selection is handy for replacing one texture with another. You can also use the invert texture mask to invert the selection.

The Include Projection setting will exclusively mask areas with both the same texture and projection. Both of these settings can be chosen by right clicking on the terrain.

Alternatively, you can right click the Chunk Textures panel to select a texture for use as a mask.

Noise: generates a perlin noise used as a mask on the terrain. The [image] button accesses a noise generation window which allows the user to alter the noise parameters.

Imported: allows the user to import a greyscale texture to be used as a mask over the terrain.

Third party tools like World Machine can create terrain texturing masks which, when used in combination with imported height masks give rapid and realistic results.

There are several example masks in fantasydemo\example_terrain_textures. The following section uses them to demonstrate the power of using imported height masks.

The [image] button will bring up a top down view of the entire space and allow the user to adjust the position of the imported mask. The interface acts similarly to the terrain height map interface. Supported formats include .r16, *.raw, *.bmp, terragen *.ter, DTED2 *.dt2.

An entire space can be flooded by using the [image]. Be warned, this can take a significantly long time to do for extremely large spaces and will sometimes have to flush the undo buffer (you will be warned by a confirm prompt in such situations).

Using imported masks to rapidly texture terrain

Firstly a new space is created with a default grass texture map.

A heightmap is imported, creating mountains in minutes.

A texture mask is imported which describes all the cliff face areas and a rock texture is placed in those areas.

A texture mask is imported which describes all the areas that have eroded and a dirt texture is placed in those areas. The height and slope mask settings are used to map the parts of the terrain where fallen snow would rest, and a snow texture is placed on the mountains.

This whole process took only minutes. The masks were generated from World Machine in under an hour.

To edit .R16 files in photoshop ( photoshop CS2 & above will be required ):

- Choose File Menu - Open As

- Select .RAW format

- Follow the settings below, then click OK. Now you can edit the file in photoshop!

Terrain texture management

The BigWorld terrain engine allows the artist to paint an unlimited number of textures on the ground in any area. However, users should show some restraint – the more textures painted, the more memory used and the more draw calls performed. Therefore, it is crucial that all terrain texturing is done with an informed understanding of the texture management tools.

The first thing that must be understood is the concept of chunks. The terrain is divided into 100 x 100m segments called chunks.

Chunks can be visualised in WorldEditor by pressing the Chunk Visualisation toolbar buttons.

Each chunk can support an unlimited number of different textures and projections. However, the number of draw calls performed to draw the terrain is a function of the number of texture layers divided by four. So if you have 1,2,3, or 4 textures on a single chunk the graphics card will be able to draw that chunk in a single draw call, but as soon as you add one more texture, you are adding another draw call.

Number of textures per chunk | Number of draw calls
1,2,3,4 | 1
5,6,7,8 | 2
9, 10, 11, 12 | 3

It is therefore useful to browse around the space with the Chunk Texture panel open and the track cursor option selected.

When you come across a chunk that is using 5, 9, or 13 textures, removing a single texture from that chunk will decrease the number of draw calls by one.

To manage the number of textures per chunk, follow the steps below:

1 Open WorldEditor.

2 Click the Terrain Texture Tool toolbar button ( [image]).

3 Activate the Chunk Textures panel – on the viewport, right-click the terrain, and in the context menu, select the Manage Textures menu item.

The Chunk Textures panel can also be activated by selecting the View→Show Chunk Textures Panel menu item.

The texture management tool allows you to view those chunks that exceed a given number of textures (specified in the Maximum Textures Per Chunk Warning field.) If the [image] button next to the field is pressed, then a red border will be placed around those chunks that contain more than the specified number of textures, and the text Too many textures will be printed on the problem chunks.

4 To reduce the number of textures in a chunk, right-click the texture that you wish to remove, and in the context menu, select the Remove Texture menu item.

You can also merge multiple textures. To do this, hold down the control key and consecutively select multiple textures from the Chunk Texture panel. The last texture you choose should be the texture and projection you want to merge to. In the case below, the grass (1) and leaf (2) texture will be collapsed to the dark rock texture (3). Note the harder red boundary around texture 3: this indicates the last selected texture. Now right click on the last selected texture and choose Merge Textures.

Alternatively, you can paint over the texture that you want removed with other existing textures – the automatic texture management system will remove a texture if its contribution to the chunk falls below a certain point. To do this, select the strongest texture under the cursor, using the Sample Texture feature (activated by the Alt keyboard shortcut and indicated by the [image] icon). Paint over the problem texture until it is no longer visible. If you have sufficiently covered the problem texture, then it should automatically disappear from the Chunk Textures panel.

You can replace one texture with another by dragging a texture from the Asset Browser onto one of the textures in the Chunk Textures panel.

Another way of limiting the number of textures per chunk is to use the Automatic Layer Limit function.

With this option ON, the texture tools will never paint more than the specified number of textures per chunk. Once the chunk limit is reached, adding a new texture will automatically replace the least contributing texture in that chunk. This option defaults to a maximum of 4 textures per chunk when using BigWorld's simple terrain.

Terrain texture projection

It is possible to project textures from any angle, just as you would a planar projection in 3dsMax or Maya. In the example below, the rock texture has been projected from two different angles: on the left it was projected from above, resulting in a stretched texture, whereas in the image on the right it was projected sideways onto the side of the hill, thus removing any texture stretching.

There are two ways to alter the projection of a terrain texture that has not yet been applied to the terrain.

Alter Terrain Texturing, Active Texture panel's projection Yaw, Pitch, Roll and UV fields.

Use the Alt + Shift + Left Click key combination to select a projection from the terrain normal.

If the texture whose projection you wish to alter is already applied to the terrain, you must use the edit projection button [image].

This will bring up a gizmo on the terrain which will allow you to alter the projection and scaling of the current texture. Alternatively, you can use the projection and scale sliders in the active texture panel.

Warning: Each newly projected angle creates a new texture layer. Too many terrain layers will impair the engine's performance. Try to limit the use of different projections to instances where it is really necessary.

The example chunk above is using the same grass.tga texture, projected at five different angles – the result is five texture layers being used. Each new texture layer is another draw call, which results in increased memory usage (due to the mask information).

Terrain texture tiling

In the example below, the same path.tga texture has been applied to the terrain with five different texture scales.

There are two ways to alter the terrain texture scale:

Alter Terrain Texturing panel's Active Texture group box's U and V fields.

Use the Terrain Projection gizmo (activated by the Shift keyboard shortcut).

Warning: Each newly resized texture adds another texture layer, even if the same texture is resized multiple times per chunk. Therefore, be careful when painting texture to only change texture scale when absolutely necessary.

Specular lighting on terrain

The terrain exhibits specular lighting. The colour of this specular light is a combination of the terrain diffuse colour and the colour of the sunlight.

The contribution of each can be adjusted using the terrain watcher specular diffuse amount (see below).

The terrain texture has to be a .tga file – this is because the specular strength is determined by the alpha map, which cannot be specified in .bmp files.

White areas in the alpha map generate bright specular highlight, while black areas generate none.

The terrain texture in the example below has specular highlights on the smooth surfaces of the cracked mud, but none within the cracks.

Colour information

Alpha information

Specular lighting applied to texture

Adjusting terrain specular properties via watchers

In World Editor you can access controls or "watchers" that describe the terrain specularity, via the Debug (Watcher) console (for details on this and other tools consoles, see the document Content Tools Reference Guide, chapter Tools Consoles).

To change the value of a watcher, follow the steps below:

1 Open WorldEditor.

2 Press control + F7 to open the Debug (Watcher) console.

3 Navigate to the [Render] item (either by using the Page Up and Page Down keyboard shortcuts, or by typing its list number – in this case, 4), then press Enter – this will navigate one level down in the watcher tree.

3 Navigate to the [Terrain2] item, then press Enter.

4 Navigate to the desired watcher, then press Enter to enter Edit mode, where you can change its value. The watcher's specular fresnel constant, specular fresnel falloff, specular multiplier and specular power will affect the terrain's specular appearance.

Some of the different effects you can get using the terrain specular watchers.

These effects are not permanently applied to the terrain – they are only preview features. If you want them to be permanently applied to the terrain, then the code needs to be updated with the values that gave you the best result in this exercise.

Terrain texture material type

Each object in BigWorld has a material kind. Material kinds can also be assigned to each terrain texture. This allows you to script different sounds, effects, etc depending on what terrain texture is being interacted with.

Terrain texture material kinds are defined in bigworld/res/system/data/material_kinds.xml

<kind>
        <id>	9	</id>
        <desc>	Snow	</desc>
        <sound> snow    </sound>
        <help> Hard crunchy snow. </help>
        <sfx>	sets/global/fx/sfx/sfx_pchang_snow.xml </sfx>
        <terrain> sets/t_ice/maps/terrain/ice_snow </terrain>
        <terrain> sets/t_ice/maps/terrain/ice_snow_pure </terrain>
        <terrain> sets/t_ice/maps/terrain/ice_snow_pure02 </terrain>
        <terrain> sets/t_ice/maps/terrain/snow_grass </terrain>
        <terrain> maps/landscape/ls2_snow01 </terrain>
        <terrain> maps/landscape/minspec_snow </terrain>
        <terrain> maps/landscape/minspec_mud </terrain>
</kind>

Cloud shadows

Clouds dynamically cast shadow on the terrain and outdoor objects. This is done automatically, and is calculated from the actual clouds in the world.

World shadowed by clouds

Creating terrain textures

Removing small frequency tiling

A good terrain texture must tile in all directions. If it is to be used over large areas, be careful that it does not look visibly and unnaturally repetitive.

Depending on your preference, you can either paint it by hand in Photoshop, or use photo reference. In this tutorial, we will use a digital photo to create a rock terrain texture.

Next, we will make this photo in a tileable texture. In Photoshop, resize the image to something square in dimension (e.g., 512x512).

Use Photoshop's Offset filter to create a tileable texture. Set Horizontal and Vertical fields to 256 (exactly half of the original texture size), and select Undefined Areas group box's Wrap Around option button.

To create a texture that is tileable in all directions, use the Clone tool to hide the edge transitions.

Below is the finished texture. After using the Clone tool, it looks seamless, and is ready to be placed on your terrain.

Save your texture into folder res/maps/landscape, then create other terrain textures for this landscape, such as grass, dirt etc.

Removing large frequency tiling

Sometimes larger differences in the texture can be seen when the texture is tiled and viewed from a distance. To remove these larger frequency repetitions, try using Photoshop's High Pass filter, or follow these instructions to mimic the effects of a high pass filter.

The Offset filter is used to remove small scale repetition, as outlined above.

Original texture

Offset filter applied

Clone tool and brushes cover up edges

A preview render (3ds Max) of the reworked texture tiled and viewed from a distance shows the large scale frequency visible in the texture.

Preview of texture tiled 8x8. Note the repetitive frequency

To remove this visible repetition, you can simulate the effects of a High Pass filter:

1 Create a backup save of your de-seamed texture.

2 Create a duplicate of the texture on a new layer.

3 Invert the top layer by selecting the Image→Adjustments→Invert menu item.

4 Use Gaussian blur to blur the inverted layer by selecting the Filter→Blur→Gaussian blur menu item.

Try to match the amount of blur to the large scale frequency that you are trying to remove.

The amount of blur is the most important part of this process. As you adjust it, watch the preview window. Common blur radii range from 10 to 60 pixels.

5 Use the overlay layer method to blend the inverted layer with the original one.

If the effect is too strong, then reduce the opacity of the inverted/blurred layer.

This overlay method has now removed most of the large scale frequency repetition. You can see the results in the tiled preview rendered in 3ds Max.

Unfortunately one side-effect of this method is that it pushes all colours to mid-grey (R=128,G=128,B=128). To compensate for this de-saturation, you should increase the saturation and play with the colour balance. The final tiled product is free of most of its large-scale tiling.


Change Environmental Settings

  • Overview
  • Night sky dome
  • Day sky dome
    • Sky gradient map
    • Fog Colour
  • Static sky boxes
    • Static Sky box shaders
    • Create a Static Sky Dome Model
  • Dynamic sky boxes (Weather)
    • Dynamic "weather" Sky box shaders
    • Create a Dynamic SkyDome Model
    • Painting Maps for the cloud_layer Effect Sky domes
  • Weather system special effects and particle systems
  • Bloom
  • Space environment options
    • Changing hour length and start time
    • Sun and Moon angle
    • Sun Flare
    • Time of day
    • Ambient and Sun Light
    • Atmospheric effects
    • Changing far plane settings
  • Pre 1.9 Clouds

Each world space has a space.settings file, which can be found in the folder where the space's chunk data is stored. The space.settings file for the main space in Fantasy Demo is located in fantasydemo/res/spaces/highlands. This file references the sky.xml file, which controls all environmental variables discussed below. The sky.xml file for FantasyDemo is located in fantasydemo/res/environments/sky.xml.

Each space.settings file can point to a different sky_spacename.xml file. Therefore, you can make a different sky.xml file for each space, which allows different environment effects per space. The desert's space.settings file, for example, points to desert_sky.xml, which changes the environmental effects to use a different colour sky.

Many of the properties outlined in sky.xml file can be modified in WorldEditor's Environment Options panel, and are described in the sections below.

Overview

Sky box layers

The diagram above shows the multiple sky boxes available within the BigWorld Engine

1. Night Sky dome

2. Day Sky dome (Sky Gradient map)

3. Static Sky Boxes

4. Dynamic Sky Boxes (Weather Systems)

Night Sky dome

The fx_skydome.model displays the stars at night. It is located in the bigworld/res/system/models, and uses the texture bigworld/res/system/maps/star.bmp. Its material properties are described in bigworld/res/system/materials/sky_dome.mfm

This sky dome is displayed behind all other sky domes.

Day Sky dome

In front of the night sky dome is a day sky dome. This sky dome is textured with the skygradient map

Sky gradient map

The sky gradient map determines the colour of the sky as the time of day changes. A single vertical line of pixels is chosen from the sky gradient map, depending on the time of day. The colour from these pixels is then stretched across the entire sky.

The image size of a sky gradient map should be 64 pixels wide and 256 pixels high.

The sky gradient map is referenced by the sky.xml file, and can be chosen on a per-space basis in WorldEditor's Environment Options panel.

At night the alpha in a sky gradient map is used to fade out the skygradient colour as nightfall sets in, allowing you to see the night sky dome behind it. Therefore, a skygradient texture must be saved as a 32-bit TGA file. To prevent sky gradient maps from being compressed to the DXT3 format, an associated .texformat file is required (for details, see lesson Texture Maps, section Texformat - Defining texture compression settings).

Note in the image below the increase to black as nightfall sets in. This allows the player to see the night sky dome behind the skygradient colour.

Below are three examples of sky gradient textures.

Example sky gradient textures

The relationship of the texture colours in the gradient to the actual sky colour can be seen in the example below. The bottom of the texture represents the horizon leading upwards to the centre of the sky dome, exactly where the sun would appear around midday.

In the example below, you can see what can be achieved by making quick changes to the sky gradient texture. You can also see the effect of the alpha channel, allowing the stars on the night sky dome to show through the evening.

Fog Colour

The fog colour is determined by the time of day and colour of the bottom line of pixels in the sky colour gradient texture. The texture is read from left (morning) to right (night), as illustrated below.

Static Sky Boxes

Static Sky boxes will completely obscure both the night and day sky domes. They are generally used when you want to define a non dynamic sky, or a ring of mountains/building around the player.

You can add a sky box to the world through the Environment Options panel in WorldEditor. Simply click the Sky Bitmaps And Gradients group box's Add button, and specify the .visual file representing the sky box. If no skybox is used the Day Sky Box will be visible.

Sky boxes defined in this section of the environments tab can be thought of as non changing fixtures to the world. For example a non changing hand painted sky, a ring of mountains, or a sister planet in the sky.

The grayed out Weather Systems entry within the sky box window allows you to decide if your static sky boxes are to be drawn in front or behind the weather systems by moving them above or below the Weather Systems entry. A mountain ring for example would need to be drawn in front of the weather systems (The clouds do not obscure the mountains), whilst a large planet in the sky is definitely going to be obscured by weather systems.

There are several types of effect files that can be used with a sky dome, all of them are located in bigworld/res/shaders/environment. These effects can be applied to your sky domes from within Model Editor and are described in the following section.

Weather Systems are described below

Static Sky box shaders

The static sky box shaders include:

sky_box.fx This is a static sky box which should be used for spaces that do not need a dynamic time of day. – see the example sky box fantasydemo/res/sets/temperate/props/skybox.visual. in the fantasy demo desert space. This type of sky box will generally be used to cover the entire sky. Using the static day sky dome is not recommended in conjunction with a dynamically changing time of day, because the illustrated light direction within the sky dome will not match the dynamic sun light source, and the same sky dome is used both during day and night.

sky_box_alpha.fx This is also a static sky box, it can however be used with a dynamic time of day as it has the option of receiving time of day lighting. This sky box effect also uses the diffuse map alpha to define transparency which allows the sky behind the dome to be seen. This sky box can be used to simulate a distant mountain range, or city scape. By setting the material property - Sunlight Response to 0.0 the sky box can be used to simulate astral objects in the sky, like a sister planet or space station. See the example skybox_alpha fantasydemo/res/sets/t_ice/props/skybox_withmount.visual in the fantasy demo arctic space.

Create a Static Sky Dome Model

What Shape?:

When using the sky_box.fx or sky_box_alpha.fx the shape of a sky box can differ significantly, with some tricky mapping a cube can be used (there are many third party applications that may help you create a cube sky dome). Alternatively you could use a sphere or cylinder (especially for mountain rings). To get an idea of what your sky box might look like from your 3d application position the camera at the world origin (0,0,0 coordinates). The sky box should surround the camera, ensure that the faces of the sky box geometry are pointing in towards the camera.

How big?:

Objects using the above sky box effect shaders are drawn first in the scene, this ensures that the sky box will be behind every other scene object giving it a distant appearance. The shader also ensures that the sky box position is fixed to the camera. This simulates the lack of parallax movement that occurs with very distant objects.

When creating a sky box in your 3d application, the size of the sky box doesn't matter. A 10meter X 10 meter sky box will appear the same as 1km X 1km sky box because of the way it is rendered and its position relative to the camera.

Dynamic Sky Boxes (Weather)

Of all the sky domes, Weather sky domes are usually drawn closest to the player.

Weather in BigWorld is a combination of multiple effects including, Dynamic Sky boxes, Particle Systems, alteration to Sun and Ambient colour and alteration to Fog Colour and Fog Distance.

Weather systems can be created and modified from the Weather tab in WorldEditor. Changes made in this tab are saved in the weather.xml file located in C:\mf\fantasydemo\res\scripts\data\weather.xml

Here is an example of the Snow weather system in the Weather Systems Tab and its related data in the weather.xml file.

Weather Tab

<Snow>
   <sky box> system/models/storm_overhead.model </sky box>
   <sky box> system/models/horizon_ring_storm.model </sky box>
   <sun>  1.0 1.4 1.8 1.0 </sun>
   <ambient> 1.1 1.1 1.1 1.0 </ambient>
   <fog> 0.8 0.8 1.0 2.0 </fog>
   <temperature> -5.0 </temperature>
   <sfx> sfx/snow.xml </sfx>
   <windSpeed>	5.0 0 </windSpeed>
   <windGustiness>	1.0 </windGustiness>
   <exclude>	spaces/desert	</exclude>
   <bloom>
       <attenuation>	1.010000 0.990000 0.980000 1.005	</attenuation>
    <numPasses>	10	</numPasses>
    <power>	8.000000	</power>
    <width>	2	</width>
   </bloom>
</snow>

The first window (1) contains all the available weather systems. You can chose which weather systems should play in a chosen space by ticking the box next to each weather system. In the example above, the Blizzard weather system will not appear in the space being edited.

Selecting a weather system will cause it to be previewed in the space.

Ensure that sky boxes are set to visible from the General Options tab, otherwise you will not be able to preview the weather systems.

Once a weather system is selected, the Sky Boxes window (2) will display the dynamic weather sky boxes used in the selected weather system. Multiple sky boxes are used in the Rainy example above. The weather system sky box material properties can be edited within ModelEditor.

Apart from the sky boxes, each weather system has associated with it a number of properties which can be edited in the Properties window (3).

Special Effect File: <sfx> The special effects file to be associated with the weather system allows you to associate particle systems and other effects with the weather system.

Rain Amount: <rain> Determines the amount of rain associated with the weather system.

Sun: <sun> Defines the sun RGB colour and sun multiplier

Ambient: <ambient> Each weather system have its own unique ambient colour RGB and ambient multiplier

Fog: <fog> RGB value of fog colour, followed by a multiplier on the Fog (farplane) distance higher numbers bring the fog plane closer to the camera

Sky Box Fog Response: <fogFactor> Determines how much of the fog colour is inherited by the skydome

Wind Speed: <windSpeed> Wind speed in the X and Z world coordinates in meters per second. Wind speed can reach a maximum of 15.

Wind Gustiness: <windGustiness> This value adds noise to the wind speed to simulate gusting wind.

Temperature: <temperature> Each weather system have its own unique temperature which can be used in script to call other events. e.g. the Ranger character breaths fog when the temperature drops

Bloom Settings: <bloom> The Bloom parameters are described here

Weather systems can be triggered from the chat console (enter) by typing "/weather SystemName" where the SystemName is replaced by any of the weather systems listed in the weather.xml file.

Examples screen shots of the same position with different weather systems

Dynamic "weather" Sky box shaders

The dynamic weather sky boxes include:

cloud_layer.fx Is designed to work with a dynamic time of day. The cloud_layer shader uses the Diffuse map alpha to determine the rims of clouds and subsequently light them. The Rim and Scattering parameters offer fine control of how this cloud rim lighting is applied.

dual_cloud_layer.fx Works the same as the cloud_layer.fx except it has a second layer to allow the appearance of higher and lower cloud layers.

Shader model compatibility

Shader model 2 cards and higher can use the dual_cloud_layer.fx with simulated light scattering

Shader model 1 cards can use the single layer cloud_layer.fx with simulated light scattering

Fixed function cards can use the dual_cloud_layer.fx without simulated light scattering

The parameters defining the cloud_layer.fx and dual_cloud_layer.fx can be altered from within Model Editors material tab.

When tweaking cloud_layer material properties ensure that the Lighting Setup is using Game Lighting, otherwise the position of the directional light that represents the sun will be offset from the actual sun position.

Diffuse Map: Defines the colour (RGB) and Opacity of the cloud layer

Fog Map: Determines the amount of fogging applied to the skydome. White areas receive more fog than dark areas. This is useful for fading off the skydome as it approaches the horizon.

Rim Power: This factor determines how far away from the sun the cloud rim lighting effect will occur. Higher numbers will cause only clouds close to the sun to be effected by rim lighting, lower numbers will cause clouds further away to be effected.

Rim Detect Power: This determines how quickly the rim lighting fades away. Higher values result in quicker falloff, lower values fade away slowly.

Rim Detect Width: When a cloud rim is detected the Rim Detect Width will offset the point at which the Rim Detect Power begins to fade the rim lighting.

Rim Strength: This factor scales the combined effect of the above rim parameters. Allowing you to dial down/up the rim power as a whole.

Scattering Strength: Adds white to the general area around the sun, it does not take into consideration the cloud rims. Higher numbers cause a larger area to receive the scattering effect.

Scattering Power: Determines the falloff of Scattering Strength, it does not take into consideration the cloud rims. Higher values result in quicker falloff, lower values fade away slowly.

Wind Speed: Determines the UV scrolling speed of the sky box Diffuse map. Use this to simulate wind moving the clouds across the sky. The wind direction is provided in-game, this wind speed value scales the amount of the effect.

Texture Tile: Determines the UV tiling and UV offset of the skydome Diffuse map.

Sun Flare Occlusion: The alpha value of the diffuse map is also used to occlude the sun flare. When the sun goes behind an area of the sky box containing alpha above the Sun Flare Occlusion value, the sun flare will not be rendered.

Parallax: Adds a small amount of parallax to the sky box position. This helps reduce "sky box stuck to camera effect" as the player increases altitude.

Multiple sky boxes can be used simultaneously. Simply add them sequentially to the Sky Model And Gradient group box's Sky Model: list box. The sky boxes will be rendered in order, from top to the bottom of the list. The order of the sky boxes can be changed via the [image] and [image] buttons. So if you want your mountain box in front of your sky box the sky box should be at the top of the list.

Ensure that the static sky option is ticked within World Editor's options tab, otherwise the sky box will not be shown.

Create a Dynamic SkyDome Model

What Shape?:

The cloud_layer.fx and dual_cloud_layer.fx shaders are intended for weather system sky boxes. There are two types used in the Fantasy Demo, an Overhead cloud layer and a Horizon ring cloud. The 3dsMax models used to create these layers are Included in bigworld/doc/tools_tutorial_examples/working_files/sky box/example_dual_layer_skybox.max.

The fantasy demo highlands space uses two different sky boxes clear_overhead.visual and horizon_ring_cloud.visual. The clear_overhead.visual is a plane that stretches off into the distance. The horizon_ring.visual is a topless cylinder. If you open either of these assets in Model Editor and apply a light only shader to them you will be able to view them as they were created in 3dsMax.

How big?:

Objects using the above sky box effect shaders are drawn first in the scene, this ensures that the sky box will be behind every other scene object giving it a distant appearance. The shader also ensures that the sky box position is fixed to the camera. This simulates the lack of parallax movement that occurs with very distant objects.

When creating a sky box in your 3d application, the size of the sky box doesn't matter. A 10meter X 10 meter sky box will appear the same as 1km X 1km sky box because of the way it is rendered and its position relative to the camera.

Painting Maps for the cloud_layer Effect Sky domes

Take a look at the following maps used on the sky domes in the fantasy demo highlands space.

mf\bigworld\res\system\maps\cumulus_horizondark_cloud.tga

mf\bigworld\res\system\maps\cumulus_overhead_cloud.tga

These skydome maps were created by stitching a series of photographs together, pay close attention to the white rim that surrounds each of the clouds. This white rim helps reduce the blue that can creep in from sky in the bitmap.

I used Photoshop's dodge tool to create the white rim around the clouds. Alternatively you could de saturate the area around the cloud rim.

A section of the cumulus_horizondark_cloud.tga showing the white cloud borders and its associated alpha.

Weather system special effects and particle systems

The Special Effect File <sfx> entry defines a special effect file which enables the user to associate a number of special effects with a weather system. In the <snow> example below a particle system called snow_flakes.xml is attached to the player model.

<snow>
   <Actor> particles
       <ParticleSystem> sparticles/snow_flakes.xml </ParticleSystem>
   </Actor>

   <Joint> particles
       <DummyModel/>
   </Joint>

   <Event> particles
    <ForceParticle/>
   </Event>

   <Event> particles
    <RampTimeTriggeredParticles>
        <fadeTime>	2.0	</fadeTime>
    </RampTimeTriggeredParticles>
   </Event>
</snow.xml>

To create the density of particles needed for a weather system most particle systems use the wrap barrier which moves a particle from one side of the barrier to the other when it collides with the barrier edge.

A particle created at position 1. will hit the barrier at position 2 where it is teleported to position 3. This ensures that the density of particles remains high around the player.

If this system was not used a fast moving player would run past the particles before they had a chance to spawn.

Weather particle systems can be restricted to only render outside by setting the outside only parameter of the sink component to true.

Bloom

The BigWorld engine simulates the blooming that occurs when looking at strong light sources by overlaying a blurred image of the screen that has been through a power function

The artist has control of these bloom parameters per weather system from the WorldEditor weather panel or may choose to edit the weather.xml file located in C:\mf\fantasydemo\res\scripts\data\weather.xml.

Here is an example of the Snow weather system from the weather.xml file.

<Snow>
   <sky box> system/models/storm_overhead.model </sky box>
   <sky box> system/models/horizon_ring_storm.model </sky box>
   <sun>  1.0 1.4 1.8 1.0 </sun>
   <ambient> 1.1 1.1 1.1 1.0 </ambient>
   <fog> 0.8 0.8 1.0 2.0 </fog>
   <temperature> -5.0 </temperature>
   <sfx> sfx/snow.xml </sfx>
   <windSpeed>	5.0 0 </windSpeed>
   <windGustiness>	1.0 </windGustiness>
   <exclude>	spaces/desert	</exclude>
   <bloom>
           <attenuation>	1.010000 0.990000 0.980000 1.005	</attenuation>
        <numPasses>	10	</numPasses>
        <power>	8.000000	</power>
        <width>	2	</width>
   </bloom>
</snow>

Attenuation: <attenuation> Defines the colour change applied to the bloom filter R, G, B and a multiplier value.

Num Passes: <numPasses> Defines the number of times the bloom filter is blurred before being applied to the screen

Sensitivity: <power> Chooses a brightness value, above which the bloom will be applied. Small values indicate higher sensitivity.

Filter Width: <width Offsets the each pass of the bloom filter

Bloom parameters can also be defined within the C:\mf\fantasydemo\res\scripts\data\bloom.xml file. This has been done in the example below, where the Standard bloom parameters are defined in the bloom.xml file.

<Cloudy4>
   <sky box> system/models/overhead04.model </sky box>
   <sky box> system/models/horizon_ring_cloud.model </sky box>
   <windSpeed>	1.0 0 </windSpeed>
   <windGustiness>	1.0 </windGustiness>
   <bloom> Standard   </bloom>
</snow>

Space environment settings

Changing hour length and start time

The start time (for WorldEditor only) and the speed at which time passes within the game can be altered per space.

Sun and Moon angle

The angle of the sun and the moon in the sky can be altered. You may want to drop the angle of the sun to simulate a more polar or winter environment, for example.

Sun Flare

Instructions on how to customise the sun flare can be found here

Time of day

The time of day can be altered in WorldEditor, but only as a preview feature, and does not affect the time of the day within the game.

Ambient and Sun Light

Both the colour and value of the sun and ambient lights can be animated throughout the course of the day. Keys can be created and removed, and the colour of each key can be altered.

These animation keys are stored as in the sky.xml file's <lightkey> tag for the chosen space.

Atmospheric effects

The environment settings are editable per space from within WorldEditor. You can also edit the sky's configuration file ( fantasydemo/res/environments/sky.xml for FantasyDemo, for example).

The fields for environment settings are explained below:

MIE Amount - Amount of scattering applied to light as it travels through the atmosphere.

Turbidity Offset - Amount of suspended particulate matter (proportionally affects MIE scattering effect).

Turbidity Factor - Defines how MIE scattering responds to increases in the global fog amount.

Vertex Effect - Vertex height contribution to MIE scattering (the vertex effect gives the scattering an elongated shape at the horizon).

Sun Height Effect - Sun height contribution to MIE scattering (the sun height effect decreases the overall amount of the effect when the sun is high in the sky, i.e., noon).

Power - Mathematical power of the MIE scattering effect (it makes the effect looks less like a flat shaded circle, and more like a circular gradient with emphasis being put on white nearer the sun).

Changing far plane settings

To change the far plane setting, you have two options: set a per-sky far plane, or set a per-space far plane.

Set a per-sky far plane – Set the farPlane tag in the sky configuration file specified in your space.settings file (for example, the desert space uses the desertsky.xml file).

Set a per-space far plane – Set the farPlane tag in the space's space.settings configuration file – this will apply only to the given space, and will override any such setting in the sky file.

The far plane should be a floating-point value and, for the best results, should be between roughly 200.0 and 1500.0 meters.

Pre 1.9 Clouds

Before BigWorld 1.9 a much simpler cloud system was used. These clouds are defined in bigworld/res/resources.xml – this file points at the two bitmaps to be used for the cloud textures.

The clouds are represented by two planes, each with its own unique texture map:

The lower plane uses cloud_loom_brood.tga to simulate the part of the cloud in shadow.

* The higher plane uses cloud_edges.tga to simulate the higher part of the cloud that is lit by the sun.

The excerpt below displays the relevant tags in bigworld/res/resources.xml:

   <cloudEdgesBmpName> system/maps/cloud_edges.tga      </cloudEdgesBmpName>
   <cloudBodyBmpName>  system/maps/cloud_loom_brood.tga </cloudBodyBmpName>

Clouds can only be set per game, i.e., all clouds in all spaces must be the same – they cannot be set per space. To use your own clouds, either overwrite the existing bitmaps, or point the <cloudEdgesBmpName> and <cloudBodyBmpName> tags to your own maps.

You can preview the clouds in FantasyDemo by accessing the client watchers (via the ~(tilde) + F7 keyboard shortcut), or through the client access tool CAT.

Weather can also be adjusted in WorldEditor, so that the clouds are visible by using the Weather Preview panel.

1-For more details, see Client Programming Guide, section Debugging, Watchers.

2-For more details, see Client Programming Guide, section Debugging, Client Access Tool (CAT).

3-For more details, see Content Tools Reference Guide, section WorldEditor, Panel Summary, Weather Preview Panel.


Add Lights to the World

  • Lighting Environments
    • Indoor Lighting
    • Outdoor Lighting
  • Light types
    • True lights
    • Image-based lights (flares)
  • Light properties
  • Light placement
  • Visualising lighting contribution
  • Placing ambient lights
  • Placing lights
  • Adjusting the colour
  • Adding coronas and streaks
  • Adding spotlights
  • Creating and editing flares

Lighting Environments

There are two types of lighting environments within the BigWorld engine:

Indoor lighting

Outdoor lighting

Indoor Lighting

Indoor lighting only applies to objects within shells, it is a more highly customisable lighting setup than outdoors lighting.

Heavenly portals allow sunlight in: Because heavenly portals allow sunlight into shells, objects within shells that have a heavenly portal will be affected by both indoor and outdoor lighting. To get a completely indoor effect, your shell must not contain a heavenly portal.

Vertex-based indoor lighting: Because the BigWorld static lighting is vertex-based, it is important to design your shells to include enough vertices for sufficient shadow and lighting precision. For more details on how to create shells for optimised lighting, please see lessons Create an Internal Shell in 3ds Max and Best Practices.

Outdoor Lighting

There are two options for outdoor lighting. You can choose a lighting type from within World Editor.

Option 1 (Default)

Outdoor lighting consists of two lights:

Ambient lighting

The sun (directional light)

Four Dynamic and two Specular lights per outdoor chunk

This option gives you a dynamic time of day. The sun rises and sets, shadows lengthen in the afternoon. The dynamic time of day comes at a trade off, you cannot have static lights in the out

An example of a fantasy demo space that uses this option is fantasydemo/res/spaces/highlands, and fantasydemo/res/spaces/min_spec

Option 2 (Unsupported)

Removes dynamic time of day lighting and allows you to add static lights to the outdoor world.

Outdoor lighting consists of two lights:

Ambient lighting

Unlimited Static Lights

Four Dynamic and two Specular lights per outdoor chunk

It is essentially similar to converting your outdoor environment into one giant indoor space.

An example of a fantasy demo space that uses this option is fantasydemo/res/spaces/urban.

Note: indoor (shell) lighting is identical between both options.

Light types

There are five true light types in BigWorld Technology, and two image-based lights types.

True lights

Ambient – Each indoor chunk can have a single ambient light. This type of light has no direction, and simulates the background light intensity.

Omni – Spherical lights with a decreasing area of effect along an outer radius.

Spot – Conical lights, such as a flashlight.

Directional – Lights whose rays do not diverge. Consequently there is no option to add further directional lights in WorldEditor

Pulse – An Omni light whose multiplier and position are animated. It is a true dynamic and specular light source. The light's multiplier animation is defined and editable from within the properties tab.

The first number defines a time and the second a multiplier. So in the image below at 1.2 seconds the light is only 41% as bright as its default value.

The light's positional animation is defined in the animation property. The animation file is of a Hard Point named "HP_light", the light will be attached to this hard point and animate accordingly.

Image-based lights (flares)

Image-based lights (or flares) do not actually emit light – they are special effect objects that mimic the effects of lights. There are two types of image-based lights:

Coronas – Coronas are a spin to face additive texture. Useful for glow effects, such as the tips of candles.

Streak – Streaks consist of two components: a spin to face streak, and a lens flare. These lights look good when place on extremely bright light sources.

A blue corona

A streak effect

You can create your own flares – for details, see Creating and editing flares

Light properties

Each of the true light types can be a combination of the following properties:

Static lights: Apply to static indoor scene objects only.

In particular, they contribute to the 'static lighting' values, and thus only work on indoor shells and their models. Static lights do not light up the character or other dynamic objects (i.e., entities ).

Static lighting is vertex-based. You may have any number of static lights, since their contribution is calculated offline.

Static lighting only occurs within shells, there is no static lighting outdoors.

Specular lights: Apply to objects that have materials with specular maps – this includes dynamic objects (like the character), and static ones.

There can only be two specular lights per shell.

Note: Spotlights cannot be specular only.

Dynamic lights: Apply to dynamic objects (like the character) and outdoor objects.

There can be up to 8 dynamic lights affecting any object – the engine will choose the closest 8 ones to illuminate it. Therefore, while there is nothing stopping you from having more than 8 lights in a shell, only 8 of them will affect each object.

Note: All objects outdoors are considered dynamic objects. If you use an outdoor light it must be set to dynamic.

Light placement

When placing more than 8 dynamic lights in a particular area, you should test for pops in the lighting as the engine chooses a different set of lights to illuminate the dynamic object.

To avoid these pops, follow the guidelines below:

Reduce the number of lights.

Reduce the intensity of individual lights.

Make sure that each light has a falloff, so that by the time the object moves away from it, its contribution to illumination is minimal.

The 8-light limit may be any combination of:

Up to 4 Omni lights

Up to 2 Spot lights

Up to 2 Directionals

The diagram below illustrates the following:

How to illuminate a shell to avoid light 'popping' – at no point in the shell do more than 8 dynamic lights overlap.

How to ensure that the player avatar will receive specular from within every position of the shell.

When the light limit is reached the BigWorld engine will take into consideration both proximity and light radius when it removes the influence of a light from an object.

Note: The objects bounding box is used to calculate its distance from a light source.

Visualising lighting contribution

WorldEditor allows you to visualize which dynamic lights are contributing to a models lighting. Select a model then Right click - Visualise dynamic light contribution.

Yellow lines indicate active lighting contribution.

Grey lines indicate lights that are within range but not used for lighting contribution (due to light limit restrictions)

Lights can be forced to contribute to a scene by changing their Light Priority setting in the lights property tab in World editor

Placing ambient lights

Ambient lights are used inside shells to illuminate the scene with a minimum uniform intensity. Ambient lighting will modulate a models surface colour, so an ambient light value of 64 will cause a pure white model to be displayed at a value of 64 on screen. (64/256)*256 = 64.

To place an ambient light within a shell, first place a shell in the world – when a shell is initially placed, it has no lighting.

Choose object placement mode to make placing the light more simple – this is configured in Object panel's Locking Mode group box.

Move inside the shell, then add the ambient light. To do that, follow the steps below:

1 Select the Asset Browser panel's Lights virtual folder.

2 In the file list, select the desired ambient light.

3 Place the light in the shell.

This can be done by dragging the file from the Asset Browser panel's file list, or by moving the placement cursor icon in the desired location in the viewport and pressing Enter.

Ambient light placed within shell

Shell with computed ambient light

4 The ambient light is represented by a small white diamond, which positions itself in the centre of the shell.

Because ambient lights have no directionality, you cannot move its light source.

Ambient light placed in the shell

5 In the Properties panel, select the ChunkAmbientLight item entry's Colour property, and adjust it to the desired value.

Placing lights

This section illustrates how to place a light model in the world (in this case, the one in the omni_static_and_dynamic.xml file).

1 In the Object panel's Object Grip Snaps group box, select the Enabled check box.

2 In the Asset Browser panel, select the Lights virtual folder, then in the file list, select the omni_static_and_dynamic.xml asset.

3 Place the light in the world.

This can be done by dragging the file from the Asset Browser panel's file list, or by moving the placement cursor icon in the desired location in the viewport and pressing Enter.

The light model, after being placed

4 Adjust the light's inner radius and outer radius.

The light has a default inner radius of 1.0, and a default outer radius of 12.0. These properties can be changed in two different ways:

Via the Properties panel – manually change the inner radius and outer radius properties.

Via the Scale gizmo (activated by the Alt keyboard shortcut) – drag the green circle in the gizmo to change the inner radius, or drag the blue one to change the outer radius.

Scale gizmo

Light, placed inside shell, being resized

Adjusting the colour

The light's colour can be changed in the Properties panel's Colour property in 3 different way:

By typing the RGB+Alpha value.

By clicking the [image] button then selecting a new value in the Color dialog box.

By expanding the property (via the [image] button) then changing the value of the Red, Green, or Blue field.

Changing the light colour in the Properties panel

Light with different colour, and its effect in the world

You can use copy-and-paste to set multiple lights with the same colour.

The light also has the Multiplier field, which sets the intensity (brightness) of the light, without affecting its hue.

Difference between a Multiplier set at 0.5 (left) and Multiplier set at 2.5 (right)

If you want to change the Colour or the Multiplier property of multiple lights, then select them and change the property to the desired value.

Omni and spot lights also have the properties Static, Dynamic, and Specular, which can be turned on or off. Setting the Static property to False changes the light's model to an inverse pyramid.

Model of a light with the Static property set to False

Adding coronas and streaks

Coronas and streaks are used only for representing or simulating sources of light, such as a candle flame or a neon bulb. Or in the case of a streak, a large powerful flood light of some sort. They cast no light themselves and are used purely for effect.

A before-and-after shot of a light source using a corona

Coronas have a default colour value of #3E50CA, and like normal lights they too can have their colour value changed to match that of the light source they are representing. This is found in the Properties panel.

A before-and-after shot of a large light source using a streak

Adding spotlights

As the name suggests, spotlights only light the spot to which they are pointed. They have no inner or outer radius, only an angle radius which will dictate how large the lights diameter is.

To place a spotlight:

1 Select the Asset Browser panel.

2 Select the Lights virtual folder.

3 In the asset list, select the spot.xml file.

4 Place the light in the world, either by dragging the file from the Asset Browser panel then dropping it in the desired location in the viewport, or by moving the mouse to the desired location in the viewport then pressing Enter.

The spotlight model

5 Configure the spotlight's area of influence (i.e., its inner radius and outer radius properties – you can do that in 2 different ways:

In the Properties panel, manually change the inner radius and outer radius properties.

-or-

Using the Scale gizmo (activated by the Alt keyboard shortcut), use the green circle to adjust the inner radius, and the blue circle to adjust the outer radius.

The spotlight's Scale gizmo (green circle adjust inner radius,
blue circle adjust outer radius, yellow circle adjusts cone angle

6 Change the cone's angle – you can do that in 3 different ways:

In the Properties panel, manually change the cone angle property.

-or-

Using the Scale gizmo (activated by the Alt keyboard shortcut), use the yellow circle to adjust the cone angle.

-or-

Using the Rotation gizmo (activated by the Shift keyboard shortcut), use the yellow circle to adjust the cone angle.

The cone angle can be adjusted via the yellow circle

7 Point the light to the desired location.

Unlike all other lights, spotlights can be rotated to point in different directions. To rotate a spotlight, use the Rotation gizmo (activated by the Shift keyboard shortcut), and drag the axis on which to rotate the light.

Rotating a spotlight

Spotlights also have the colour and multiplier properties, which work as described in the previous session of this lesson.

Creating and editing flares

Flares are additive images placed in front of light sources, usually used to simulate lens effects or to amplify the intensity of a light. The sun flare used in the fantasy demo can be found in bigworld\res\system\data

The sun flare (fx_sun.xml) shown below is a multi-stage flare. When the source of the flare becomes obscured, a different stage flare is used – this simulates the streaking that occurs as a light source becomes obscured.

When creating your own flare, start by modifying one of the existing flares. You will also require a programmer to add the flare to the world.

The following is a breakdown of fx_sun.xml (see notes below):

<root>
   <maxDistance> 1000000 </maxDistance> A
   <area>        75      </area>        B
   <fadeSpeed>   0.1      </fadeSpeed>  C
   <Flare>
      <occlusionLevel> 0.5                        </occlusionLevel> D
      <type>           materials/fx/sun_flare.mfm </type>           E
      <size>           1.0                        </size>           F
      <secondaries> G
         <Flare>
            <type>    materials/fx/secondary.mfm </type>
            <size>    0.1                        </size>
            <depth>   0.3                        </depth> H
            <rgba>    255 128 0 48               </rgba>  I
         </Flare>
         <Flare>
            <type>    materials/fx/secondary.mfm </type>
            <size>    0.2                        </size>
            <depth>   0.2                        </depth>
            <rgba>    255 0 0 32                 </rgba>
         </Flare>
         <Flare>
            <type>    materials/fx/corona.mfm    </type>
            <size>    0.1                        </size>
            <depth>   -0.1                       </depth>
            <rgba>    255 255 0 32               </rgba>
         </Flare>
         <Flare>
            <type>    materials/fx/secondary.mfm </type>
            <size>    0.05                       </size>
            <depth>   -0.4                       </depth>
            <rgba>    128 255 0 32               </rgba>
         </Flare>
      </secondaries>
   </Flare>
   <Flare> J
      <occlusionLevel> 0.1                        </occlusionLevel>
      <type>           materials/fx/sun_split.mfm </type>
      <size>           1.0                        </size>
      <rgba>           255 255 255 128            </rgba>
   </Flare>
</root>

A maxDistance is the distance beyond which the flare will not be seen.

B area determines how large the visibility test is. This area is used when calculating the flares occlusion, and represents the size of the flare source in number of pixels on screen.

C fadeSpeed is a multiplier that effects how slow the flares fade in/out. Larger numbers result in slower fade in/out speeds.

D occlusionLevel is the minimum percentage of the flare that needs to visible in order for this stage of the flare to appear in the world – this sets the percentage of flare visible needed to use the next flare stage.

E type is the material file used to describe the flare. Alternatively the effect file and bitmap can be directly defined, eliminating the need for an MFM.

F size scales the given material.

G secondaries specifies the multiple images that make up a single flare. These images are splayed outward from the initial flare source towards the centre of the camera. This simulates the effect of light passing through a camera lens.

H depth specifies the distance from the primary flare to the secondary flare.

I rgba specifies the colour values of the flare.

J This is the flare that will be seen through the trees. The engine automatically uses a new flare stage when the light source is partially obstructed. If it is fully obstructed, no flare will be shown. The point at which the next flare stage is rendered is controlled by how much of the flare remains visible, as determined by the occlusionLevel setting (see note D).


Build and Use Normal Maps

  • Normal maps in the BigWorld engine
    • Channel direction
    • BigWorld uses Tangent space normals.
  • Naming conventions
  • Normal mapping hints and tips
    • Visualising the normal map contribution
    • "Flat Blue"
  • Which application to use
  • Normal map creation methods
    • Zbrush-generated normal maps
    • 3ds Max/Maya-generated normal maps
      • Building the high-polygon model
      • Building the low-polygon model
        • UV-unwrapping the low-polygon mesh
      • Generating normal maps within 3ds Max
      • Generating normal maps with Maya 8.0
    • ATI Normal Mapper-generated normal maps
    • Texture-generated normal maps
    • Combining mesh- and texture-generated normal maps
    • Renormalising a normal map

Normal maps in the BigWorld engine

Channel direction

Normal maps are a 2-dimensional representation of a 3-dimensional model. Different engines handle normal maps in different ways. The BigWorld engine represents normals using the following rules.

The normal map below represents a cube coming out of a plane – the internal blue square is sticking out of the page towards you; the green side is pointing up, and the red side is pointing to the right.

Complete colours

Red channel X

Green channel Y

Blue channel Z

Different normal-mapping applications may have these channels inverted. It is recommended that you test the application that you plan to use, and adjust your normal maps appropriately.

We have tested a number of applications and found the following:

The ATI NormalMapper tool produces normal maps as displayed above, and can therefore be used directly in the BigWorld engine without alteration.

The NVIDIA nvTools Photoshop plug-in produces normal maps with the Y (green) component inverted (see below for instructions on how to use these maps).

Zbrush produces normal maps with the Y (green) component inverted. You can invert the green channel before exporting, by selecting the Preferences→Import/export→Normal map flip Y (Green) menu item.

If you are using the Zbrush plug-in Zmapper, then use the ATI_TangentSpace_BestQuality.zmp within the configuration menu.

Maya's Surface Sample produces normal maps as displayed above, and can therefore be used directly in the BigWorld engine without alteration.

We still recommend testing the normal maps that you create using any of the above methods, as different versions may have different results.

BigWorld uses Tangent space normals.

The BigWorld engine uses Tangent space normal maps – it does NOT use World Space's.

Tangent space normal maps are on average a flat blue colour with values R=128, G=128, B=255

World Space normal maps are easily identified by their rainbow colour, and are not used in the BigWorld Engine.

Naming conventions

The BigWorld engine automatically converts all textures into compressed .dds format. When normal maps are compressed, they produce visible artifacts, and for this reason they are compressed differently from other textures.

The BigWorld engine recognises a texture as a normal map if it is named with the suffix _norms or _normals (for example, dungeon_wall_norms.bmp). Such textures remain free of compression artifact.

Warning: If you do not use the suffix _norms or _normals, then the normal maps will be over-compressed, resulting in visual artifact

Normal mapping hints and tips

Visualising the normal map contribution

Sometimes, a normal map will add very little to the visual contribution of an object. It is always best to visualise the contribution of a normal map on an object without the interference of other maps. This will help you identify problems with the map, and decide if a normal map is really required.

To preview the effect of a normal map alone, simply apply a mid-grey diffuse map to your model within ModelEditor.

"Flat Blue"

Flat Blue is the colour R=128, G=128, B=256, and represents a flat surface normal. A flat blue normal map means there is no difference in angle from the low-polygon model to the high-polygon model. Flat blue can be useful for removing normal mapping seams. If you are experiencing a lighting seam due to normal maps, paint in a little flat blue along the problem line.

Before and after fixing the forehead lighting seam
by painting in "Flat Blue" along the UV seam.

The background colour of all normal maps should be set to "Flat Blue", to avoid mipmap sampling errors.

Which application to use

There are many applications available for creating normal maps – they can be divided into two categories.

Mesh-based normal maps

Mesh-based normal maps use a low- and high-polygon model to generate a normal map. Typically, rays are cast from the low-polygon model, and the intersecting angle at which they pass through the high-polygon model determines the colour value of the normal map.

Mesh-based normal maps tend to be better for creating macro detail that is easily modelled into the high-polygon model – the exception is Zbrush and Mudbox, which allow for intricate details to be modelled quickly.

Some mesh-based normal mapping programs include:

3dsMax Render to texture technique

Maya 6.5 Transfer Surface Information technique

Kaldera

ATI Normal mapper

Zbrush

Image-based normal maps

Image-based normal maps convert a greyscale height map into a normal map with surprisingly good results. This technique is best for creating extremely small details, such as fine lines and wrinkles. It is perfect for creating details on flat surfaces, like bricks on a wall or cracks in pavement.

Some image-based normal mapping programs include:

Nvidia's Normal Map Filter (NvTools) for Photoshop 7.0

The Zbrush Plug-In Z mapper

Normal map creation methods

To create normal maps to be applied to complex organic shapes, such as the human face, it is best to use mesh-generated normal maps. The following sections describe several ways of generating a normal map from a high-resolution mesh.

Zbrush-generated normal maps

To comprehensively cover the capabilities of Zbrush 2.0 is beyond the scope of this tutorial. The following workflow describes a way of generating highly detailed normal maps:

1 Create a low-polygon object in 3ds Max/Maya.

2 Unwrap the low-polygon object in 3ds Max/Maya.

3 Export the low-polygon object as a .obj file from 3ds Max/Maya.

4 Import the low-polygon .obj file into Zbrush.

5 Create a high-polygon object by sculpting extra detail into the low-polygon model, using sub-divide, sculpting tools, and projection master.

6 Use Zbrush to generate a normal map, or export the high-polygon model for normal map generation in a third-party tool.

7 Use the Zbrush plug-in Zmapper to further refine the normal map, by combing normal maps and bump maps and adjusting the normal map intensity with realtime preview.

In its native configuration, Zbrush produces normal maps with the Y (green) component inverted. To make Zbrush-generated normal maps compatible with BigWorld, invert the green channel before exporting, by selecting the Preferences→Import/Export→Normal Map Flip Y menu item.

If you are using the Zbrush plug-in Zmapper, then use the ATI_TangentSpace_BestQuality.zmp within the configuration menu.

3ds Max/Maya-generated normal maps

Building the high-polygon model

To generate a high-polygon model in 3ds Max or Maya, follow the guidelines below:

Start by building a high-polygon version of the character, with all details actually built into the mesh.

At this stage, the polygon count is pretty much irrelevant, so you should include as much detail as possible, in order to justify the use of the normal maps.

When modelling your high-poly model, do not worry about issues like ease of deformation, as the high-poly character will not be animated, and will only used for creating the normal map.

The high-poly model does not need to be UV-mapped, or textured.

It is ideal to model the mesh as one continuous shell, but there may be cases when this is not applicable. The reason for this is that intersecting geometry can cause artifacts in the map generation process.

Normal mapping uses ray gathering to determine the depth of the high-poly model. If a face is perpendicular to the ray cast by the low-poly mesh, then it will not register it as having any change in depth. To avoid this from happening, try to avoid 90-degree edges.

Perpendicular angle is bad for ray gathering

Obtuse angle is good for ray gathering

Exaggerate your details – the nature of normal maps means that they work better with large, obvious forms, rather than minute, complex ones. This does not mean that a model cannot be complex; it only means that the details themselves work better when they are larger.

Subdivision Surfaces: A common technique used to model high-poly characters is to use sub-division surfaces. These are represented in 3ds Max by the meshsmooth modifier (set the Subdivision Method drop-down list box to Classic) or in Maya by the Smooth or Smooth Proxy buttons.

3ds Max's Subdivision Method field

Maya's Smooth and Smooth Proxy buttons

Edge loops: One of the problems with high-poly modelling is keeping control of all your vertices. Using edge loops is a good way to get around this.

Edge loops are the most effective way of modelling a surface that is clean, manageable and that has definite, strong forms. They are basically loops of edges that define both the silhouette and primary forms of your model. By sorting these out before you carve in detail, you can better control the high levels of detail that you will end up adding later.

Quads: It is good practice to keep the surface of your mesh in quads, as opposed to triangles, whenever possible. This results in a cleaner sub-division operation, particularly across areas that have wrinkles or lots of detail. Below is an example of how to resolve an edge loop whilst retaining quads.

Example of a bad surface

Example of a good surface

Building the low-polygon model

To generate a low-polygon model in 3ds Max or Maya, follow the guidelines below:

Once the high-poly version is complete, you need to build a low-polygon version that encloses the high-poly one like a cage. The closer the low-poly version of the mesh is to the shape of the high-poly version, the better result you will get in the normal map. The idea is to let the normal maps do most of the detail work, and the low version will provide the overall shape.

During the process of building the low-poly model, pay attention to how closely it matches the shape of the high-poly version. Curved areas especially should be as close as possible to one another, to prevent distortion of the normal map.

Once the low-poly mesh has been modelled and UV-mapped, run it though STL check in 3ds Max – you can access this via the Modifier panel.

UV-unwrapping the low-polygon mesh

To generate a normal map, UV coordinates are not required for the high-poly model. Only layout UVs for your low-poly model.

Wherever possible, unwrap the model with as few seams as possible. Normal mapping creates visible artifacts wherever there is a seam, so the less of these the better.

You can mirror UV coordinates on models that will use normal maps within the BigWorld engine. The engine automatically flips during run-time the normal map on the opposite side of the model.

All UVW coordinates must be within 0.01 and 0.99, otherwise some normal map utilities will not generate a sensible normal map. It is also important to allow a small amount of room around each group of UVs, as some normal utilities expand the pixels around the border to prevent mipmapping artifacts.

Generating normal maps within 3ds Max

Normal maps can be generated within 3dsMax 7.0 and above using the Render to Texture method. To generate normal maps within 3ds Max, follow the steps below:

1 Make sure that you have both your high- and low-poly models in 3dsMax.

2 Select your low-poly model.

3 Select the Rendering→Render To Texture menu item – the Render To Texture dialog box will be displayed.

4 In the Render To Texture dialog box, expand the Output rollout, then click the Add button – the Add Texture Elements dialog box will be displayed.

5 In the Add Texture Elements dialog box's Available Elements list box, select the NormalsMap item, then click the Add Elements button.

6 In the Render To Texture dialog box, expand the Objects To Bake rollout.

7 In the Objects To Bake rollout's Mapping Coordinates group box's Object field:

A Select the Use Existing Channel option button.

B Set the Channel drop-down list box to the same UV channel that you unwrapped your model to.

8 In the Objects To Bake rollout's Projection Mapping group box:

A Select the Enabled check box, and set its drop-down list box to Projection.

B Click the Pick button – the Add Targets dialog box will be displayed.

9 In the Add Targets dialog box, select your high-poly model, then click the Add button.

10 Click the Render button to create your normal map.

Generating normal maps with Maya 8.0

The Transfer Maps tool was named Surface Sampler in Maya 7.0 and below.

To generate normal maps in Maya, follow the steps below:

1 Select your low-poly model.

2 Select the Ligting/Shading→Transfer Maps menu item – the Transfer Maps dialog box will be displayed.

3 In the Output Maps rollout:

Select the Normal Map check box.

Set the Normal Map field to the folder and name of your normal map file – the folder must be under the res folder structure, and the file name must contain the suffix _norms.

Set the Map Space drop-down list box to Tangent Space.

4 Click the Bake button to generate your normal map.

Maya generates normal maps with Red=Right and Green=Up, so they are compatible with the BigWorld engine.

ATI Normal Mapper-generated normal maps

To generate normal maps in ATI Normal Mapper, follow the steps below:

1 Load your file with both the high-poly model and the low-poly model together.

The pictures below show hi-poly model (left), and the hi-poly and low-poly model together (right).

Hi-poly model

Hi-poly model, along low-poly model

Please follow the guidelines below:

Ensure that your low-poly model has only one smoothing group for the entire object – multiple smoothing groups can adversely effect the normal calculations.

Make sure that both the high- and the low-poly meshes do not have an inverted transform. The best way to fix this is to reset the X-form in 3ds Max.

2 If you are going to mirror the final object, then only half of the low-poly model is required to generate the normal map.

3 As mentioned in the previous lesson, the low-poly model must be UVW-unwrapped in order to generate the map.

Here is an example of how this head model was unwrapped, using the Texturing helper bitmap.

4 Export the two different models to the ATI Normal map utility (it can be found in http://www.ati.com/developer/tools.html.

Unzip the NormalMapper utility and copy the MAX_ExportNMF.dle file to the plugins folder of 3ds Max – this will allow you to export your high- and low-resolution models as *.NMF files to be used by the NormalMapper utility.

5 With the high-poly model selected, select the File→Export Selected menu item – the Open dialog box will be displayed.

6 In the Open dialog box:

Set the File Name field to hi.nmf.

Set the Files Of Type drop-down list box to NMF (*.NMF).

Click the OK button.

7 Repeat the same steps for the low-poly model, naming it lo.nmf.

8 Use the ATI NormalMapper utility to generate the map.

If you prefer a graphical interface, we suggest to run the NormalMapperUI plugin script from within 3ds Max – the NormalMapperUI dialog box will be displayed.

9 In the NormalMapperUI dialog box:

Set the Input Files group box's Low Resolution Model field to the low-poly model saved in the previous steps (in our example, lo.nmf).

Set the Input Files group box's High Resolution Model field to the high-poly model saved in the previous steps (in our example, hi.nmf).

Set the Output File group box's field to the file to which you want the normals exported.

Click the Create Normal Map button.

The ATI Normal Mapping tools come with instructions on how to install the plugins and the NormalmapperUI.

10 Use the NMFView utility to check the normal map just created for errors and areas to improve (this utility should be located in the same folder as the other ATI tools).

NMFViewer asks for 2 files during startup: first the lo-poly .NMF file, then the .TGA normal map previously generated.

It will save you a lot of time keeping all .NMF and .TGA files in the same folder.

The following keyboard shortcuts can be used in NMFviewer (please refer to the ATI help for a complete list):

A – Toggles between normal map and coloured normal map modes.

W – Toggles between the wireframe and shaded modes.

11 Once you are satisfied with the normal map, it is time to make the model ready for exporting to the BigWorld format.

Back in 3ds Max, if only half of the model was used, then you will need to mirror the object to make a complete model.

12 Next, the colour texture map for the model must be created, applied, and referenced correctly (see lesson Modify a Model).

13 With the texture correctly referenced, select the File→ Export menu item – the Select File To Export dialog box will be displayed.

14 In the Select File To Export dialog box:

Set the Save In drop-down list box to the folder where you want the model saved.

Set the File Name field to the name of the model.

Set the Save As Type drop-down list box to Visual Exporter (*.VISUAL).

Click the Save button the Visual Exporter dialog box will be displayed.

15 In the Visual Exporter dialog box:

Select the Normal Mapped check box.

Click the OK button.

15 Open the visual file in ModelEditor, and make sure that the right texture and normal maps are referenced.

The Material Settings panel should be used for that.

No Normal map applied

Normal map applied

Texture-generated normal maps

Normal mapping large flat surfaces with high detail can be achieved using texture-generated normal maps. Normal maps can be generated from grey scale height maps using NVIDIA's nvTools plug-in for Photoshop.

This plug-in can be found on NVIDIA's website http://developer.nvidia.com/object/photoshop_dds_plugins.html

1 Open Photoshop.

2 Load the diffuse texture.

3 Use the diffuse texture to paint a greyscale heightmap.

Diffuse texture

Greyscale heightmap

4 With the heightmap selected, select the Filter→ nvTools→NormalMapFilter menu item – the NVIDIA Normal Map Filter dialog box will be displayed..

5 In the NVIDIA Normal Map Filter dialog box:

Select the Height Generation group box's Invert Y check box.

Select the Height Generation group box's Scale field to a value between 10 and 30.

Click the OK button.

Small sample sizes will capture small detail, whilst missing large variations in tone. Large sample sizes will capture larger detail, whilst missing smaller variations. In this case we are looking to capture large bumps in the surface detail, so a high sample range was chosen.

The Height Generation group box's Scale field determines the strength of the normal map – values between 10 and 30 generally yield good results. Try a few different levels to find the optimum one.

Multiple bitmaps – one created with a high Scale value and one created with a small one – can be overlaid in Photoshop, allowing the user to obtain both large and small surface detail. If this is done, then the normal map must be renormalised as described below in the section Renormalising a normal map.

Warning: Normal maps created with Nvidia Normal Map Filter have their Y component inverted. The Height Generation group box's Invert Y option button should be selected when creating normal maps with this technique.

6 The plugin will generate a normal map based on the heightmap that you painted.

7 Save the normal map appropriately (see below for details).

Combining mesh- and texture-generated normal maps

In some cases, both techniques above can be combined to produce a superior normal map.

If you are using Zbrush to create your normal maps, then you can use the Zbrush plugin Zmapper to preview and create normal maps combined with a bumpmap. Otherwise, you can follow this tutorial and create them manually in Photoshop.

The normal map below is a mesh-generated normal map made using Zbrush 2.0, although any 3D package will suffice. Like most mesh-generated normal maps, it captures large details such as bony protrusions, bumps, scales and muscles.

Normal maps created using Zbrush have their Y (green) component inverted for use in the BigWorld engine. When creating normal maps from Zbrush you must invert the Green channel in Photoshop before use. You can do that before exporting by selecting the Preferences →Import/Export→Normal Map Flip Y (Green) menu item.

Fine detail such as cracks in the dragon statue would have been difficult and time-consuming to model into a high-resolution mesh. Such fine detail is also difficult to capture with ray casting (the method by which normals are calculated from mesh objects). Instead, the fine detail is painted onto a texture. This texture is then used to generate a second normal map as outlined in the section above.

The two normal maps are then overlaid within Photoshop using Overlay layers.

Before this texture can be used, it must be renormalised – for details, read the section below.

Renormalising a normal map

Each pixel on a normal maps represents a normalised (adds up to 1.0) 3D vector where the values R,G,B represent X,Y,Z.

Any editing done to a normal map will cause all normals to not add up to 1.0, resulting in visual artifacts. Therefore, normal maps that have been edited in any way must be 'renormalised'.

Normal maps can be renormalised using NVIDIA's Photoshop plug-in texture tools ( http://developer.nvidia.com/object/photoshop_dds_plugins.html).

To renormalise a texture, open the normal map in Photoshop, then select the Filter→nvTools→NormalMapFilter menu item, then in the NVIDIA Normal Map Filter dialog box, select the Alternate Conversions group box's Normalise Only check box.

Your normal map will now be ready to use.


Outdoor-to-Indoor Transitions

  • Creating an entrance/exit
  • Cutting the Terrain
  • Placing an interior shell

Creating an entrance/exit

To create an entrance/exit in WorldEditor, follow the steps below:

1 Open WorldEditor.

2 To create a seamless entryway between an outdoor space and an indoor shell, first select an appropriate location for your entrance.

If you have not created any area for this, it is suggested that you create a gentle hillside in the terrain, in order to have an area that an entrance model can be moulded into.

To make future additions to the interior shell set easy, do the following:

Face the entrance/exit either north, south, east, or west.

Select the Object panel's Object Grid Snaps group box's Enabled check box, then click its Shell Snaps button – this will set the x, y, z, and Angle field to optimal values for shell placement.

3 Now that we have selected an area that is appropriate for an entrance/exit, we should place and position our entrance/exit model.

For the purposes of this tutorial, we use one entrance/exit model, one entrance/exit shell and one interior shell.

4 Position your entrance/exit into the hillside itself.

You should try to 'bury' it into the terrain, as you will later cut away the overlapping terrain sections.

Cutting the Terrain

This section describes how to cut the terrain as part of creating an entrance/exit in your world.

1 Select the Terrain Mesh Tool ( [image]) toolbar button – the Terrain Mesh Cut/Repair panel will be activated.

2 Select the Brush Mode group box's Cut option button.

3 Set the Size field to 1.

4 Zoom into your entrance/exit model for a better view of the areas of terrain that you will need to cut.

5 Click the Pole Markers ( [image]) toolbar button – this will activate the Pole Markers chunk visualisation mode.

6 Cut the terrain by dragging the mouse over the areas that are blocking the entrance/exit. It is important to leave room for reshaping the terrain around your entrance/exit model after this cutting process.

After this step, you will now notice large holes in the terrain from certain angles.

7 Click the Terrain Height Tool ( [image]) toolbar button – the Terrain Height panel will be activated.

8 Gently reshape the terrain to fit perfectly around this model.

This is the most difficult and time consuming step in the entire process, as terrain heights will differ from model to model. It might take a few minutes of massaging the terrain into the correct shapes, and you might even have to reposition the entrance/exit.

To help with areas in this terrain blending, try placing objects such as plants, etc., as it would also be a natural area for these models to exist, and where they help to draw the eye away from the transition area.

Placing an interior shell

This section describes how to place your interior shell (which must contain an exit portal) as part of creating an entrance/exit in your world.

If you do not have a shell with an exit portal, then see the lesson Create an Internal Shell.

1 Click the Object Tool ( [image]) toolbar button – the Object panel will be activated.

2 In the Asset Browser panel, select the Shells virtual folder.

3 Drag the desired shell from the assets list to the viewport.

4 Ensure that your exit portal (B) begins before the overlapping terrain cut (A) (see diagram 1). Otherwise the player will not be able to enter the exit portal and will instead collide with the terrain and be lifted to the surface as in diagram 2.

5 Connect all your interior shells to this entry/exit portal. Shells can be snapped into place using the portal resolving feature – simply select your shell and middle-click over a shell you would like it to snap to.

You can continue to build your interior spaces inward from this entrance.

Another method of transition form indoor to outdoor space is to simply use additional models to surround your entrance/exit. This method does not require you to cut into any terrain segments, and may be useful in some, yet not all situations. Be creative with your entrances – this is a great example of the use of additional objects to turn the entrance into a feature, and blend it perfectly with the scenery, without cutting away terrain.

For objects that act as a façade to internal entrances, it might be necessary to turn the WorldEditor's editable flag Outside Only to True in the Properties panel. This prevents the façade from being rendered as if it were inside the internal chunk. For more details, see the lesson Create Internal Shells.


Particles and Special Effects

  • Special effects - A combination of mesh and particles
  • Creating your particle system
  • Creating a particle source
  • Adding a Sink component to remove particles
  • Adding a force like gravity or wind
  • Adding a new particle sub-system
  • Colouring your particles
  • Changing the number of spawned particles
  • Sub-system components
    • System Properties sub-panel
    • Renderer Properties sub-panel
    • Source sub-panel
    • Sink sub-panel
    • Barrier sub-panel
    • Force sub-panel
    • Stream sub-panel
    • Jitter sub-panel
    • Scaler sub-panel
    • Tint Shader sub-panel
    • Node Clamp sub-panel
    • Orbitor sub-panel
    • Flare sub-panel
    • Collide sub-panel
    • Matrix Swarm sub-panel
    • Magnet sub-panel
    • Splat sub-panel
  • Limitations
  • Using Python
    • Python Macros
    • Attaching a weapon to the player character
    • Playing an action on a model
    • Attaching a particle system to a hardpoint
    • Swapping Player Models

Special effects - A combination of mesh and particles

Not all special effects should rely on a particle systems alone. Most of the time, complex special effects require multiple particle systems, meshes, and animations, all perfectly timed.

For example, the effect seen in the first two frames below (used for the player re-spawn) was made using an animated mesh, NOT a particle system. Only the last frame contains a particle system.

Animated mesh special effect

Animated mesh special effect

Particle system special effect

Special effects are coordinated via SFX files. SFX files are created by programmers and bring together the various components (particles, models, animation) for the final effect. It is very important to work alongside a programmer when creating complex visual effects.

The directory mf/fantasydemo/res/sfx contains all the special effects for the fantasy demo.

Let's take a look at the staff_idle.xml effect on the Ranger's magic staff by opening the file in Notepad.

This SFX file actually contains two separate effects named staff_particle 1A and staff_light 2A. These names are used to indicate which tags belong to which effect system.

The first thing to occur is the creation of the Actors, these are the objects that make up the special effect.

1a: The particle system staff_idle.xml

2a: A light with set radius and colour are created

1b: The particle is attached to HP_Snake_Neck

2b: The Light is attached to HP_Top

1c: The particle system is played

2c: The light is set to flicker

<SFXFile>
    <Actor> staff_particle 1A
          <ParticleSystem>  particle/staff_idle.xml     </ParticleSystem></
    </Actor>

     <Actor> staff_light 2A
          <Light>
            <innerRadius>    2       </innerRadius>
            <outerRadius>    8       </outerRadius>
            <colour>    128 192 255 2558       </colour>
        </Light>
    </Actor>

    <Joint> staff_particle 1B
            <Node> HP_Snake_Neck </Node>
    </Joint>

    <Joint> staff_light 2B
            <LightSource> HP_Top </LightSource>
    </Joint>

    <Event> staff_particles 1C
            <ForceParticle/>
    </Event>

    <Event> staff_light 2C
            <Flicker>
                <amplitude>    0.1       </amplitude>
                <speed>    0.5       </speed>
            </Flicker>
    </Event>
</SFXFile>

Creating your particle system

For the purposes of this tutorial, we will create a particle system called pollen, which will be placed near plants and flowers to give them drifting pollen.

This particle system will consist of two particle sub-systems: glows and colouredglows.

1 Open ParticleEditor.

2 In the Systems panel, click the [image] to create a new particle system – a new entry will be added at the bottom of the Particle List, where the insertion point will be moved.

3 Name the new particle system pollen.

4 New particle systems have a new sub-system automatically added, named component – press F2 and rename it glows.

5 Expand the glows sub-system – the System Properties and Render Properties sub-system components (created by default on new sub-system components) will be displayed.

6 Select the System Properties sub-system component – the System Properties sub-panel will be activated.

7 In the System Properties sub-panel, set the Capacity field to 30.

This field controls the number of particles that your particle sub-system will spawn.

Please note the following:

This example particle system will be sprite-based, so you should now create your texture for the particle sub-system, and save it in a folder appropriate for its use.

This example has a pollen texture without an alpha channel, because we will set its properties to Additive. We have made the surrounding base texture pure black, as this will then be rendered transparent. We have then placed an almost-white shape for the pollen in the centre of this image.

Leaving the pollen-shaped section of the image almost colourless means that we can later tint the colour of the texture with more effect via the Tint Shader sub-panel.

8 Select the Renderer Properties sub-system component – the Renderer Properties sub-panel will be activated.

9 In the Renderer Properties sub-panel:

Select the Sprite option button.

Specify the pollen texture (first make sure that your current folder is correctly set, using the [image] button).

Set the Blend Mode drop-down list box to Additive.

Using textures set to Additive is generally less intensive for rendering, and therefore more particle effects can be used in a single scene without increasing rendering costs. However, the look of Additive settings may not always suit your purposes.

Creating a particle source

The Source component of a particle sub-system is responsible for generating its initial position and velocity, among other settings.

1 In the Systems panel's Component list box, select the Source item, then click the [image] button – this will add a Source sub-system component to the particle's sub-system, and will also activate the Source sub-panel.

2 Specify the particle sub-system's initial position and velocity.

You can do this by manipulating the 3D gizmo, or by changing the value of the x, y, and z fields.

x, y, z fields and 3D gizmos for Point Initial Position Generator and Initial Velocity Generator

x, y, z fields and 3D gizmos for Cylinder Initial Position Generator and Initial Velocity Generator

3 Click the [image] toolbar button to see your particle spawning in the direction you have chosen in the Initial Velocity Generator fields.

3 If you would like to see the particles spawning without having to click the [image] toolbar button, then select the Triggers/Grounded group box's Time Trigger check box, then set the Emitter Rate field to the number of particles that should be generated per second (for this lesson, set it to 3.0).

You should see something like this.

Eventually, the particles will stop appearing. That is because there is a maximum number of particles that can exist (256), and none of our particles is being removed yet. We have to remove the particles by adding a Sink component.

Adding a Sink component to remove particles

The Sink component of a particle sub-system is responsible for removing particles from the engine.

1 In the Systems panel's Component list box, select the Sink item, then click the [image] button – this will add a Sink sub-system component to the particle's sub-system, and will also activate the Sink sub-panel.

2 Set the Maximum Age field to 2.0, this will determine that the pollen sprites will remain visible for around 2 seconds.

The continual cycle of sprites will now be created and then removed after 2 seconds. If you would like your sprites to be visible for an unlimited period of time, then set the Maximum Age field to -1. This will ensure that sprites always remain alive, or rendered.

Be very careful using an unlimited period of time for your particles' age, as it can use up a lot of resources if not used properly.

Sometimes your particles will emit in short bursts, disappear, then burst again – this is because you are reaching the maximum number of particles (256) that can be rendered per sub-system. If this happens you should either:

Decrease the Source sub-panel's Emitter Rate field.

Decrease the Sink sub-panel's Maximum Age field.

Decrease the System Properties sub-panel's Capacity field.

Outside only will cause particles to stop rendering if they move into a shell. This is commonly used for weather particle systems.

Adding a force like gravity or wind

We would now like our particle system moving in a more natural and chaotic pattern, as compared to the straight and direct line that it is currently traveling.

The first step towards achieving this is to add the Force component to the particle's sub-system.

1 In the Systems panel's Component list box, select the Force item, then click the [image] button.

2 Specify the direction of the force. You can do that in 2 different ways:

In the Force sub-panel, set the x field to 0.0, y to 1.0, and z to 2.0.

In the viewport, use the 3D gizmo.

After this change, you will see an immediate change in the direction in which the particles move.

You will notice that the farther from the point of origin (specified in the Source sub-panel's Position fields) that you move the tool, the more the speed of the particles increases.

You should now see something like this.

3 Change the particles' origin to a less focused area.

To do this, change the Source sub-panel's Position and Velocity fields.

Set the Position group box's Initial Position Generator drop-down list box to Sphere, then do the same with the Velocity group box's Initial Velocity Generator drop-down list box.

The sub-system's components are an integral part of ParticleEditor and its workflow. You should get used to editing and returning to these items in order to experiment with your settings, as one setting change can always have a flow on effect to the next. Through this system, you can achieve impressive results.

4 Notice that the 3D gizmos for Initial Position Generator and Initial Velocity Generator are now represented by a sphere each. You will have to enlarge these spheres in order to gain some effect from your new source.

5 Change the Initial Position Generator's sphere's Min Radius and Max Radius.

A Use the Scale gizmo (activated by the Alt keyboard shortcut) to set the Max Radius (represented by the red circle) to roughly 4.0 metres.

B Use the Scale gizmo to set the Min Radius (represented by the green circle) to roughly 1.7 metres.

6 Repeat this process to set the Initial Velocity Generator's Min Radius and Max Radius.

The result of these changes is that your particles will appear from a less focused area within this source sphere, and will also appear (or spawn at differing velocities.

You can vary the appearance of the system by adjusting the difference between the Min Radius and Max Radius of the source spheres.

To toggle the display of a background world area, click the [image] toolbar button.

At this stage, our particles simply blink out of existence after the 2.0 seconds of their lifetime. This can be avoided by adding the Scaler component to the particle's sub-system.

7 In the Systems panel's Component list box, select the Scaler item, then click the [image] button.

8 In the Scaler sub-panel:

Set the Final Particle Size field to 0.01.

Set the Rate field to 0.02.

You might want to experiment with different settings and observe the effects. The basic premise of this step it to cause the particle to scale itself down to a barely visible object before it is no longer rendered, giving a smoother transition into extinction. The rate of change will determine the speed at which your particle grows smaller or larger.

After this step, the particles will decrease in size before disappearing.

Adding a new particle sub-system

Now that the first particle's sub-system is established, we can very quickly add a new one.

1 In the Systems panel, click the [image] button – this will create a copy of the item selected in the particle list box.

2 Rename the new particle's sub-system tinted.

This will provide us with a good template for quickly adding to the look of our system by simply changing some values for each sub-system's component.

Colouring your particles

The first thing we are going to change about this new particle's sub-system is the colour.

For this example we will have the particles cycle from yellow to blue, then to green.

1 In the Systems panel's particle list, select the tinted particle's sub-system.

2 In the Systems panel's Component list box, select the TintShader item, then click the [image] button

The illustration below describes the Tint Timeline and the Selected Tint portions of the TintShader sub-panel.

The TintShader sub-panel contains a colour selection swatch (the Selected Tint portion). Clicking the small squares changes the colour of your particle's sub-system. By tinting it, you can also cause this tint to cycle through various colours during the life span of the particle.

3 Add a new tint to the Tint Timeline, by clicking the Add New Tint button, then clicking anywhere in the Tint Timeline's coloured bar.

4 Set the tint cycle to last 2 seconds, by setting the Tint Cycle Time field to 2.0.

5 Make the tint cycle loop continuously, by selecting the Loop Tint Cycle check box.

6 Configure the overall opacity of your particles per point in the tint cycle, by setting the Alpha field for each of them.

Experiment with changing these settings and add new point to the tint cycle to add even more colour possibilities to the cycle.

The TintShader component can also be used to colourise and change the opacity of mesh-based particle systems. If you want mesh objects to change opacity, then the Renderer Properties sub-panel's Mesh's Blend Mode drop-down list box must be set to Blended.

Changing the number of spawned particles

1 In the System Properties sub-panel, set the Capacity field to 200.

2 In the Source sub-panel, set the Triggers/Rounded group box's Emitter Rate field to 60.

The result is immediate, and should look like the screen shot below.

Save your work, either by pressing the [image] button, or by selecting the File→Save Particle System menu item.

Your new particle system is now ready to be placed in the world.

You are now ready to experiment with all settings. Here are some suggestions:
Try changing the values in the Force sub-panel, combined with the ones in the Source sub-panel, in order to make your new particle's sub-system act in many different ways.
Change the texture of your system in the Renderer Properties sub-panel .
Experiment with the packaged particle systems – they might use settings in a way you never though of.
Add new components, such as a Magnet and Orbitor, and study the results. Try setting the Magnet sub-panel's Magnet Strength to 60, and Minimum Distance For Force Calculations to 4, for example.

Sub-system components

What follows is a brief explanation of each of the sub-system's component, and their fields.

System Properties sub-panel

The System Properties sub-panel is shown below:

The table below describes the fields in this sub-panel:

Field | Description
Capacity | Caps the number of particles displayed on screen by that particular sub-system.
Wind Factor Amount of effect that the wind will have on the particle system's velocity.

Value ranges from 0.0 (wind velocity will not be added to particles' velocity, i.e., particles will not be affected by wind) to 1.0 (wind velocity will be fully added to particles' velocity).

The effect of wind in the particle systems can be tested via the Debug (Watcher) Console. To do that, follow the steps below:

Press F7 to activate the Debug (Watcher) Console.

Select the Client Settings item – you can either type its number, or navigate to it via the Page Up and Page Down keyboard shortcuts, then press Enter.

Select the Weather item.

Edit the windVelX and windVelY items – navigate to it via the Page Up and Page Down keyboard shortcuts, then press Enter.

Press Esc to exit the console and see the effect of the new wind settings.

Max Lod Furthest distance from camera for which the particle system will still be drawn.

Good for improving system performance.

Renderer Properties sub-panel

The Renderer Properties sub-panel is shown below:

The table below describes the fields in this sub-panel:

Field | Description

World Dependent

Sets the particle system to use the world coordinates. If the particle was emitted whilst the system was attached to a moving object, the particle would stay in the spot created whilst the object moves away.
Local Dependent | Sets the particle system to use the particles systems own local coordinates. If a particle was emitted whilst the system was attached to a moving object, the particle would follow the object due to its particle systems local coordinates being attached to the object.
View Dependent Sets the particle system to use the camera view matrix, So if the camera moves the particles will move with it.

Sprite A sprite is a bitmap that turns to face the camera perspective.

The Sprite portion of this sub-panel contains the fields below:

Field Description
Blend Mode List of available modes to blend the particle. The options are described in the table below:

Option | Description
Additive | Adds particle colour to the background. This is an efficient way of creating a pseudo alpha channel for your particle system. Completely black areas (RGB (0,0,0)) of the bitmap will be rendered transparent, removing the need for an alpha channel, although an alpha channel can still be used. Will appear to glow at night.
Additive Alpha | Uses alpha mask to determine the intensity of the additive blending between particles. A mix between blended and additive. Areas with white alpha will be drawn solid, areas with black alpha will be added to the background
Blended | Blends particles using the full 256 values of the alpha channel.
Blended Colour | Uses colour values to blend particles. Multiplies the source colour by itself and the background by the inverse source colour.
Blended Inverse Colour | Uses colour value to blend particles. Multiplies the source colour by itself and the background by the inverse source colour.
Solid | Renders particles as solid sprites, with no blending performed.
Shimmer | Shimmers the background using the alpha channel to mask the shimmer.
Alpha Test | Uses the sprite's alpha channel as a mask where alpha values less than 128 are transparent.
Frame Count

The Frame Count and Frame Rate fields provide an efficient way for creating animated textures using quantised UV scrolling. The alternative method uses an animated texture – .texanim – file. For details on this type of file, see the lesson Texture Maps, section Animated Texture Maps.

Quantised UV scrolling uses a single texture map like the example below. The engine then samples a section of the texture map determined by the Frame Count and the Frame Rate fields.

Frame Count: Should be set to the number of frames in your texture (15 in the example below).

Please take a look at the bradford_pear_flowers.xml particle in the Fantasydemo as an example of a particle system using quantised UV scrolling.

Using a .texanim animated texture results in synchronization of the animation independent of particle age. i.e. Multiple particles will all synchronise their animation

Using quantised UV scrolling reduces the number of bitmaps that need to be accessed by the graphics card, and synchronises the animation to individual particle age.

Frame Rate Number of frames to render per second.

Point Sprite Indicates that the sprite is smaller than 64x64 pixels and has no animation, which reduces the amount of necessary memory, thus increasing the rendering performance.

Point sprites are an extremely efficient way of rendering sprites, but beware of the following limitations.

Point sprites cannot use rolling UV coordinates. That means that the Frame Rate field will be ignored.

On some graphics cards, there can be a limitation to the sprite's size.

You cannot rotate or spin point sprites

Normal sprite-based particle systems require a quad to be sent from the graphics engine to the graphics card. When point sprites are used, only a single point needs to be sent to the card – the graphics card then creates the quad in hardware, which is a much faster way of rendering a sprite.

Enable Explicit Orientation

Turning this option ON will force the sprite to face a specific direction as defined by the XYZ entry.

When turned OFF, the sprite will automatically spin to face the camera.

Mesh The mesh particle renderer is capable of rendering two types of visual files:

Standard visual – Uses any mesh .visual file as a particle. The standin.visual file can be changed for any other mesh. Currently, there is no support for using animated meshs as a particle.

Mesh particle's visual – The Mesh Particles option in the BigWorld's Visual Exporter allows the BigWorld engine to (very efficiently) render multiple objects with a single draw call. Up to fifteen separate objects can be exported as one object by the BigWorld's Visual Exporter. Simply place your (less than or equal to 15) objects within the scene, then export them as a single object by selecting the Mesh Particles option button in the Visual Exporter.

The picture below shows multiple particle meshes rendered with a single draw call.

Please note that all objects that make up a mesh particle system must use the same material type, and a single texture.

A good example of how to utilise mesh particle systems is the falling_leaves particle system. In this system, several 3ds Max leaf models share a single texture, but are rendered by the engine for the cost of a single object.

The Mesh portion of this sub-panel contains the fields below:

Field | Description
Blend Mode | Please refer to the description of the Blend Mode drop-down list box in the Sprite group of fields.
Sorting Determines the quality of the alpha-blending sorting, and makes a trade-off between quality and speed. The options are described in the table below:

Option | Description
None | The particle system as a whole will be rendered in order with respect to other sorted objects, and the triangles contained within will be sorted back to front. The particles themselves, however, will be rendered out of order. Choose this method if speed is paramount and the visual artifacts introduced are not noticeable.
Quick | Sorting will be done in a way that allows the renderer to still draw in groups of 15. This introduces some sorting inaccuracies, but maintains most of the speed of unsorted mesh particles. This method is highly recommended if the sorting inaccuracies are not noticeable.
Accurate | Sorting of individual objects and triangles is performed. This provides the most accurate sorting, but breaks the ability of the renderer to perform fast 15-at-a-time rendering, thus decreasing rendering performance. If you choose this sorting method, then make sure to double-check the performance hit induced.
Visual Allows a regular mesh to be drawn as a particle system.

It does not support tint shaders, unless they have a specially written shader, nor does it support blend modes like Mesh renderers.

Amp

The Amp portion of this sub-panel contains the fields below:

Field | Description
Width | Thickness in which to draw the image in the source file.
Steps | Number of kinks in each line.
Length | How compressed or elongated the original texture will be when rendering the particle – the particle is composed of continuous segments of the specified texture.
Variation | Distance that each arc jumps away from the line, back to the origin.
Circular | Indicates that the sprites should be drawn connecting each particle to the next, instead of connecting each particle to the point of origin.
Trail Draws a trail of particles behind each particle. Trail remembers the particle's previous position, allowing you to use centrifugal forces like the Orbitor component on the particle.

The Trail portion of this sub-panel contains the fields below:

Field | Description
Width | Thickness in which to draw the image in the source file. Try using small width values, as larger ones make the billboard cross-visible.
Steps | Number of times that the sprite will be drawn behind each particle, thus actually altering the length of the trail.
Blur Blur creates a trail of particles behind each particle.

The Blur portion of this sub-panel contains the fields below:

Field | Description
Width | Thickness in which to draw the image in the source file.
Time | How long to extend the particle back along its current velocity vector.

Blur does not remember the particle's previous position. Instead, it works by drawing multiple particles along one vector. So if you are going to use Blur, it may not work as intended if you have centrifugal forces controlling your particle. Instead, try Trail.

The figure below illustrates the key difference between Blur and Trail.

Blur

Trail

Using Mesh Particles to add small objects to the world.

Mesh particles are a type of visual that allow the user to render multiple objects in a single draw call. The above section describes how to create them.

Below are some of the examples of how mesh particles have been used to add clutter to the fantasy demo worlds.

Examples of particle systems street_grim.xml, leaf_litter, and falling_leaves used in the fantasydemo.

In order to a mesh particle system to draw multiple objects in a single draw call, each of the objects must share a common texture map. The map below is used by all three leaf type sin the leaf_litter.xml particle system.

Source sub-panel

The Source sub-panel is shown below:

The table below describes some of the fields in this sub-panel:

Field | Description
Position | Group of fields defining a space within which to create the particle.
Velocity | Defines a set of velocities applied in local space that will be given to the particles on their creation.
Triggers/
Grounded 		Group of fields for time-triggered particle sub-systems.

It contains the fields described in the table below:

Field | Description
Time Trigger | Indicates that the particle sub-systems will periodically generate particles.
Motion Trigger | Causes particles to be emitted per distance traveled. This is useful for creating a smoke trail behind a rocket, for example. Select the System Properties and drag the system to preview the effect
Grounded | Makes all particles spawn from the ground plane, provided they are within Drop Distance of the it.
Particle Size | Group of fields defining the limits for randomising the size of the particles.
Sprite Only | Group of fields defining initial orientation and spin rate for sprite-based particles.
Mesh Only | Group of fields defining initial orientation and spin rate for mesh-based particles.
Miscellaneous Assorted settings for the particle system.

It contains the fields described in the table below:

Field | Description
Number Of Particles To Spawn On Demand | Number of particles to create, for non-continuous emitters. This field is mandatory for non-continuous emitters, which are designed to be dynamically created by the game (and not via WorldEditor). For these particle systems, a game event must force the creation of particles.
Allowed Time To Create Particles | Limits the time allowed to calculate particles – if particles are not created within this time, then they are not spawned. This is most useful for grounded particles, where system performance can be affected by spawning too many particles.
The maximum speed | Prevents the particle system from generating new particles if the system goes above the maximum speed setting. Select the System Properties and drag the system to preview the effect

Sink sub-panel

The Sink component removes particles from the world due to their age or speed, and is shown below.

The table below describes the fields in this sub-panel:

Field | Description
Maximum Age | Maximum number of seconds that the particles are allowed to exist. A particle might be removed before its lifetime expires, if it reaches Minimum Speed.
Minimum Speed | Minimum speed that the particles may have before being removed. A particle might be removed without reaching Minimum Speed if its lifetime expires.

Barrier sub-panel

The Barrier component creates a barrier of selectable shapes, which depending on the selected barrier effect, will bounce, remove, wrap or allow particles to pass through.

The table below describes the fields in this sub-panel:

Field | Description
Barrier Shape | Shape of the Barrier.
Barrier Effect | How the particles should interact with the barrier.

The wrap barrier moves a particle from one side of the barrier to the other when it collides with the barrier edge. It is particularly useful for creating dens particle effects around the player like those used in weather systems.

A particle created at position 1. will hit the barrier at position 2 where it is teleported to position 3. This ensures that the density of particles remains high around the player.

Force sub-panel

The Force component applies a second force (separate to the initial velocity generator) to be applied to all particles in the sub-system. Force is applied in world space, so rotating the particle in WorldEditor will not rotate the direction that the force is applied.

The table below describes the fields in this sub-panel:

Field | Description
x | Direction/magnitude of the force to be applied to the particles in the sub-system.
y
z

Stream sub-panel

The Stream component is similar to the Force component, although it allows control over how much force is imparted to each particle per time (via the Half-Life field). Stream is applied in world space, so rotating the particle in WorldEditor will not rotate the direction that the stream is applied.

The table below describes the fields in this sub-panel:

Field | Description
Stream Direction | Direction/magnitude of the force to be applied.
Half-Life | Number of seconds that the particle's velocity will take to move halfway towards the stream's velocity. A large value will impart force slowly, while a short one will impart force rapidly. A negative number means infinite half-life, i.e., the particles will not be affected by the stream.

Drag can be simulated by setting the stream direction to (0,0,0), and the half life to <1.0

Jitter sub-panel

Allows the user to create a jittering/wobbling effect on both particle position and/or velocity.

The table below describes the fields in this sub-panel:

Field | Description
Affect Position | Check box | Indicates that the jitter effect should be applied to the particles' positions.
 | Drop-down list box | Shape within which the effect positions are created. Larger objects result in larger differences in particle position, resulting in a stronger jitter effect.
Affect Velocity | Check box | Indicates that the jitter effect should be applied to the particles' velocities.
 | Drop-down list box | Shape within which the velocity vectors are created. Larger objects result in larger effect vectors, resulting in a stronger jitter effect.

Position jitter actually teleports the particle to a new position defined by the distance of the jitter volume. This has implications for barriers and collisions. In the image below you can see that particles given a position jitter may escape a barrier volume because they can teleport through the barriers surface.

Scaler sub-panel

The Scaler component allows the user to scale the size of a particle over time.

The table below describes the fields in this sub-panel:

Field | Description
Final Particle Size | Final size of the particle (in metres). Might be smaller than particle's original size.
Rate | Number of metres per second by which to increase or decrease the particle.

Tint Shader sub-panel

The Tint Shader component is explained in the Colouring Your Particles section of this lesson.

Node Clamp sub-panel

The Node Clamp component is used to determine that the generated particles should be clamped to the origin of the particle sub-system.

There are no settings for this component.

Orbitor sub-panel

The Orbitor sub-panel causes particles to orbit around a vertical line along the y-axis.

The table below describes the fields in this sub-panel:

Field | Description
Orbit Y-Axis | Coordinates of the point around which the particles will orbit along the y-axis. To have the particle orbit around a different axis while placed in the word, simply rotate the particle sub-system in WorldEditor.
Angular Velocity | Angular velocity of the orbit (in degrees per second).
Affect Velocity | Indicates that the velocity should also be rotated with the particle. If this if not selected, then the velocity will always be in the same direction.

Flare sub-panel

The Flare component allows the user to specify that a certain number of the particles should be spawned with a flare effect.

The table below describes the fields in this sub-panel:

Field | Description
Flare Name | Texture used to apply the flare effect to the particles.
Flare Step | Frequency in which to apply the flare effect to the particles. 0 means that the last spawned particle will have the flare. 1 means all particles have flares. 2..n means every nth particle will have the flare effect.
Colourise | Determines whether to use the settings specified for the Tint Shader component (if any) to colour the particles.
Use Particle Size | Determines whether the particle should be sized as per its source file, instead of using the size of the chosen texture for the flare.

Collide sub-panel

The Collide component is similar to the Barrier, except that it uses the ground and other objects BSPs to calculate collisions.

Using this component can be expensive, so it is best to mix it in combination with sub-systems that do not use it. This way, half the particles will pass through the ground, but the effect will still be convincing, as the other half will bounce.

The table below describes the fields in this sub-panel:

Field | Description
Elasticity Amount of bounce to apply to the particle when hitting the ground or other objects (in which case their BSP trees are used for the calculation).

The elasticity is applied as a factor to which the incoming velocity should be multiplied to determine the outgoing velocity.

For example, if Elasticity is set to 0.75 and a particle hits the ground at a downward velocity of 1.0 m/s, then it will bounce upwards at a velocity of 0.75 m/s.

Enable Sound | Determines whether a sound should be played when particles hit the ground or other objects.
Sound Tag | Source file containing the sound to be played upon particle collision.
Source Src Idx | Index (within the source file) of the sound to be played upon collision.

Matrix Swarm sub-panel

The Matrix Swarm component allows particles to be attached to a node or a list of nodes. This involves writing Python scripts in the game, in order to attach this sub-system correctly.

Adding a Matrix Swarm component in ParticleEditor exposes the functionality in the game script.

When the particle system is given a set of node matrices (by a programmer), this option allows the particles to be attached to those nodes.

For example: There is an effect in the Fantasy demo Online mode when a guard is attacked with a fireball: The result is that lighting strobes all over his body. This effect was achieved using the Matrix Swarm feature.

To understand how this effect is achieved take a look at the SFX person_explosion.xml in mf\fantasydemo\res\sfx. This file written by a programmer, contains a list of "SwarmTargets" that the programmer has defined for the particle system staff_implosion to spawn particles from.

The SFX file is simple to follow, it takes the staff_implosion particle system and plays (ForceParticle) the particle system on the models root node (ModelRoot). A single particle will spawn at each node sequentially from the top of the list downward and then repeat.

Magnet sub-panel

The Magnet component panel allows the user to specify a magnet effect to the particle's point of origin.

The table below describes the fields in this sub-panel:

Field | Description
Magnet Strength | Strength of the magnet. Determines how strongly the particles are attracted to it, and how fast they move in its direction.
Minimum Distance | Area around the magnet in which it will not exert force.

Splat sub-panel

The Splat component is similar to the Collide one, except that objects disappear when they hit the terrain or the world collision space.

Splat also notes the position the particle collides with the ground. This can then be used by the programmer to do things like add decals or spawn other effects

Limitations

Particle systems need to be used with care, as they can easily have an adverse effect on the game's performance. Consider the following:

Large particles using blending may hinder performance (due to fill rate issues).

Each particle consumes memory even if not being used (memory usage is shown in the status bar).

In the System Properties sub-panel, set the Capacity field to be just enough to contain the number of particles being used (see status bar).

The Amp and Trail particle sub-systems (set in the Renderer Properties sub-panel) need to cache each particle's history, and therefore consume considerably more memory.

Using python

For the purpose of previewing complex special effects and testing the alignment of hardpoints it can be useful to know a little Python.

Python Macros

Note: The FantasyDemo scripts use shortcut macros. If these macros are not configured within your scripts then the following shortcuts need to be replaced with their full notation.

$B = BigWorld

$p = BigWorld.player( )

$t =BigWorld.target( )

So that a command such as

$B.debugAQ($p.model)

becomes

BigWorld.debugAQ(BigWorld.player().model)

Attaching a weapon to the player character

We can use Python to preview what a newly created weapon would look like in the player models hands.

Ensure that both your weapon model and player character share the same Hard Point. Open the client.

1 Enter the Python console by typing pressing ~(tilde) + P and type:

2 m = $B.Model("sets/town/props/axe.model")

3 $p.model.right_hand = m

4 press ~(tilde) + P to exit the Python console

In summary we imported the BigWorld Model "sets/town/props/axe.model" and called it "m" (you would replace that path with the model you wanted to attach). We then attached "m" to the player models right hand.

Playing an action on a model

We can use Python to play an action on a model. For example if we wanted to preview the Ranger swinging the axe that we just attached we could do the following.

1 Enter the Python console by typing pressing ~(tilde) + P and type:

2 $p.model.SwingSword()

If we wanted the Ranger to swing the sword whilst running we could type:

2 $p.model.SwingSword(); $p.model.RunForward()

4 press ~(tilde) + P to exit the Python console

Attaching a particle system to a hardpoint

We can use Python to test the alignment of a particle system to a model

I will use the alignment of staff_idle.xml to the staff model as an example.

1 Enter the Python console by typing pressing ~(tilde) + P and type:

2 m = $B.Model("sets/items/staff.model")

3 $p.model = m

4 import Pixie

5 p = Pixie.create("particles/staff_idle.xml")

6 m.node("HP_Spell").attach(p)

In summary we imported the BigWorld Model "sets/town/props/staff.model" and called it "m". We then swapped the player model for "m". We imported Pixie (particle module) so that we could add the particle system "staff_idle.xml" to the world. The staff_idle.xml particle system was then attached to the HP_Spell node of m.

Swapping Player Models

There are times when you might want to test current actions on a new character model asset that has been created. You can swap the player character models in the client via the Python console.

To do this follow this example command:

Open the Python console ( ~(tilde) + P) and type:

p = $B.Model ("characters/npc/spider/spider.model")

$p.model = p

This basically tells the client that you are assigning the value " p " to a Bigworld model, then swap the current player character model to this new " p " model.


Create and Use Flora

  • Creating your flora artwork
    • Flora texture size and polycount
    • Flora UV coordinatesx
  • Flora configuration
    • Flora.xml
    • Flora draw distance
  • Flora placement, noise and weight
    • Flora noise
    • Keeping flora off paths, the weight tag
  • Miscellaneous xml tags
  • Art and performance tips

Flora is the millions of small objects populating the landscape, providing detail and depth to the landscape. Typical flora objects include grass, stones, small ferns, and flowers. They are automatically created as the player moves around the world, and fade based on distance.

An Ecotype, as referred to in this document, is another name for a type of ecosystem. In your world, ecotypes are linked to terrain textures. Wherever a particular texture is used, you will find the associated flora growing there.

Creating your flora artwork

Flora texture size and polycount

Flora objects are simply standard static .visual files, created in a 3d application, and exported using BigWorld's Visual Exporter.

Ecotypes are groups of visual files associated with a particular terrain texture. For example the terrain texture "grass.tga" might have 10 different grass like models (visuals) associated with it.

Flora triangle density:

The number of flora triangles drawn by the engine depends on the vertex buffer setting <vb_size> in the flora.xml file, this specifies the number of bytes available for the vertex buffer. The default setting is 5,000,000, this is then multiplied by the graphics setting "flora density"

Very High Flora has a multiplier of 6 so the vertex buffer will be 30,000,000 bytes

High Flora has a multiplier of 1 so the vertex buffer will be 5,000,000 bytes

Medium Flora has a multiplier of 0.5 so the vertex buffer will be 2,500,000 bytes

Low Flora has a multiplier of 0.25 so the vertex buffer will be 1,250,000 bytes

Ecotype triangle limit:

There is also an internal triangle limit per each ecotype which is again dependant on the vertex buffer and flora density graphics settings.

To work out the number of triangles available to each ecotype you can do the following:

Number of triangles available to each ecotype = ( ( ( vb_size in bytes ) * graphics setting ) / 625 ) / 16 ) / 3

625 = number of 4x4 flora blocks

16 = bytes per vertex

3 = verts in a triangle

Or put more simply; vb_size * graphics setting / 30,000 which gives you the following table.

Flora Detail Level | Number of Triangles per Ecotype
Very High Flora | 960 triangles per ecotype set
High Flora | 160 triangles per ecotype set
Medium Flora | 80 triangles per ecotype set
Low Flora | 40 triangles per ecotype set

So when using High Flora density the total number of triangles making up an ecotype should be no more than 160 triangles – In the game, there will be 160 triangles of flora drawn for each 4x4m block of terrain (1 terrain quad).

As an example, if your grass ecotype consisted of the following;

<flora.xml>
  ...
  <ecotypes>
    ...
    <gra_grass_long>
      <texture>   maps/landscape/gra_grass_02.dds       </texture>
      <visual>    grassland/flora/flower.visual </visual> <!-- A 100 triangle flower model -->
      <visual>    grassland/flora/shrub.visual </visual> <!-- An 80 triangle shrub model -->
  ...

then your shrub model will not be drawn at high flora density settings because the 160 triangle limit would of been exceeded.

Flora object density:

Using higher polycount objects isn't necessarily better. The more polygons in each object the fewer objects can be drawn per 4x4m flora block.

You could draw one extremely detailed flora object per block or like in the example below use simpler objects to get a more dense flora cover.

Flora Texture size:

Within a single ecotype, all flora objects must use a single bitmap.

The size of each ecotype bitmap is defined by the <texture_width> X </texture_width> and <texture_height> Y </texture_height> tags in the flora.xml file.

The default settings are 512x256. Exceeding 512x512 is not recommended.

If it is your intention to have grass and flower flora growing on the greengrass ecotype, then both grass and flowers must be drawn on the same bitmap.

There can be more than one flora object per ecotype, but each ecotype can have only 1 texture.

Flora is drawn with full alpha-blending enabled, so make sure that you use the alpha channel to its fullest extent.

Below is an example of a flora texture and its alpha channel. As you can see, multiple objects can be displayed within the one ecotype, provided they use the same bitmap and some careful UV mapping.

Flora UV coordinates

When creating the flora UV's it's important to remain inside the 0,1 boundary of the UV coordinates. The flora system compounds multiple flora bitmaps into a large texture, if your UV's stray outside the 0,1 boundary the flora model may borrow texture from a neighbouring bitmap.

Flora configuration

Flora.xml

WorldEditor automatically seeds the world with the flora that you created. In order to do this, you must correctly configure the game.

The space.setting file located in each space folder contains a tag <flora> describing the location of that particular space's flora.xml file. This allows you to define different flora rules per space.

If a space's space.settings file does not contain a <flora> tag then the space will default to the flora.xml described by the resources.xml. In the case of the FantasyDemo this flora.xml is located in res/environments

Your flora configuration file is specified in bigworld/res/resources.xml's file, in the <environment> section's <floraXML> tag. You can change this setting to another location for your game, if you like.

<resources.xml>
  ...
  <environment>
    ...
    <floraXML> system/data/flora.xml </floraXML>
  ...

The ecotypes present in your world can then be configured in the flora configuration file (in the example above, system/data/flora.xml), in the <ecotypes> tag. Examples of ecotype that you might have are: grass, arid grass, swamp mud, water verge, dusty path, etc...

<flora.xml>
  ...
  <ecotypes>
    ...
    <gra_grass_long>
      <texture>   maps/landscape/gra_grass_02.dds       </texture>
      <texture>   maps/landscape/lev_grass_02.dds       </texture>
      <visual>    grassland/flora/gra_grass_long.visual </visual>
  ...

Each ecotype has the following information:

A list of terrain textures to use in WorldEditor. This list represents all terrain textures that will have this particular ecotype growing upon it.

A list of visuals. This is the list of meshes that will grow in that ecotype. Within this list, all visuals must use the same texture.

When adding ecotypes, always add it to the bottom of the list – this will save you from having to recalculate the ecotypes for the entire world again.

In the example configuration above, the gra_grass_long.visual will grow wherever in the world the predominant texture is gra_grass_02.dds.

Flora draw distances

Flora is drawn using alpha blend (8 bit alpha) which softly fades the flora in and out of view, and predominatly alpha test (1 bit alpha) when close to the player.

Here are the settings from the flora.xml file for fantasy demo.

<AlphaTestRef>			128			</AlphaTestRef>
<ShadowAlphaTestRef>		128			</ShadowAlphaTestRef>
<AlphaTestDistance>		25			</AlphaTestDistance>
<AlphaBlendDistance>		0			</AlphaBlendDistance>
<AlphaTestFadePercent>		75			</AlphaTestFadePercent>
<AlphaBlendFadePercent>		50			</AlphaBlendFadePercent>...

Flora will draw to a maximum of 50 meters from the player. Using the above default settings, alpha tested flora will be drawn 25 meters from the player and alpha blended flora will be drawn out to the 50 meter mark.
<AlphaBlendDistance> Is measured from the 50 meter mark towards the player. So when set to the default 0, the flora will use alpha blend all the way out to the 50 meter mark.
<AlphaTestDistance> determines how far out from the player that alpha test should be used. So when set 25 the flora will be drawn using alpha test 25 meters from the player.

Flora placment, noise and weight

Flora noise

Flora such as grass, flowers, and ferns do not grow evenly dispersed around the world. Instead, they clump together in some places, and do not grow in others.

To simulate this, we have added the ability to add noise to the distribution of flora, via the <generator> tag, as illustrated below:

<flora.xml>
  ...
  <ecotypes>
    ...
    <gra_grass_long>
      ...
      <generator> chooseMax
    <fixed>
        <value> 1.1 </value>
    </fixed>
        <noise>
          <frequency> 0.15 </frequency>
          <generator> visual
            <visual> flora/dry_grass/flower_3_tris_stem_1_tris02.visual    </visual>
            <visual> flora/dry_grass/flower_3_tris_stem_1_tris.visual      </visual>
          </generator>
        </noise>
        <noise>
          <frequency> 0.8 </frequency>
          <generator> visual
            <visual> flora/dry_grass/grass_upsidedown_2_tris.visual        </visual>
            <visual> flora/dry_grass/grass_upsidedown_1_tris.visual        </visual>
            <visual> flora/dry_grass/grass_upsidedown_1_tris02.visual      </visual>
            <visual> flora/dry_grass/grass_upside_upsidedown_2_tris.visual </visual>
            <visual> flora/dry_grass/grass_3_tris.visual                   </visual>
          </generator>
         </noise>
         <noise>
           <frequency>  4.0 </frequency>
           <generator> visual
             <visual> flora/dry_grass/grass_upsidedown_1_tris02.visual      </visual>
             <visual> flora/dry_grass/grass_upside_upsidedown_2_tris.visual </visual>
             <visual> flora/dry_grass/flower_3_tris_stem_1_tris02.visual    </visual>
             <visual> flora/dry_grass/flower_3_tris_stem_1_tris.visual      </visual>
           </generator>
         </noise>
  </generator>
       ...

The following diagram displays graphically what is occuring in the above noise generator.

The <generator> is Choosing the Maximum "choosemax" values above the <fixed> level to place flora objects.

So in the image to the right, blue indicates no flora and the other indicate flora comprised of the visuals listed in the above .xml.

Keeping flora off paths, the weight tag

The above noise settings can sometimes cause your flora objects to creep into places that you have defined as <empty> ecotypes within the flora.xml file. This usually manifests as flora growing on paths or roads.

This can be fixed using the <weight> tag found inside the material_kinds.xml file (bigworld\res\system\data\material_kinds.xml)

<kind>
        <id>	9	</id>
        <desc>	Dirt	</desc>
        <sound> dirt    </sound>
        <weight>	1.0	</weight>
        <help> Hard crunchy snow. </help>
        <sfx>	sets/global/fx/sfx/sfx_pchang_dirt.xml </sfx>
        <terrain> maps/landscape/path01 </terrain>
        <terrain> maps/landscape/path02
        <weight>	4.0	</weight>
        </terrain>
        <terrain> maps/landscape/path03 </terrain>
</kind>

To get a good understanding of how the <weight> tag works you must first understand Texture Blend Maps and Flora Blend Maps

Texture and Flora Blend Maps:

The resolution of the terrain texture brush is determined by the Texture Blend Map settings used when the space was initially created.

The engine uses a similar blend map, the Flora Blend Map to decide what ecotype is going to be placed in a given location. The resolution of this Flora Blend Map is always half the resolution of the Texture Blend Map for advanced terrain, and full size for simple terrain.

The <weight> tag mentioned above simply multiplies the value of a given texture in the Flora Blend Map. So when we give the texture path02.tga a weight tag of 4.0 its effect in the flora blend map is 4 times as strong as the other textures, preventing flora from creeping into its territory.

Note: For further uses of the material_kinds.xml file please read Terrain Material Kinds

Miscellaneous xml tags

Here are several other tags useful xml tags associated with flora

<vb_size> This tag controls the size of a vertex buffer which will determine how many flora objects can be shown at once depending on its size. Larger values result in more flora but come at a performance cost.

<flex> 0.0 </flex> Determines how much the flora object is effected by the in game wind. 0 = no effect, 1.0 = full effect.

<density> 0.8 </density> Can be used to control how often a flora object is placed on the terrain. Valid values are between 0 and 1.0. This will not increase the total amount of flora, only scale it back from its maximum (1.0) value. To increase the overall amount of flora see the tag <vb_size>.

<scaleVariation> 0.7 </scaleVariation> Applies a random scale variation factor to the flora object. A scaleVariation value of 0.5 will cause an object of size 1.0m to be drawn between 0.5m and 1.5m tall.

<weight> 5 </weight> This tag is found within the material_kinds.xmlfile located bigworld\res\system\data\material_kinds.xml although not located in the flora.xml file it does affect the way flora is placed on the ground. All ecotypes have a certain amount of creep, i.e. they will spread into other areas, the <weight> tag can be used to prevent other ecotypes from invading a particular ecotype. High values will prevent other ecotypes from creeping into the area defined by this ecotypes texture. This is useful for preventing grass growing on paths for example.

Art and performance tips

When creating and placing the flora, keep in mind the following:

The impact in the game's performance will be directly related to how many pixels are drawn on the screen – the vertex cost is negligible.

Therefore, make sure that your detail objects do not cover too many pixels, i.e., do not make thick head - high grass unless you know exactly what you are doing.

The colour of the detail objects is very important.

Since you want them to fade out seamlessly, and you do not want to see the intersection between the objects and the ground, make sure that the texture colour matches exactly the colour of the terrain on which each detail object sits.

Obviously, you can add more colour variation in towards the top of the object, as this will not be sitting directly on the ground. For example, the stems of flowers should exactly match the colour of the ground on which they are sitting, while the petals can be bright and bold.

Slightly darken the alpha map of your flora objects where they intersect with the ground. This tends to hide the intersection, and also blends the colours of the flora with the colour of the terrain.

Variety is also very important, so try to fit as many different visuals into the one ecotype (i.e., on the one ecotype texture).

Small variations in a grass object can add a lot to the realism of your flora.

Flora density is not only controlled by the vertex buffer size but also by the number of triangles in each visual.


Best Practices

  • Realtime Profiling Console
  • Using the Client Watchers to identify problem assets
  • Testing Portal Culling
  • Animation tree - Using LOD models to share animations
  • Batch rendering
  • DPVS and Umbra
    • DPVS
    • Umbra
    • Creating assets for DPVS and Umbra
  • Using the Client Access Tool (CAT)
  • Using the complete range of textures and lighting
  • Using SpeedTree
    • Billboards
    • Optimisations
  • Lock Server; Working simultaneously on one space
  • Reloading client assets on the fly

This lesson describes ways of minimising the the impact of artwork on game performance.

Using the Realtime Profiling Console to test game performance

If you press ~(tilde) + F5 when in the client you will be presented with the Realtime Profiling Console

This will give you a overview of your game performance.

Fps: Frames per second

DrawCalls: The number of draw calls used to render the scene.

Primitives: The number of primitives rendered to the scene.

Primitives/DrawCall: The average numberof primitives rendered per drawcall.

Texture (Total): The total size of textures currently loaded (Textures around the player)

Texture (Frame): The total size of textures used to render the last frame.

Heap Memory/Allocations (Current): The amount of memory currently allocated by the application/the number of allocations

Heap Memory/Allocations (Peak): The maximum amount of memory allocated by the application in this run/the number of allocations

The Realtime Profiling Console can be expanded by pressing Enter to give an even further breakdown of how long the engine is spending on each part of the scene.

Each part can be graphed by pressing G

Using the Client Watchers to identify problem assets

The Client Watchers can be accessed by a ~(tilde) +F7

Use the PageUp and PageDown keys to navigate through the lists and enter to change a parameter or expand a folder.

One of the more useful client watchers is the Debug Sorted Triangles watcher. When set to true (1) this watcher will draw everything dark except for alpha blended objects.

Alpha blended objects require sorting and when used excessively can cause the game performance to drop. You should use this watcher to find objects in the game that are unnecessarily using alpha blend. For example a rock should not be using alpha blend.

Note: The flora uses alpha blending, this is OK.

Testing portal culling

You can test the effectiveness of portal culling using a combination of watchers and draw wireframe.

Use ~(tilde) + F7 to access the Render options and set draw portals to true (1).

This will draw a red line around the perimeter of each portal allowing you to better identify their position.

Press ~(tilde) + F8 three times to make everything draw in wireframe mode. This will allow you to see through objects and visualise what is actually being drawn/culled.

In the scene below I can see that the deeper areas of the dungeon network, and the outside world are being culled.

Animation tree - Using LOD models to share animations

BigWorld allows characters to share animations, as long as the bones used to rig each character share the same name structure – animations are shared by using a common LOD model.

It is recommended that animations only be shared between characters using exactly the same skeletal rig. Sharing animations between models of different size or shape will result in the models vertice's being transformed to fit the new rig.

It performs the steps described below (assuming the LOD configuration depicted in the screenshot below:

1 Action Matcher calls an animation to be played in the game.

2 The currently rendered LOD model is queried, to check if it has the appropriate animation. If it does not, then Action Matcher looks down the LOD tree (LODs called further away), checking them for the animation.

In the example below, if ranger.model is being rendered and the walk animation is called, then the ranger.model will play the generic male walk animation assigned to base.model. That is so because ranger.model and rangerlod.model do not have specialised walk animations of their own.

Action Matcher does not look up a tree, so in the example below, if loddy.model is being rendered, and the ranger.model specific animation firegun_ranger is called, then no animation will be played. This is usually not a problem, as loddy.model is rendered at such great distances that the animation would be invisible. This means that animations that would otherwise be invisible at such great distances are not played, increasing game performance.

The table below described the LOD models used in this example:

LOD Model Description
loddy.model This is a single-piece mesh 50-polygon character, viewed at such distances that it is unnecessary to utilise all skeletal bones to deform its mesh.

Although it was rigged using the exact same skeleton as ranger.model, the only bones set to influence the mesh were:

Right_upperarm

Left_uppperarm

Left_thigh

Right_thigh

The centre node pelvis.

Although the animation contains detailed information about the other joints, it is unnecessary to use it, as the model is rendered so far away that these movements would never be seen. This decreases the number of transforms the vertex shader needs to perform and increases performance.

Only the most common animations are assigned to loddy, such as walk and jump. For details on how to reduce node influence in LOD models, see the lesson Create Level-of-Detail Mesh for Characters,Node LOD Theory.

base.model

This is a low-poly (300-polygon) single-mesh generic male character.

Even though the animations used to deform base.model contain more than 17 bones, the base.model mesh is deformed by less than 17 bones.

When base.model was rigged, the hands were linked to the forearm, instead of each individual finger being influenced by separate bones. Hand and finger animations are not visible at large distances, so there is little need to show them.

This model has all male specific animations assigned to it. All male bipedal characters should use base.model as a LOD so they can share these generic animations.

For example, animations assigned to the base model may include male variations of:

walk

run

turn

jump

rangerlod.model This is a lower poly version (1,700-poly) of ranger.model.

Although the mesh is broken up in segments, the smaller detail animations are not used. For example, the fingers are not individually animated.

All specific ranger animations are assigned to this model, such as:

ranger_attack

ranger_sneek

ranger_fight

ranger.model This is the final high-poly version (2,500-poly) of the model.

The model is now rendered close up, so each individual bone is used – fingers, ponytails, and clothing must animate independently.

The complexity of your animation tree depends on the number of characters sharing skeletal rig structure and animations. If each character animation is to be unique down to the finest detail, then there is little need to share animations between them.

In the example below, base_male.model is used to share animations between two models that both use the same skeletal rig: ranger and scout.

Note that in the example below the animation to be shared from base_male.model to its two higher LODs must contain all nodes that you wish to use for those higher LODs. So make sure that you add all skeleton's nodes to the skin modifier, even if base_male.model does not use every node.

Batch rendering

If you have an object that is featured more than approximately 3 times within a single view, then batch rendering that object should improve the game performance.

Batching can be performed on both animated and non-animated objects, and is set in ModelEditor's Object Properties panel.

Batch rendering cannot be performed on models with a material tint or alpha blended objects

DPVS and Umbra

dPVS and Umbra are third party occlusion culling solutions that can be used to improve the performance of the game by avoiding processing of 3d content which is hidden from view.

DPVS

Occlusion culling is performed on the CPU, there is some overhead in calculating when an object is being used as an occluder. For this reason it's important to only flag those objects which are naturally good occluders. e.g. larger objects like walls, and houses. If smaller objects are used as occluders they can decrease game performance.

To flag an object as an occluder

Umbra

Occlusion culling is performed on the graphics card and as a result there is no overhead in testing an object as an occluder. Umbra requires no artist assistance.

Umbra understands BigWorlds portal system and as a result can improve portal culling by using game geometry such as shells and their contents to occlude portals.

Creating assets for DPVS and Umbra

Umbra basically uses line of sight to determine if an object should be drawn or not. Consequently, it's extremely important to ensure that models which should block the line of sight of other models (walls, shells, and buildings) need to have good modelling integrity. Good modelling integrity means no holes, un welded vertices, or broken edges. If models contain holes they will not be able to cull geometry correctly resulting in decreased game performance. You can check for culling problems by turning on wire frame mode whilst in the client or WorldEditor. If objects are being drawn behind walls and buildings then there may be a problem.

Wire frame mode is enabled by pressing ~(tilde) + F8 in the client, or in the options menu of WorldEditor

3dsMax's STL Check Modifier can identify problems like holes and un welded verts with a model.

Maya contains a similar function called polygon cleanup Mesh - Cleanup.

Model Editors Check For Sparkles can be used to identify holes in a mesh. It colours models black and the background white, this makes it easier to see tiny holes and cracks.

Using the Client Access Tool (CAT)

The Client Access Tool (CAT) allows you to execute Python scripts from an easy-to-use GUI.

Although CAT ships with some basic commands it's mostly a framework of a tool available for customisation. If you need artists to execute python commands during development then CAT is the perfect tool.

CAT can be found in bigworld/tools/cat/cat.bat. Simply run this program after running the client (game).

For CAT to function you will need to install the latest Python and wxPython, both can be found via an internet search.

Using the complete range of textures and lighting

Many games tend to adopt the dark is cool approach, resulting in a world that is overall dark in appearance, and only use half the available colour range. To tackle this issue, we have incorporated a realtime histogram into WorldEditor and into the BigWorld client, allowing you to check the range of colours and luminance used by your game assets.

The histogram can be viewed in WorldEditor in the Histogram panel, or via the Histogram Console, which can be activated by pressing F11 in WorldEditor, or by pressing F4 in the Client Engine.

WorldEditor's Histogram panel

WorldEditor's Histogram console

The keyboard shortcuts available in the Histogram Console are described in the table below (please note that the alphanumeric must be used):

Key | Action
0 | Toggles the graphing of luminance.
1 | Toggles the graphing of the red component in the RGB histogram.
2 | Toggles the graphing of the green component in the RGB histogram.
3 | Toggles the graphing of the blue component in the RGB histogram.
4 | Toggles the rendering of the scene background on the histogram.
5 | Decreases the vertical range ratio of the Luminance and RGB histograms.
6 | Increases the vertical range ratio of the Luminance and RGB histograms.

Using SpeedTree

Billboards

For better visual results and runtime performance, BigWorld's 3D engine renders trees' billboards as crossed quads, without spin to face.

For each tree, BigWorld's 3D engine will render as many 360° billboards as have been exported into the composite texture map, although three billboards should yield the best visual results. If available on the exported map, one horizontal billboard will also be rendered.

When exporting a tree, SpeedTreeCAD pre-renders billboards into the composite texture map. Due to that, a billboard will exactly match a tree only when it uses the same seed number as the one used when exporting the .spt file.
To make sure that BigWorld uses the same seed number used when exporting the tree, set it to 1 in WorldEditor.

Optimisations

To improve memory and runtime performance, BigWorld's 3D engine uses the following techniques:

Instancing – A single copy of a tree is kept in memory for all its instances.

Batching – When rendering trees, BigWorld's 3D engine sorts the primitives in order to reduce the number of state changes required to render all trees.

Compounding – Trees are compiled together into few vertex buffers, to be rendered with fewer draw calls.

The higher the ratio of trees-to-tree-types, the better these techniques will work. Thus, in order to maximise time and memory savings, world builders must try to minimise the number of distinct trees placed in the world.

Distinct trees are the ones with different source .spt files or seed numbers.

The Compounding technique is applied only to billboards, due to the higher memory and processing requirements of compounding higher detail trees.

In order to be able to render billboards with a single draw call, a texture atlas containing the billboards for all tree types, at all viewing angles, must be built. This is automatically taken care by the engine, but world builders might need to tweak the size of the texture atlas to hold all billboards required.

If the texture atlas is not large enough to hold all billboards, a warning will be issued into the debug output, and the billboards will start to overlap themselves in the atlas, resulting in wrong texture mapping.

For details on how to tweak the texture atlas, see SpeedTree's XML configuration file, section billboardOptimizer. The name of SpeedTree's configuration file is specified in resources.xml, located in the game's resource folder, as illustrated below:

A good amount of variety without performance impact can be achieved by scaling and rotating instances of a single tree.
Interleaving instances with distinct trees also helps disguising repetition.
Beware, though, that some care must be taken when rotating trees if the they are expected to animate correctly under strong winds. For details, see Content Tools Reference Guide, chapter WorldEditor, section SpeedTree → Wind Animation

Lock Server; Working simultaneously on one space

The Lock Server (bwlockd) server allows world builders to work simultaneously within the same space without overwriting each others changes. It works by allowing users to lock regions of a space so that only they have editing access to it.

The Lock Server must be run on a machine that all world builders can connect to. The bwlockd.py python script is found here bigworld/tools/bwlockd.

To connect to a bwlockd server each user must configure their WorldEditor options.xml file to connect to the Lock Server.

    <bwlockd>
        <use>	true	</use>
        <host>	</host>
        <username>	</username>
    </bwlockd>

When a user first connects the entire space will be shaded red to indicate that the user cannot alter any of the assets.

To lock off a region for editing select the project view button. This will give you an overhead representation of the space.

Marquee select the region you want to lock for editing.

Enter a commit message in the message box

Press Lock Selected Chunks, the Lock Server will consult the source control software you are using and ensure you have the latest version of the chunks before allowing you to edit them.

Once the chunks are locked they will appear the normal colour in the 3d viewport. You may now edit the space

Once you have finished editing you can either Discard Changes or Save and Commit your changes. Each button has the option to Keep Locks after the function, this will retain the lock on the area previously selected.

Remember that even if you exit WorldEditor the space remains locked so that only you can access it. Always unlock a region if others need to work there.

Reloading client assets on the fly

Changes made to textures and models of non entity objects can be reloaded without restarting the client executable by executing the following python console command.

Ctrl + P (to access the python console)

$B.reloadChunks()

Or, if the shortcuts are not loaded

BigWorld.reloadChunks()


Use Maya Visual Exporter

  • Using the exporter
  • Defining portals using BigWorld shelf
  • Creating hard points within Maya

This document describes how to use Maya to define portals and create hard points. It is not meant as a substitute to the lessons Create Low-Polygon Characters and Create an Internal Shell – those documents are essential reading.

This lesson assumes that the BigWorld Maya Exporter and the BigWorld shelf have already been installed on your machine. For details on how to install them, see Content Tools Reference Guide, chapter 3ds Max and Maya Exporter, section Maya → Installing the 3ds Max Exporters.

Using the exporter

1 Start the export process.

Select the File→Export All menu item to export all objects in the scene – this will export all objects, even the hidden ones.

–or–

Select the File→Export Selection menu item – this will export only currently selected object.

The Export dialog box will be displayed.

3 In the Export dialog box:

A In the Look In drop-down list box, specify the folder where the asset should be saved.

B In the File Name drop-down list box, specify the name of your asset.

C In the Files Of Type drop-down list box, select the BigWorld Asset item.

D Click the Options button – depending on the menu item previously selected, the Export All Options or the Export Selection Options dialog box will be displayed.

In the dialog box's General Options group box, set the File Type drop-down list box to BigWorld Asset.

Click the Export All or Export Selection button (the button displayed depends on the menu item previously selected) – this will close the current dialog box and return to the Export dialog box.

E Click the Export button – the Visual Exporter dialog box will be displayed.

In the Visual Exporter dialog box, click the OK button – the asset will be exported to the specified folder.

Defining portals using BigWorld shelf

The BigWorld Maya shelf allows users to define objects as portals. It contains 3 icons, which allow you to define objects as Portal, Exit, or Heaven portal types.

The shelf contains the following buttons:

– Add Portal flag

– Add Exit flag

– Add Heaven flag

To assign a mesh object as a portal type, first select it, then click the portal type from that you wish to assign it. You can check your assignment by viewing the attribute editor.

The Extra Attributes rollout contains the Portal check box – it will contain a Heaven check box for Heaven portals, and an Exit check box for Exit portals.

After the portals have been assigned the shell is ready for export.

Creating hard points within Maya

This document is not meant as a substitute to the lesson Create Low-Polygon Characters, section Placing hard points on your character for attaching items – please read that section before continuing.

Hard points should be created as a polygon object, and represent the directions X, Y, Z of the object's node. This makes it easy to position the hard points in the appropriate place.

The shape, texture and geometry are only visual cues for the artist. The BigWorld engine requires only for the hard point to use the HP_ naming convention, and for it to be a node of the object that it is attached to.

For the purposes of this tutorial, we will be creating a hard point that will be positioned in the right hand of a character avatar.

1 Create and position a a suitable piece of geometry.

2 Select the Window → Hypergraph menu item – the Hypergraph window will be displayed.

3 Right-click the node, then select the Rename option.

4 Rename the node HP_RightHand.

5 Middle-click the HP_RightHand node, then drag it onto the parent RightHand node.

6 The hard point is now attached and ready to use.


BigWorld Shaders and Materials

  • Material properties
  • Material Kinds
  • BigWorld shaders
    • Multiple UV's and Vertex Colour
    • Skybox shaders
    • How to choose the correct shader
    • How to apply a shader in ModelEditor
  • Creating a rolling UV material
  • Saving a material MFM file

The *.fx files are a way of defining how an object is rendered within the BigWorld engine.

The *.mfm, or material files, are meta-data files that contain artist-editable features, including FX file, shader properties, and texture references. ModelEditor can create new material files that can be assigned to mesh objects.

Material properties

Bitmaps and artist-editable features are assigned and accessed by ModelEditor's Materials Settings panel. The available properties are determined by the type of BigWorld Shader (.fx) used.

The table below describes the most common properties shared between several materials:

Property | Description
Collision Flags

Camera On Player Off – Player does not collide with object; camera does. Object casts shadows by default.

Camera Off Player Off– Neither player nor camera collide with the object. Object does NOT cast shadows.

Camera On Player On– Both player and camera collide with object. Object casts shadows by default.

Camera Off Player On– Player collides; camera does not. Object casts shadows by default.

Material Kind Used for assigning particular sounds and particle systems to objects.

A wooden barrel should play a wood sound and emit wooden particles when shot at, for example.

The default setting (Use Visual's) uses the visual file's material kind.

material kinds are defined in bigworld/res/system/data/material_kinds.xml

New material kinds can be created by simply adding a new <kind> tag.

<kind>
        <id>	9	</id>
        <desc>	Snow	</desc>
        <sound> snow    </sound>
        <help> Hard crunchy snow. </help>
        <sfx>	sets/global/fx/sfx/sfx_pchang_snow.xml </sfx>
        <terrain> sets/t_ice/maps/terrain/ice_snow </terrain>
        <terrain> sets/t_ice/maps/terrain/ice_snow_pure </terrain>
        <terrain> sets/t_ice/maps/terrain/ice_snow_pure02 </terrain>
        <terrain> sets/t_ice/maps/terrain/snow_grass </terrain>
        <terrain> maps/landscape/ls2_snow01 </terrain>
        <terrain> maps/landscape/minspec_snow </terrain>
        <terrain> maps/landscape/minspec_mud </terrain>
</kind>
Texture Operation | Describes the mathematical functions used to blend textures together.
vTransform/uTransform | This property is described in lesson Create a New Material, section Creating a rolling UV material.
Alpha Reference Value at which an alpha-tested material reads a greyscale image as values of 1 or 0. Value range is between 0 and 255.

A value of 200 will read all areas of an image with a value greater than 200 as white, and all areas below it as black.

Alpha Test | Determines whether the alpha map of the material should be used.
Double Sided | Indicates whether the material can be seen from both sides.
Self Illumination | Intensity with which the material should be illuminated as if it was a light source.
Light Enable Indicates whether the material will receive lighting.

If set to False, then the texture's original colour will be displayed.

Diffuse Map Bitmap file containing the object's colour information.

The file must be 8-bits-per-channel RGB of format *.bmp or *.tga.

Specular Map Bitmap file containing specular colour and value information.

White areas represent specular highlights brighter than darker areas.

Normal Map Used to add fine details to shading, by representing normal direction – green = up, red = right, blue = height.

File must be 8-bit RGB *.bmp.

Sub Surface Map Bitmap file containing the object's subsurface colour information. Alpha channel controls the amount of subsurface scattering.

The file must be 8-bits-per-channel RGB of format *.tga.

Glow Map File containing information for self-illumination simulation.

The file must be 8-bits-per-channel RGB of format *.bmp.
Reflection Map Bitmap file containing an image to be used as a reflection upon the applied object.

normalmap_chrome shaders support .dds Cube Maps as reflection maps.

lightonly_chrome shaders use .bmp files as reflection maps.

Mask Map | Bitmap file containing an image that masks out the effect of some part of the current shader

Material Kinds

The file bigworld/res/system/data/material_kinds.xml contains the current set of predefined material kinds, and can be edited to customise the available material kinds, which are listed below:

▪ None (Default)
▪ Wood
▪ Stone
▪ Chain
▪ Light metal
▪ Heavy metal
▪ Glass
▪ Dirt
▪ Grass
▪ Snow

    <kind>
        <id>	1	</id>
        <desc>	Wood	</desc>
        <sound> wood    </sound>
        <help> Dull surfaces, not very reactive. </help>
        <sfx>	sets/global/fx/sfx/sfx_pchang_wood.xml </sfx>
    </kind>

Material Kinds allow you to script different sounds, effects, etc depending on what material is being interacted with.

Terrain textures can also be assigned a Material Kind

BigWorld shaders

BigWorld ships with some commonly used shaders, which can be found in the bigworld/res/shaders/std_effects folder.

The table below describes all standard shaders (FX files) included with BigWorld, and their common uses. New FX files can be added, provided they use the BigWorld lighting model.

File | Description
normalmap.fx | Objects with normal and diffuse maps. Bone deformation animations are performed on CPU. Object is affected by pre-calculated static lighting.
normalmap_skinned.fx | Objects with normal and diffuse maps. Soft-skinned (each vertex may have up to three bones influencing it) animations are performed on GPU. Object is affected by pre-calculated static lighting.
normalmap_glow.fx | Objects with normal, diffuse, and glow maps. Bone deformation animations are performed on CPU. Object is affected by pre-calculated static lighting.
normalmap_chrome.fx | Objects with normal, diffuse, and cube reflection maps. Bone deformation animations are performed on CPU. Object is affected by pre-calculated static lighting.
normalmap_chrome_skinned.fx | Objects with normal, diffuse, and cube reflection maps. Soft-skinned (each vertex may have up to three bones influencing it) animations are performed on GPU. Object is affected by pre-calculated static lighting.
normalmap_glow_alpha.fx | Objects with normal, diffuse (including alpha blend transparency, values of 1 to 256), and glow maps. Bone deformation animations are performed on CPU. Object is affected by pre-calculated static lighting.
normalmap_chrome_glow.fx | Objects with normal, diffuse, glow and cube reflection maps. Bone deformation animations are performed on CPU. Object is affected by pre-calculated static lighting. The reflection mask defines areas of reflectivity – white areas are highly reflective, dark areas are not.
normalmap_glow_skinned.fx | Objects with normal, diffuse, and glow maps. Soft-skinned (each vertex may have up to three bones influencing it) animations are performed on GPU. Object is affected by pre-calculated static lighting.
normalmap_specmap.fx | Objects with normal, diffuse, and specular maps. Bone deformation animations are performed on CPU. Object is affected by pre-calculated static lighting.
normalmap_specmap_alpha.fx | Objects with normal, diffuse (including alpha blend transparency, values of 1 to 256), and specular maps. Bone deformation animations are performed on CPU. Object is affected by pre-calculated static lighting.
normalmap_specmap_chrome.fx | Objects with normal, diffuse, specular maps and cube reflection maps. Bone deformation animations are performed on CPU. Object is affected by pre-calculated static lighting.
normalmap_specmap_chrome_skinned.fx | Objects with normal, diffuse, specular maps and cube reflection maps. Soft-skinned (each vertex may have up to three bones influencing it) animations are performed on GPU. Object is affected by pre-calculated static lighting.
normalmap_specmap_chrome_glow.fx | Objects with normal, diffuse, glow maps and cube reflection maps. Bone deformation animations are performed on CPU. Object is affected by pre-calculated static lighting.
normalmap_specmap_chrome_glow_skinned.fx | Objects with normal, diffuse, glow maps and cube reflection maps. Soft-skinned (each vertex may have up to three bones influencing it) animations are performed on GPU. Object is affected by pre-calculated static lighting.
normalmap_chrome_glow_skinned.fx | Objects with normal, cube reflection and glow maps. Soft-skinned (each vertex may have up to three bones influencing it) animations are performed on GPU. Object is affected by pre-calculated static lighting.
normalmap_specmap_skinned.fx | Objects with normal, diffuse, and specular maps. Soft-skinned (each vertex may have up to three bones influencing it) animations are performed on GPU. Object is affected by pre-calculated static lighting.
colourise_add.fx | Objects with diffuse map. Bone deformation animations are performed on CPU. Object is affected by pre-calculated static lighting. A single colour picker affects additively the object's existing colour.
colourise_normalmap_specmap_skinned.fx

colourise_lightonly_skinned.fx

colourise_subsurface_skinned.fx

Objects with diffuse, and mask maps. Soft-skinned (each vertex may have up to three bones influencing it) animations are performed on GPU. Object is affected by pre-calculated static lighting. Channels of mask map used to select regions of diffuse map for colourisation.

This shader is perfect for creating customisable character variations. Each channel of the mask map can define an area to be colourised.

Because the shader multiplies the customised colour with the existing diffuse colour, it is best to paint those sections to be colourised with almost 0 saturation (no colour), then brighten them somewhat, as the shader will only make them darker. (See diffuse image below).

The colourise_lightonly_skinned.fx version is a very efficient (single-pass) shader that allows the user to customise colours of areas (defined by channels in a mask texture) of the diffuse texture.

3 colour variations done with the shader

Diffuse map used with
the colourise shader –
note the desaturated
and lightened areas to
be colour customised

Channels of the mask
map define areas to
be colourised on the
diffuse map

Colours to be applied to
the colourised areas are
chosen ModelEditors's
Materials Settings panel

distort.fx

Objects with distortion (normal map), diffuse, and reflection (cube map). Bone deformation animations are performed on CPU. Object is affected by pre-calculated static lighting. The shader contains many editable parameters which can dramatically alter the appearance of the object it is applied to.

Fresnel falloff and fresnel constant control the way in which reflections fade off as a function of the viewing angle.

Reflection amount controls the reflectivity of the object, or how much of the cube map is displayed on the object's surface.

Distortion scale controls how strong the distortion map affects the scene behind the object – be sure to use a normal map as the distortion map.

This shader is great for semi-transparent objects that will distort the scene behind them. The classic example is stained glass or water.

Alpha test option will only work when the Use Diffuse Map option is set to True

lightonly.fx | Objects with a diffuse map (including alpha test transparency, values of 1 or 0 only). Bone deformation animations are performed on CPU. Object is affected by pre-calculated static lighting.
lightonly_alpha.fx | Objects with a diffuse map (including alpha blend transparency, values of 1 to 256). Bone deformation animations are performed on CPU. Object is affected by pre-calculated static lighting.
lightonly_chrome.fx | Objects with a diffuse map and transparency (within alpha blend, values of 1 to 256). Bone deformation animations are performed on CPU. Object is affected by pre-calculated static lighting. The alpha map of the diffuse channel defines areas of reflectivity – white areas are highly reflective, dark areas are not.
lightonly_chrome_add.fx | Objects with diffuse and additive reflective map. The combined diffuse and reflection map adds to the background. Used in special effects, explosions, and glass windows. Bone deformation animations are performed on CPU. Object is affected by pre-calculated static lighting. The alpha map of the diffuse channel defines areas of reflectivity – white areas are highly reflective, dark areas are not.
lightonly_chrome_alpha.fx | Objects with diffuse (including alpha blend transparency, values of 1 to 256) and reflection map. Bone deformation animations are performed on CPU. Object is affected by pre-calculated static lighting.
lightonly_vertexcolour.fx | Objects with a diffuse map and vertex colourisation support. Bone deformation animations are performed on CPU. Object is affected by pre-calculated static lighting.
lightonly_dual.fx | Objects with two diffuse maps. Diffuse map 1 uses UV channel 1, diffuse map 2 uses UV channel 2. Bone deformation animations are performed on CPU. Object is affected by pre-calculated static lighting.
lightonly_dual_multiply.fx

Objects with two diffuse maps. Diffuse map 1 uses UV channel 1, diffuse map 2 uses UV channel 2 and is multiplied with difuse map 1. Bone deformation animations are performed on CPU. Object is affected by pre-calculated static lighting.

Commonly used for baked ambient occlusion or baked shadow maps,
lightonly_glow.fx | Objects with diffuse and glow map. Bone deformation animations are performed on CPU. Object is affected by pre-calculated static lighting.
lightonly_glow_alpha.fx | Objects with diffuse map (including alpha blend transparency, values of 1 to 256), and glow map. Bone deformation animations are performed on CPU. Object is affected by pre-calculated static lighting.
lightonly_normal | Objects with diffuse map, and an additive texture projected from the camera space normals. Bone deformation animations are performed on CPU. Object is affected by pre-calculated static lighting.
lightonly_normal_add.fx | Objects with diffuse map, and an additive texture projected from the camera space normals. Blends additively with the background. Bone deformation animations are performed on CPU. Object is affected by pre-calculated static lighting.
lightonly_normal_alpha.fx | Objects with diffuse map (including alpha blend transparency, values of 1 to 256), and an additive texture projected from the camera space normals. Bone deformation animations are performed on CPU. Object is affected by pre-calculated static lighting.
lightonly_projection.fx | Objects with diffuse map, and an additive reflection texture mapped from world space. World space texture will stay still even as object moves around the world. Bone deformation animations are performed on CPU. Object is affected by pre-calculated static lighting.
lightonly_projection_add.fx | Objects with diffuse map, and an additive reflection texture mapped from world space. World space texture will stay still even as object moves around the world. Blends additively with background. Bone deformation animations are performed on CPU. Object is affected by pre-calculated static lighting.
lightonly_projection_alpha.fx | Objects with diffuse map (including alpha blend transparency, values of 1 to 256), and an additive texture mapped from world space. World space texture will stay still even as object moves around the world. Bone deformation animations are performed on CPU. Object is affected by pre-calculated static lighting.
lightonly_skinned.fx | Objects with diffuse map. Soft-skinned (each vertex may have up to three bones influencing it) animations are performed on GPU. Object is affected by pre-calculated static lighting.
lightonly_uvtransform.fx | Objects with diffuse map, and an additive texture with rolling UVs. Bone deformation animations are performed on CPU. Object is affected by pre-calculated static lighting.
lightonly_uvtransform_add.fx | Objects with diffuse map, with rolling UVs. Blends additively with the background. Bone deformation animations are performed on CPU. Object is affected by pre-calculated static lighting.
lightonly_uvtransform_alpha.fx | Objects with diffuse map (including alpha blend transparency, values of 1 to 256), and an additive texture with rolling UVs. Bone deformation animations are performed on CPU. Object is affected by pre-calculated static lighting.
lightonly_uvtransform2.fx | Objects with diffuse map, and an additive texture with rolling UVs. Primary diffuse map also has rolling UVs. Bone deformation animations are performed on CPU. Object is affected by pre-calculated static lighting.
lightonly_uvtransform2_add.fx | Objects with diffuse map, with rolling UVs .Primary diffuse map also has rolling UVs. Blends additively with the background. Bone deformation animations are performed on CPU. Object is affected by pre-calculated static lighting.
lightonly_uvtransform2_alpha.fx | Objects with diffuse map (including alpha blend transparency, values of 1 to 256), and an additive texture with rolling UVs. Primary diffuse map also has rolling UVs. Bone deformation animations are performed on CPU. Object is affected by pre-calculated static lighting.
lightonly_uvtransform2_alpha_mask.fx | Objects with diffuse map (including alpha blend transparency, values of 1 to 256), and an additive texture with rolling UVs. Primary diffuse map also has rolling UVs. A mask map controls the transparency of the primary texture. Bone deformation animations are performed on CPU. Object is affected by pre-calculated static lighting. Commonly used for water effects
lightonly_add | Objects with diffuse map, and an additive texture. Bone deformation animations are performed on CPU. Object is affected by pre-calculated static lighting.
parallax_lighting_specmap.fx | Objects with diffuse, normal, specular, and displacement (height) maps. Displaces UV coordinates as a function of the heightmap away from the camera view. Gives the appearance of 3D geometry. Best used on flat/semi-flat objects, such as brick walls. Commonly referred to as parallax or displacement mapping. Bone deformation animations are performed on CPU. Object is affected by pre-calculated static lighting. Note: The displacement map is stored in the alpha channel of the normal map.
shimmer.fx | A transparent heat like shimmer effect, commonly seen above heat sources. Alpha channel defines localised shimmer intensity. The opacity parameter affects the overall intensity. Requires a diffuse map. Bone deformation animations are performed on CPU. Object is not affected by pre-calculated static lighting.
spintoface_add.fx | Objects with diffuse map. Blends additively with the background. Object will spin to face the camera. Bone deformation animations are performed on CPU. Object is not affected by pre-calculated static lighting.
stdinclude.fx | Utility FX file not used by artists – it has components referenced by all other FX files.
subsurface_skinned.fx Objects with diffuse, specular, and sub surface maps. The skinned version performs soft-skinning on GPU (each vertex may have up to three bones influencing it).

This advanced shader uses the angle of light and camera to simulate the sub-surface scattering that occurs when light enters skin.

It also simulates rim/bounced lighting, by increasing the luminance of the side of the model facing away from the primary light source.

The amount of the sub-surface scattering is controlled by the alpha channel of the sub surface map, and its colour is controlled by the RGB channels.

As well as simulating sub-surface scattering, these shaders simulate bounced light on the non-illuminated side of the object.

The rim lighting strength and angle is controlled by the Rim Strength and Rim Width settings.

When painting a sub surface map for human skin, consider the thickness of the surface – thicker parts end up dark red, while membranes and areas next to bone end up light orange.

Gradient of colour used to define areas – from thicker areas (left) to thinner membranes (right)

Example sub surface map and its alpha channel

Areas of thick skin and flesh are dark red, while areas close to the bone are light orange.

Dark areas of the alpha map (such as the hair and beard) reduce the amount of sub-surface scattering.
ambient_skylight_skinned.fx

Objects with diffuse, specular, and sub surface and mask maps. performs soft-skinning on GPU (each vertex may have up to three bones influencing it).

This shader creates two lights (See image, Key and Fill) that illuminate the object in camera space. The effect of these lights on the model is inversely modulated depending on the proximity of dynamic lighting.

Therefore if there is no scene lighting your model will be lit using the lighting setup defined in the shader.

Channels of mask map used to select regions of diffuse map for colourisation.

This advanced shader uses the angle of light and camera to simulate the sub-surface scattering that occurs when light enters skin. It also simulates rim/bounced lighting, by increasing the luminance of the side of the model facing away from the primary light source.

The amount of the sub-surface scattering is controlled by the alpha channel of the sub surface map, and its colour is controlled by the RGB channels.

Multiple UV's and Vertex Colour

BigWorld supports multiple UV's and Vertex colour exported from both 3dsMax and Maya

The shader lightonly_dual.fx supports multiple UV's and is intended as an example on top of which more complex multiple UV shaders can be written by your team. Information on how to create dual UV's can be found here

The shader lightonly_vertexcolour.fx supports vertex colour information and is intended as an example on top of which more complex vertex colour shaders can be written by your team. Information on how to create vertex colour can be found here

Skybox shaders

Information regarding the use of skybox shaders can be found here

How to choose the correct shader

When choosing a shader there are several questions you should ask yourself:

Do I want to use normal-mapped or standard lighting?

Shaders with the normalmap inclusion will use normal maps to calculate their lighting; shaders with the lightonly inclusion will use standard lighting.

Do I want to use Glow, Chrome, Rolling UVs?

Shaders with the glow inclusion use a glow map to self-illuminate the object; shaders with the chrome inclusion use a cube reflection map to simulate reflections from the environment; shaders with the uvtransform inclusion contain parameters to allow rolling UV coordinates.

Do I want to use Alpha Test or Alpha Blend?

Shaders with the alpha inclusion use the diffuse map's alpha channel for opacity, enabling blend values from 1 to 256 (8-bit).

Please note that many other non alpha shaders contain alpha test, which will clamp the blend value to either 1 or 0 (2-bit) as defined the by the shader's alpha reference setting. If the alpha reference setting is set to 128, then all values above 128 will be regarded as a blend value of 1 (opaque) and all the values below will be regarded as a blend value of 0 (transparent).

Does your object have allot of self-intersection? When using alpha blended shaders self-intersection can lead to artifacts in the polygon sorting.

Alpha blended shaders do not use GPU skinning, so if your alpha blended model is skinned all animations will occur on the CPU (slower).

When possible use alpha test rather than blend. Alpha blended objects require sorting, excessive use of blended shaders will result in poor game performance.

Do I want to use Skinned, or Static?

Shaders with the skinned inclusion perform soft-skinning (each vertex may be influenced by up to three bones) on the GPU. Objects using 3ds Max's Skin, or Physique modifiers, or Maya's Skinning should use a skinned shader.

Please note that it is extremely important that when choosing a shader for a skinned object, that you use a skinned shader. Skinned shaders perform bone translations on the GPU, which is a much faster way than the alternate (CPU). If the CPU is forced to calculate animations, there may be a performance hit.

Are there going to be performance issues?

This is probably the most important, yet least thought of question. The more advanced shaders (those that use normal maps, subsurface and parallax mapping) are more costly in performance terms when compared with those that do not. Use these shaders wisely.

Should I create my own shaders?

Ultimately, we cannot offer every combination of shader available, because the list is infinite. Most customers will choose to create several of their own shaders for special case purposes.

How to apply a shader in ModelEditor

From ModelEditor's Asset Browser panel, select the Effects virtual folder. This gives you access to all BigWorld shaders.

To apply a shader to a model, simply drag it in the Material Settings panel's Effect drop-down list box.

BigWorld shaders can also be directly applied to models within 3dsMax (not supported for Maya). For information on how to do this, see the Create and Export a Static Object in 3ds Max and Maya lesson's Apply BigWorld shaders directly to 3ds Max models section.

Creating a rolling UV material

The series of shaders with suffix uvtransform, such as lightonly_uvtransform.fx, allow the artist to create a rolling UV effect. To create this effect on your object simply drag a uvtransform shader from the Asset Browser pane's Effects virtual folder into the Material Settings panel's Effects drop-down list box.

Choose a texture map that you want to roll across the surface by double-clicking the Transform Map property in the Material Settings panel. Alternatively, you can drag one from the Asset Browser panel.

The vector properties allow you to control the tiling, offset, speed and direction of the rolling UVs.

The UV tiling is determined by the first value in the U Transform property and by the second value in the V Transform property. A value of 2 will cause the texture to be tiled twice over the normal UV range.

The rotational offset of the UV coordinates is determined by the second value in the U Transform property and by the first value in the V Transform property.

The scroll speed of the moving texture is determined by the third value in the U Transform and the V Transform properties.

The initial UV offset of the texture is determined by the fourth value in the U Transform and the V Transform properties.

Saving a material MFM file

An existing model's material settings can be saved as a .mfm file. This allows artists to store complex material setups to be applied on different models.

1 Select the Material Settings panel.

2 Select the material that you wish to save as an MFM.

3 click the [image] button – this will open the Save As dialog box.

4 In the Save As dialog box, specify the folder and the name of the material file that you want to save, then click the Save button.

To apply an MFM file to an existing material, click the [image] button and select the desired file.


Create Custom BSPs

  • BSP definition
  • Creating a BSP for an animated object
  • Custom BSPs and material collision flags
  • Navigation
    • Vertical navigation limits

BSP definition

BSPs (Binary Space Partitioning) are used by the BigWorld engine to calculate object collisions and terrain shadows. The BigWorld's Visual Exporter automatically creates BSPs for non-animated objects.

There are several reasons you may want to create a custom BSP:

To define what parts of a model can be collision obstacles.

To reduce the memory used on the server by using custom BSP's with fewer polygons than the rendered model

To define which parts of an object create shadows.

To create a BSP for an animated object (BigWorld's Visual Exporter does not create BSPs for animated objects automatically).

Creating a BSP for an animated object

The tree below is animated, and therefore a BSP is not created when the object is exported.

To create a BSP, build a lower-polygon mesh that closely represents the object (LOD meshes can be useful for this purpose). Take extra care to match the mesh as close as possible in areas where player/object collisions will take place.

Name the lower-polygon mesh with the suffix _bsp, and export the object as normal. Do not hide the BSP model.

The model should now have a custom BSP, which can be checked in ModelEditor – make sure that the Display Settings panel's Show Box check box is selected.

Custom BSPs and material collision flags

Material collision flags are set in ModelEditor's Material Settings panel, and define what an object collides with.

The Collision Flag drop-down list box options are described in the table below:

Option | Description
Camera On Player On | Object collides with both the camera and the player.
Camera On Player Off | Object collides with the camera, but not with the player.
Camera Off Player On | Object collides with the player but not the camera.
Camera Off Player Off | Object does not collide with anything.

An object that collides with the player prevents the player from moving through that object.

Camera collision is slightly more complicated. The default camera type in Fantasy Demo draws a ray from the camera to the player. If an object that collides with camera ray then the camera will be said to have collided with that object. In the case of the Fantasy Demo this causes the camera to move forward through the colliding object until it can see the player.

Individual parts of a custom BSP can be assigned different material collision flags, if the custom BSP model is assigned material names matching the host model.

Navigation and art

Vertical navigation limit

There are a few restrictions to navigation that artists should be aware of.

There can be a maximum of 15 vertical navigation points at any one point in a chunk. This means that you should not create an asset such as a building that has more than 15 navigatable vertical levels. This doesn't rule out high rise apartments, it just means that if you do create such an asset you must divide those vertical levels into shells which will also give you the added bonus of better portal occlusion.


Create Decal Textures

  • Creation guidelines

Decals are images added dynamically on top of objects on the world to simulate effects such as damage and bullet holes.

The grenade explosion below triggers code to place a decal on the ground.

Keep in mind that the decal system in the BigWorld client projects decals onto the scene by performing an intersection test and clips the decal geometry to the underlying collision BSP. As such, visual artifacts may occur (e.g. floating decals) if the collision BSP differs significantly from the visual mesh.

Creation guidelines

Decals work differently to most alpha transparency textures. The rules that you must adhere to when making decal textures are described in the table below:

Item | Rule
Size | Decals must be 64x64 pixels.
Dark values Decals are not affected by the game lighting, so lighter decals will appear to glow at night.

For this reason, it is recommended that you stick with dark colours.

Alpha channel Decals must have an alpha channel, to mask the background to which they are applied, not the decal texture – the example below illustrates this point.

Colour channel of the
explosion decal shown above

Alpha channel of the
explosion decal shown above

Invisible borders Decal maps are joined together as one large bitmap in the BigWorld engine. It is therefore important to make sure that the border of the alpha channel is pure white (255,255,255), and the border of the colour channel is pure black (0,0,0).

If these channels are not set up correctly, then sampling will cause the alpha channels and/or colour channels to leak into each other, resulting in visible borders on your decal textures.

Remember that the decal is blended additively, so even if the alpha channel is white on the border, any colour values above pure black will create a visible border.


Create Trees And Billboards With Better Lighting

  • Using the mungenormals script

This section applies only to customers not using SpeedTree.

Trees can be one of the most difficult objects to light correctly, due to the way in which they are made. Most trees are made using a series of billboards that splay outwards in multiple directions from branches. The vertex normals (used for lighting) of these billboards point in many directions, and therefore do not light correctly.

3ds Max 7 has the Edit Normals modifier, that allows users to manually change the normals of each vertex. Manually changing the vertex normal of each billboard would take a long time, so we created a MaxScript that allows the user to edit the direction of multiple vertex normals with a single click.

In the example bellow, you can see that without editing the normals of the billboards, the tree is incorrectly lit within the game – although the sunlight comes from the left of the picture, some branches on the right are completely lit, while some on the left are in shadow. Note the blue lines in the second picture indicating the direction of the normals.

In the following example, we have used the MaxScript mungenormals.ms to edit the normals of the model, so that they point outwards from the inside of the tree (see green lines). This causes the billboards to light correctly as the sun travels overhead. You can see in the first picture that the left side of the tree is completely lit, while the right side is in shadow.

The tree below is an example of where no normal editing was required. All billboards face outwards from the main branch, and as a result all normals point towards the sky. This results in the tree lighting correctly as the sun travels overhead.

Using the mungenormals script

To use the mungenormals script follow the steps below, or you can use the BigWorld Maxscripts toolbar to execute the script.

1 Copy the mungernormals.ms MaxScript from the bigworld/tools/misc folder to 3dsMax/scripts folder.

The mungernormals script works by splaying all the vertex normals away from a selected object. For this reason, we added a dummy in the centre of the tree from which the normals will point away.

2 Apply the Edit Normals modifier to the object on which you want to run the script. The modifier should be the last one in the stack, so if you are animating the tree as we have below, then add the modifier after the Physique/Skin modifier.

3 If you cannot see the blue normals as displayed above, then you might need to increase the Parameters rollout's Display Length value in the Edit Normals modifier.

4 In the Edit Normals modifier, select the Normal sub-component, then marquee select all vertex normals that you wish to change with the mungernormals script.

5 Select the MaxScript→Run Script menu item – the Choose Editor File dialog box will be displayed.

6 In the the Choose Editor File dialog box, select the mungernormals.ms script, then click the OK button – the pointer within 3ds Max will turn into a selection pointer.

7 Select the dummy placed in the middle of the tree (you might have to zoom in to get a clear shot) – all vertex normals should splay outwards from the dummy.

8 Hide the dummy and export your model with the Edit Normals modifier selected.

Now your tree should be correctly lit within the game.

If you are animating your trees, then you will need a custom BSP – if that is the case, then please read the lesson Create Custom BSPs.


Using SpeedTree in the BigWorld engine

  • Placing SpeedTrees in the world through World Editor
  • Hints and Tips
    • Values and Colours
    • Specular Lighting
    • Leaf Dimming
    • Reduce wasted texture space
    • How many billboards and what size texture?
    • Billboard lighting
  • Defining a trees collision volume
  • Engine generated files
  • SpeedTree LOD
  • SpeedTree and Wind

Please note that SpeedTree is an optional add-on to the BigWorld package. Speed Tree CAD is supplied with the SpeedTree licence – it is not part of the BigWorld toolset.

Describing all the functionality of SpeedTree CAD is beyond the scope of this tutorial. All the documentation on how to create your own trees can be found with the SpeedTree package.

All the trees packaged within BigWorld were made using SpeedTreeCAD 4.2

Placing SpeedTrees in the world through World Editor

SpeedTrees can be accessed in WorldEditor via the Asset Browser panel's Trees virtual folder.

To place a tree simply, select it in the Asset Browser panel, then either drag it into the desired location in the viewport, or position the mouse cursor over the desired location then press Enter. SpeedTrees can now be moved, rotated and scaled, just like any other object.

When placing trees, it can be handy to set (in the Object Tool panel) the Locking Mode to Terrain.

Hints and Tips

Values and Colours

Many textures shipped with SpeedTree use a low range of values (see example below). If you use the stock SpeedTree textures, it can be useful to play with the values and colours to match the colours of other texture in your game. For FantasyDemo, the value and colour saturation was increased.

Lower range of levels of texture shipped with SpeedTree

Adjusted levels and colours to use more range

Specular Lighting

Both the normal map and the normal maps alpha chanel effect the specular values of the tree.

The normal map alters the leaf geometry's normal (angle at which the light effects it). Whilst the alpha map determines how strong the specular highlight will be.

Generally, specular highlights tend to appear on half of the leaf surface due to the folded shapes of leaves.

The specular lighting of SpeedTree leaves can be significantly improved by authoring the leaf billboard normal maps by hand.

Half the leaf shines with a low gloss highlight

1 To author the leaf normal maps we need to create a colour pallet.

2 Create a radial gradient in Photoshop

3 Convert that gradient into a normal map using Nvidias Photoshop Plugins

4 This converted texture will now be used as our colour pallet for hand painting the leaf normals.

5Take the leaf diffuse map into Photoshop and choose normal colour (directions) from the colour pallet that best represent the direction of the leaf face.

6 Be sure to paint outside the bounds of the leaf where possible. This will ensure you get a nice even highlight across the half of the leaf.

Leaf Dimming

The leaf dimming parameter defined in SpeedTreeCAD's Lighting tab is used by the BigWorld engine to darken some of the trees billboards. If excessive dimming is used it can result in sections of the tree appearing too dark.

Note: Only shader model 3 uses the dimming feature.

An example of excessive leaf dimming, note the excessively shadowed leaves

Reduce wasted texture space

When SpeedTree creates a composite map, it takes all the separate textures used to create a tree and tries to fit them into the smallest possible space.

Sometimes, textures can be created that have a large amount of wasted texture space – this usually occurs because of an abnormally-sized frond texture.

In the example below, the frond texture was resized so that the composite map would fit into a 1024x1024 space.

Before resize

After resize

How many billboards and what size texture?

Most SpeedTrees in FantasyDemo use six vertical, plus one horizontal billboard, each at 128x128 pixels.

For very large trees or tree clusters, it is recommended that you test the effectiveness of your billboards from different angles. If they do not look right, then increase the number and/or size of the textures.

Billboards do not need to be power of 2 textures, you can use the Adjust Billboard Sizes slider to make the billboards fit comfortably in the composite map.

Most common settings used to export trees from SpeedTree Cad into FantasyDemo

Billboard lighting

If you are using normal mapping on SpeedTree billboards then make sure you turn on the Uniform lighting option when exporting the composite map. This will ensure that there is no directional lighting baked into the billboard maps.

Defining a tree's collision volume

Collision geometry for SpeedTrees is defined within SpeedTree Cad – to view the collision objects, press the Toggle Collision Objects ( ) button's drop-down arrow, then select its shape (in the example below, we selected the Add Box menu item).

Move the collision objects around until they look similar to the tree's geometry. It's best to use simple collision volumes, cubes are much more efficient than spheres, try to avoid spheres as much as possible.

There is no need to define the collision volume of the trunk. BigWorld uses the trunk geometry as collision data automatically.

Be careful when defining the collision objects for the foliage – if they hang too low, then the player will bump into them.

You can see In WorldEditor the collision geometry defined in SpeedTree Cad and the automatically generated trunk collision volume by selecting the General Options panel's Show group box's Scenery→BSP check box.

Engine generated files

When a SpeedTree is first placed in WorldEditor two files will be created.

1. .bsp2 file (A collision scene file)

2. .ctree file (A cached tree file)

These files need to be saved to your project. If you are using source control, make sure they are committed.

SpeedTree LOD

SpeedTree Level of Detail (LOD) settings can be defined within the speedtree.xml file located in C:\mf\bigworld\res\system\data\speedtree.xml

Most of the parameters defined within speedtree.xml can be changed (preview only) whilst the client is running using the client watchers ~(tilde) + F7, 13 [SpeedTree],

The contents of the speedtree.xml file are as follows. Comments within the xml file should explain how the parameters effect SpeedTree.

<speedtree.xml>
    <lodMode> -2 </lodMode>
    <!-- lodMode to use:
        -1: dynamic (near and far LOD defined per tree using speedtreeCAD defined values);
        -2: dynamic (use global near and far LOD values);
        [0.0 - 1.0]: forces static value.
    -->

    <lodNear> 40 </lodNear>
    <!-- Distance from camera at which trees will start
        to display maximum detail. Only used if lodMode is -2 -->

    <lodFar> 200 </lodFar>
    <!-- Distance from camera from which trees be rendered
    as billboards only. Only used if lodMode is -2 -->

    <lod0Yardstick> 60 </lod0Yardstick>
    <!-- Trees taller than the yardstick will LOD to billboard farther than LodFar.
    Trees shorter than the yardstick will LOD to billboard closer than LodFar.
    This should be set to average the height of your trees-->

    <lod0Variance> 0.3 </lod0Variance>
    <!-- How much will the lod level vary depending on the size of the tree -->

    <speedWindINI> system/data/speedwind.ini </speedWindINI>
    <!-- Global SpeedWind setup file -->

    <fxFiles>
        <branches> 		shaders/speedtree/branches.fx 	</branches>
        <leaves> 		shaders/speedtree/leaves.fx 	</leaves>
        <billboards> 	shaders/speedtree/billboards.fx </billboards>
        <shadows> 		shaders/speedtree/speedtree_shadows.fx </shadows>
    </fxFiles>
    <!-- Effect file used to render trees -->

    <billboardOptimiser>
        <fxFile>	shaders/speedtree/billboards_opt.fx	</fxFile>
        <enabled>	true </enabled>
        <textureAtlas>
            <!-- The optimiser will create one big
            texture to hold all billboards -->

            <minSize>	128	</minSize>
            <maxSize>	2048	</maxSize>
            <mipLevels>	7		</mipLevels>
            <!--
                2^(mipLevels-1) should not
                be greater than minSize
            -->

            <save>			false	</save>
            <!-- If true, will save the texture atlas into a file called
            bboptimiser.dds, in the current work dir. This can be useful
            for debugging and also to tune the ideal parameters of the
            texture atlas. The file will be resaved for every new tree
            type read from disk. So, make sure all tree types have been
            loaded before making any decision based on this file. -->

        </textureAtlas>

        <buffers>
            <framesToRecycle>	5		</framesToRecycle>
            <!-- number of frames before a buffer is
            made available for reuse by a new chunk -->

            <framesToDelete>	100	</framesToDelete>
            <!-- number of frames since last time before a
            buffer is permanently deleted -->

        </buffers>
    </billboardOptimiser>
</speedtree.xml>

SpeedTree and Wind

SpeedTree Trees are effected by in game wind. How they are effected is controlled by the speedwind.ini file located in bigworld\res\system\data\speedwind.ini. This file is a global setting for all trees.

If you want each tree to have its own speedwind setting you must include a separate speedwind.ini file in the directory containing the tree. Having separate speedwind.ini files per tree is less efficient than having one global setting and may slow engine performance.

The following properties of the speedwind.ini file are described in SpeedTree CADs User Reference document under the heading SpeedWind dialog.

NumWindMatricesAndLeafAngles 6 8
WindResponseAndLimit 0.4 0.01
MaxBendAngle 70
BranchExponent 3
LeafExponent 0.8
GustStrengthMinMax 0.1 0.5
GustDurationMinMax 2 5
GustFrequency 0.166667
BranchOscillationX_LaLsHaHs 2 3 15 4
BranchOscillationY_LaLsHaHs 1 3 65 3
LeafRocking_LaLsHaHs 1 3 5 15
LeafRustling_LaLsHaHs 2 3 5 10

These settings correspond with the settings available in SpeedTreeCAD under the Edit SpeedWind parameters

The effect of changes to the speedwind.ini file can be previewed in the client using the client watchers

~(tilde) F7 - Client settings - Weather - WindVelX and WindVelY

The maximum wind speed is 15.

Wind speed and gustiness is defined by the weather system


Morph Targets and Blend Shapes

  • Morph target restrictions
  • 3ds Max Morph Targets
    • Exporting 3ds Max Morph Target Visuals and Animations
  • Maya Blend Shapes
    • Using blendshapes with skeletal animation
    • Exporting Maya Blend Shapes

The BigWorld engine supports both Mesh Morph Target from 3ds Max and Mesh Blend Shapes from Maya. It does not support UV mapping morph targets.

Morph targets are commonly used for facial expressions and lip sync, although by no means are they restricted to these uses.

When making facial animations, it is best to create a base relaxed pose, and have all the morph targets added to this base.

Morph targets must contain the same vertex count as the base object. It is therefore recommended to create your morph targets only when the character has been taken as far down the art pipeline as possible. A single revision at the mesh level will require the recreation of all your morph targets.

The vertex morph animation is relative to the local coordinate system of the morph target. This allows you to place all morph targets anywhere in the scene. Do not alter the morph target's local coordinate system, otherwise all the vertices will offset relative to that local coordinate change when the animation is played.

Morph targets in 3dsMax placed around the player character

Morph target restrictions

There are several restrictions and rules that need to be followed in order for morph targets to work.

The order of morph and skin matter: In both 3dsMax and Maya the morph targets must be applied underneath the skinning otherwise the result seen in BigWorld will differ to the result seen in the 3d App.

Do not alter the vertex count after creating morph targets: Once a morph target has been added you cannot make changes to the mesh which will alter the vertex index. Alterations that commonly effect vertex index include (cutting, extruding, dividing, turn edges, adding geometry, removing geometry). Note: Alterations that do not modify the vertex index such as moving vertices should be OK, but I advise testing your workflow on a simple cube before starting on a character.

3ds Max Morph Targets

In 3ds Max, the typical workflow for creating morph targets is to make copies of the base object and move vertices within these copies to create the morph targets. Alterations must not affect the vertex count of the copied object. So operations like cut, divide, and extrude cannot be used.

Morph targets in 3ds Max are added using the Morpher modifier.

1 Select your base object and add a Morpher modifier.

2 Click either the Pick Object from Scene or the Load Multiple Targets button to select the morph targets to use for the base object.

3 Once the targets have been added to your object, set key frames for the sliders to create your animation.

Exporting 3ds Max Morph Target Visuals and Animations

Before exporting your morph target model, make sure you hide all morph targets and set them to 0%. If you exported the visual mid animation that exported pose would be used as the neutral position. Subsequent animations added to the model would play on top of this "neutral" pose.

Morph targets set to neutral pose 0% on export of visual.

1 Export the object as an animated visual.

2 Export the animations with the Export Morph Animation selected.

Maya Blend Shapes

To add blend shapes to an object in Maya, follow the steps below:

1 Firstly ensure that all your blendshape objects have a uniqe name.

2 Shift select all the blend shape objects then shift select the base object (the base object must be selected last).

2 Select the Create Deformers → Blend Shape→ [image] menu item – the Create Blend Shape Options dialog box will be displayed.

3 In the Create Blend Shape Options dialog box's Basic tab:

A In the BlendShape Node field, type the name of your blend shape.

B Click the Create button.

To view and animate your blend shapes, you can select the Window → Animation Editors → Blend Shape menu item – the Blend Shape dialog box will be displayed.

Using blendshapes with skeletal animation

When using morphs on a skinned object it is important to create the blend targets first, then skin the object.

If you create the blend shapes after skinning the mesh will animate differently in BigWorld than it does in Maya.

Exporting Maya Blend Shapes

Before exporting your blend shape model, make sure you hide all blend shapes and set them to 0%. If you exported the visual mid animation that exported pose would be used as the neutral position. Subsequent animations added to the model would play on top of this "neutral" pose.

Blend shapes set to neutral pose 0% on export of visual.

To export the blend shape animation, follow the steps below:

1 Select the File → Export All menu item – the Export dialog box will displayed.

2 In the Export dialog box, specify the folder, file name, and file type (BigWorld Asset) of the animation, then click the Export button – the Visual Exporter dialog box will be displayed.

3 In the Visual Exporter dialog box, select the Visual options button and the Animated Type group box's Animated, skinned option button, then click the OK button.


Add Water to the World

  • Adding water in WorldEditor
  • Water surface
    • Multiple water surfaces
  • Water properties
  • Custom water surfaces
    • Lightonly_uvtransform2_alpha_mask.fx for water surfaces
    • water_surface.fx for water surfaces

Adding water in WorldEditor

All water objects that can be rendered at the same time should be placed at exactly the same Y height. If they are placed at different heights the reflection will update at half the speed resulting in visual artifact.

To place a body of water in the world using WorldEditor, follow the steps below:

1 On the Asset Browser panel, select the Misc virtual folder.

2 Select the water.xml asset – this ffile is located under bigworld/res/helpers/misc folder

3 Drag the asset to the desired location in the viewport, then drop it.

The water can then be resized and tweaked to the desired state as any other object in the world, except for the rotation, which is limited to the Y axis.

Water surface

The water effect is created through an FX shader that combines render target textures for reflection and refraction using a Fresnel term.

The ripples on the surface are defined with a normal map in wave texture property, and is animated with two sets of parameters. The default map is bigworld\res\system\maps\waves2.dds.

If simulation is enabled (by use simulation property), then the water surface will combine the output of the simulation in the ripples and lighting.

An alpha value is generated per vertex (based on height above terrain) to fade out at the edges. This feature is toggled by the use edge alpha property.

Multiple water surfaces

If you put multiple water surfaces into your space and wish to use the real time reflection, they should be positioned at exactly the same height (Y position).

When using real time reflections the engine will update the reflections of multiple water objects sequentially. i.e if they are positioned at different heights. If you have two or more water objects drawn in the same scene the reflection updates will slow down and appear to skip frames.

Water properties

The water automatically generates the mesh required, taking into account the terrain shape to fade the edges of the water. The fading uses an alpha value, which can be switched off via the use edge alpha property. The texture used is defined by the wave texture property.

It is recommended to choose a surface which size is as a multiple of the mesh size.

It is not advisable to have multiple water objects close to one another, unless they maintain the same Y position.

Water simulation is automatically turned on, and can be disabled by the use simulation property.

Wave animation is defined by animating texture coordinates through the properties in the table below:

Property
wind speed
wave scale
scroll speed 1
scroll speed 2

The table below lists the properties of the water item:

Property | Description
consistency | The surface simulation propagation decay. A value of 1.0 means no decay in the wave movement.
fresnel constant | Fresnel reflection constant. Defines the minimum amount of reflection.
fresnel exponent | Fresnel reflection falloff exponent. Used to vary the falloff of reflection as the angle between the surface and the eye position varies.
mesh Size | Size of the individual surface triangles. Higher values result in a surface with fewer triangles; lower values increase the triangle count. It is recommended to have a mesh which size isa multiple of the surface's size. For seeing the effect of this property, it is useful to selected the General Options panel's Show group box's Terrain→Wireframe check box.
orientation | Water surface rotation.
position | Water surface position.
reflection strength | Scale of distortion that the reflections receive from wave animation.
reflection tint | Colour of the water reflections.
refraction Strength | Scale of distortion for the refraction.
refraction tint | Colour of the water refraction.
scroll speed 1 | Texture coordinate animation for the first of the two textures combined to construct the water wave animation.
scroll speed 2 | Texture coordinate animation for the second of the two textures combined to construct the water wave animation.
sim cell size | Size of the simulation cell divisions in the surface. Large values make more visible the artifacts in the simulation, as the texture will be stretched over a larger area; small values increase the detail of the simulation (best used only on small areas of water).
size | Water surface scaling.
sun Power | Amount of specular highlight on the water surface. Higher values result in a smaller, sharper highlight.
sun Scale | Amount of specular highlight on the water surface. Higher values result larger wider highlight.
fade start depth | The point at which the depth fogging starts to occur.
foam intersection | The depth at which the foam texture is displayed. Small values cause foam to appear over deep areas, larger values will cause the foam to only appear over shallow areas.
foam multiplier | A multiplier on the foam texture. Larger values will make the foam texture stronger
surface smoothness | Influence of the wave animation in the surface.Mbr> 1.0 means no influence, 0.0 (default) means full influence.
foam tiling | A UV tiling paramerter for the foam. Larger values will cause the foam texture to till more.
faom texture | Path to the texture dfining the foam.
texture Size | Virtual size of the individual surface triangles. Similar to mesh Size, except that it is more of a virtual triangle size, because it only applies to the tessellation of the texture coordinates for the surface.
use edge alpha | Toggles transparency of the water's edge.
use simulation | Toggles the water simulation.
wave scale | Scale to apply to either texture map by wave texture animation (X value for texture map 2, Y value for texture map 2).
wave texture | Texture file used to define the surface waves.
wind speed | Scale to apply to the wave animation speed.

Custom water surfaces

Lightonly_uvtransform2_alpha_mask.fx for water surfaces

When creating a body of water you do not have to use the water surface "water.xml" object.

It is possible to create a water surface using existing BigWorld shaders and custom geometry. Though many of the advanced properties of the water surface will not be available, such as the dynamic interactions.

The above image is of the stream.model in in the fantasy demo. The predominant effect is generated using the lightonly_uvtransform2_alpha_mask.fx shader and several tricks with the geometry.

Firstly the UV's of the above mesh are warped like so that when the water texture scrolls across its surface it appears to have allot of turbulence.

Secondly the surface is not flat. A noise modifier was used to give the surface several morph target shapes which loop in an animation simulating rapids in a fast flowing stream.

water_surface.fx for water surfaces

Another shader that is particularly suited to creating custom water volumes is the water_surface.fx shader

This particular shader uses a cube map for water reflections and a normal map for its surface ripples.


Using greyscale heightmaps to edit terrain

The Project view and using greyscale heightmaps to edit terrain

  • Project view
  • Creating heightmaps
    • Heightmaps for level design prototyping
  • Importing heightmaps
  • Exporting heightmaps

Project view

The project view [image] gives the user a top down view of the scene. This view can be used for navigation purposes (middle clicking on the project view will navigate the user to the chosen point), or for generating a minimap. Each chunk is photographed and a copy of this photograph is stored in the chunks corresponding .cdata file and a compilation of all the chunks is written to the space.thumbnail.dds file located in the space fodder.

The dimensions photographed by the project view can be modified by altering the space.settings file <bounds> tag, each number refers to an offset of chunks from the origin.

<bounds>
<minX> -10 </minX>
<maxX> 10 </maxX>
<minY> -10 </minY>
<maxY> 10 </maxY>
</bounds>

Warning: Modifications to the space.settings file will change the bounds loaded by WorldEditor and what chunks are loaded on the server.

Users wishing to get a higher resolution photograph of the terrain should consult the Python API reference manual (bigworld/doc/api_python/python_worldeditor.chm) for the function WorldEditor.photographChunk.

Creating heightmaps

BigWorld's WorldEditor allows you to take advantage of 3rd party heightmap-editing tools to rapidly generate and refine terrain height.

There are many applications available that can create greyscale maps for representing terrain height. Some of them allow the user to simulate complex geographical processes, such as wind and water erosion. Some of the more powerful heightmap-editing tools include:

World Machine

Terragen

Bryce

FantasyDemo's space heightmap was generated in World Machine and composited in Photoshop

You can find several example heightmaps in the fantasydemo\example_terrain_textures\ folder.

Heightmaps for level design prototyping

The heightmap feature can also be useful for blocking out areas during prototyping. Quick sketches in Photoshop can be imported into WorldEditor to check distances and lines of sight, and to adjust other design issues before world building begins.

A quick sketch in Photoshop can help designers prototype terrain layouts.

Importing heightmaps

The Terrain Import/Export Tool toolbar button ( [image]) activates the Terrain Import/Export panel, which uses the viewport to display an overhead representation of the terrain height in greyscale.

The Terrain Import/Export panel's Import button allows you to import the following types of heightmap.

.raw (16bit)

.r16 (16bit)

.bmp (8bit/channel)

.ter (Terragen files)

.dt2 (DTED2)

Be aware that when using lower bit depth images (8bit), you will get terracing artifacts in your terrain, due to the precision information stored in the 8-bit image. If you want to 16-bit images by hand, Photoshop CS is capable of editing them.

Once the file is imported, you can adjust the minimum and maximum height of the map, either via the Height fields or via its sliders.

The strength of the imported map can be adjusted using the Strength field/slider – this is similar to the Layer Opacity feature in Photoshop.

There are several options for how the imported height map is applied to the existing terrain

Replace: Simply swaps the existing terrain for the imported terrain. Commonly used to add features to the terrain but usually requires some clean up at the edges.

Add: Adds the two terrain values together

Subtract: Subtracts one terrain from the other.

Overlay: Values less than 128 are subtracted, values higher than 128 are added.

Minimum: Chooses the lowest value of the two heights. This blend mode is great for cutting away at mountains.

Maximum: Chooses the highest value of the two heights. Great for adding mountains to non mountainous areas.

The Alt keyboard shortcut sets the Height field's maximum value to the height of the terrain clicked.

Handles on the imported heightmap allow the user to adjust the size of the imported map. You can snap the handles to chunk boundaries (100mx100m) by using the Shift keyboard shortcut.

The buttons on the bottom of the Terrain Import/Export group box allow you to rotate, flip, and mirror the imported map.

The Renormalise Colour button ( [image]) simply readjusts the levels displayed in the preview – it does not affect the overall terrain height.

The way in which the new layer is applied to the terrain is configured via the Mode drop-down list box. These different mathematical instructions can be useful for adding features to already existing terrain. The Maximum option is great for adding mountains to your terrain, while Minimum is useful for cutting out canyons and rivers.

When you are satisfied with the outcome, click the Place button to place the terrain.

Exporting heightmaps

Terrain height can be exported, which is useful for:

Moving existing terrain features to different locations.

Exporting your world to touch it up in Photoshop

Adding another erosion pass in your favourite terrain-editing tool.

To export a heightmap, use the blue handles to select the area that you need to export, then click the Export button – this will invoke the Save As dialog box, where you can specify the folder and file name of the exported heightmap. We suggest using a 16-bit file type, as they do not suffer from precision artifacts found in 8-bit formats.

When a height map is exported it will generate an *.xml file for the purpose of remembering the exact position it was exported from. This allows the user to modify the map with the assurance that if re-imported it will automatically snap back to the same position.

<root>
    <export>
        <minHeight>	19.360001	</minHeight>
        <maxHeight>	299.880005	</maxHeight>
        <imageWidth>	779	</imageWidth>
        <imageHeight>	789	</imageHeight>
        <littleEndian>	true	</littleEndian>
        <left>	3.570073	</left>
        <top>	11.604759	</top>
        <right>	9.651198	</right>
        <bottom>	5.447620	</bottom>
        <absolute>	false	</absolute>
    </export>
</root>

In the example above we have exported a section of mountain that will be edited in Photoshop so that it can be placed seamlessly elsewhere in the scene.

The file mountain.r16 must first be renamed to mountain.raw so that photoshop can open it.

note Versions of photoshop later than 7.0 are required to edit 16 bit images

When you try to open a .raw file Photoshop will prompt you with a dialog requesting the dimensions, channel count, bit depth and byte order.

Dimensions : Can be found in the exported .xml file (see above)

Channels : should be set to 1 for .raw files

Bit depth : should be set to 16 for .raw files

Byte Order: IBM PC

Once inside photoshop we are going to take the mountain image and darken its edges using a mask. This will prevent hard edges in the terrain when we import the texture. The image below is a before and after shot of the exported terrain with a black border mask.

The image is then saved as a .raw file with the same options used during open.

When you import the height map into WorldEditor the alternative layering mode Additive can be used to place the modified height map onto the terrain.The dark texture borders will ensure the mountain is blended into the terrain without causing a hard transition in height.

The imported mountain sits where there was once an empty valley.


Using UDOs (User Data Objects) and Entities

  • UDO and Entity Properties
  • Performance profiling using UDO camera nodes
    • Placing UDOs

UDOs (User Data Objects) are objects that can be customised for each project's needs.

They allow the user to place game logic information in the world, and to link it up with other UDOs and/or entities. UDOs could be used to specify player traps, patrol nodes, and good cover positions, for example.

Entities are dynamic game objects that have script associated with them, they can be client, client-server, or server side entities. Some examples of entities may include, NPC's, monsters, doors, quest Items, vehicles, spawn points.

UDO and Entity Properties

Custom User Data Objects for your specific game will be created by your team's programmers, and should be accessible in the World Editor's Asset Browser panel's User Data Object virtual folder.

We cannot cover how your specific projects UDOs will operate, so this section describes some of the more useful UDO's available within the BigWorld Demo.

UDO : CameraNode – Defines a path for a camera fly through. Each node along the path defines the position, rotation and direction of the camera as it passes through that node.
The BigWorld Demo fly through script will begin the fly through on the camera with property name "camera node0"

UDO : PatrolNode – Defines a path upon which the Guard entity will travel.
Patrol nodes have several useful properties that can be edited within the Properties panel, as described in the table below.

Property | Description
departureSpeed | Speed at which an entity will depart from the patrol node. Set this to a large value if you want the guard to run away from the patrol node.
importance | Chance an entity will take this path if multiple path choices exist. The likelihood of selecting a path is defined by Importance divided by the sum of all possible paths.
backtrackChange | Percentage chance that a guard will turn around when he reaches this node.
waitSecs | How long a Guard entity will wait once it reaches the patrol node.
radius | Size of the patrol node. Guards traveling from one patrol node to the next will need to pass somewhere within the radius of each patrol node.

UDO : PlatformNode –Path for the floating platform in the online FantasyDemo space. Its properties include:

Property | Description
Approach Speed | Speed at which a platform will approach the node.
Approach Acceleration | Acceleration used to match the Approach Speed.
Wait Time | How long a platform will wait once it reaches the platform node.

Entity : IndoorMapInfo –This entity swaps the outdoor minimap for an indoor minimap, it should be placed at the entrance to indoor (shell) areas so the client knows when to change the minimap.

Property | Description
mapName | Location of the texture to be displayed as minimap (alpha)
Position x,y,z | The centre point of the map
worldMapHeight,Width | The dimensions in world space of the map

Placing UDOs

The default set of UDOs use the same user interface. For the purpose of this manual, we will describe the patrol path UDO.

Patrol nodes are added like any other object within WorldEditor, i.e., you can either drag the object into the viewport from the Asset Browser panel, or select the object and press Enter.

The newly added patrol node will have a selectable cross and circle. Selecting and dragging from the cross will create a new patrol node that is connected to the existing patrol node.

The patrol direction (defined by the direction of blue lines along the patrol link) will by default be in the direction of the newly created patrol node.

If you wish to change the direction of the patrol node, then you can right-click the patrol path and in its context menu select the Swap Link Direction menu item.

A Guard entity can be linked to the patrol node by selecting the patrol path and dragging from its node circle to the Guard entity, or vice-versa.

Existing patrol nodes can be linked to each other by dragging from the patrol node circle to the next patrol node.

Performance profiling using UDO camera nodes

One of the useful ways in which UDO camera nodes can be used is to run performance profiling

Performance profiling can be a powerful tool that allows you to see empirical data about how artwork alterations effect final frame rate.

For example, if you want to see how performance is impacted when a set of models is added, textures are up-res 'd or a new shader it included you can run a performance profile before and after the change and compare the differences.

Before you can run a performance profile you must set up a series of cameras in a loop as described in the section Placing UDO's

The very first camera in the loop must have the its name set to "camera node0"

To generate a performance profile run the client.

Open the Python consol by pressing ~ (tilde) + P

Type BigWorld.runProfiler ('camera node0',3,"nameofoutputfile.csv")

The 3 Refers to how many times the profile will repeat the fly through, generally its a good idea to run the fly through more than once and ignore the first data sets, this ensures the data has been loaded into memory and gives a true indication of performance.

The above command will initiate the camera fly through and output the frame rate to a .csv file located in the client executable folder (fantasydemo/game). These files can be compared directly in a spread sheet program like Excel or you can use the python script caclstats2.py to generate a .png graph of the performance (framerate) over time.

To generate the graph you will need python 2-5 and a number of python libraries (numpy, matplotlib) installed.

Copy the .csv file and calcstats2.py to a common directory (I have put them in C:/performance tests/)

Go to Start - Run

Type "cmd" in the prompt

Run the calcstats2.py python script on the generated .csv file

This will create a .png file called "output.png"

The generated .png displays the frame rate over time. Use photoshop to overlay two graphs with before and after test conditions.


Using the Scene Browser

  • Scene Browser
    • Common properties
    • Using the Scene Browser to find problem assets

The Scene Browswer tab in World Editor is a spread sheet view of all the objects loaded in a space

Scene Browswer

The Scene Brower has many possible applications some of which are listed below.

Finding objects – The search field will filter objects by name, right clicking on an object allows you to zoom to the objects location.

Selecting multiple objects – multiple objects can easily be selected and their common properties edited at once

Modifiying multiple objects –When multiple objects of the same type are slected their common properties can be modified from the properties tab

Monitoring Triangle count per assets – The column Tris can be used to sort assets by the number of triangles, very useful when looking for polygon heavy assets.

Monitoring Primitive groups per assets – The column Primitives gives an indication of how many parts each asset is broken up into. This is usually due to multiple material kinds or high bone counts. Large primitive group numbers will impact performance, it is best to investigate assets at the top range to see if their primitive group count can be reduced. It's rare that objects should need greater than 10 primitive groups.

Hide / Show assets – [image] The scene browser can be used to hide assets to enable easier world building. Hidden assets are only hidden in World Editor, they will be drawn as usual in the client engine.

Freeze / Thaw assets – [image] The scene browser can be used to freeze and thaw assets to enable easier world building. Frozen assets will appear grey and be unselectable from the 3d window. If you need to unfreeze an asset, select it from the scene browser and click the thaw button.

Common properties

If multiple objects of the same type are selected together their common properties will be shown in the properties tab.

This allows users to change the properties of hundresd of objects in a single click.

229 flare objects selected at once

Using the Scene Browser to find problem assets

You can use the Scene Browser to locate problem assets by sorting the columns by Primitives or Triangles.


Post Processing

  • Post Processing
  • Post Processing Chain
  • Render Targets and the Backbuffer
  • Filter Quad Components
  • Post Processing Effects
    • FXAA
    • Hatching
    • Colour Correct
    • HSV Colour Correct
    • Lens Distortion
    • Rainbow
    • Scotopic Vision
    • Posterise and Edge
    • Depth of Field
    • Film Grain
  • Using Post Processing Effects in special effects

The Post Processing tab in World Editor allows you to create a wide array of visual effects by controlling how the rendered image is processed before being displayed on the screen.

Post Processing

Post processing is a way of manipulating the rendered image that would normally be drawn on screen. Instead of drawing directly to the screen the video card goes through extra cycles to alter the image. It's similar to applying filter effects on a picture with Photoshop. The Post Processing tab in World Editor allows artists to directly control what post processing is done to the image.

Post Processing Chain

The Post Processing Chain view shows the sequence of Effects done to the rendered image from left to right. Each effect in the chain is made of several phases.
New Effects can be created by dragging in an <empty effect> from the Asset Browser - Post Processing Effects Tab, or by modifying an existing effect through changing its individual phases.
Each phase has an FX file and set of parameters associated with it. New phases can be created by dragging a <new empty phase> into an effect from the Asset Browser - Post Processing Phases folder.

You can preview the effect of each phase step by step by turning on the preview button indicated below.

Render targets and the Backbuffer

Understanding render targets and the backbuffer is essential for creating post processing effects. Render targets can be thought of as temporary storage areas where the scene can be stored and transfered between effects. This section will step through the following two effects to illustrate a typical chain of effects.

The red line defines the direction of data and processing.

The first step of the Down Sample effect chain is to copy the back buffer.

copy back buffer

This copies a full sized version of the rendered scene into the render target called "backBufferCopy"

multiple down samples

The "backBufferCopy" (input Texture) is then down sampled and stored in the render target "downSample1". The destination blend is set to Zero , because we are writing over the existing data in the render target downSample1. Since the source blend is set to ONE, the render target does not need to be cleared and can be set to False.

The phase is then repeated, this time the already downsized render target "downSample1" is downsized and copied to render target "downSample2"

The phase is then repeated, this time the already downsized render target "downSample2" is downsized and copied to render target "downSample3"

This back and forth downsampling is done to support lower end graphics cards. If only higher spec graphics cards were used the downsample could be done in a single phase with a different shader (FX file).

The processing then moves on to the next effect (Bloom) the first phase of which is;

Colour scale

Colour scale takes the render target "downSampled3" and through the algorithms used in the colour_scale.fx alters the image so that only the brighter parts of the screen remain bright (see image).

4-tap blur horizontal, vertical

These two phases take the down sampled powered image and blur it even further, both horizontally and vertically.

Transfer

The final phase overlays the image with the rendered scene, the result is blooming.

Filter Quad Components

The Fade Env (environment) Map Post-Processing Chain is an example of an effect using filter quad components.

The geometry used to draw screen-space effects are called filter quads. Their vertices contain 4 sets of texture coordinates, each going from (0,0) .. (1,1). These coordinates are slightly offset and are used by filtering shaders to fetch multiple samples from the input texture(s). For example, this can be used to down sample an image to a render target half of the size. Some shaders don't use these uv's at all, and instead implement larger filter kernels directly in the shader, for example nine_tap_filter.fx

Additionally, each vertex contains a view and world normal. How can a screen-space quad have world normals? Easy - a line is drawn from the camera's world space location to the corners of the near plane, the lines extending into the scene represent the world space normals.

The

In the following image, you can see the world and view normals visualised. +ve X (East) comes out red; +ve Y (Up) comes out green. And +ve Z (Forward) comes out blue. Note that the black region in the "Down, NE World normals" is down, which corresponds to -ve Y, or -ve green and thus can't be visualised directly in colour. The view normals remain constant no matter what direction you look.

You can use the world normals to look up a cube map. For example, the "Fade Env Map" post processing chain demonstrates fading the scene out to the in-engine environment cube map. This completely hides the far clipping plane and looks somewhat like fog :

Post Processing Effects

This chapter explains some of the post processing effects shipped with BigWorld. More information about the specifics of each effect and their phases can be found in the tools reference guide.

FXAA

FXAA stands for "Fast approXimate Anti-Aliasing" is a high performance high quality screen space software approximation to anti aliasing. The technique is based on an Nvidia white paper by Timothy Lottes titled FXAA.

Screen shots of no FXAA (left) and FXAA on (right)

FXAA has no property values to modify so it is relatively simple to use. If you include it in an effects chain it is important to put it into the correct position along the chain. If you put it after a blurring effect such as bloom then its not going to find edges as easily and may cause some strange results.

The FXAA effect as seen in WorldEditor's Post Processing panel.

Debug screen showing the edge detection used by the FXAA

Hatching

The Hatching effect overlays a texture on top of the rendered scene and then animates the position of that texture according to a "punch card" offset texture. In the example below the Hatching effect is used to give the scene a hand drawn illustrated appearance.

The offset texture works similar to a punch card, in that each frame the shader reads in a single pixels value Red (X position) and Green (Y value) and then offsets the hatch texture using these values. Each frame the offset texture reads the subsequent pixel (from top to bottom). Only the left most pixel is read from this particular punch card. In the example below the first frame position is defined by a pure red pixel (R=255 G = 0), this translates to the top right hand corner of the screen.

Offset texture works similar to a punch card

Hatch texture overlayed on scene

Colour Correct

Colour correction enables the user to change the colour of each individual pixel on the screen by using a lookup image.

Take a look at the following image.

The image is 256 x 4 pixels of RGB 8bit per channel .bmp format. It was created in photoshop using a linear gradient from pure black (0,0,0) to pure white (255,255,255).

If we break down the individual channels you will see that each channel is exactly the same. This is the colour_correct_default.bmp image found in bigworld\doc\tools_tutorial_examples\Tutorials\post_processing_examples\system\maps\post_processing\

When using colour correction every pixel drawn by the graphics card is compared to this look up image. If a pure black pixel is drawn it will look up at position 1 to find its new colour. In the case below it will be given the exact same colour because this is the Default Colour Map. The same is true for a grey pixel (2), or a white pixel (3), it will come out with the exact same value that went in.

red channel

green channel

blue channel

The magic occurs when we replace the default map with something different. In the example below a black pixel (1) will still remain black, but a grey pixel which would usually have the value (128,128,128) gets transformed into a (0, 187, 0) pixel, and a white pixel (3) gets transformed into a (0,255,0) pixel.

red channel

green channel

blue channel

The result is the entire screen gets tinted green and all other colour values are removed.

Here's a few more colour correction lookup maps and their resulting effect

It's quite easy to create the effect you want using Photoshop.

Firstly take a screen shot of your game and open it in Photoshop

Alter the image to the colour you like by using the curves tool Image - Adjustments - Curves (Ctrl + M)

In this example we are going to apply what is commonly called an S-Curve (used extensively in photography to add contrast to the mid tones at the expense of shadows and highlights).

When you obtain the effect you want Save the curve as s_curve.acv

We now need to apply this curve to our default lookup image

In Photoshop, Open the default_colour_corrrection.bmp found in bigworld\doc\tools_tutorial_examples.zip or create one yourself using the gradient tool

From the Curves tool Load the s_curve.acv file and press OK

This file can now be used in the Post Processing Effects - Colour Correction

The Photoshop curves tool is not the only way to create colour correction maps.

In the following example a hand painted colour correction map is used in combination with the HSV colour correction to create a black and white cell shaded image.

HSV Colour Correct

This effect allows you to modify the Hue, Saturation and Brightness of the input image through modifying the phase parameters

Lens Distortion

This effect distorts each point of the the input image in the direction of the overlayed normal map distortionTexture

This example (hexagonal_norms.bmp) can be tiled for an insect eye effect

This example (fisheye_norms.bmp) creates a fisheye effect by distorting pixels away from the center of the screen.

Rainbow

This effect simulates a rainbow through rainbow.fx and the lee_diagram.dds

Scotopic Vision

Scotopic Vision effect adds noise to the areas of the scene which fall below a darkness threshold. This simulates the noise seen by the human eye as light levels decrease. The image below has increasing levels of scotopic vision applied.

Posterise and Edge

The Posterise effect gives similar results to the posterise filter in photoshop. Put simply the image is blurred and edges are found onto which a black outline is traced.

Depth of Field

For the depth of field effect to work the graphics detail of the client must be set to Very High, likewise in World editor the Options tab -Advanced Post Processing must be set ON.

Note the ability to preview the focal length by turning on the preview button.

Film Grain

The film grain effect uses a number of phases to simulate the old scratched look of rustic film.

Firstly the rendered image is colour corrected to look like old sepia faded film. This is done with a colour correct phase and the following sepia lookup bitmap

Multiple dust_and_scratches phases overlay textures of dust and scratches in positions defined by a punch card texture

The 3rd-6th column of the oldfilm_punchcard texture is used to position various dirt textures at different places on the screen over time,

The 1st -2nd column of the oldfilm_punchcard texture is used to slowly move the scratch texture across the screen

In the client this effect is topped off by adding a vignette effect that darkens the edge of the screen

Using Post Processing Effects in Special Effects

Post processing Effects can be associated with within special effect files

For example: In Fantasy Demo the weather system DustStorm uses the Post Processing effect "God Rays"

If you take a look at the dust_storm.xml file below you can see that when ever the sfx file dust_storm.xml is called from the weather system DustStorm, the post processing chain god rays.ppchain will be used. This system is not unique to weather sfx files. Any sfx file can have a post processing chain associated with it.

<dust_storm>
        <Actor>	particles
            <ParticleSystem>	particles/dust_storm.xml	</ParticleSystem>
        </Actor>

        <Actor> godrays
            <PPChain>	system/post_processing/chains/god rays.ppchain
                <Property>	God Rays/god rays/exposure
                    <Float>	0.00	</Float>
                </Property>
            </PPChain>
        </Actor>

        <Joint>	particles
            <Camera/>
        </Joint>

        <Joint>	godrays
            <PPScreen/>
        </Joint>

        <Event> particles
            <ForceParticle/>
        </Event>

        <Event> godrays
            <PPAnimateProperty>	God Rays/god rays/exposure
                <Key>	0.0	<Float>	0.0 </Float>	</Key>
                <Key>	5.0	<Float>	0.08 </Float>	</Key>
            </PPAnimateProperty>
        </Event>

        <Event> particles
            <RampTimeTriggeredParticles>
                <fadeTime>	15.0	</fadeTime>
            </RampTimeTriggeredParticles>
        </Event>

</dust_storm.xml>


BigWorld MAXScripts

BigWorld MAXScripts and the BigWorld Maya Shelf

  • Installation
    • Maxscript Installation
    • Maya BigWorld Shelf Installation
  • Export Visual and Animation
  • Make Custom Hull
  • Add Portal
  • Label Portal
  • Import Hard Point
  • Add a Note Track
  • Flag as BSP (collision object)
  • Munge Normals
  • Attach Hitbox and Export Hitbox to XML
  • Object Divider
  • Prefab Assembler
    • Maya Prefab Assembler
  • Large Object Workflow

The BigWorld MAXScripts simplify some of the BigWorld specific tasks that are required during asset creation.

All these scripts modify your 3dsMax file, it is highly recommended that you save before using any of these scripts.

Installation

Maxscript Installation

The BigWorld Maxscripts have been tested with 3dsMax version 2010 and onwards. If using 3dsMax 2010 please ensure you have service pack 1 installed.

Drag and drop the BigWorld_MAXScripts.mzp located in bigworld\tools\maxscripts\bigworld_maxscripts_v1.6.mzp file onto the 3dsMax 3d view.

Restart 3dsMax.

Now your ready to use the toolbar.

Maya BigWorld Shelf Installation

To install the BigWorld Maya Shelf

1. Ensure the Maya exporters are installed. Information on how to install the exporters can be found in bigworld\doc\content_tools_reference_guide.pdf

2. Copy the BigWorld Shelf from bigworld\tools\melscripts\src\shelf\shelf_BigWorld.mel to your Maya shelf folder Documents and Settings\username\My Documents\maya\2011\prefs\shelves

3. Copy the scripts from bigworld\tools\melscripts\src\scripts\ to the Maya scripts folder Documents and Settings\username\My Documents\maya\scripts\

4. Copy the BigWorld Icons from bigworld\tools\melscripts\src\icons to your Maya Icon folder Documents and Settings\adamm\My Documents\maya\2011\prefs\icons

5. Copy the BigWorld helper maps from bigworld\tools\melscripts\resources\textures to the textures folder of your current Maya Project folder Documents and Settings\username\My Documents\maya\projects\default\textures

(AID_BSP.bmp, AID_exitportal.bmp, AID_hportal.bmp, AID_Hull.bmp, AID_portal.bmp)

6. Copy the contents of bigworld\tools\melscripts\resources\assets to the assets folder of your current Maya Project folder Documents and Settings\adamm\My Documents\maya\projects\default\assets

(maya_hard_point.mtl, maya_hard_point.obj, hardpoint_helper.bmp)

7. Add your game res/ path to the BigWorldAsset property of your current Project.

Export Visual and Animation

You can export an asset with using the export visual button [image] or animations using the export animation button [image] (3dsMax only).

If you have objects selected the script will do an Export Selected.

If you have nothing selected then the script will do an Export All.

Further information on specific maxScript commands for the BigWorld exporters can be found in the content tools reference guide (bigworld\doc\content_tools_reference_guide.pdf)

Add Custom Hull

See the Content Creation manual bigworld/doc/content_creation.chm shells section for information on Custom Hulls

Clicking the Add Hull button [image] converts the selected object into a Custom Hull, by appending the suffix "_hull" to the objects name. A custom hull material is added to the object for visualisation purposes.

In 3dsMax, polygons of the hull can then be assigned portals using the scripts below.

Add Portal

See the Content Creation manual bigworld/doc/content_creation.chm shells section for information regarding Portals

By clicking the Add Portal button the script will automatically assign a portal flag to the object selected. Subsequent clicks will remove the portal.

Adds a standard portal flag

Adds an Exit portal flag

Adds a Heaven portal flag

The portal assignment will add a material to the portal to make it easily recognisable. The material library used is stored in the BigWorld_MaterialLibrary.mat located in bigworld/tools/maxscripts/resources/materiallibraries/

Portal assignment can be done in two ways using this script.

1. Whole objects (planes) can be assigned portal flags, in which case they will use the "portal = true" custom attribute.

2. Alternatively, if you are in sub-object mode, Polygon selection of a Custom Hull, then that polygon will be assigned a portal material.

Label Portal

This button adds a label to a selected portal.

Only geometry portals can be labeled.

Adds a portal label

Import Hard Point

See the Content Creation manual bigworld/doc/content_creation.chm section Hard Points for information regarding Hard Points.

When multiple artists are creating assets with interdependent Hard Points (e.g. a gun and an avatars hand), discrepancies in the orientation of the Hard Points can occur. This script should reduce the number of misaligned Hard Points by standardising the Hard Point model and its alignment to the parent node.

Pressing the Import Hard Point button [image] will automatically attach and align a standardised hard point model to the selected object.

If no object is selected the Hard Point model will be aligned to the world origin (0,0,0).

The Hard Point representation model will be automatically scaled so that it is ~20cm in scene units no matter your System Unit Settings. The model is a representation of the BigWorld coordinate system.

The hard point model hard_point.fbx is installed into the 3dsMax's project folder: import folder and uses materials from the BigWorld_MaterialLibrary.mat.

Note: The standardised hard_point.fbx model is located in 3dsMax's Project Path - import folder. Changing 3dsMax's Project folder will cause this script to loose track of the hard point model. This can be fixed by re-installing the scripts, or moving the hard_point.fbx from the old /import folder to the new Project Path - import folder.

Add a Note Track

See the Content Creation manual bigworld/doc/content_creation.chm section Note Tracks for information regarding Note Tracks

Pressing the Add Note Track button [image] will allow the user to quickly add a note track of type "cue:" or "sound:" to the selected node at the slider Time.

Flag as BSP (collision geometry)

See the Content Creation manual bigworld/doc/content_creation.chm for information regarding BSP collision geometry

Pressing the Convert to BSP button [image] converts any geometric object to a BigWorld BSP collision object. The suffix "_bsp" is added to the objects name, and a material is applied so the object can be easily recognised within 3dsMax as a BSP object

Munge Normals

See the Content Creation manual bigworld/doc/content_creation.chm for information regarding the mungenormals script.

Pressing the Munge Normals button [image] will cause any normals of currently selected objects with an Edit Normals modifier to splay away from a subsequently selected object.

Attach Hitbox and Export HitBox to XML

By default BigWorld uses the entities bounding boxes for targeting. This works well for most cases, but some times more accurate targeting is needed. This script will generate a skeleton collider xml file that programmers can use for more accurate entity targeting.

More detailed information on skeleton colliders can be found in \bigworld\doc\howto_accurately_target_entities.pdf

1. Select all the nodes onto which you would like to attach hitboxes. Try to be conservative, adding hitboxes to individual fingers is unnecessary and will result in poor game performance.

2. Press the Attach Hitbox button [image]. This will generate hitboxes and attach them to the selected nodes.

3. Adjust the size, and position of the hitboxes to best match your target model. Do not break the links between parent and hitbox. If you do, the hitbox will be ignored on export.

4. Export the hitboxes to a skeleton collider xml file by pressing the Export Hitbox to XML button [image].

Once loaded (see details in howto_accurately_target_entities.pdf) the skeleton collider can be visualised by turning on the client watcher (~tilde + F7) Client Settings - displayIMpactBoxes = True

Object Divider

Objects imported into BigWorld have a maximum size restriction of 100m, 100m, 200m (XYZ). Sometimes it can be necessary to divide an object into several sections which can be exported individually.

The Object Divider script [image] will automatically divide an object up into sections smaller than the user defined Maximum size setting.

This script is usually used in conjunction with the Prefab Assembler script

Its a good idea to save your work before using this script as its going to chop up your model into little pieces.

The Object divider will recommend a default setting of 70 meters, this is because if an object with a side length of 70 meters is rotated it will exceed the 100M object size limit if rotated 45 degrees. This concept is illustrated in the picture above.

Both the 3dsMax and Maya object dividers will place the divided object pieces on separate special named layers with the suffix "_bw_model_layer". This is to help facilitate the Prefab Assembler script.

Prefab Assembler

Due to object size restrictions it is often necessary to divide a very large object into multiple pieces and export each piece individually. These objects are manually reassembled within WorldEditor and a prefab is created for future placement.

To aid in manually reassembling the objects relative to each other, users will often export objects in-place from 3dsMax so that they all share a common pivot point. This can cause serious issues with chunk lending if the pivot point is greater than 100 meters from the objects bounding box and it makes object manipulation extremely difficult, this is NOT a recommended technique.

The correct technique is to move each object to the origin and then export so that the objects pivot point is in close proximity to the objects bounding box. This creates the problem that the user must now reassemble the assets in WorldEditor relative to each other, either by eye, or by first recording the transformation done prior to export.

To prevent such problems the Prefab Assembler macro script [image] allows you to create a prefab file from multiple objects in 3dsMax.

The script does the following.

1. Scans the scene for layers with the suffix "_bw_shell_layer" or "_bw_model_layer" and considers all objects on each layer a single .model

2. Records the position of each object in each Layer

3. Moves each object, temporarily to the world origin (0,0,0) to ensure that the objects pivot point resides within the objects bounding box.

4. Exports each layer generating a .model, .visual and .primitive file.

5. Generates a .prefab file of all the above models

The option to "Export Shells" allows users to export a scene containing multiple shells. Shells are made up of multiple components (portals, custom hulls, shell geometry).

Users must manually place each shell and all its parts on separate layers with the suffix "_bw_shell_layer" so that the Prefab Assembler will correctly export them.

Note: Save your work file before using this script.

Maya Prefab Assembler

The Maya version of the prefab assembler also requires specifically named layers.

Model objects should be placed on layers with the suffix or prefix "_bw_model_layer" (Note the object divider script does this automatically to objects it cuts up)

Shell objects should be placed on layers with the suffix or prefix "_bw_shell_layer"

Large object workflow

This tutorial will take you through step by step how to create a prefab out of a very large object using the object divider and prefab assembler max/mel scripts.

1. Always save your work to a separate backup file first.

2. Firstly I have created a very large (greater than 100m) single piece model in 3dsMax of a castle and a second lower resolution model of its BSP

3. The Models are placed over the top of each other and collapsed into a single model using the Attach command in the 3dsMax modifier panel.

This will make the two models into a single piece model. We need to do this so that the object divider script can divide both objects up equally along the same lines.

If the model's LODs are already made, they too would be attached to the primary model to make a single object for the object divider. Alternatively the LOD models can be created after the primary model is exported and the prefab created.

If you model contains neither custom BSP or LOD's then this, and step 6 are unecessary.

The separate BSP and LOD models must be given unique material names or mesh ID's, to enable the user to separate the pieces into individual models once the object divider had done its job.

4. Run the object divider [image] script. A dialog will prompt you for an Editable Poly object and for maximum size settings.

If you plan to rotate your object in WorldEditor then we recommend that you do not exceed 70 meters in any direction. A 70 meter square cube is 100 meters from corner to corner.

5. The Object Divider script will put the divided objects on individual layers with specific names.

Each layer is considered a single BigWorld model by the Prefab assembler script, so if you have multiple mesh on a single layer they will be exported as a single model.

Only layers with specific names will be exported by the prefab assembler.

Layers containing the "_bw_model_layer" are considered models by the prefab assembler.

Layers containing the "_bw_shell_layer" are considered shells by the prefab assembler. The placement of individual shells on separate layers must be done manually by the user.

The layer name in conjunction with the model export name will be used as the BigWorld model name when exported by the prefab assembler

6. Following object division you will then have to separate the BSP and LOD sections from your now divided model using the Detach command in the 3dsMax modifier panel. Ensure that each detached BSP model is appropriately named with the
"_bsp" suffix and is located on the appropriate layer.

7. You are now ready to export the models using the Prefab Assembler macro script

Choose an export location within your resource path.

Choose where to save your prefab file within your resource path.

8. You are now ready to place your prefab file in the WorldEditor


This file contains licenses of external libraries included in the
BigWorld server, server tools and client tools components.
=================================================================

***************************************************************************
* Python                                                                  *
***************************************************************************

A. HISTORY OF THE SOFTWARE
==========================

Python was created in the early 1990s by Guido van Rossum at Stichting
Mathematisch Centrum (CWI, see http://www.cwi.nl) in the Netherlands
as a successor of a language called ABC.  Guido remains Python's
principal author, although it includes many contributions from others.

In 1995, Guido continued his work on Python at the Corporation for
National Research Initiatives (CNRI, see http://www.cnri.reston.va.us)
in Reston, Virginia where he released several versions of the
software.

In May 2000, Guido and the Python core development team moved to
BeOpen.com to form the BeOpen PythonLabs team.  In October of the same
year, the PythonLabs team moved to Digital Creations (now Zope
Corporation, see http://www.zope.com).  In 2001, the Python Software
Foundation (PSF, see http://www.python.org/psf/) was formed, a
non-profit organization created specifically to own Python-related
Intellectual Property.  Zope Corporation is a sponsoring member of
the PSF.

All Python releases are Open Source (see http://www.opensource.org for
the Open Source Definition).  Historically, most, but not all, Python
releases have also been GPL-compatible; the table below summarizes
the various releases.

    Release         Derived     Year        Owner       GPL-
                    from                                compatible? (1)

    0.9.0 thru 1.2              1991-1995   CWI         yes
    1.3 thru 1.5.2  1.2         1995-1999   CNRI        yes
    1.6             1.5.2       2000        CNRI        no
    2.0             1.6         2000        BeOpen.com  no
    1.6.1           1.6         2001        CNRI        yes (2)
    2.1             2.0+1.6.1   2001        PSF         no
    2.0.1           2.0+1.6.1   2001        PSF         yes
    2.1.1           2.1+2.0.1   2001        PSF         yes
    2.2             2.1.1       2001        PSF         yes
    2.1.2           2.1.1       2002        PSF         yes
    2.1.3           2.1.2       2002        PSF         yes
    2.2.1           2.2         2002        PSF         yes
    2.2.2           2.2.1       2002        PSF         yes
    2.2.3           2.2.2       2003        PSF         yes
    2.3             2.2.2       2002-2003   PSF         yes
    2.3.1           2.3         2002-2003   PSF         yes
    2.3.2           2.3.1       2002-2003   PSF         yes
    2.3.3           2.3.2       2002-2003   PSF         yes
    2.3.4           2.3.3       2004        PSF         yes
    2.3.5           2.3.4       2005        PSF         yes
    2.4             2.3         2004        PSF         yes
    2.4.1           2.4         2005        PSF         yes
    2.4.2           2.4.1       2005        PSF         yes
    2.4.3           2.4.2       2006        PSF         yes
    2.5             2.4         2006        PSF         yes

Footnotes:

(1) GPL-compatible doesn't mean that we're distributing Python under
    the GPL.  All Python licenses, unlike the GPL, let you distribute
    a modified version without making your changes open source.  The
    GPL-compatible licenses make it possible to combine Python with
    other software that is released under the GPL; the others don't.

(2) According to Richard Stallman, 1.6.1 is not GPL-compatible,
    because its license has a choice of law clause.  According to
    CNRI, however, Stallman's lawyer has told CNRI's lawyer that 1.6.1
    is "not incompatible" with the GPL.

Thanks to the many outside volunteers who have worked under Guido's
direction to make these releases possible.

B. TERMS AND CONDITIONS FOR ACCESSING OR OTHERWISE USING PYTHON
===============================================================

PYTHON SOFTWARE FOUNDATION LICENSE VERSION 2
--------------------------------------------

1. This LICENSE AGREEMENT is between the Python Software Foundation
("PSF"), and the Individual or Organization ("Licensee") accessing and
otherwise using this software ("Python") in source or binary form and
its associated documentation.

2. Subject to the terms and conditions of this License Agreement, PSF
hereby grants Licensee a nonexclusive, royalty-free, world-wide
license to reproduce, analyze, test, perform and/or display publicly,
prepare derivative works, distribute, and otherwise use Python
alone or in any derivative version, provided, however, that PSF's
License Agreement and PSF's notice of copyright, i.e., "Copyright (c)
2001, 2002, 2003, 2004, 2005, 2006 Python Software Foundation; All Rights
Reserved" are retained in Python alone or in any derivative version
prepared by Licensee.

3. In the event Licensee prepares a derivative work that is based on
or incorporates Python or any part thereof, and wants to make
the derivative work available to others as provided herein, then
Licensee hereby agrees to include in any such work a brief summary of
the changes made to Python.

4. PSF is making Python available to Licensee on an "AS IS"
basis.  PSF MAKES NO REPRESENTATIONS OR WARRANTIES, EXPRESS OR
IMPLIED.  BY WAY OF EXAMPLE, BUT NOT LIMITATION, PSF MAKES NO AND
DISCLAIMS ANY REPRESENTATION OR WARRANTY OF MERCHANTABILITY OR FITNESS
FOR ANY PARTICULAR PURPOSE OR THAT THE USE OF PYTHON WILL NOT
INFRINGE ANY THIRD PARTY RIGHTS.

5. PSF SHALL NOT BE LIABLE TO LICENSEE OR ANY OTHER USERS OF PYTHON
FOR ANY INCIDENTAL, SPECIAL, OR CONSEQUENTIAL DAMAGES OR LOSS AS
A RESULT OF MODIFYING, DISTRIBUTING, OR OTHERWISE USING PYTHON,
OR ANY DERIVATIVE THEREOF, EVEN IF ADVISED OF THE POSSIBILITY THEREOF.

6. This License Agreement will automatically terminate upon a material
breach of its terms and conditions.

7. Nothing in this License Agreement shall be deemed to create any
relationship of agency, partnership, or joint venture between PSF and
Licensee.  This License Agreement does not grant permission to use PSF
trademarks or trade name in a trademark sense to endorse or promote
products or services of Licensee, or any third party.

8. By copying, installing or otherwise using Python, Licensee
agrees to be bound by the terms and conditions of this License
Agreement.

BEOPEN.COM LICENSE AGREEMENT FOR PYTHON 2.0
-------------------------------------------

BEOPEN PYTHON OPEN SOURCE LICENSE AGREEMENT VERSION 1

1. This LICENSE AGREEMENT is between BeOpen.com ("BeOpen"), having an
office at 160 Saratoga Avenue, Santa Clara, CA 95051, and the
Individual or Organization ("Licensee") accessing and otherwise using
this software in source or binary form and its associated
documentation ("the Software").

2. Subject to the terms and conditions of this BeOpen Python License
Agreement, BeOpen hereby grants Licensee a non-exclusive,
royalty-free, world-wide license to reproduce, analyze, test, perform
and/or display publicly, prepare derivative works, distribute, and
otherwise use the Software alone or in any derivative version,
provided, however, that the BeOpen Python License is retained in the
Software, alone or in any derivative version prepared by Licensee.

3. BeOpen is making the Software available to Licensee on an "AS IS"
basis.  BEOPEN MAKES NO REPRESENTATIONS OR WARRANTIES, EXPRESS OR
IMPLIED.  BY WAY OF EXAMPLE, BUT NOT LIMITATION, BEOPEN MAKES NO AND
DISCLAIMS ANY REPRESENTATION OR WARRANTY OF MERCHANTABILITY OR FITNESS
FOR ANY PARTICULAR PURPOSE OR THAT THE USE OF THE SOFTWARE WILL NOT
INFRINGE ANY THIRD PARTY RIGHTS.

4. BEOPEN SHALL NOT BE LIABLE TO LICENSEE OR ANY OTHER USERS OF THE
SOFTWARE FOR ANY INCIDENTAL, SPECIAL, OR CONSEQUENTIAL DAMAGES OR LOSS
AS A RESULT OF USING, MODIFYING OR DISTRIBUTING THE SOFTWARE, OR ANY
DERIVATIVE THEREOF, EVEN IF ADVISED OF THE POSSIBILITY THEREOF.

5. This License Agreement will automatically terminate upon a material
breach of its terms and conditions.

6. This License Agreement shall be governed by and interpreted in all
respects by the law of the State of California, excluding conflict of
law provisions.  Nothing in this License Agreement shall be deemed to
create any relationship of agency, partnership, or joint venture
between BeOpen and Licensee.  This License Agreement does not grant
permission to use BeOpen trademarks or trade names in a trademark
sense to endorse or promote products or services of Licensee, or any
third party.  As an exception, the "BeOpen Python" logos available at
http://www.pythonlabs.com/logos.html may be used according to the
permissions granted on that web page.

7. By copying, installing or otherwise using the software, Licensee
agrees to be bound by the terms and conditions of this License
Agreement.

CNRI LICENSE AGREEMENT FOR PYTHON 1.6.1
---------------------------------------

1. This LICENSE AGREEMENT is between the Corporation for National
Research Initiatives, having an office at 1895 Preston White Drive,
Reston, VA 20191 ("CNRI"), and the Individual or Organization
("Licensee") accessing and otherwise using Python 1.6.1 software in
source or binary form and its associated documentation.

2. Subject to the terms and conditions of this License Agreement, CNRI
hereby grants Licensee a nonexclusive, royalty-free, world-wide
license to reproduce, analyze, test, perform and/or display publicly,
prepare derivative works, distribute, and otherwise use Python 1.6.1
alone or in any derivative version, provided, however, that CNRI's
License Agreement and CNRI's notice of copyright, i.e., "Copyright (c)
1995-2001 Corporation for National Research Initiatives; All Rights
Reserved" are retained in Python 1.6.1 alone or in any derivative
version prepared by Licensee.  Alternately, in lieu of CNRI's License
Agreement, Licensee may substitute the following text (omitting the
quotes): "Python 1.6.1 is made available subject to the terms and
conditions in CNRI's License Agreement.  This Agreement together with
Python 1.6.1 may be located on the Internet using the following
unique, persistent identifier (known as a handle): 1895.22/1013.  This
Agreement may also be obtained from a proxy server on the Internet
using the following URL: http://hdl.handle.net/1895.22/1013".

3. In the event Licensee prepares a derivative work that is based on
or incorporates Python 1.6.1 or any part thereof, and wants to make
the derivative work available to others as provided herein, then
Licensee hereby agrees to include in any such work a brief summary of
the changes made to Python 1.6.1.

4. CNRI is making Python 1.6.1 available to Licensee on an "AS IS"
basis.  CNRI MAKES NO REPRESENTATIONS OR WARRANTIES, EXPRESS OR
IMPLIED.  BY WAY OF EXAMPLE, BUT NOT LIMITATION, CNRI MAKES NO AND
DISCLAIMS ANY REPRESENTATION OR WARRANTY OF MERCHANTABILITY OR FITNESS
FOR ANY PARTICULAR PURPOSE OR THAT THE USE OF PYTHON 1.6.1 WILL NOT
INFRINGE ANY THIRD PARTY RIGHTS.

5. CNRI SHALL NOT BE LIABLE TO LICENSEE OR ANY OTHER USERS OF PYTHON
1.6.1 FOR ANY INCIDENTAL, SPECIAL, OR CONSEQUENTIAL DAMAGES OR LOSS AS
A RESULT OF MODIFYING, DISTRIBUTING, OR OTHERWISE USING PYTHON 1.6.1,
OR ANY DERIVATIVE THEREOF, EVEN IF ADVISED OF THE POSSIBILITY THEREOF.

6. This License Agreement will automatically terminate upon a material
breach of its terms and conditions.

7. This License Agreement shall be governed by the federal
intellectual property law of the United States, including without
limitation the federal copyright law, and, to the extent such
U.S. federal law does not apply, by the law of the Commonwealth of
Virginia, excluding Virginia's conflict of law provisions.
Notwithstanding the foregoing, with regard to derivative works based
on Python 1.6.1 that incorporate non-separable material that was
previously distributed under the GNU General Public License (GPL), the
law of the Commonwealth of Virginia shall govern this License
Agreement only as to issues arising under or with respect to
Paragraphs 4, 5, and 7 of this License Agreement.  Nothing in this
License Agreement shall be deemed to create any relationship of
agency, partnership, or joint venture between CNRI and Licensee.  This
License Agreement does not grant permission to use CNRI trademarks or
trade name in a trademark sense to endorse or promote products or
services of Licensee, or any third party.

8. By clicking on the "ACCEPT" button where indicated, or by copying,
installing or otherwise using Python 1.6.1, Licensee agrees to be
bound by the terms and conditions of this License Agreement.

        ACCEPT

CWI LICENSE AGREEMENT FOR PYTHON 0.9.0 THROUGH 1.2
--------------------------------------------------

Copyright (c) 1991 - 1995, Stichting Mathematisch Centrum Amsterdam,
The Netherlands.  All rights reserved.

Permission to use, copy, modify, and distribute this software and its
documentation for any purpose and without fee is hereby granted,
provided that the above copyright notice appear in all copies and that
both that copyright notice and this permission notice appear in
supporting documentation, and that the name of Stichting Mathematisch
Centrum or CWI not be used in advertising or publicity pertaining to
distribution of the software without specific, written prior
permission.

STICHTING MATHEMATISCH CENTRUM DISCLAIMS ALL WARRANTIES WITH REGARD TO
THIS SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND
FITNESS, IN NO EVENT SHALL STICHTING MATHEMATISCH CENTRUM BE LIABLE
FOR ANY SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT
OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.

***************************************************************************
* aalloc.hpp                                                              *
***************************************************************************

/*
 * Copyright (c) 1992-2001 by P.J. Plauger.  ALL RIGHTS RESERVED.
 * Consult your license regarding permissions and restrictions.
 */

/*
 * This file is derived from software bearing the following
 * restrictions:
 *
 * Copyright (c) 1994
 * Hewlett-Packard Company
 *
 * Permission to use, copy, modify, distribute and sell this
 * software and its documentation for any purpose is hereby
 * granted without fee, provided that the above copyright notice
 * appear in all copies and that both that copyright notice and
 * this permission notice appear in supporting documentation.
 * Hewlett-Packard Company makes no representations about the
 * suitability of this software for any purpose. It is provided
 * "as is" without express or implied warranty.
 V3.10:0009 */

***************************************************************************
* avector.hpp                                                             *
***************************************************************************

/*
 * Copyright (c) 1992-2001 by P.J. Plauger.  ALL RIGHTS RESERVED.
 * Consult your license regarding permissions and restrictions.
 */

/*
 * This file is derived from software bearing the following
 * restrictions:
 *
 * Copyright (c) 1994
 * Hewlett-Packard Company
 *
 * Permission to use, copy, modify, distribute and sell this
 * software and its documentation for any purpose is hereby
 * granted without fee, provided that the above copyright notice
 * appear in all copies and that both that copyright notice and
 * this permission notice appear in supporting documentation.
 * Hewlett-Packard Company makes no representations about the
 * suitability of this software for any purpose. It is provided
 * "as is" without express or implied warranty.
 V3.10:0009 */

***************************************************************************
* bsdiff                                                                  *
***************************************************************************

/*
 * Parts of this library are derived from Colin Percival's bsdiff tool.
 *
 * Copyright 2003-2005 Colin Percival
 * All rights reserved
 *
 * Redistribution and use in source and binary forms, with or without
 * modification, are permitted providing that the following conditions
 * are met:
 * 1. Redistributions of source code must retain the above copyright
 *    notice, this list of conditions and the following disclaimer.
 * 2. Redistributions in binary form must reproduce the above copyright
 *    notice, this list of conditions and the following disclaimer in the
 *    documentation and/or other materials provided with the distribution.
 *
 * THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR
 * IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
 * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
 * ARE DISCLAIMED.  IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY
 * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
 * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
 * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
 * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
 * STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING
 * IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
 * POSSIBILITY OF SUCH DAMAGE.
 */

***************************************************************************
* CppUnitLite2                                                            *
***************************************************************************
CppUnitLite2 Version 1.1
Released 2005/12/12

Released under the MIT license (with an extra restriction)

Copyright (c) 2005 Noel Llopis

Permission is hereby granted, free of charge, to any person obtaining a
copy of this software and associated documentation files (the "Software"),
to deal in the Software without restriction, including without limitation
the rights to use, copy, modify, merge, publish, distribute, sublicense,
and/or sell copies of the Software, and to permit persons to whom the Software
is furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in
all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

Additionally, this software cannot be used for any software developed for
or funded by a military organization.

***************************************************************************
* OpenSSL                                                                 *
***************************************************************************

  LICENSE ISSUES
  ==============

  The OpenSSL toolkit stays under a dual license, i.e. both the conditions of
  the OpenSSL License and the original SSLeay license apply to the toolkit.
  See below for the actual license texts. Actually both licenses are BSD-style
  Open Source licenses. In case of any license issues related to OpenSSL
  please contact openssl-core@openssl.org.

  OpenSSL License
  ---------------

/* ====================================================================
 * Copyright (c) 1998-2007 The OpenSSL Project.  All rights reserved.
 *
 * Redistribution and use in source and binary forms, with or without
 * modification, are permitted provided that the following conditions
 * are met:
 *
 * 1. Redistributions of source code must retain the above copyright
 *    notice, this list of conditions and the following disclaimer.
 *
 * 2. Redistributions in binary form must reproduce the above copyright
 *    notice, this list of conditions and the following disclaimer in
 *    the documentation and/or other materials provided with the
 *    distribution.
 *
 * 3. All advertising materials mentioning features or use of this
 *    software must display the following acknowledgment:
 *    "This product includes software developed by the OpenSSL Project
 *    for use in the OpenSSL Toolkit. (http://www.openssl.org/)"
 *
 * 4. The names "OpenSSL Toolkit" and "OpenSSL Project" must not be used to
 *    endorse or promote products derived from this software without
 *    prior written permission. For written permission, please contact
 *    openssl-core@openssl.org.
 *
 * 5. Products derived from this software may not be called "OpenSSL"
 *    nor may "OpenSSL" appear in their names without prior written
 *    permission of the OpenSSL Project.
 *
 * 6. Redistributions of any form whatsoever must retain the following
 *    acknowledgment:
 *    "This product includes software developed by the OpenSSL Project
 *    for use in the OpenSSL Toolkit (http://www.openssl.org/)"
 *
 * THIS SOFTWARE IS PROVIDED BY THE OpenSSL PROJECT ``AS IS'' AND ANY
 * EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
 * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
 * PURPOSE ARE DISCLAIMED.  IN NO EVENT SHALL THE OpenSSL PROJECT OR
 * ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
 * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
 * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
 * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
 * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
 * STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
 * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED
 * OF THE POSSIBILITY OF SUCH DAMAGE.
 * ====================================================================
 *
 * This product includes cryptographic software written by Eric Young
 * (eay@cryptsoft.com).  This product includes software written by Tim
 * Hudson (tjh@cryptsoft.com).
 *
 */

 Original SSLeay License
 -----------------------

/* Copyright (C) 1995-1998 Eric Young (eay@cryptsoft.com)
 * All rights reserved.
 *
 * This package is an SSL implementation written
 * by Eric Young (eay@cryptsoft.com).
 * The implementation was written so as to conform with Netscapes SSL.
 *
 * This library is free for commercial and non-commercial use as long as
 * the following conditions are adhered to.  The following conditions
 * apply to all code found in this distribution, be it the RC4, RSA,
 * lhash, DES, etc., code; not just the SSL code.  The SSL documentation
 * included with this distribution is covered by the same copyright terms
 * except that the holder is Tim Hudson (tjh@cryptsoft.com).
 *
 * Copyright remains Eric Young's, and as such any Copyright notices in
 * the code are not to be removed.
 * If this package is used in a product, Eric Young should be given attribution
 * as the author of the parts of the library used.
 * This can be in the form of a textual message at program startup or
 * in documentation (online or textual) provided with the package.
 *
 * Redistribution and use in source and binary forms, with or without
 * modification, are permitted provided that the following conditions
 * are met:
 * 1. Redistributions of source code must retain the copyright
 *    notice, this list of conditions and the following disclaimer.
 * 2. Redistributions in binary form must reproduce the above copyright
 *    notice, this list of conditions and the following disclaimer in the
 *    documentation and/or other materials provided with the distribution.
 * 3. All advertising materials mentioning features or use of this software
 *    must display the following acknowledgement:
 *    "This product includes cryptographic software written by
 *     Eric Young (eay@cryptsoft.com)"
 *    The word 'cryptographic' can be left out if the routines from the library
 *    being used are not cryptographic related :-).
 * 4. If you include any Windows specific code (or a derivative thereof) from
 *    the apps directory (application code) you must include an acknowledgement:
 *    "This product includes software written by Tim Hudson (tjh@cryptsoft.com)"
 *
 * THIS SOFTWARE IS PROVIDED BY ERIC YOUNG ``AS IS'' AND
 * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
 * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
 * ARE DISCLAIMED.  IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
 * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
 * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
 * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
 * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
 * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
 * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
 * SUCH DAMAGE.
 *
 * The licence and distribution terms for any publicly available version or
 * derivative of this code cannot be changed.  i.e. this code cannot simply be
 * copied and put under another distribution licence
 * [including the GNU Public Licence.]
 */

***************************************************************************
* MySQL-python                                                            *
***************************************************************************

Copyright 1991-1995 by Stichting Mathematisch Centrum, Amsterdam,
The Netherlands.

                        All Rights Reserved

Permission to use, copy, modify, and distribute this software and its
documentation for any purpose and without fee is hereby granted,
provided that the above copyright notice appear in all copies and that
both that copyright notice and this permission notice appear in
supporting documentation, and that the names of Stichting Mathematisch
Centrum or CWI or Corporation for National Research Initiatives or
CNRI not be used in advertising or publicity pertaining to
distribution of the software without specific, written prior
permission.

While CWI is the initial source for this software, a modified version
is made available by the Corporation for National Research Initiatives
(CNRI) at the Internet address ftp://ftp.python.org.

STICHTING MATHEMATISCH CENTRUM AND CNRI DISCLAIM ALL WARRANTIES WITH
REGARD TO THIS SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS, IN NO EVENT SHALL STICHTING MATHEMATISCH
CENTRUM OR CNRI BE LIABLE FOR ANY SPECIAL, INDIRECT OR CONSEQUENTIAL
DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR
PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER
TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
PERFORMANCE OF THIS SOFTWARE.

***************************************************************************
* StackWalker                                                             *
***************************************************************************

Copyright (c) 2007, Jochen Kalmbach

All rights reserved.

Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:

* Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.
* Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.
* Neither the name of the <ORGANIZATION> nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission.

THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
"AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR
PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING
NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

***************************************************************************
* Py2Exe - It is used to build some of the files but is not redistributed *
***************************************************************************
Copyright (c) 2000-2005 Thomas Heller, Mark Hammond, Jimmy Retzlaff

Permission is hereby granted, free of charge, to any person obtaining
a copy of this software and associated documentation files (the
"Software"), to deal in the Software without restriction, including
without limitation the rights to use, copy, modify, merge, publish,
distribute, sublicense, and/or sell copies of the Software, and to
permit persons to whom the Software is furnished to do so, subject to
the following conditions:

The above copyright notice and this permission notice shall be
included in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE
LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION
OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION
WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

***************************************************************************
* SQLite																  *
***************************************************************************

Copyright (C) 1994 X Consortium

Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to
deal in the Software without restriction, including without limitation the
rights to use, copy, modify, merge, publish, distribute, sublicense, and/or
sell copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in
all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL THE
X CONSORTIUM BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN
AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNEC-
TION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

Except as contained in this notice, the name of the X Consortium shall not
be used in advertising or otherwise to promote the sale, use or other deal-
ings in this Software without prior written authorization from the X Consor-
tium.

***************************************************************************
* PyAMF																      *
***************************************************************************

PyAMF is available under the terms of the MIT license.  The full text of the
MIT license is included below.

MIT License
===========

Copyright (c) 2007-2008 The PyAMF Project. All rights reserved.

Arnar Birgisson
Thijs Triemstra
Nick Joyce

Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
SOFTWARE.

***************************************************************************
* MySQLdb (Using the original license and not the GPL)                    *
***************************************************************************
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2, or (at your option)
any later version. Alternatively, you may use the original license
reproduced below.

Copyright 1999 by Comstar.net, Inc., Atlanta, GA, US.

                        All Rights Reserved

Permission to use, copy, modify, and distribute this software and its
documentation for any purpose and without fee is hereby granted,
provided that the above copyright notice appear in all copies and that
both that copyright notice and this permission notice appear in
supporting documentation, and that the name of Comstar.net, Inc.
or COMSTAR not be used in advertising or publicity pertaining to
distribution of the software without specific, written prior permission.

COMSTAR DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE,
INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS, IN NO
EVENT SHALL COMSTAR BE LIABLE FOR ANY SPECIAL, INDIRECT OR
CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF
USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR
OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
PERFORMANCE OF THIS SOFTWARE.

***************************************************************************
* SQLAlchemy                                                              *
***************************************************************************

This is the MIT license: http://www.opensource.org/licenses/mit-license.php

Copyright (c) 2005, 2006, 2007, 2008 Michael Bayer and contributors.
SQLAlchemy is a trademark of Michael Bayer.

Permission is hereby granted, free of charge, to any person obtaining a copy of
this software and associated documentation files (the "Software"), to deal in
the Software without restriction, including without limitation the rights to
use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies
of the Software, and to permit persons to whom the Software is furnished to do
so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
SOFTWARE.

********************************************************************
*  GECKO                                                           *
********************************************************************

                          MOZILLA PUBLIC LICENSE
                                Version 1.1

                              ---------------

1. Definitions.

     1.0.1. "Commercial Use" means distribution or otherwise making the
     Covered Code available to a third party.

     1.1. "Contributor" means each entity that creates or contributes to
     the creation of Modifications.

     1.2. "Contributor Version" means the combination of the Original
     Code, prior Modifications used by a Contributor, and the Modifications
     made by that particular Contributor.

     1.3. "Covered Code" means the Original Code or Modifications or the
     combination of the Original Code and Modifications, in each case
     including portions thereof.

     1.4. "Electronic Distribution Mechanism" means a mechanism generally
     accepted in the software development community for the electronic
     transfer of data.

     1.5. "Executable" means Covered Code in any form other than Source
     Code.

     1.6. "Initial Developer" means the individual or entity identified
     as the Initial Developer in the Source Code notice required by Exhibit
     A.

     1.7. "Larger Work" means a work which combines Covered Code or
     portions thereof with code not governed by the terms of this License.

     1.8. "License" means this document.

     1.8.1. "Licensable" means having the right to grant, to the maximum
     extent possible, whether at the time of the initial grant or
     subsequently acquired, any and all of the rights conveyed herein.

     1.9. "Modifications" means any addition to or deletion from the
     substance or structure of either the Original Code or any previous
     Modifications. When Covered Code is released as a series of files, a
     Modification is:
          A. Any addition to or deletion from the contents of a file
          containing Original Code or previous Modifications.

          B. Any new file that contains any part of the Original Code or
          previous Modifications.

     1.10. "Original Code" means Source Code of computer software code
     which is described in the Source Code notice required by Exhibit A as
     Original Code, and which, at the time of its release under this
     License is not already Covered Code governed by this License.

     1.10.1. "Patent Claims" means any patent claim(s), now owned or
     hereafter acquired, including without limitation,  method, process,
     and apparatus claims, in any patent Licensable by grantor.

     1.11. "Source Code" means the preferred form of the Covered Code for
     making modifications to it, including all modules it contains, plus
     any associated interface definition files, scripts used to control
     compilation and installation of an Executable, or source code
     differential comparisons against either the Original Code or another
     well known, available Covered Code of the Contributor's choice. The
     Source Code can be in a compressed or archival form, provided the
     appropriate decompression or de-archiving software is widely available
     for no charge.

     1.12. "You" (or "Your")  means an individual or a legal entity
     exercising rights under, and complying with all of the terms of, this
     License or a future version of this License issued under Section 6.1.
     For legal entities, "You" includes any entity which controls, is
     controlled by, or is under common control with You. For purposes of
     this definition, "control" means (a) the power, direct or indirect,
     to cause the direction or management of such entity, whether by
     contract or otherwise, or (b) ownership of more than fifty percent
     (50%) of the outstanding shares or beneficial ownership of such
     entity.

2. Source Code License.

     2.1. The Initial Developer Grant.
     The Initial Developer hereby grants You a world-wide, royalty-free,
     non-exclusive license, subject to third party intellectual property
     claims:
          (a)  under intellectual property rights (other than patent or
          trademark) Licensable by Initial Developer to use, reproduce,
          modify, display, perform, sublicense and distribute the Original
          Code (or portions thereof) with or without Modifications, and/or
          as part of a Larger Work; and

          (b) under Patents Claims infringed by the making, using or
          selling of Original Code, to make, have made, use, practice,
          sell, and offer for sale, and/or otherwise dispose of the
          Original Code (or portions thereof).

          (c) the licenses granted in this Section 2.1(a) and (b) are
          effective on the date Initial Developer first distributes
          Original Code under the terms of this License.

          (d) Notwithstanding Section 2.1(b) above, no patent license is
          granted: 1) for code that You delete from the Original Code; 2)
          separate from the Original Code;  or 3) for infringements caused
          by: i) the modification of the Original Code or ii) the
          combination of the Original Code with other software or devices.

     2.2. Contributor Grant.
     Subject to third party intellectual property claims, each Contributor
     hereby grants You a world-wide, royalty-free, non-exclusive license

          (a)  under intellectual property rights (other than patent or
          trademark) Licensable by Contributor, to use, reproduce, modify,
          display, perform, sublicense and distribute the Modifications
          created by such Contributor (or portions thereof) either on an
          unmodified basis, with other Modifications, as Covered Code
          and/or as part of a Larger Work; and

          (b) under Patent Claims infringed by the making, using, or
          selling of  Modifications made by that Contributor either alone
          and/or in combination with its Contributor Version (or portions
          of such combination), to make, use, sell, offer for sale, have
          made, and/or otherwise dispose of: 1) Modifications made by that
          Contributor (or portions thereof); and 2) the combination of
          Modifications made by that Contributor with its Contributor
          Version (or portions of such combination).

          (c) the licenses granted in Sections 2.2(a) and 2.2(b) are
          effective on the date Contributor first makes Commercial Use of
          the Covered Code.

          (d)    Notwithstanding Section 2.2(b) above, no patent license is
          granted: 1) for any code that Contributor has deleted from the
          Contributor Version; 2)  separate from the Contributor Version;
          3)  for infringements caused by: i) third party modifications of
          Contributor Version or ii)  the combination of Modifications made
          by that Contributor with other software  (except as part of the
          Contributor Version) or other devices; or 4) under Patent Claims
          infringed by Covered Code in the absence of Modifications made by
          that Contributor.

3. Distribution Obligations.

     3.1. Application of License.
     The Modifications which You create or to which You contribute are
     governed by the terms of this License, including without limitation
     Section 2.2. The Source Code version of Covered Code may be
     distributed only under the terms of this License or a future version
     of this License released under Section 6.1, and You must include a
     copy of this License with every copy of the Source Code You
     distribute. You may not offer or impose any terms on any Source Code
     version that alters or restricts the applicable version of this
     License or the recipients' rights hereunder. However, You may include
     an additional document offering the additional rights described in
     Section 3.5.

     3.2. Availability of Source Code.
     Any Modification which You create or to which You contribute must be
     made available in Source Code form under the terms of this License
     either on the same media as an Executable version or via an accepted
     Electronic Distribution Mechanism to anyone to whom you made an
     Executable version available; and if made available via Electronic
     Distribution Mechanism, must remain available for at least twelve (12)
     months after the date it initially became available, or at least six
     (6) months after a subsequent version of that particular Modification
     has been made available to such recipients. You are responsible for
     ensuring that the Source Code version remains available even if the
     Electronic Distribution Mechanism is maintained by a third party.

     3.3. Description of Modifications.
     You must cause all Covered Code to which You contribute to contain a
     file documenting the changes You made to create that Covered Code and
     the date of any change. You must include a prominent statement that
     the Modification is derived, directly or indirectly, from Original
     Code provided by the Initial Developer and including the name of the
     Initial Developer in (a) the Source Code, and (b) in any notice in an
     Executable version or related documentation in which You describe the
     origin or ownership of the Covered Code.

     3.4. Intellectual Property Matters
          (a) Third Party Claims.
          If Contributor has knowledge that a license under a third party's
          intellectual property rights is required to exercise the rights
          granted by such Contributor under Sections 2.1 or 2.2,
          Contributor must include a text file with the Source Code
          distribution titled "LEGAL" which describes the claim and the
          party making the claim in sufficient detail that a recipient will
          know whom to contact. If Contributor obtains such knowledge after
          the Modification is made available as described in Section 3.2,
          Contributor shall promptly modify the LEGAL file in all copies
          Contributor makes available thereafter and shall take other steps
          (such as notifying appropriate mailing lists or newsgroups)
          reasonably calculated to inform those who received the Covered
          Code that new knowledge has been obtained.

          (b) Contributor APIs.
          If Contributor's Modifications include an application programming
          interface and Contributor has knowledge of patent licenses which
          are reasonably necessary to implement that API, Contributor must
          also include this information in the LEGAL file.

               (c)    Representations.
          Contributor represents that, except as disclosed pursuant to
          Section 3.4(a) above, Contributor believes that Contributor's
          Modifications are Contributor's original creation(s) and/or
          Contributor has sufficient rights to grant the rights conveyed by
          this License.

     3.5. Required Notices.
     You must duplicate the notice in Exhibit A in each file of the Source
     Code.  If it is not possible to put such notice in a particular Source
     Code file due to its structure, then You must include such notice in a
     location (such as a relevant directory) where a user would be likely
     to look for such a notice.  If You created one or more Modification(s)
     You may add your name as a Contributor to the notice described in
     Exhibit A.  You must also duplicate this License in any documentation
     for the Source Code where You describe recipients' rights or ownership
     rights relating to Covered Code.  You may choose to offer, and to
     charge a fee for, warranty, support, indemnity or liability
     obligations to one or more recipients of Covered Code. However, You
     may do so only on Your own behalf, and not on behalf of the Initial
     Developer or any Contributor. You must make it absolutely clear than
     any such warranty, support, indemnity or liability obligation is
     offered by You alone, and You hereby agree to indemnify the Initial
     Developer and every Contributor for any liability incurred by the
     Initial Developer or such Contributor as a result of warranty,
     support, indemnity or liability terms You offer.

     3.6. Distribution of Executable Versions.
     You may distribute Covered Code in Executable form only if the
     requirements of Section 3.1-3.5 have been met for that Covered Code,
     and if You include a notice stating that the Source Code version of
     the Covered Code is available under the terms of this License,
     including a description of how and where You have fulfilled the
     obligations of Section 3.2. The notice must be conspicuously included
     in any notice in an Executable version, related documentation or
     collateral in which You describe recipients' rights relating to the
     Covered Code. You may distribute the Executable version of Covered
     Code or ownership rights under a license of Your choice, which may
     contain terms different from this License, provided that You are in
     compliance with the terms of this License and that the license for the
     Executable version does not attempt to limit or alter the recipient's
     rights in the Source Code version from the rights set forth in this
     License. If You distribute the Executable version under a different
     license You must make it absolutely clear that any terms which differ
     from this License are offered by You alone, not by the Initial
     Developer or any Contributor. You hereby agree to indemnify the
     Initial Developer and every Contributor for any liability incurred by
     the Initial Developer or such Contributor as a result of any such
     terms You offer.

     3.7. Larger Works.
     You may create a Larger Work by combining Covered Code with other code
     not governed by the terms of this License and distribute the Larger
     Work as a single product. In such a case, You must make sure the
     requirements of this License are fulfilled for the Covered Code.

4. Inability to Comply Due to Statute or Regulation.

     If it is impossible for You to comply with any of the terms of this
     License with respect to some or all of the Covered Code due to
     statute, judicial order, or regulation then You must: (a) comply with
     the terms of this License to the maximum extent possible; and (b)
     describe the limitations and the code they affect. Such description
     must be included in the LEGAL file described in Section 3.4 and must
     be included with all distributions of the Source Code. Except to the
     extent prohibited by statute or regulation, such description must be
     sufficiently detailed for a recipient of ordinary skill to be able to
     understand it.

5. Application of this License.

     This License applies to code to which the Initial Developer has
     attached the notice in Exhibit A and to related Covered Code.

6. Versions of the License.

     6.1. New Versions.
     Netscape Communications Corporation ("Netscape") may publish revised
     and/or new versions of the License from time to time. Each version
     will be given a distinguishing version number.

     6.2. Effect of New Versions.
     Once Covered Code has been published under a particular version of the
     License, You may always continue to use it under the terms of that
     version. You may also choose to use such Covered Code under the terms
     of any subsequent version of the License published by Netscape. No one
     other than Netscape has the right to modify the terms applicable to
     Covered Code created under this License.

     6.3. Derivative Works.
     If You create or use a modified version of this License (which you may
     only do in order to apply it to code which is not already Covered Code
     governed by this License), You must (a) rename Your license so that
     the phrases "Mozilla", "MOZILLAPL", "MOZPL", "Netscape",
     "MPL", "NPL" or any confusingly similar phrase do not appear in your
     license (except to note that your license differs from this License)
     and (b) otherwise make it clear that Your version of the license
     contains terms which differ from the Mozilla Public License and
     Netscape Public License. (Filling in the name of the Initial
     Developer, Original Code or Contributor in the notice described in
     Exhibit A shall not of themselves be deemed to be modifications of
     this License.)

7. DISCLAIMER OF WARRANTY.

     COVERED CODE IS PROVIDED UNDER THIS LICENSE ON AN "AS IS" BASIS,
     WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING,
     WITHOUT LIMITATION, WARRANTIES THAT THE COVERED CODE IS FREE OF
     DEFECTS, MERCHANTABLE, FIT FOR A PARTICULAR PURPOSE OR NON-INFRINGING.
     THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE COVERED CODE
     IS WITH YOU. SHOULD ANY COVERED CODE PROVE DEFECTIVE IN ANY RESPECT,
     YOU (NOT THE INITIAL DEVELOPER OR ANY OTHER CONTRIBUTOR) ASSUME THE
     COST OF ANY NECESSARY SERVICING, REPAIR OR CORRECTION. THIS DISCLAIMER
     OF WARRANTY CONSTITUTES AN ESSENTIAL PART OF THIS LICENSE. NO USE OF
     ANY COVERED CODE IS AUTHORIZED HEREUNDER EXCEPT UNDER THIS DISCLAIMER.

8. TERMINATION.

     8.1.  This License and the rights granted hereunder will terminate
     automatically if You fail to comply with terms herein and fail to cure
     such breach within 30 days of becoming aware of the breach. All
     sublicenses to the Covered Code which are properly granted shall
     survive any termination of this License. Provisions which, by their
     nature, must remain in effect beyond the termination of this License
     shall survive.

     8.2.  If You initiate litigation by asserting a patent infringement
     claim (excluding declatory judgment actions) against Initial Developer
     or a Contributor (the Initial Developer or Contributor against whom
     You file such action is referred to as "Participant")  alleging that:

     (a)  such Participant's Contributor Version directly or indirectly
     infringes any patent, then any and all rights granted by such
     Participant to You under Sections 2.1 and/or 2.2 of this License
     shall, upon 60 days notice from Participant terminate prospectively,
     unless if within 60 days after receipt of notice You either: (i)
     agree in writing to pay Participant a mutually agreeable reasonable
     royalty for Your past and future use of Modifications made by such
     Participant, or (ii) withdraw Your litigation claim with respect to
     the Contributor Version against such Participant.  If within 60 days
     of notice, a reasonable royalty and payment arrangement are not
     mutually agreed upon in writing by the parties or the litigation claim
     is not withdrawn, the rights granted by Participant to You under
     Sections 2.1 and/or 2.2 automatically terminate at the expiration of
     the 60 day notice period specified above.

     (b)  any software, hardware, or device, other than such Participant's
     Contributor Version, directly or indirectly infringes any patent, then
     any rights granted to You by such Participant under Sections 2.1(b)
     and 2.2(b) are revoked effective as of the date You first made, used,
     sold, distributed, or had made, Modifications made by that
     Participant.

     8.3.  If You assert a patent infringement claim against Participant
     alleging that such Participant's Contributor Version directly or
     indirectly infringes any patent where such claim is resolved (such as
     by license or settlement) prior to the initiation of patent
     infringement litigation, then the reasonable value of the licenses
     granted by such Participant under Sections 2.1 or 2.2 shall be taken
     into account in determining the amount or value of any payment or
     license.

     8.4.  In the event of termination under Sections 8.1 or 8.2 above,
     all end user license agreements (excluding distributors and resellers)
     which have been validly granted by You or any distributor hereunder
     prior to termination shall survive termination.

9. LIMITATION OF LIABILITY.

     UNDER NO CIRCUMSTANCES AND UNDER NO LEGAL THEORY, WHETHER TORT
     (INCLUDING NEGLIGENCE), CONTRACT, OR OTHERWISE, SHALL YOU, THE INITIAL
     DEVELOPER, ANY OTHER CONTRIBUTOR, OR ANY DISTRIBUTOR OF COVERED CODE,
     OR ANY SUPPLIER OF ANY OF SUCH PARTIES, BE LIABLE TO ANY PERSON FOR
     ANY INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES OF ANY
     CHARACTER INCLUDING, WITHOUT LIMITATION, DAMAGES FOR LOSS OF GOODWILL,
     WORK STOPPAGE, COMPUTER FAILURE OR MALFUNCTION, OR ANY AND ALL OTHER
     COMMERCIAL DAMAGES OR LOSSES, EVEN IF SUCH PARTY SHALL HAVE BEEN
     INFORMED OF THE POSSIBILITY OF SUCH DAMAGES. THIS LIMITATION OF
     LIABILITY SHALL NOT APPLY TO LIABILITY FOR DEATH OR PERSONAL INJURY
     RESULTING FROM SUCH PARTY'S NEGLIGENCE TO THE EXTENT APPLICABLE LAW
     PROHIBITS SUCH LIMITATION. SOME JURISDICTIONS DO NOT ALLOW THE
     EXCLUSION OR LIMITATION OF INCIDENTAL OR CONSEQUENTIAL DAMAGES, SO
     THIS EXCLUSION AND LIMITATION MAY NOT APPLY TO YOU.

10. U.S. GOVERNMENT END USERS.

     The Covered Code is a "commercial item," as that term is defined in
     48 C.F.R. 2.101 (Oct. 1995), consisting of "commercial computer
     software" and "commercial computer software documentation," as such
     terms are used in 48 C.F.R. 12.212 (Sept. 1995). Consistent with 48
     C.F.R. 12.212 and 48 C.F.R. 227.7202-1 through 227.7202-4 (June 1995),
     all U.S. Government End Users acquire Covered Code with only those
     rights set forth herein.

11. MISCELLANEOUS.

     This License represents the complete agreement concerning subject
     matter hereof. If any provision of this License is held to be
     unenforceable, such provision shall be reformed only to the extent
     necessary to make it enforceable. This License shall be governed by
     California law provisions (except to the extent applicable law, if
     any, provides otherwise), excluding its conflict-of-law provisions.
     With respect to disputes in which at least one party is a citizen of,
     or an entity chartered or registered to do business in the United
     States of America, any litigation relating to this License shall be
     subject to the jurisdiction of the Federal Courts of the Northern
     District of California, with venue lying in Santa Clara County,
     California, with the losing party responsible for costs, including
     without limitation, court costs and reasonable attorneys' fees and
     expenses. The application of the United Nations Convention on
     Contracts for the International Sale of Goods is expressly excluded.
     Any law or regulation which provides that the language of a contract
     shall be construed against the drafter shall not apply to this
     License.

12. RESPONSIBILITY FOR CLAIMS.

     As between Initial Developer and the Contributors, each party is
     responsible for claims and damages arising, directly or indirectly,
     out of its utilization of rights under this License and You agree to
     work with Initial Developer and Contributors to distribute such
     responsibility on an equitable basis. Nothing herein is intended or
     shall be deemed to constitute any admission of liability.

13. MULTIPLE-LICENSED CODE.

     Initial Developer may designate portions of the Covered Code as
     "Multiple-Licensed".  "Multiple-Licensed" means that the Initial
     Developer permits you to utilize portions of the Covered Code under
     Your choice of the NPL or the alternative licenses, if any, specified
     by the Initial Developer in the file described in Exhibit A.

EXHIBIT A -Mozilla Public License.

     ``The contents of this file are subject to the Mozilla Public License
     Version 1.1 (the "License"); you may not use this file except in
     compliance with the License. You may obtain a copy of the License at
     http://www.mozilla.org/MPL/

     Software distributed under the License is distributed on an "AS IS"
     basis, WITHOUT WARRANTY OF ANY KIND, either express or implied. See the
     License for the specific language governing rights and limitations
     under the License.

     The Original Code is ______________________________________.

     The Initial Developer of the Original Code is ________________________.
     Portions created by ______________________ are Copyright (C) ______
     _______________________. All Rights Reserved.

     Contributor(s): ______________________________________.

     Alternatively, the contents of this file may be used under the terms
     of the _____ license (the  "[___] License"), in which case the
     provisions of [______] License are applicable instead of those
     above.  If you wish to allow use of your version of this file only
     under the terms of the [____] License and not to allow others to use
     your version of this file under the MPL, indicate your decision by
     deleting  the provisions above and replace  them with the notice and
     other provisions required by the [___] License.  If you do not delete
     the provisions above, a recipient may use your version of this file
     under either the MPL or the [___] License."

     [NOTE: The text of this Exhibit A may differ slightly from the text of
     the notices in the Source Code files of the Original Code. You should
     use the text of this Exhibit A rather than the text found in the
     Original Code Source Code for Your Modifications.]

     ----------------------------------------------------------------------

     AMENDMENTS

     The Netscape Public License Version 1.1 ("NPL") consists of the
     Mozilla Public License Version 1.1 with the following Amendments,
     including Exhibit A-Netscape Public License.  Files identified with
     "Exhibit A-Netscape Public License" are governed by the Netscape
     Public License Version 1.1.

     Additional Terms applicable to the Netscape Public License.
          I. Effect.
          These additional terms described in this Netscape Public
          License -- Amendments shall apply to the Mozilla Communicator
          client code and to all Covered Code under this License.

          II. "Netscape's Branded Code" means Covered Code that Netscape
          distributes and/or permits others to distribute under one or more
          trademark(s) which are controlled by Netscape but which are not
          licensed for use under this License.

          III. Netscape and logo.
          This License does not grant any rights to use the trademarks
          "Netscape", the "Netscape N and horizon" logo or the "Netscape
          lighthouse" logo, "Netcenter", "Gecko", "Java" or "JavaScript",
          "Smart Browsing" even if such marks are included in the Original
          Code or Modifications.

          IV. Inability to Comply Due to Contractual Obligation.
          Prior to licensing the Original Code under this License, Netscape
          has licensed third party code for use in Netscape's Branded Code.
          To the extent that Netscape is limited contractually from making
          such third party code available under this License, Netscape may
          choose to reintegrate such code into Covered Code without being
          required to distribute such code in Source Code form, even if
          such code would otherwise be considered "Modifications" under
          this License.

          V. Use of Modifications and Covered Code by Initial Developer.
               V.1. In General.
               The obligations of Section 3 apply to Netscape, except to
               the extent specified in this Amendment, Section V.2 and V.3.

               V.2. Other Products.
               Netscape may include Covered Code in products other than the
               Netscape's Branded Code which are released by Netscape
               during the two (2) years following the release date of the
               Original Code, without such additional products becoming
               subject to the terms of this License, and may license such
               additional products on different terms from those contained
               in this License.

               V.3. Alternative Licensing.
               Netscape may license the Source Code of Netscape's Branded
               Code, including Modifications incorporated therein, without
               such Netscape Branded Code becoming subject to the terms of
               this License, and may license such Netscape Branded Code on
               different terms from those contained in this License.

          VI. Litigation.
          Notwithstanding the limitations of Section 11 above, the
          provisions regarding litigation in Section 11(a), (b) and (c) of
          the License shall apply to all disputes relating to this License.

     EXHIBIT A-Netscape Public License.

          "The contents of this file are subject to the Netscape Public
          License Version 1.1 (the "License"); you may not use this file
          except in compliance with the License. You may obtain a copy of
          the License at http://www.mozilla.org/NPL/

          Software distributed under the License is distributed on an "AS
          IS" basis, WITHOUT WARRANTY OF ANY KIND, either express or
          implied. See the License for the specific language governing
          rights and limitations under the License.

          The Original Code is Mozilla Communicator client code, released
          March 31, 1998.

          The Initial Developer of the Original Code is Netscape
          Communications Corporation. Portions created by Netscape are
          Copyright (C) 1998-1999 Netscape Communications Corporation. All
          Rights Reserved.

          Contributor(s): ______________________________________.

          Alternatively, the contents of this file may be used under the
          terms of the _____ license (the "[___] License"), in which case
          the provisions of [______] License are applicable  instead of
          those above.  If you wish to allow use of your version of this
          file only under the terms of the [____] License and not to allow
          others to use your version of this file under the NPL, indicate
          your decision by deleting  the provisions above and replace  them
          with the notice and other provisions required by the [___]
          License.  If you do not delete the provisions above, a recipient
          may use your version of this file under either the NPL or the
          [___] License."

      *********************
      *********************
      *** SPECIAL NOTES ***
      *********************
      *********************
      *********************
      See The Directory Game\Mozilla\Patch For Specific Details
      No Changes Except For The Linden Patch Were Done To Gecko

********************************************************************
*  LLMOZLIB                                                        *
********************************************************************

                          MOZILLA PUBLIC LICENSE
                                Version 1.1

                              ---------------

1. Definitions.

     1.0.1. "Commercial Use" means distribution or otherwise making the
     Covered Code available to a third party.

     1.1. "Contributor" means each entity that creates or contributes to
     the creation of Modifications.

     1.2. "Contributor Version" means the combination of the Original
     Code, prior Modifications used by a Contributor, and the Modifications
     made by that particular Contributor.

     1.3. "Covered Code" means the Original Code or Modifications or the
     combination of the Original Code and Modifications, in each case
     including portions thereof.

     1.4. "Electronic Distribution Mechanism" means a mechanism generally
     accepted in the software development community for the electronic
     transfer of data.

     1.5. "Executable" means Covered Code in any form other than Source
     Code.

     1.6. "Initial Developer" means the individual or entity identified
     as the Initial Developer in the Source Code notice required by Exhibit
     A.

     1.7. "Larger Work" means a work which combines Covered Code or
     portions thereof with code not governed by the terms of this License.

     1.8. "License" means this document.

     1.8.1. "Licensable" means having the right to grant, to the maximum
     extent possible, whether at the time of the initial grant or
     subsequently acquired, any and all of the rights conveyed herein.

     1.9. "Modifications" means any addition to or deletion from the
     substance or structure of either the Original Code or any previous
     Modifications. When Covered Code is released as a series of files, a
     Modification is:
          A. Any addition to or deletion from the contents of a file
          containing Original Code or previous Modifications.

          B. Any new file that contains any part of the Original Code or
          previous Modifications.

     1.10. "Original Code" means Source Code of computer software code
     which is described in the Source Code notice required by Exhibit A as
     Original Code, and which, at the time of its release under this
     License is not already Covered Code governed by this License.

     1.10.1. "Patent Claims" means any patent claim(s), now owned or
     hereafter acquired, including without limitation,  method, process,
     and apparatus claims, in any patent Licensable by grantor.

     1.11. "Source Code" means the preferred form of the Covered Code for
     making modifications to it, including all modules it contains, plus
     any associated interface definition files, scripts used to control
     compilation and installation of an Executable, or source code
     differential comparisons against either the Original Code or another
     well known, available Covered Code of the Contributor's choice. The
     Source Code can be in a compressed or archival form, provided the
     appropriate decompression or de-archiving software is widely available
     for no charge.

     1.12. "You" (or "Your")  means an individual or a legal entity
     exercising rights under, and complying with all of the terms of, this
     License or a future version of this License issued under Section 6.1.
     For legal entities, "You" includes any entity which controls, is
     controlled by, or is under common control with You. For purposes of
     this definition, "control" means (a) the power, direct or indirect,
     to cause the direction or management of such entity, whether by
     contract or otherwise, or (b) ownership of more than fifty percent
     (50%) of the outstanding shares or beneficial ownership of such
     entity.

2. Source Code License.

     2.1. The Initial Developer Grant.
     The Initial Developer hereby grants You a world-wide, royalty-free,
     non-exclusive license, subject to third party intellectual property
     claims:
          (a)  under intellectual property rights (other than patent or
          trademark) Licensable by Initial Developer to use, reproduce,
          modify, display, perform, sublicense and distribute the Original
          Code (or portions thereof) with or without Modifications, and/or
          as part of a Larger Work; and

          (b) under Patents Claims infringed by the making, using or
          selling of Original Code, to make, have made, use, practice,
          sell, and offer for sale, and/or otherwise dispose of the
          Original Code (or portions thereof).

          (c) the licenses granted in this Section 2.1(a) and (b) are
          effective on the date Initial Developer first distributes
          Original Code under the terms of this License.

          (d) Notwithstanding Section 2.1(b) above, no patent license is
          granted: 1) for code that You delete from the Original Code; 2)
          separate from the Original Code;  or 3) for infringements caused
          by: i) the modification of the Original Code or ii) the
          combination of the Original Code with other software or devices.

     2.2. Contributor Grant.
     Subject to third party intellectual property claims, each Contributor
     hereby grants You a world-wide, royalty-free, non-exclusive license

          (a)  under intellectual property rights (other than patent or
          trademark) Licensable by Contributor, to use, reproduce, modify,
          display, perform, sublicense and distribute the Modifications
          created by such Contributor (or portions thereof) either on an
          unmodified basis, with other Modifications, as Covered Code
          and/or as part of a Larger Work; and

          (b) under Patent Claims infringed by the making, using, or
          selling of  Modifications made by that Contributor either alone
          and/or in combination with its Contributor Version (or portions
          of such combination), to make, use, sell, offer for sale, have
          made, and/or otherwise dispose of: 1) Modifications made by that
          Contributor (or portions thereof); and 2) the combination of
          Modifications made by that Contributor with its Contributor
          Version (or portions of such combination).

          (c) the licenses granted in Sections 2.2(a) and 2.2(b) are
          effective on the date Contributor first makes Commercial Use of
          the Covered Code.

          (d)    Notwithstanding Section 2.2(b) above, no patent license is
          granted: 1) for any code that Contributor has deleted from the
          Contributor Version; 2)  separate from the Contributor Version;
          3)  for infringements caused by: i) third party modifications of
          Contributor Version or ii)  the combination of Modifications made
          by that Contributor with other software  (except as part of the
          Contributor Version) or other devices; or 4) under Patent Claims
          infringed by Covered Code in the absence of Modifications made by
          that Contributor.

3. Distribution Obligations.

     3.1. Application of License.
     The Modifications which You create or to which You contribute are
     governed by the terms of this License, including without limitation
     Section 2.2. The Source Code version of Covered Code may be
     distributed only under the terms of this License or a future version
     of this License released under Section 6.1, and You must include a
     copy of this License with every copy of the Source Code You
     distribute. You may not offer or impose any terms on any Source Code
     version that alters or restricts the applicable version of this
     License or the recipients' rights hereunder. However, You may include
     an additional document offering the additional rights described in
     Section 3.5.

     3.2. Availability of Source Code.
     Any Modification which You create or to which You contribute must be
     made available in Source Code form under the terms of this License
     either on the same media as an Executable version or via an accepted
     Electronic Distribution Mechanism to anyone to whom you made an
     Executable version available; and if made available via Electronic
     Distribution Mechanism, must remain available for at least twelve (12)
     months after the date it initially became available, or at least six
     (6) months after a subsequent version of that particular Modification
     has been made available to such recipients. You are responsible for
     ensuring that the Source Code version remains available even if the
     Electronic Distribution Mechanism is maintained by a third party.

     3.3. Description of Modifications.
     You must cause all Covered Code to which You contribute to contain a
     file documenting the changes You made to create that Covered Code and
     the date of any change. You must include a prominent statement that
     the Modification is derived, directly or indirectly, from Original
     Code provided by the Initial Developer and including the name of the
     Initial Developer in (a) the Source Code, and (b) in any notice in an
     Executable version or related documentation in which You describe the
     origin or ownership of the Covered Code.

     3.4. Intellectual Property Matters
          (a) Third Party Claims.
          If Contributor has knowledge that a license under a third party's
          intellectual property rights is required to exercise the rights
          granted by such Contributor under Sections 2.1 or 2.2,
          Contributor must include a text file with the Source Code
          distribution titled "LEGAL" which describes the claim and the
          party making the claim in sufficient detail that a recipient will
          know whom to contact. If Contributor obtains such knowledge after
          the Modification is made available as described in Section 3.2,
          Contributor shall promptly modify the LEGAL file in all copies
          Contributor makes available thereafter and shall take other steps
          (such as notifying appropriate mailing lists or newsgroups)
          reasonably calculated to inform those who received the Covered
          Code that new knowledge has been obtained.

          (b) Contributor APIs.
          If Contributor's Modifications include an application programming
          interface and Contributor has knowledge of patent licenses which
          are reasonably necessary to implement that API, Contributor must
          also include this information in the LEGAL file.

               (c)    Representations.
          Contributor represents that, except as disclosed pursuant to
          Section 3.4(a) above, Contributor believes that Contributor's
          Modifications are Contributor's original creation(s) and/or
          Contributor has sufficient rights to grant the rights conveyed by
          this License.

     3.5. Required Notices.
     You must duplicate the notice in Exhibit A in each file of the Source
     Code.  If it is not possible to put such notice in a particular Source
     Code file due to its structure, then You must include such notice in a
     location (such as a relevant directory) where a user would be likely
     to look for such a notice.  If You created one or more Modification(s)
     You may add your name as a Contributor to the notice described in
     Exhibit A.  You must also duplicate this License in any documentation
     for the Source Code where You describe recipients' rights or ownership
     rights relating to Covered Code.  You may choose to offer, and to
     charge a fee for, warranty, support, indemnity or liability
     obligations to one or more recipients of Covered Code. However, You
     may do so only on Your own behalf, and not on behalf of the Initial
     Developer or any Contributor. You must make it absolutely clear than
     any such warranty, support, indemnity or liability obligation is
     offered by You alone, and You hereby agree to indemnify the Initial
     Developer and every Contributor for any liability incurred by the
     Initial Developer or such Contributor as a result of warranty,
     support, indemnity or liability terms You offer.

     3.6. Distribution of Executable Versions.
     You may distribute Covered Code in Executable form only if the
     requirements of Section 3.1-3.5 have been met for that Covered Code,
     and if You include a notice stating that the Source Code version of
     the Covered Code is available under the terms of this License,
     including a description of how and where You have fulfilled the
     obligations of Section 3.2. The notice must be conspicuously included
     in any notice in an Executable version, related documentation or
     collateral in which You describe recipients' rights relating to the
     Covered Code. You may distribute the Executable version of Covered
     Code or ownership rights under a license of Your choice, which may
     contain terms different from this License, provided that You are in
     compliance with the terms of this License and that the license for the
     Executable version does not attempt to limit or alter the recipient's
     rights in the Source Code version from the rights set forth in this
     License. If You distribute the Executable version under a different
     license You must make it absolutely clear that any terms which differ
     from this License are offered by You alone, not by the Initial
     Developer or any Contributor. You hereby agree to indemnify the
     Initial Developer and every Contributor for any liability incurred by
     the Initial Developer or such Contributor as a result of any such
     terms You offer.

     3.7. Larger Works.
     You may create a Larger Work by combining Covered Code with other code
     not governed by the terms of this License and distribute the Larger
     Work as a single product. In such a case, You must make sure the
     requirements of this License are fulfilled for the Covered Code.

4. Inability to Comply Due to Statute or Regulation.

     If it is impossible for You to comply with any of the terms of this
     License with respect to some or all of the Covered Code due to
     statute, judicial order, or regulation then You must: (a) comply with
     the terms of this License to the maximum extent possible; and (b)
     describe the limitations and the code they affect. Such description
     must be included in the LEGAL file described in Section 3.4 and must
     be included with all distributions of the Source Code. Except to the
     extent prohibited by statute or regulation, such description must be
     sufficiently detailed for a recipient of ordinary skill to be able to
     understand it.

5. Application of this License.

     This License applies to code to which the Initial Developer has
     attached the notice in Exhibit A and to related Covered Code.

6. Versions of the License.

     6.1. New Versions.
     Netscape Communications Corporation ("Netscape") may publish revised
     and/or new versions of the License from time to time. Each version
     will be given a distinguishing version number.

     6.2. Effect of New Versions.
     Once Covered Code has been published under a particular version of the
     License, You may always continue to use it under the terms of that
     version. You may also choose to use such Covered Code under the terms
     of any subsequent version of the License published by Netscape. No one
     other than Netscape has the right to modify the terms applicable to
     Covered Code created under this License.

     6.3. Derivative Works.
     If You create or use a modified version of this License (which you may
     only do in order to apply it to code which is not already Covered Code
     governed by this License), You must (a) rename Your license so that
     the phrases "Mozilla", "MOZILLAPL", "MOZPL", "Netscape",
     "MPL", "NPL" or any confusingly similar phrase do not appear in your
     license (except to note that your license differs from this License)
     and (b) otherwise make it clear that Your version of the license
     contains terms which differ from the Mozilla Public License and
     Netscape Public License. (Filling in the name of the Initial
     Developer, Original Code or Contributor in the notice described in
     Exhibit A shall not of themselves be deemed to be modifications of
     this License.)

7. DISCLAIMER OF WARRANTY.

     COVERED CODE IS PROVIDED UNDER THIS LICENSE ON AN "AS IS" BASIS,
     WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING,
     WITHOUT LIMITATION, WARRANTIES THAT THE COVERED CODE IS FREE OF
     DEFECTS, MERCHANTABLE, FIT FOR A PARTICULAR PURPOSE OR NON-INFRINGING.
     THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE COVERED CODE
     IS WITH YOU. SHOULD ANY COVERED CODE PROVE DEFECTIVE IN ANY RESPECT,
     YOU (NOT THE INITIAL DEVELOPER OR ANY OTHER CONTRIBUTOR) ASSUME THE
     COST OF ANY NECESSARY SERVICING, REPAIR OR CORRECTION. THIS DISCLAIMER
     OF WARRANTY CONSTITUTES AN ESSENTIAL PART OF THIS LICENSE. NO USE OF
     ANY COVERED CODE IS AUTHORIZED HEREUNDER EXCEPT UNDER THIS DISCLAIMER.

8. TERMINATION.

     8.1.  This License and the rights granted hereunder will terminate
     automatically if You fail to comply with terms herein and fail to cure
     such breach within 30 days of becoming aware of the breach. All
     sublicenses to the Covered Code which are properly granted shall
     survive any termination of this License. Provisions which, by their
     nature, must remain in effect beyond the termination of this License
     shall survive.

     8.2.  If You initiate litigation by asserting a patent infringement
     claim (excluding declatory judgment actions) against Initial Developer
     or a Contributor (the Initial Developer or Contributor against whom
     You file such action is referred to as "Participant")  alleging that:

     (a)  such Participant's Contributor Version directly or indirectly
     infringes any patent, then any and all rights granted by such
     Participant to You under Sections 2.1 and/or 2.2 of this License
     shall, upon 60 days notice from Participant terminate prospectively,
     unless if within 60 days after receipt of notice You either: (i)
     agree in writing to pay Participant a mutually agreeable reasonable
     royalty for Your past and future use of Modifications made by such
     Participant, or (ii) withdraw Your litigation claim with respect to
     the Contributor Version against such Participant.  If within 60 days
     of notice, a reasonable royalty and payment arrangement are not
     mutually agreed upon in writing by the parties or the litigation claim
     is not withdrawn, the rights granted by Participant to You under
     Sections 2.1 and/or 2.2 automatically terminate at the expiration of
     the 60 day notice period specified above.

     (b)  any software, hardware, or device, other than such Participant's
     Contributor Version, directly or indirectly infringes any patent, then
     any rights granted to You by such Participant under Sections 2.1(b)
     and 2.2(b) are revoked effective as of the date You first made, used,
     sold, distributed, or had made, Modifications made by that
     Participant.

     8.3.  If You assert a patent infringement claim against Participant
     alleging that such Participant's Contributor Version directly or
     indirectly infringes any patent where such claim is resolved (such as
     by license or settlement) prior to the initiation of patent
     infringement litigation, then the reasonable value of the licenses
     granted by such Participant under Sections 2.1 or 2.2 shall be taken
     into account in determining the amount or value of any payment or
     license.

     8.4.  In the event of termination under Sections 8.1 or 8.2 above,
     all end user license agreements (excluding distributors and resellers)
     which have been validly granted by You or any distributor hereunder
     prior to termination shall survive termination.

9. LIMITATION OF LIABILITY.

     UNDER NO CIRCUMSTANCES AND UNDER NO LEGAL THEORY, WHETHER TORT
     (INCLUDING NEGLIGENCE), CONTRACT, OR OTHERWISE, SHALL YOU, THE INITIAL
     DEVELOPER, ANY OTHER CONTRIBUTOR, OR ANY DISTRIBUTOR OF COVERED CODE,
     OR ANY SUPPLIER OF ANY OF SUCH PARTIES, BE LIABLE TO ANY PERSON FOR
     ANY INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES OF ANY
     CHARACTER INCLUDING, WITHOUT LIMITATION, DAMAGES FOR LOSS OF GOODWILL,
     WORK STOPPAGE, COMPUTER FAILURE OR MALFUNCTION, OR ANY AND ALL OTHER
     COMMERCIAL DAMAGES OR LOSSES, EVEN IF SUCH PARTY SHALL HAVE BEEN
     INFORMED OF THE POSSIBILITY OF SUCH DAMAGES. THIS LIMITATION OF
     LIABILITY SHALL NOT APPLY TO LIABILITY FOR DEATH OR PERSONAL INJURY
     RESULTING FROM SUCH PARTY'S NEGLIGENCE TO THE EXTENT APPLICABLE LAW
     PROHIBITS SUCH LIMITATION. SOME JURISDICTIONS DO NOT ALLOW THE
     EXCLUSION OR LIMITATION OF INCIDENTAL OR CONSEQUENTIAL DAMAGES, SO
     THIS EXCLUSION AND LIMITATION MAY NOT APPLY TO YOU.

10. U.S. GOVERNMENT END USERS.

     The Covered Code is a "commercial item," as that term is defined in
     48 C.F.R. 2.101 (Oct. 1995), consisting of "commercial computer
     software" and "commercial computer software documentation," as such
     terms are used in 48 C.F.R. 12.212 (Sept. 1995). Consistent with 48
     C.F.R. 12.212 and 48 C.F.R. 227.7202-1 through 227.7202-4 (June 1995),
     all U.S. Government End Users acquire Covered Code with only those
     rights set forth herein.

11. MISCELLANEOUS.

     This License represents the complete agreement concerning subject
     matter hereof. If any provision of this License is held to be
     unenforceable, such provision shall be reformed only to the extent
     necessary to make it enforceable. This License shall be governed by
     California law provisions (except to the extent applicable law, if
     any, provides otherwise), excluding its conflict-of-law provisions.
     With respect to disputes in which at least one party is a citizen of,
     or an entity chartered or registered to do business in the United
     States of America, any litigation relating to this License shall be
     subject to the jurisdiction of the Federal Courts of the Northern
     District of California, with venue lying in Santa Clara County,
     California, with the losing party responsible for costs, including
     without limitation, court costs and reasonable attorneys' fees and
     expenses. The application of the United Nations Convention on
     Contracts for the International Sale of Goods is expressly excluded.
     Any law or regulation which provides that the language of a contract
     shall be construed against the drafter shall not apply to this
     License.

12. RESPONSIBILITY FOR CLAIMS.

     As between Initial Developer and the Contributors, each party is
     responsible for claims and damages arising, directly or indirectly,
     out of its utilization of rights under this License and You agree to
     work with Initial Developer and Contributors to distribute such
     responsibility on an equitable basis. Nothing herein is intended or
     shall be deemed to constitute any admission of liability.

13. MULTIPLE-LICENSED CODE.

     Initial Developer may designate portions of the Covered Code as
     "Multiple-Licensed".  "Multiple-Licensed" means that the Initial
     Developer permits you to utilize portions of the Covered Code under
     Your choice of the NPL or the alternative licenses, if any, specified
     by the Initial Developer in the file described in Exhibit A.

EXHIBIT A -Mozilla Public License.

     ``The contents of this file are subject to the Mozilla Public License
     Version 1.1 (the "License"); you may not use this file except in
     compliance with the License. You may obtain a copy of the License at
     http://www.mozilla.org/MPL/

     Software distributed under the License is distributed on an "AS IS"
     basis, WITHOUT WARRANTY OF ANY KIND, either express or implied. See the
     License for the specific language governing rights and limitations
     under the License.

     The Original Code is ______________________________________.

     The Initial Developer of the Original Code is ________________________.
     Portions created by ______________________ are Copyright (C) ______
     _______________________. All Rights Reserved.

     Contributor(s): ______________________________________.

     Alternatively, the contents of this file may be used under the terms
     of the _____ license (the  "[___] License"), in which case the
     provisions of [______] License are applicable instead of those
     above.  If you wish to allow use of your version of this file only
     under the terms of the [____] License and not to allow others to use
     your version of this file under the MPL, indicate your decision by
     deleting  the provisions above and replace  them with the notice and
     other provisions required by the [___] License.  If you do not delete
     the provisions above, a recipient may use your version of this file
     under either the MPL or the [___] License."

     [NOTE: The text of this Exhibit A may differ slightly from the text of
     the notices in the Source Code files of the Original Code. You should
     use the text of this Exhibit A rather than the text found in the
     Original Code Source Code for Your Modifications.]

     ----------------------------------------------------------------------

     AMENDMENTS

     The Netscape Public License Version 1.1 ("NPL") consists of the
     Mozilla Public License Version 1.1 with the following Amendments,
     including Exhibit A-Netscape Public License.  Files identified with
     "Exhibit A-Netscape Public License" are governed by the Netscape
     Public License Version 1.1.

     Additional Terms applicable to the Netscape Public License.
          I. Effect.
          These additional terms described in this Netscape Public
          License -- Amendments shall apply to the Mozilla Communicator
          client code and to all Covered Code under this License.

          II. "Netscape's Branded Code" means Covered Code that Netscape
          distributes and/or permits others to distribute under one or more
          trademark(s) which are controlled by Netscape but which are not
          licensed for use under this License.

          III. Netscape and logo.
          This License does not grant any rights to use the trademarks
          "Netscape", the "Netscape N and horizon" logo or the "Netscape
          lighthouse" logo, "Netcenter", "Gecko", "Java" or "JavaScript",
          "Smart Browsing" even if such marks are included in the Original
          Code or Modifications.

          IV. Inability to Comply Due to Contractual Obligation.
          Prior to licensing the Original Code under this License, Netscape
          has licensed third party code for use in Netscape's Branded Code.
          To the extent that Netscape is limited contractually from making
          such third party code available under this License, Netscape may
          choose to reintegrate such code into Covered Code without being
          required to distribute such code in Source Code form, even if
          such code would otherwise be considered "Modifications" under
          this License.

          V. Use of Modifications and Covered Code by Initial Developer.
               V.1. In General.
               The obligations of Section 3 apply to Netscape, except to
               the extent specified in this Amendment, Section V.2 and V.3.

               V.2. Other Products.
               Netscape may include Covered Code in products other than the
               Netscape's Branded Code which are released by Netscape
               during the two (2) years following the release date of the
               Original Code, without such additional products becoming
               subject to the terms of this License, and may license such
               additional products on different terms from those contained
               in this License.

               V.3. Alternative Licensing.
               Netscape may license the Source Code of Netscape's Branded
               Code, including Modifications incorporated therein, without
               such Netscape Branded Code becoming subject to the terms of
               this License, and may license such Netscape Branded Code on
               different terms from those contained in this License.

          VI. Litigation.
          Notwithstanding the limitations of Section 11 above, the
          provisions regarding litigation in Section 11(a), (b) and (c) of
          the License shall apply to all disputes relating to this License.

     EXHIBIT A-Netscape Public License.

          "The contents of this file are subject to the Netscape Public
          License Version 1.1 (the "License"); you may not use this file
          except in compliance with the License. You may obtain a copy of
          the License at http://www.mozilla.org/NPL/

          Software distributed under the License is distributed on an "AS
          IS" basis, WITHOUT WARRANTY OF ANY KIND, either express or
          implied. See the License for the specific language governing
          rights and limitations under the License.

          The Original Code is Mozilla Communicator client code, released
          March 31, 1998.

          The Initial Developer of the Original Code is Netscape
          Communications Corporation. Portions created by Netscape are
          Copyright (C) 1998-1999 Netscape Communications Corporation. All
          Rights Reserved.

          Contributor(s): ______________________________________.

          Alternatively, the contents of this file may be used under the
          terms of the _____ license (the "[___] License"), in which case
          the provisions of [______] License are applicable  instead of
          those above.  If you wish to allow use of your version of this
          file only under the terms of the [____] License and not to allow
          others to use your version of this file under the NPL, indicate
          your decision by deleting  the provisions above and replace  them
          with the notice and other provisions required by the [___]
          License.  If you do not delete the provisions above, a recipient
          may use your version of this file under either the NPL or the
          [___] License."

      *********************
      *********************
      *** SPECIAL NOTES ***
      *********************
      *********************
      *********************
      See The Directory Game\Mozilla\Patch For Specific Details
      No Changes except for adding external files and fixing one
      compilation error in llmozlib.

***************************************************************************
* bsdiff                                                                  *
***************************************************************************

BigWorld Technology includes code derived from the bsdiff binary diff/patch
utility developed by Colin Percival. As per the licensing requirements, the
copyright notice and licensing conditions are reproduced below.

Copyright 2003-2005 Colin Percival

All rights reserved.

Redistribution and use in source and binary forms, with or without
modification, are permitted providing that the following conditions are
met:

  * Redistributions of source code must retain the above copyright
  notice, this list of conditions and the following disclaimer.

  * Redistributions in binary form must reproduce the above
  copyright notice, this list of conditions and the following
  disclaimer in the documentation and/or other materials provided with
  the distribution.

THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS
OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
DISCLAIMED. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT,
INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
(INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN
ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
POSSIBILITY OF SUCH DAMAGE.

***************************************************************************
* cURL                                                                    *
***************************************************************************

Curl and libcurl are licensed under a MIT/X derivate license, see below.

COPYRIGHT AND PERMISSION NOTICE

Copyright (c) 1996 - 2011, Daniel Stenberg, <daniel@haxx.se>.

All rights reserved.

Permission to use, copy, modify, and distribute this software for any purpose
with or without fee is hereby granted, provided that the above copyright
notice and this permission notice appear in all copies.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OF THIRD PARTY RIGHTS. IN
NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM,
DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR
OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE
OR OTHER DEALINGS IN THE SOFTWARE.

Except as contained in this notice, the name of a copyright holder shall not
be used in advertising or otherwise to promote the sale, use or other dealings
in this Software without prior written authorization of the copyright holder.

***************************************************************************
* jsoncpp                                                                 *
***************************************************************************

The json-cpp library and this documentation are in Public Domain.

***************************************************************************
* nedalloc                                                                *
***************************************************************************

Boost Software License - Version 1.0 - August 17th, 2003

Permission is hereby granted, free of charge, to any person or organization
obtaining a copy of the software and accompanying documentation covered by
this license (the "Software") to use, reproduce, display, distribute,
execute, and transmit the Software, and to prepare derivative works of the
Software, and to permit third-parties to whom the Software is furnished to
do so, all subject to the following:

The copyright notices in the Software and this entire statement, including
the above license grant, this restriction and the following disclaimer,
must be included in all copies of the Software, in whole or in part, and
all derivative works of the Software, unless such copies or derivative
works are solely in the form of machine-executable object code generated by
a source language processor.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE, TITLE AND NON-INFRINGEMENT. IN NO EVENT
SHALL THE COPYRIGHT HOLDERS OR ANYONE DISTRIBUTING THE SOFTWARE BE LIABLE
FOR ANY DAMAGES OR OTHER LIABILITY, WHETHER IN CONTRACT, TORT OR OTHERWISE,
ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
DEALINGS IN THE SOFTWARE.

***************************************************************************
* OpenAutomate                                                            *
***************************************************************************

/*******************************************************************************
 * NVIDIA Corporation
 * Software License Agreement - OpenAutomate SDK
 *
 * IMPORTANT - READ BEFORE COPYING, INSTALLING OR USING
 * Do not use or load the OpenAutomate SDK and any associated materials
 * provided by NVIDIA on NVIDIA's website (collectively, the "Software")
 * until You have carefully read the following terms and conditions. By
 * loading or using the Software, You agree to fully comply with the terms
 * and conditions of this Software License Agreement ("Agreement") by and
 * between NVIDIA Corporation, a Delaware corporation with its principal
 * place of business at 2701 San Tomas Expressway, Santa Clara, California
 * 95050 U.S.A. ("NVIDIA"), and You. If You do not wish to so agree, do not
 * install or use the Software.
 *
 * For the purposes of this Agreement:
 *
 * "Licensee," "You" and/or "Your" shall mean, collectively and
 * individually, Original Equipment Manufacturers, Independent Hardware
 * Vendors, Independent Software Vendors, and End-Users of the Software
 * pursuant to the terms and conditions of this Agreement.
 *
 * "Derivative Works" shall mean derivatives of the Software created by You
 * or a third party on Your behalf, which term shall include:  (a) for
 * copyrightable or copyrighted material, any translation, abridgement,
 * revision or other form in which an existing work may be recast,
 * transformed or adapted; (b) for work protected by topography or mask
 * right, any translation, abridgement, revision or other form in which an
 * existing work may be recast, transformed or adapted; (c) for patentable
 * or patented material, any Improvement; and (d) for material protected by
 * trade secret, any new material derived from or employing such existing
 * trade secret.
 *
 * "Excluded License" is any license that requires as a condition of use,
 * modification and/or distribution of software subject to the Excluded
 * License, that such software or other software distributed and/or
 * combined with such software be (i) disclosed or distributed in source
 * code form, (ii) licensed for the purpose of making derivative works, or
 * (iii) redistributable at no charge.
 *
 * SECTION 1 - GRANT OF LICENSE.
 * NVIDIA agrees to provide the Software and any associated materials
 * pursuant to the terms and conditions of this Agreement.  Subject to the
 * terms of this Agreement, NVIDIA grants to You a nonexclusive,
 * transferable, worldwide, revocable, limited, royalty-free, fully paid-up
 * license under NVIDIA's copyrights to
 *
 * (a) install, deploy, use, have used execute, reproduce, display,
 * perform, run, modify the source code of the Software, or to prepare and
 * have prepared Derivative Works thereof the Software for Your own
 * internal development, testing and maintenance purposes to incorporate
 * the Software or Derivative Works thereof, in part or whole, into Your
 * software applications;
 *
 * (b)   to transfer, distribute and sublicense the Software (in its
 * unmodified form as delivered to You by NVIDIA pursuant to this
 * Agreement) in any medium or technology for Your sublicensees to
 * incorporate the Software or Derivative Works thereof, in part or whole,
 * into their respective software applications; and
 *
 * (c) to transfer, distribute and sublicense Derivative Works (in object
 * code only) of the Software (i)_as incorporated in Your application
 * software in any medium or technology; and (ii) certified as OpenAutomate
 * Compatible Software.
 *
 * You may exercise your license rights pursuant to Subsection 1(b) and (c)
 * above pursuant to the terms and conditions of any form of end-user
 * software license agreement of Your choice, including but not limited to
 * an Excluded License.
 *
 * In the event NVIDIA certifies Your application software, incorporating
 * the Derivative Works (in object code only) of the Software, as
 * OpenAutomate compatible ("OpenAutomate Compatible Software"), NVIDIA
 * grants You a nonexclusive, worldwide, revocable, paid-up license to use
 * the name and trademark to "OpenAutomate Compatible" solely for the
 * purposes of identifying and/or marketing Your application software as
 * OpenAutomate Compatible Software; provided that Licensee fully complies
 * with the following:
 *
 * (x) Licensee agrees that it is strictly prohibited from using the name
 * and trademark of "OpenAutomate Compatible" if Your application software
 * is not OpenAutomate Compatible Software;
 *
 * (y) if NVIDIA objects to Your improper use of the "OpenAutomate
 * Compatible" name and trademark, You will take all reasonable steps
 * necessary to resolve NVIDIA's objections. NVIDIA may reasonably monitor
 * the quality of Your application software bearing the "OpenAutomate
 * Compatible" name or trademark pursuant to this Agreement; and
 *
 * (z) any goodwill attached to NVIDIA's trademarks, service marks, or
 * trade names belong to NVIDIA and this Agreement does not grant You any
 * right to use them.
 *
 * If You are not the final manufacturer or vendor of a computer system or
 * software program incorporating the Software, or if Your Contractors (as
 * defined below), affiliates or subsidiaries need to exercise any, some or
 * all of the license grant described above herein to the Software on Your
 * behalf, then You may transfer a copy of the Software, (and related
 * end-user documentation) to such recipient for use in accordance with the
 * terms of this Agreement, provided such recipient agrees to be fully
 * bound by the terms hereof. Except as expressly permitted in this
 * Agreement, Unless otherwise authorized in the Agreement, You shall not
 * otherwise assign, sublicense, lease, or in any other way transfer or
 * disclose Software to any third party. Unless otherwise authorized in the
 * Agreement, You shall not reverse- compile, disassemble,
 * reverse-engineer, or in any manner attempt to derive the source code of
 * the Software from the object code portions of the Software.
 *
 * Except as expressly stated in this Agreement, no license or right is
 * granted to You directly or by implication, inducement, estoppel or
 * otherwise. NVIDIA shall have the right to inspect or have an independent
 * auditor inspect Your relevant records to verify Your compliance with the
 * terms and conditions of this Agreement.
 *
 * SECTION 2 - CONFIDENTIALITY.
 * If applicable, any exchange of Confidential Information (as defined in
 * the NDA) shall be made pursuant to the terms and conditions of a
 * separately signed Non-Disclosure Agreement ("NDA") by and between NVIDIA
 * and You. For the sake of clarity, You agree that the Software is
 * Confidential Information of NVIDIA.
 *
 * If You wish to have a third party consultant or subcontractor
 * ("Contractor") perform work on Your behalf which involves access to or
 * use of Software, You shall obtain a written confidentiality agreement
 * from the Contractor which contains terms and obligations with respect to
 * access to or use of Software no less restrictive than those set forth in
 * this Agreement and excluding any distribution or sublicense rights, and
 * use for any other purpose than permitted in this Agreement. Otherwise,
 * You shall not disclose the terms or existence of this Agreement or use
 * NVIDIA's name in any publications, advertisements, or other
 * announcements without NVIDIA's prior written consent.  Unless otherwise
 * provided in this Agreement, You do not have any rights to use any NVIDIA
 * trademarks or logos.
 *
 * SECTION 3 - OWNERSHIP OF SOFTWARE AND INTELLECTUAL PROPERTY RIGHTS.
 * All rights, title and interest to all copies of the Software remain with
 * NVIDIA, subsidiaries, licensors, or its suppliers. The Software is
 * copyrighted and protected by the laws of the United States and other
 * countries, and international treaty provisions. You may not remove any
 * copyright notices from the Software. NVIDIA may make changes to the
 * Software, or to items referenced therein, at any time and without
 * notice, but is not obligated to support or update the Software. Except
 * as otherwise expressly provided, NVIDIA grants no express or implied
 * right under any NVIDIA patents, copyrights, trademarks, or other
 * intellectual property rights.
 *
 * All rights, title and interest in the Derivative Works of the Software
 * remain with You subject to the underlying license from NVIDIA to the
 * Software.  In Your sole discretion, You may grant NVIDIA, upon NVIDIA's
 * request for such a license described herein, an irrevocable, perpetual,
 * nonexclusive, worldwide, royalty-free paid-up license to make, have
 * made, use, have used, sell, license, distribute, sublicense or otherwise
 * transfer Derivative Works created by You that add functionality or
 * improvement to the Software.
 *
 * You has no obligation to give NVIDIA any suggestions, comments or other
 * feedback ("Feedback") relating to the Software.  However, NVIDIA may use
 * and include any Feedback that You voluntarily provide to improve the
 * Software or other related NVIDIA technologies.  Accordingly, if You
 * provide Feedback, You agree NVIDIA and its licensees may freely use,
 * reproduce, license, distribute, and otherwise commercialize the Feedback
 * in the Software or other related technologies without the payment of any
 * royalties or fees.
 *
 * You may transfer the Software only if the recipient agrees to be fully
 * bound by these terms and conditions of this Agreement.
 *
 * SECTION 4 - NO WARRANTIES.
 * THE SOFTWARE IS PROVIDED "AS IS" WITHOUT ANY EXPRESS OR IMPLIED WARRANTY
 * OF ANY KIND, INCLUDING WARRANTIES OF MERCHANTABILITY, NONINFRINGEMENT,
 * OR FITNESS FOR A PARTICULAR PURPOSE. NVIDIA does not warrant or assume
 * responsibility for the accuracy or completeness of any information,
 * text, graphics, links or other items contained within the Software.
 * NVIDIA does not represent that errors or other defects will be
 * identified or corrected.
 *
 * SECTION 5 - LIMITATION OF LIABILITY.
 * EXCEPT WITH RESPECT TO THE MISUSE OF THE OTHER PARTY'S INTELLECTUAL
 * PROPERTY OR DISCLOSURE OF THE OTHER PARTY'S CONFIDENTIAL INFORMATION IN
 * BREACH OF THIS AGREEMENT, IN NO EVENT SHALL NVIDIA, SUBSIDIARIES,
 * LICENSORS, OR ITS SUPPLIERS BE LIABLE FOR ANY DAMAGES WHATSOEVER
 * (INCLUDING, WITHOUT LIMITATION,  INDIRECT, LOST PROFITS, CONSEQUENTIAL,
 * BUSINESS INTERRUPTION OR LOST INFORMATION) ARISING OUT OF THE USE OF OR
 * INABILITY TO USE THE SOFTWARE, EVEN IF NVIDIA HAS BEEN ADVISED OF THE
 * POSSIBILITY OF SUCH DAMAGES. SOME JURISDICTIONS PROHIBIT EXCLUSION OR
 * LIMITATION OF LIABILITY FOR IMPLIED WARRANTIES OR CONSEQUENTIAL OR
 * INCIDENTAL DAMAGES, SO THE ABOVE LIMITATION MAY NOT APPLY TO YOU. YOU
 * MAY ALSO HAVE OTHER LEGAL RIGHTS THAT VARY FROM JURISDICTION TO
 * JURISDICTION.  NOTWITHSTANDING THE FOREGOING, NVIDIA'S AGGREGATE
 * LIABILITY ARISING OUT OF THIS AGREEMENT SHALL NOT EXCEED ONE HUNDRED
 * UNITED STATES DOLLARS (USD$100).
 *
 * SECTION 6 - TERM.
 * This Agreement and the licenses granted hereunder shall be effective as
 * of the date You download the applicable Software ("Effective Date") and
 * continue for a period of one (1) year ("Initial Term") respectively,
 * unless terminated earlier in accordance with the "Termination" provision
 * of this Agreement.  Unless either party notifies the other party of its
 * intent to terminate this Agreement at least three (3) months prior to
 * the end of the Initial Term or the applicable renewal period, this
 * Agreement will be automatically renewed for one (1) year renewal periods
 * thereafter, unless terminated in accordance with the "Termination"
 * provision of this Agreement.
 *
 * SECTION 7 - TERMINATION.
 * NVIDIA may terminate this Agreement at any time if You violate its
 * terms. Upon termination, You will immediately destroy the Software or
 * return all copies of the Software to NVIDIA, and certify to NVIDIA in
 * writing that such actions have been completed.  Upon termination or
 * expiration of this Agreement the license grants to Licensee shall
 * terminate, except that sublicenses rightfully granted by Licensee under
 * this Agreement in connection with Section 1(b) and (c) of this Agreement
 * provided by Licensee prior to the termination or expiration of this
 * Agreement shall survive in accordance with their respective form of
 * license terms and conditions.
 *
 * SECTION 8 - MISCELLANEOUS.
 *
 * SECTION 8.1 - SURVIVAL.
 * Those provisions in this Agreement, which by their nature need to
 * survive the termination or expiration of this Agreement, shall survive
 * termination or expiration of the Agreement, including but not limited to
 * Sections 2, 3, 4, 5, 7, and 8.
 *
 * SECTION 8.2 - APPLICABLE LAWS.
 * Claims arising under this Agreement shall be governed by the laws of
 * Delaware, excluding its principles of conflict of laws and the United
 * Nations Convention on Contracts for the Sale of Goods. The state and/or
 * federal courts residing in Santa Clara County, California shall have
 * exclusive jurisdiction over any dispute or claim arising out of this
 * Agreement. You may not export the Software in violation of applicable
 * export laws and regulations.
 *
 * SECTION 8.3 - AMENDMENT.
 * The Agreement shall not be modified except by a written agreement that
 * names this Agreement and any provision to be modified, is dated
 * subsequent to the Effective Date, and is signed by duly authorized
 * representatives of both parties.
 *
 * SECTION 8.4 - NO WAIVER.
 * No failure or delay on the part of either party in the exercise of any
 * right, power or remedy under this Agreement or under law, or to insist
 * upon or enforce performance by the other party of any of the provisions
 * of this Agreement or under law, shall operate as a waiver thereof, nor
 * shall any single or partial exercise of any right, power or remedy
 * preclude other or further exercise thereof, or the exercise of any other
 * right, power or remedy; rather the provision, right, or remedy shall be
 * and remain in full force and effect.
 *
 * SECTION 8.5 - NO ASSIGNMENT.
 * This Agreement and Licensee's rights and obligations herein, may not be
 * assigned, subcontracted, delegated, or otherwise transferred by Licensee
 * without NVIDIA's prior written consent, and any attempted assignment,
 * subcontract, delegation, or transfer in violation of the foregoing will
 * be null and void.  The terms of this Agreement shall be binding upon
 * Licensee's assignees.
 *
 * SECTION 8.6 - GOVERNMENT RESTRICTED RIGHTS.
 * The parties acknowledge that the Software is subject to U.S. export
 * control laws and regulations.   The parties agree to comply with all
 * applicable international and national laws that apply to the Software,
 * including the U.S. Export Administration Regulations, as well as
 * end-user, end-use and destination restrictions issued by U.S. and other
 * governments.
 *
 * The Software has been developed entirely at private expense and is
 * commercial computer software provided with RESTRICTED RIGHTS. Use,
 * duplication or disclosure of the Software by the U.S. Government or a
 * U.S. Government subcontractor is subject to the restrictions set forth
 * in the Agreement under which the Software was obtained pursuant to DFARS
 * 227.7202-3(a) or as set forth in subparagraphs (c)(1) and (2) of the
 * Commercial Computer Software - Restricted Rights clause at FAR
 * 52.227-19, as applicable. Contractor/manufacturer is NVIDIA, 2701 San
 * Tomas Expressway, Santa Clara, CA 95050. Use of the Software by the
 * Government constitutes acknowledgment of NVIDIA's proprietary rights
 * therein.
 *
 * SECTION 8.7 - INDEPENDENT CONTRACTORS.
 * Licensee's relationship to NVIDIA is that of an independent contractor,
 * and neither party is an agent or partner of the other.  Licensee will
 * not have, and will not represent to any third party that it has, any
 * authority to act on behalf of NVIDIA.
 *
 * SECTION 8.8 - SEVERABILITY.
 * If for any reason a court of competent jurisdiction finds any provision
 * of this Agreement, or portion thereof, to be unenforceable, that
 * provision of the Agreement will be enforced to the maximum extent
 * permissible so as to affect the intent of the parties, and the remainder
 * of this Agreement will continue in full force and effect. This Agreement
 * has been negotiated by the parties and their respective counsel and will
 * be interpreted fairly in accordance with its terms and without any
 * strict construction in favor of or against either party.
 *
 * SECTION 8.9 - ENTIRE AGREEMENT.
 * This Agreement and NDA constitute the entire agreement between the
 * parties with respect to the subject matter contemplated herein, and
 * merges all prior and contemporaneous communications.
 *
 ******************************************************************************/

***************************************************************************
* OpenCOLLADA                                                             *
***************************************************************************a

The OpenCOLLADA SDK including the Max and Maya converter is open source
software and released under the MIT license.

The MIT License

Copyright (C) 2009 NetAllied Systems GmbH

Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in
all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
THE SOFTWARE.

***************************************************************************
* zip                                                                     *
***************************************************************************

Copyright notice:

 (C) 1995-2004 Jean-loup Gailly and Mark Adler

  This software is provided 'as-is', without any express or implied
  warranty.  In no event will the authors be held liable for any damages
  arising from the use of this software.

  Permission is granted to anyone to use this software for any purpose,
  including commercial applications, and to alter it and redistribute it
  freely, subject to the following restrictions:

  1. The origin of this software must not be misrepresented; you must not
     claim that you wrote the original software. If you use this software
     in a product, an acknowledgment in the product documentation would be
     appreciated but is not required.
  2. Altered source versions must be plainly marked as such, and must not be
     misrepresented as being the original software.
  3. This notice may not be removed or altered from any source distribution.

  Jean-loup Gailly        Mark Adler
  jloup@gzip.org          madler@alumni.caltech.edu

If you use the zlib library in a product, we would appreciate *not*
receiving lengthy legal documents to sign. The sources are provided
for free but without warranty of any kind.  The library has been
entirely written by Jean-loup Gailly and Mark Adler; it does not
include third-party code.

If you redistribute modified sources, we would appreciate that you include
in the file ChangeLog history information documenting your changes. Please
read the FAQ for more information on the distribution of modified source
versions.

***************************************************************************
* libpng                                                                  *
***************************************************************************

This copy of the libpng notices is provided for your convenience.  In case of
any discrepancy between this copy and the notices in the file png.h that is
included in the libpng distribution, the latter shall prevail.

COPYRIGHT NOTICE, DISCLAIMER, and LICENSE:

If you modify libpng you may insert additional notices immediately following
this sentence.

libpng versions 1.2.6, August 15, 2004, through 1.2.22, October 13, 2007, are
Copyright (c) 2004, 2006-2007 Glenn Randers-Pehrson, and are
distributed according to the same disclaimer and license as libpng-1.2.5
with the following individual added to the list of Contributing Authors

   Cosmin Truta

libpng versions 1.0.7, July 1, 2000, through 1.2.5 - October 3, 2002, are
Copyright (c) 2000-2002 Glenn Randers-Pehrson, and are
distributed according to the same disclaimer and license as libpng-1.0.6
with the following individuals added to the list of Contributing Authors

   Simon-Pierre Cadieux
   Eric S. Raymond
   Gilles Vollant

and with the following additions to the disclaimer:

   There is no warranty against interference with your enjoyment of the
   library or against infringement.  There is no warranty that our
   efforts or the library will fulfill any of your particular purposes
   or needs.  This library is provided with all faults, and the entire
   risk of satisfactory quality, performance, accuracy, and effort is with
   the user.

libpng versions 0.97, January 1998, through 1.0.6, March 20, 2000, are
Copyright (c) 1998, 1999 Glenn Randers-Pehrson, and are
distributed according to the same disclaimer and license as libpng-0.96,
with the following individuals added to the list of Contributing Authors:

   Tom Lane
   Glenn Randers-Pehrson
   Willem van Schaik

libpng versions 0.89, June 1996, through 0.96, May 1997, are
Copyright (c) 1996, 1997 Andreas Dilger
Distributed according to the same disclaimer and license as libpng-0.88,
with the following individuals added to the list of Contributing Authors:

   John Bowler
   Kevin Bracey
   Sam Bushell
   Magnus Holmgren
   Greg Roelofs
   Tom Tanner

libpng versions 0.5, May 1995, through 0.88, January 1996, are
Copyright (c) 1995, 1996 Guy Eric Schalnat, Group 42, Inc.

For the purposes of this copyright and license, "Contributing Authors"
is defined as the following set of individuals:

   Andreas Dilger
   Dave Martindale
   Guy Eric Schalnat
   Paul Schmidt
   Tim Wegner

The PNG Reference Library is supplied "AS IS".  The Contributing Authors
and Group 42, Inc. disclaim all warranties, expressed or implied,
including, without limitation, the warranties of merchantability and of
fitness for any purpose.  The Contributing Authors and Group 42, Inc.
assume no liability for direct, indirect, incidental, special, exemplary,
or consequential damages, which may result from the use of the PNG
Reference Library, even if advised of the possibility of such damage.

Permission is hereby granted to use, copy, modify, and distribute this
source code, or portions hereof, for any purpose, without fee, subject
to the following restrictions:

1. The origin of this source code must not be misrepresented.

2. Altered versions must be plainly marked as such and must not
   be misrepresented as being the original source.

3. This Copyright notice may not be removed or altered from any
   source or altered source distribution.

The Contributing Authors and Group 42, Inc. specifically permit, without
fee, and encourage the use of this source code as a component to
supporting the PNG file format in commercial products.  If you use this
source code in a product, acknowledgment is not required but would be
appreciated.

A "png_get_copyright" function is available, for convenient use in "about"
boxes and the like:

   printf("%s",png_get_copyright(NULL));

Also, the PNG logo (in PNG format, of course) is supplied in the
files "pngbar.png" and "pngbar.jpg (88x31) and "pngnow.png" (98x31).

Libpng is OSI Certified Open Source Software.  OSI Certified Open Source is a
certification mark of the Open Source Initiative.

Glenn Randers-Pehrson
glennrp at users.sourceforge.net
October 13, 2007

***************************************************************************
* Recast/Detour                                                           *
***************************************************************************

Copyright (c) 2009 Mikko Mononen memon@inside.org

This software is provided 'as-is', without any express or implied
warranty.  In no event will the authors be held liable for any damages
arising from the use of this software.

Permission is granted to anyone to use this software for any purpose,
including commercial applications, and to alter it and redistribute it
freely, subject to the following restrictions:

1. The origin of this software must not be misrepresented; you must not
claim that you wrote the original software. If you use this software
in a product, an acknowledgment in the product documentation would be
appreciated but is not required.
2. Altered source versions must be plainly marked as such, and must not be
misrepresented as being the original software.
3. This notice may not be removed or altered from any source distribution.

***************************************************************************
* Jinja2                                                                  *
***************************************************************************

Copyright (c) 2009 by the Jinja Team, see AUTHORS for more details.

Some rights reserved.

Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions are
met:

    * Redistributions of source code must retain the above copyright
      notice, this list of conditions and the following disclaimer.

    * Redistributions in binary form must reproduce the above
      copyright notice, this list of conditions and the following
      disclaimer in the documentation and/or other materials provided
      with the distribution.

    * The names of the contributors may not be used to endorse or
      promote products derived from this software without specific
      prior written permission.

THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
"AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

***************************************************************************
* jQuery                                                                  *
***************************************************************************

Copyright (c) 2012 John Resig, http://jquery.com/

Permission is hereby granted, free of charge, to any person obtaining
a copy of this software and associated documentation files (the
"Software"), to deal in the Software without restriction, including
without limitation the rights to use, copy, modify, merge, publish,
distribute, sublicense, and/or sell copies of the Software, and to
permit persons to whom the Software is furnished to do so, subject to
the following conditions:

The above copyright notice and this permission notice shall be
included in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE
LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION
OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION
WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

***************************************************************************
* jQuery-mousewheel plugin                                                *
***************************************************************************

Copyright 2011, Brandon Aaron (http://brandonaaron.net/)

Permission is hereby granted, free of charge, to any person obtaining
a copy of this software and associated documentation files (the
"Software"), to deal in the Software without restriction, including
without limitation the rights to use, copy, modify, merge, publish,
distribute, sublicense, and/or sell copies of the Software, and to
permit persons to whom the Software is furnished to do so, subject to
the following conditions:

The above copyright notice and this permission notice shall be
included in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE
LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION
OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION
WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

***************************************************************************
* FontAwesome                                                             *
***************************************************************************

THE WORK (AS DEFINED BELOW) IS PROVIDED UNDER THE TERMS OF THIS CREATIVE
COMMONS PUBLIC LICENSE ("CCPL" OR "LICENSE"). THE WORK IS PROTECTED BY
COPYRIGHT AND/OR OTHER APPLICABLE LAW. ANY USE OF THE WORK OTHER THAN AS
AUTHORIZED UNDER THIS LICENSE OR COPYRIGHT LAW IS PROHIBITED.

BY EXERCISING ANY RIGHTS TO THE WORK PROVIDED HERE, YOU ACCEPT AND AGREE TO BE
BOUND BY THE TERMS OF THIS LICENSE. TO THE EXTENT THIS LICENSE MAY BE
CONSIDERED TO BE A CONTRACT, THE LICENSOR GRANTS YOU THE RIGHTS CONTAINED HERE
IN CONSIDERATION OF YOUR ACCEPTANCE OF SUCH TERMS AND CONDITIONS.

1. Definitions

"Adaptation" means a work based upon the Work, or upon the Work and other
pre-existing works, such as a translation, adaptation, derivative work,
arrangement of music or other alterations of a literary or artistic work, or
phonogram or performance and includes cinematographic adaptations or any other
form in which the Work may be recast, transformed, or adapted including in any
form recognizably derived from the original, except that a work that
constitutes a Collection will not be considered an Adaptation for the purpose
of this License. For the avoidance of doubt, where the Work is a musical work,
performance or phonogram, the synchronization of the Work in timed-relation
with a moving image ("synching") will be considered an Adaptation for the
purpose of this License.
"Collection" means a collection of literary or artistic works, such as
encyclopedias and anthologies, or performances, phonograms or broadcasts, or
other works or subject matter other than works listed in Section 1(f) below,
which, by reason of the selection and arrangement of their contents,
constitute intellectual creations, in which the Work is included in its
entirety in unmodified form along with one or more other contributions, each
constituting separate and independent works in themselves, which together are
assembled into a collective whole. A work that constitutes a Collection will
not be considered an Adaptation (as defined above) for the purposes of this
License.
"Distribute" means to make available to the public the original and copies of
the Work or Adaptation, as appropriate, through sale or other transfer of
ownership.
"Licensor" means the individual, individuals, entity or entities that offer(s)
the Work under the terms of this License.
"Original Author" means, in the case of a literary or artistic work, the
individual, individuals, entity or entities who created the Work or if no
individual or entity can be identified, the publisher; and in addition (i) in
the case of a performance the actors, singers, musicians, dancers, and other
persons who act, sing, deliver, declaim, play in, interpret or otherwise
perform literary or artistic works or expressions of folklore; (ii) in the
case of a phonogram the producer being the person or legal entity who first
fixes the sounds of a performance or other sounds; and, (iii) in the case of
broadcasts, the organization that transmits the broadcast.
"Work" means the literary and/or artistic work offered under the terms of this
License including without limitation any production in the literary,
scientific and artistic domain, whatever may be the mode or form of its
expression including digital form, such as a book, pamphlet and other writing;
a lecture, address, sermon or other work of the same nature; a dramatic or
dramatico-musical work; a choreographic work or entertainment in dumb show; a
musical composition with or without words; a cinematographic work to which are
assimilated works expressed by a process analogous to cinematography; a work
of drawing, painting, architecture, sculpture, engraving or lithography; a
photographic work to which are assimilated works expressed by a process
analogous to photography; a work of applied art; an illustration, map, plan,
sketch or three-dimensional work relative to geography, topography,
architecture or science; a performance; a broadcast; a phonogram; a
compilation of data to the extent it is protected as a copyrightable work; or
a work performed by a variety or circus performer to the extent it is not
otherwise considered a literary or artistic work.
"You" means an individual or entity exercising rights under this License who
has not previously violated the terms of this License with respect to the
Work, or who has received express permission from the Licensor to exercise
rights under this License despite a previous violation.
"Publicly Perform" means to perform public recitations of the Work and to
communicate to the public those public recitations, by any means or process,
including by wire or wireless means or public digital performances; to make
available to the public Works in such a way that members of the public may
access these Works from a place and at a place individually chosen by them; to
perform the Work to the public by any means or process and the communication
to the public of the performances of the Work, including by public digital
performance; to broadcast and rebroadcast the Work by any means including
signs, sounds or images.
"Reproduce" means to make copies of the Work by any means including without
limitation by sound or visual recordings and the right of fixation and
reproducing fixations of the Work, including storage of a protected
performance or phonogram in digital form or other electronic medium.

2. Fair Dealing Rights. Nothing in this License is intended to reduce, limit,
or restrict any uses free from copyright or rights arising from limitations or
exceptions that are provided for in connection with the copyright protection
under copyright law or other applicable laws.

3. License Grant. Subject to the terms and conditions of this License,
Licensor hereby grants You a worldwide, royalty-free, non-exclusive, perpetual
(for the duration of the applicable copyright) license to exercise the rights
in the Work as stated below:

to Reproduce the Work, to incorporate the Work into one or more Collections,
and to Reproduce the Work as incorporated in the Collections;
to create and Reproduce Adaptations provided that any such Adaptation,
including any translation in any medium, takes reasonable steps to clearly
label, demarcate or otherwise identify that changes were made to the original
Work. For example, a translation could be marked "The original work was
translated from English to Spanish," or a modification could indicate "The
original work has been modified.";
to Distribute and Publicly Perform the Work including as incorporated in
Collections; and,
to Distribute and Publicly Perform Adaptations.
For the avoidance of doubt:

Non-waivable Compulsory License Schemes. In those jurisdictions in which the
right to collect royalties through any statutory or compulsory licensing
scheme cannot be waived, the Licensor reserves the exclusive right to collect
such royalties for any exercise by You of the rights granted under this
License;
Waivable Compulsory License Schemes. In those jurisdictions in which the right
to collect royalties through any statutory or compulsory licensing scheme can
be waived, the Licensor waives the exclusive right to collect such royalties
for any exercise by You of the rights granted under this License; and,

Voluntary License Schemes. The Licensor waives the right to collect royalties,
whether individually or, in the event that the Licensor is a member of a
collecting society that administers voluntary licensing schemes, via that
society, from any exercise by You of the rights granted under this License.

The above rights may be exercised in all media and formats whether now known
or hereafter devised. The above rights include the right to make such
modifications as are technically necessary to exercise the rights in other
media and formats. Subject to Section 8(f), all rights not expressly granted
by Licensor are hereby reserved.

4. Restrictions. The license granted in Section 3 above is expressly made
subject to and limited by the following restrictions:

You may Distribute or Publicly Perform the Work only under the terms of this
License. You must include a copy of, or the Uniform Resource Identifier (URI)
for, this License with every copy of the Work You Distribute or Publicly
Perform. You may not offer or impose any terms on the Work that restrict the
terms of this License or the ability of the recipient of the Work to exercise
the rights granted to that recipient under the terms of the License. You may
not sublicense the Work. You must keep intact all notices that refer to this
License and to the disclaimer of warranties with every copy of the Work You
Distribute or Publicly Perform. When You Distribute or Publicly Perform the
Work, You may not impose any effective technological measures on the Work that
restrict the ability of a recipient of the Work from You to exercise the
rights granted to that recipient under the terms of the License. This Section
4(a) applies to the Work as incorporated in a Collection, but this does not
require the Collection apart from the Work itself to be made subject to the
terms of this License. If You create a Collection, upon notice from any
Licensor You must, to the extent practicable, remove from the Collection any
credit as required by Section 4(b), as requested. If You create an Adaptation,
upon notice from any Licensor You must, to the extent practicable, remove from
the Adaptation any credit as required by Section 4(b), as requested.

If You Distribute, or Publicly Perform the Work or any Adaptations or
Collections, You must, unless a request has been made pursuant to Section
4(a), keep intact all copyright notices for the Work and provide, reasonable
to the medium or means You are utilizing: (i) the name of the Original Author
(or pseudonym, if applicable) if supplied, and/or if the Original Author
and/or Licensor designate another party or parties (e.g., a sponsor institute,
publishing entity, journal) for attribution ("Attribution Parties") in
Licensor's copyright notice, terms of service or by other reasonable means,
the name of such party or parties; (ii) the title of the Work if supplied;
(iii) to the extent reasonably practicable, the URI, if any, that Licensor
specifies to be associated with the Work, unless such URI does not refer to
the copyright notice or licensing information for the Work; and (iv) ,
consistent with Section 3(b), in the case of an Adaptation, a credit
identifying the use of the Work in the Adaptation (e.g., "French translation
of the Work by Original Author," or "Screenplay based on original Work by
Original Author"). The credit required by this Section 4 (b) may be
implemented in any reasonable manner; provided, however, that in the case of a
Adaptation or Collection, at a minimum such credit will appear, if a credit
for all contributing authors of the Adaptation or Collection appears, then as
part of these credits and in a manner at least as prominent as the credits for
the other contributing authors. For the avoidance of doubt, You may only use
the credit required by this Section for the purpose of attribution in the
manner set out above and, by exercising Your rights under this License, You
may not implicitly or explicitly assert or imply any connection with,
sponsorship or endorsement by the Original Author, Licensor and/or Attribution
Parties, as appropriate, of You or Your use of the Work, without the separate,
express prior written permission of the Original Author, Licensor and/or
Attribution Parties.
Except as otherwise agreed in writing by the Licensor or as may be otherwise
permitted by applicable law, if You Reproduce, Distribute or Publicly Perform
the Work either by itself or as part of any Adaptations or Collections, You
must not distort, mutilate, modify or take other derogatory action in relation
to the Work which would be prejudicial to the Original Author's honor or
reputation. Licensor agrees that in those jurisdictions (e.g. Japan), in which
any exercise of the right granted in Section 3(b) of this License (the right
to make Adaptations) would be deemed to be a distortion, mutilation,
modification or other derogatory action prejudicial to the Original Author's
honor and reputation, the Licensor will waive or not assert, as appropriate,
this Section, to the fullest extent permitted by the applicable national law,
to enable You to reasonably exercise Your right under Section 3(b) of this
License (right to make Adaptations) but not otherwise.
5. Representations, Warranties and Disclaimer

UNLESS OTHERWISE MUTUALLY AGREED TO BY THE PARTIES IN WRITING, LICENSOR OFFERS
THE WORK AS-IS AND MAKES NO REPRESENTATIONS OR WARRANTIES OF ANY KIND
CONCERNING THE WORK, EXPRESS, IMPLIED, STATUTORY OR OTHERWISE, INCLUDING,
WITHOUT LIMITATION, WARRANTIES OF TITLE, MERCHANTIBILITY, FITNESS FOR A
PARTICULAR PURPOSE, NONINFRINGEMENT, OR THE ABSENCE OF LATENT OR OTHER
DEFECTS, ACCURACY, OR THE PRESENCE OF ABSENCE OF ERRORS, WHETHER OR NOT
DISCOVERABLE. SOME JURISDICTIONS DO NOT ALLOW THE EXCLUSION OF IMPLIED
WARRANTIES, SO SUCH EXCLUSION MAY NOT APPLY TO YOU.

6. Limitation on Liability. EXCEPT TO THE EXTENT REQUIRED BY APPLICABLE LAW,
IN NO EVENT WILL LICENSOR BE LIABLE TO YOU ON ANY LEGAL THEORY FOR ANY
SPECIAL, INCIDENTAL, CONSEQUENTIAL, PUNITIVE OR EXEMPLARY DAMAGES ARISING OUT
OF THIS LICENSE OR THE USE OF THE WORK, EVEN IF LICENSOR HAS BEEN ADVISED OF
THE POSSIBILITY OF SUCH DAMAGES.

7. Termination

This License and the rights granted hereunder will terminate automatically
upon any breach by You of the terms of this License. Individuals or entities
who have received Adaptations or Collections from You under this License,
however, will not have their licenses terminated provided such individuals or
entities remain in full compliance with those licenses. Sections 1, 2, 5, 6,
7, and 8 will survive any termination of this License.
Subject to the above terms and conditions, the license granted here is
perpetual (for the duration of the applicable copyright in the Work).
Notwithstanding the above, Licensor reserves the right to release the Work
under different license terms or to stop distributing the Work at any time;
provided, however that any such election will not serve to withdraw this
License (or any other license that has been, or is required to be, granted
under the terms of this License), and this License will continue in full force
and effect unless terminated as stated above.
8. Miscellaneous

Each time You Distribute or Publicly Perform the Work or a Collection, the
Licensor offers to the recipient a license to the Work on the same terms and
conditions as the license granted to You under this License.
Each time You Distribute or Publicly Perform an Adaptation, Licensor offers to
the recipient a license to the original Work on the same terms and conditions
as the license granted to You under this License.
If any provision of this License is invalid or unenforceable under applicable
law, it shall not affect the validity or enforceability of the remainder of
the terms of this License, and without further action by the parties to this
agreement, such provision shall be reformed to the minimum extent necessary to
make such provision valid and enforceable.
No term or provision of this License shall be deemed waived and no breach
consented to unless such waiver or consent shall be in writing and signed by
the party to be charged with such waiver or consent.
This License constitutes the entire agreement between the parties with respect
to the Work licensed here. There are no understandings, agreements or
representations with respect to the Work not specified here. Licensor shall
not be bound by any additional provisions that may appear in any communication
from You. This License may not be modified without the mutual written
agreement of the Licensor and You.
The rights granted under, and the subject matter referenced, in this License
were drafted utilizing the terminology of the Berne Convention for the
Protection of Literary and Artistic Works (as amended on September 28, 1979),
the Rome Convention of 1961, the WIPO Copyright Treaty of 1996, the WIPO
Performances and Phonograms Treaty of 1996 and the Universal Copyright
Convention (as revised on July 24, 1971). These rights and subject matter take
effect in the relevant jurisdiction in which the License terms are sought to
be enforced according to the corresponding provisions of the implementation of
those treaty provisions in the applicable national law. If the standard suite
of rights granted under applicable copyright law includes additional rights
not granted under this License, such additional rights are deemed to be
included in the License; this License is not intended to restrict the license
of any rights under applicable law.

***************************************************************************
* SDL (Simple DirectMedia Layer library)                                  *
***************************************************************************

                  GNU LESSER GENERAL PUBLIC LICENSE
                       Version 2.1, February 1999

 Copyright (C) 1991, 1999 Free Software Foundation, Inc.
 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301  USA
 Everyone is permitted to copy and distribute verbatim copies
 of this license document, but changing it is not allowed.

[This is the first released version of the Lesser GPL.  It also counts
 as the successor of the GNU Library Public License, version 2, hence
 the version number 2.1.]

                            Preamble

  The licenses for most software are designed to take away your
freedom to share and change it.  By contrast, the GNU General Public
Licenses are intended to guarantee your freedom to share and change
free software--to make sure the software is free for all its users.

  This license, the Lesser General Public License, applies to some
specially designated software packages--typically libraries--of the
Free Software Foundation and other authors who decide to use it.  You
can use it too, but we suggest you first think carefully about whether
this license or the ordinary General Public License is the better
strategy to use in any particular case, based on the explanations below.

  When we speak of free software, we are referring to freedom of use,
not price.  Our General Public Licenses are designed to make sure that
you have the freedom to distribute copies of free software (and charge
for this service if you wish); that you receive source code or can get
it if you want it; that you can change the software and use pieces of
it in new free programs; and that you are informed that you can do
these things.

  To protect your rights, we need to make restrictions that forbid
distributors to deny you these rights or to ask you to surrender these
rights.  These restrictions translate to certain responsibilities for
you if you distribute copies of the library or if you modify it.

  For example, if you distribute copies of the library, whether gratis
or for a fee, you must give the recipients all the rights that we gave
you.  You must make sure that they, too, receive or can get the source
code.  If you link other code with the library, you must provide
complete object files to the recipients, so that they can relink them
with the library after making changes to the library and recompiling
it.  And you must show them these terms so they know their rights.

  We protect your rights with a two-step method: (1) we copyright the
library, and (2) we offer you this license, which gives you legal
permission to copy, distribute and/or modify the library.

  To protect each distributor, we want to make it very clear that
there is no warranty for the free library.  Also, if the library is
modified by someone else and passed on, the recipients should know
that what they have is not the original version, so that the original
author's reputation will not be affected by problems that might be
introduced by others.

  Finally, software patents pose a constant threat to the existence of
any free program.  We wish to make sure that a company cannot
effectively restrict the users of a free program by obtaining a
restrictive license from a patent holder.  Therefore, we insist that
any patent license obtained for a version of the library must be
consistent with the full freedom of use specified in this license.

  Most GNU software, including some libraries, is covered by the
ordinary GNU General Public License.  This license, the GNU Lesser
General Public License, applies to certain designated libraries, and
is quite different from the ordinary General Public License.  We use
this license for certain libraries in order to permit linking those
libraries into non-free programs.

  When a program is linked with a library, whether statically or using
a shared library, the combination of the two is legally speaking a
combined work, a derivative of the original library.  The ordinary
General Public License therefore permits such linking only if the
entire combination fits its criteria of freedom.  The Lesser General
Public License permits more lax criteria for linking other code with
the library.

  We call this license the "Lesser" General Public License because it
does Less to protect the user's freedom than the ordinary General
Public License.  It also provides other free software developers Less
of an advantage over competing non-free programs.  These disadvantages
are the reason we use the ordinary General Public License for many
libraries.  However, the Lesser license provides advantages in certain
special circumstances.

  For example, on rare occasions, there may be a special need to
encourage the widest possible use of a certain library, so that it becomes
a de-facto standard.  To achieve this, non-free programs must be
allowed to use the library.  A more frequent case is that a free
library does the same job as widely used non-free libraries.  In this
case, there is little to gain by limiting the free library to free
software only, so we use the Lesser General Public License.

  In other cases, permission to use a particular library in non-free
programs enables a greater number of people to use a large body of
free software.  For example, permission to use the GNU C Library in
non-free programs enables many more people to use the whole GNU
operating system, as well as its variant, the GNU/Linux operating
system.

  Although the Lesser General Public License is Less protective of the
users' freedom, it does ensure that the user of a program that is
linked with the Library has the freedom and the wherewithal to run
that program using a modified version of the Library.

  The precise terms and conditions for copying, distribution and
modification follow.  Pay close attention to the difference between a
"work based on the library" and a "work that uses the library".  The
former contains code derived from the library, whereas the latter must
be combined with the library in order to run.

                  GNU LESSER GENERAL PUBLIC LICENSE
   TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION

  0. This License Agreement applies to any software library or other
program which contains a notice placed by the copyright holder or
other authorized party saying it may be distributed under the terms of
this Lesser General Public License (also called "this License").
Each licensee is addressed as "you".

  A "library" means a collection of software functions and/or data
prepared so as to be conveniently linked with application programs
(which use some of those functions and data) to form executables.

  The "Library", below, refers to any such software library or work
which has been distributed under these terms.  A "work based on the
Library" means either the Library or any derivative work under
copyright law: that is to say, a work containing the Library or a
portion of it, either verbatim or with modifications and/or translated
straightforwardly into another language.  (Hereinafter, translation is
included without limitation in the term "modification".)

  "Source code" for a work means the preferred form of the work for
making modifications to it.  For a library, complete source code means
all the source code for all modules it contains, plus any associated
interface definition files, plus the scripts used to control compilation
and installation of the library.

  Activities other than copying, distribution and modification are not
covered by this License; they are outside its scope.  The act of
running a program using the Library is not restricted, and output from
such a program is covered only if its contents constitute a work based
on the Library (independent of the use of the Library in a tool for
writing it).  Whether that is true depends on what the Library does
and what the program that uses the Library does.

  1. You may copy and distribute verbatim copies of the Library's
complete source code as you receive it, in any medium, provided that
you conspicuously and appropriately publish on each copy an
appropriate copyright notice and disclaimer of warranty; keep intact
all the notices that refer to this License and to the absence of any
warranty; and distribute a copy of this License along with the
Library.

  You may charge a fee for the physical act of transferring a copy,
and you may at your option offer warranty protection in exchange for a
fee.

  2. You may modify your copy or copies of the Library or any portion
of it, thus forming a work based on the Library, and copy and
distribute such modifications or work under the terms of Section 1
above, provided that you also meet all of these conditions:

    a) The modified work must itself be a software library.

    b) You must cause the files modified to carry prominent notices
    stating that you changed the files and the date of any change.

    c) You must cause the whole of the work to be licensed at no
    charge to all third parties under the terms of this License.

    d) If a facility in the modified Library refers to a function or a
    table of data to be supplied by an application program that uses
    the facility, other than as an argument passed when the facility
    is invoked, then you must make a good faith effort to ensure that,
    in the event an application does not supply such function or
    table, the facility still operates, and performs whatever part of
    its purpose remains meaningful.

    (For example, a function in a library to compute square roots has
    a purpose that is entirely well-defined independent of the
    application.  Therefore, Subsection 2d requires that any
    application-supplied function or table used by this function must
    be optional: if the application does not supply it, the square
    root function must still compute square roots.)

These requirements apply to the modified work as a whole.  If
identifiable sections of that work are not derived from the Library,
and can be reasonably considered independent and separate works in
themselves, then this License, and its terms, do not apply to those
sections when you distribute them as separate works.  But when you
distribute the same sections as part of a whole which is a work based
on the Library, the distribution of the whole must be on the terms of
this License, whose permissions for other licensees extend to the
entire whole, and thus to each and every part regardless of who wrote
it.

Thus, it is not the intent of this section to claim rights or contest
your rights to work written entirely by you; rather, the intent is to
exercise the right to control the distribution of derivative or
collective works based on the Library.

In addition, mere aggregation of another work not based on the Library
with the Library (or with a work based on the Library) on a volume of
a storage or distribution medium does not bring the other work under
the scope of this License.

  3. You may opt to apply the terms of the ordinary GNU General Public
License instead of this License to a given copy of the Library.  To do
this, you must alter all the notices that refer to this License, so
that they refer to the ordinary GNU General Public License, version 2,
instead of to this License.  (If a newer version than version 2 of the
ordinary GNU General Public License has appeared, then you can specify
that version instead if you wish.)  Do not make any other change in
these notices.

  Once this change is made in a given copy, it is irreversible for
that copy, so the ordinary GNU General Public License applies to all
subsequent copies and derivative works made from that copy.

  This option is useful when you wish to copy part of the code of
the Library into a program that is not a library.

  4. You may copy and distribute the Library (or a portion or
derivative of it, under Section 2) in object code or executable form
under the terms of Sections 1 and 2 above provided that you accompany
it with the complete corresponding machine-readable source code, which
must be distributed under the terms of Sections 1 and 2 above on a
medium customarily used for software interchange.

  If distribution of object code is made by offering access to copy
from a designated place, then offering equivalent access to copy the
source code from the same place satisfies the requirement to
distribute the source code, even though third parties are not
compelled to copy the source along with the object code.

  5. A program that contains no derivative of any portion of the
Library, but is designed to work with the Library by being compiled or
linked with it, is called a "work that uses the Library".  Such a
work, in isolation, is not a derivative work of the Library, and
therefore falls outside the scope of this License.

  However, linking a "work that uses the Library" with the Library
creates an executable that is a derivative of the Library (because it
contains portions of the Library), rather than a "work that uses the
library".  The executable is therefore covered by this License.
Section 6 states terms for distribution of such executables.

  When a "work that uses the Library" uses material from a header file
that is part of the Library, the object code for the work may be a
derivative work of the Library even though the source code is not.
Whether this is true is especially significant if the work can be
linked without the Library, or if the work is itself a library.  The
threshold for this to be true is not precisely defined by law.

  If such an object file uses only numerical parameters, data
structure layouts and accessors, and small macros and small inline
functions (ten lines or less in length), then the use of the object
file is unrestricted, regardless of whether it is legally a derivative
work.  (Executables containing this object code plus portions of the
Library will still fall under Section 6.)

  Otherwise, if the work is a derivative of the Library, you may
distribute the object code for the work under the terms of Section 6.
Any executables containing that work also fall under Section 6,
whether or not they are linked directly with the Library itself.

  6. As an exception to the Sections above, you may also combine or
link a "work that uses the Library" with the Library to produce a
work containing portions of the Library, and distribute that work
under terms of your choice, provided that the terms permit
modification of the work for the customer's own use and reverse
engineering for debugging such modifications.

  You must give prominent notice with each copy of the work that the
Library is used in it and that the Library and its use are covered by
this License.  You must supply a copy of this License.  If the work
during execution displays copyright notices, you must include the
copyright notice for the Library among them, as well as a reference
directing the user to the copy of this License.  Also, you must do one
of these things:

    a) Accompany the work with the complete corresponding
    machine-readable source code for the Library including whatever
    changes were used in the work (which must be distributed under
    Sections 1 and 2 above); and, if the work is an executable linked
    with the Library, with the complete machine-readable "work that
    uses the Library", as object code and/or source code, so that the
    user can modify the Library and then relink to produce a modified
    executable containing the modified Library.  (It is understood
    that the user who changes the contents of definitions files in the
    Library will not necessarily be able to recompile the application
    to use the modified definitions.)

    b) Use a suitable shared library mechanism for linking with the
    Library.  A suitable mechanism is one that (1) uses at run time a
    copy of the library already present on the user's computer system,
    rather than copying library functions into the executable, and (2)
    will operate properly with a modified version of the library, if
    the user installs one, as long as the modified version is
    interface-compatible with the version that the work was made with.

    c) Accompany the work with a written offer, valid for at
    least three years, to give the same user the materials
    specified in Subsection 6a, above, for a charge no more
    than the cost of performing this distribution.

    d) If distribution of the work is made by offering access to copy
    from a designated place, offer equivalent access to copy the above
    specified materials from the same place.

    e) Verify that the user has already received a copy of these
    materials or that you have already sent this user a copy.

  For an executable, the required form of the "work that uses the
Library" must include any data and utility programs needed for
reproducing the executable from it.  However, as a special exception,
the materials to be distributed need not include anything that is
normally distributed (in either source or binary form) with the major
components (compiler, kernel, and so on) of the operating system on
which the executable runs, unless that component itself accompanies
the executable.

  It may happen that this requirement contradicts the license
restrictions of other proprietary libraries that do not normally
accompany the operating system.  Such a contradiction means you cannot
use both them and the Library together in an executable that you
distribute.

  7. You may place library facilities that are a work based on the
Library side-by-side in a single library together with other library
facilities not covered by this License, and distribute such a combined
library, provided that the separate distribution of the work based on
the Library and of the other library facilities is otherwise
permitted, and provided that you do these two things:

    a) Accompany the combined library with a copy of the same work
    based on the Library, uncombined with any other library
    facilities.  This must be distributed under the terms of the
    Sections above.

    b) Give prominent notice with the combined library of the fact
    that part of it is a work based on the Library, and explaining
    where to find the accompanying uncombined form of the same work.

  8. You may not copy, modify, sublicense, link with, or distribute
the Library except as expressly provided under this License.  Any
attempt otherwise to copy, modify, sublicense, link with, or
distribute the Library is void, and will automatically terminate your
rights under this License.  However, parties who have received copies,
or rights, from you under this License will not have their licenses
terminated so long as such parties remain in full compliance.

  9. You are not required to accept this License, since you have not
signed it.  However, nothing else grants you permission to modify or
distribute the Library or its derivative works.  These actions are
prohibited by law if you do not accept this License.  Therefore, by
modifying or distributing the Library (or any work based on the
Library), you indicate your acceptance of this License to do so, and
all its terms and conditions for copying, distributing or modifying
the Library or works based on it.

  10. Each time you redistribute the Library (or any work based on the
Library), the recipient automatically receives a license from the
original licensor to copy, distribute, link with or modify the Library
subject to these terms and conditions.  You may not impose any further
restrictions on the recipients' exercise of the rights granted herein.
You are not responsible for enforcing compliance by third parties with
this License.

  11. If, as a consequence of a court judgment or allegation of patent
infringement or for any other reason (not limited to patent issues),
conditions are imposed on you (whether by court order, agreement or
otherwise) that contradict the conditions of this License, they do not
excuse you from the conditions of this License.  If you cannot
distribute so as to satisfy simultaneously your obligations under this
License and any other pertinent obligations, then as a consequence you
may not distribute the Library at all.  For example, if a patent
license would not permit royalty-free redistribution of the Library by
all those who receive copies directly or indirectly through you, then
the only way you could satisfy both it and this License would be to
refrain entirely from distribution of the Library.

If any portion of this section is held invalid or unenforceable under any
particular circumstance, the balance of the section is intended to apply,
and the section as a whole is intended to apply in other circumstances.

It is not the purpose of this section to induce you to infringe any
patents or other property right claims or to contest validity of any
such claims; this section has the sole purpose of protecting the
integrity of the free software distribution system which is
implemented by public license practices.  Many people have made
generous contributions to the wide range of software distributed
through that system in reliance on consistent application of that
system; it is up to the author/donor to decide if he or she is willing
to distribute software through any other system and a licensee cannot
impose that choice.

This section is intended to make thoroughly clear what is believed to
be a consequence of the rest of this License.

  12. If the distribution and/or use of the Library is restricted in
certain countries either by patents or by copyrighted interfaces, the
original copyright holder who places the Library under this License may add
an explicit geographical distribution limitation excluding those countries,
so that distribution is permitted only in or among countries not thus
excluded.  In such case, this License incorporates the limitation as if
written in the body of this License.

  13. The Free Software Foundation may publish revised and/or new
versions of the Lesser General Public License from time to time.
Such new versions will be similar in spirit to the present version,
but may differ in detail to address new problems or concerns.

Each version is given a distinguishing version number.  If the Library
specifies a version number of this License which applies to it and
"any later version", you have the option of following the terms and
conditions either of that version or of any later version published by
the Free Software Foundation.  If the Library does not specify a
license version number, you may choose any version ever published by
the Free Software Foundation.

  14. If you wish to incorporate parts of the Library into other free
programs whose distribution conditions are incompatible with these,
write to the author to ask for permission.  For software which is
copyrighted by the Free Software Foundation, write to the Free
Software Foundation; we sometimes make exceptions for this.  Our
decision will be guided by the two goals of preserving the free status
of all derivatives of our free software and of promoting the sharing
and reuse of software generally.

                            NO WARRANTY

  15. BECAUSE THE LIBRARY IS LICENSED FREE OF CHARGE, THERE IS NO
WARRANTY FOR THE LIBRARY, TO THE EXTENT PERMITTED BY APPLICABLE LAW.
EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR
OTHER PARTIES PROVIDE THE LIBRARY "AS IS" WITHOUT WARRANTY OF ANY
KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE
IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
PURPOSE.  THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE
LIBRARY IS WITH YOU.  SHOULD THE LIBRARY PROVE DEFECTIVE, YOU ASSUME
THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION.

  16. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN
WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY
AND/OR REDISTRIBUTE THE LIBRARY AS PERMITTED ABOVE, BE LIABLE TO YOU
FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR
CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE
LIBRARY (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING
RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A
FAILURE OF THE LIBRARY TO OPERATE WITH ANY OTHER SOFTWARE), EVEN IF
SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH
DAMAGES.

                     END OF TERMS AND CONDITIONS

           How to Apply These Terms to Your New Libraries

  If you develop a new library, and you want it to be of the greatest
possible use to the public, we recommend making it free software that
everyone can redistribute and change.  You can do so by permitting
redistribution under these terms (or, alternatively, under the terms of the
ordinary General Public License).

  To apply these terms, attach the following notices to the library.  It is
safest to attach them to the start of each source file to most effectively
convey the exclusion of warranty; and each file should have at least the
"copyright" line and a pointer to where the full notice is found.

    <one line to give the library's name and a brief idea of what it does.>
    Copyright (C) <year>  <name of author>

    This library is free software; you can redistribute it and/or
    modify it under the terms of the GNU Lesser General Public
    License as published by the Free Software Foundation; either
    version 2.1 of the License, or (at your option) any later version.

    This library is distributed in the hope that it will be useful,
    but WITHOUT ANY WARRANTY; without even the implied warranty of
    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
    Lesser General Public License for more details.

    You should have received a copy of the GNU Lesser General Public
    License along with this library; if not, write to the Free Software
    Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301  USA

Also add information on how to contact you by electronic and paper mail.

You should also get your employer (if you work as a programmer) or your
school, if any, to sign a "copyright disclaimer" for the library, if
necessary.  Here is a sample; alter the names:

  Yoyodyne, Inc., hereby disclaims all copyright interest in the
  library `Frob' (a library for tweaking knobs) written by James Random Hacker.

  <signature of Ty Coon>, 1 April 1990
  Ty Coon, President of Vice

That's all there is to it!

***************************************************************************
* cocos2d for iPhone license                                              *
***************************************************************************

cocos2d for iPhone: http://www.cocos2d-iphone.org

Copyright © 2011 - Zynga Inc. and contributors (see each file to see the
different copyright owners)

Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the “Software”), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
SOFTWARE.


This file contains licenses of external libraries included in the
BigWorld game client.
=================================================================

***************************************************************************
* Python                                                                  *
***************************************************************************

A. HISTORY OF THE SOFTWARE
==========================

Python was created in the early 1990s by Guido van Rossum at Stichting
Mathematisch Centrum (CWI, see http://www.cwi.nl) in the Netherlands
as a successor of a language called ABC.  Guido remains Python's
principal author, although it includes many contributions from others.

In 1995, Guido continued his work on Python at the Corporation for
National Research Initiatives (CNRI, see http://www.cnri.reston.va.us)
in Reston, Virginia where he released several versions of the
software.

In May 2000, Guido and the Python core development team moved to
BeOpen.com to form the BeOpen PythonLabs team.  In October of the same
year, the PythonLabs team moved to Digital Creations (now Zope
Corporation, see http://www.zope.com).  In 2001, the Python Software
Foundation (PSF, see http://www.python.org/psf/) was formed, a
non-profit organization created specifically to own Python-related
Intellectual Property.  Zope Corporation is a sponsoring member of
the PSF.

All Python releases are Open Source (see http://www.opensource.org for
the Open Source Definition).  Historically, most, but not all, Python
releases have also been GPL-compatible; the table below summarizes
the various releases.

    Release         Derived     Year        Owner       GPL-
                    from                                compatible? (1)

    0.9.0 thru 1.2              1991-1995   CWI         yes
    1.3 thru 1.5.2  1.2         1995-1999   CNRI        yes
    1.6             1.5.2       2000        CNRI        no
    2.0             1.6         2000        BeOpen.com  no
    1.6.1           1.6         2001        CNRI        yes (2)
    2.1             2.0+1.6.1   2001        PSF         no
    2.0.1           2.0+1.6.1   2001        PSF         yes
    2.1.1           2.1+2.0.1   2001        PSF         yes
    2.2             2.1.1       2001        PSF         yes
    2.1.2           2.1.1       2002        PSF         yes
    2.1.3           2.1.2       2002        PSF         yes
    2.2.1           2.2         2002        PSF         yes
    2.2.2           2.2.1       2002        PSF         yes
    2.2.3           2.2.2       2003        PSF         yes
    2.3             2.2.2       2002-2003   PSF         yes
    2.3.1           2.3         2002-2003   PSF         yes
    2.3.2           2.3.1       2002-2003   PSF         yes
    2.3.3           2.3.2       2002-2003   PSF         yes
    2.3.4           2.3.3       2004        PSF         yes
    2.3.5           2.3.4       2005        PSF         yes
    2.4             2.3         2004        PSF         yes
    2.4.1           2.4         2005        PSF         yes
    2.4.2           2.4.1       2005        PSF         yes
    2.4.3           2.4.2       2006        PSF         yes
    2.5             2.4         2006        PSF         yes

Footnotes:

(1) GPL-compatible doesn't mean that we're distributing Python under
    the GPL.  All Python licenses, unlike the GPL, let you distribute
    a modified version without making your changes open source.  The
    GPL-compatible licenses make it possible to combine Python with
    other software that is released under the GPL; the others don't.

(2) According to Richard Stallman, 1.6.1 is not GPL-compatible,
    because its license has a choice of law clause.  According to
    CNRI, however, Stallman's lawyer has told CNRI's lawyer that 1.6.1
    is "not incompatible" with the GPL.

Thanks to the many outside volunteers who have worked under Guido's
direction to make these releases possible.

B. TERMS AND CONDITIONS FOR ACCESSING OR OTHERWISE USING PYTHON
===============================================================

PYTHON SOFTWARE FOUNDATION LICENSE VERSION 2
--------------------------------------------

1. This LICENSE AGREEMENT is between the Python Software Foundation
("PSF"), and the Individual or Organization ("Licensee") accessing and
otherwise using this software ("Python") in source or binary form and
its associated documentation.

2. Subject to the terms and conditions of this License Agreement, PSF
hereby grants Licensee a nonexclusive, royalty-free, world-wide
license to reproduce, analyze, test, perform and/or display publicly,
prepare derivative works, distribute, and otherwise use Python
alone or in any derivative version, provided, however, that PSF's
License Agreement and PSF's notice of copyright, i.e., "Copyright (c)
2001, 2002, 2003, 2004, 2005, 2006 Python Software Foundation; All Rights
Reserved" are retained in Python alone or in any derivative version
prepared by Licensee.

3. In the event Licensee prepares a derivative work that is based on
or incorporates Python or any part thereof, and wants to make
the derivative work available to others as provided herein, then
Licensee hereby agrees to include in any such work a brief summary of
the changes made to Python.

4. PSF is making Python available to Licensee on an "AS IS"
basis.  PSF MAKES NO REPRESENTATIONS OR WARRANTIES, EXPRESS OR
IMPLIED.  BY WAY OF EXAMPLE, BUT NOT LIMITATION, PSF MAKES NO AND
DISCLAIMS ANY REPRESENTATION OR WARRANTY OF MERCHANTABILITY OR FITNESS
FOR ANY PARTICULAR PURPOSE OR THAT THE USE OF PYTHON WILL NOT
INFRINGE ANY THIRD PARTY RIGHTS.

5. PSF SHALL NOT BE LIABLE TO LICENSEE OR ANY OTHER USERS OF PYTHON
FOR ANY INCIDENTAL, SPECIAL, OR CONSEQUENTIAL DAMAGES OR LOSS AS
A RESULT OF MODIFYING, DISTRIBUTING, OR OTHERWISE USING PYTHON,
OR ANY DERIVATIVE THEREOF, EVEN IF ADVISED OF THE POSSIBILITY THEREOF.

6. This License Agreement will automatically terminate upon a material
breach of its terms and conditions.

7. Nothing in this License Agreement shall be deemed to create any
relationship of agency, partnership, or joint venture between PSF and
Licensee.  This License Agreement does not grant permission to use PSF
trademarks or trade name in a trademark sense to endorse or promote
products or services of Licensee, or any third party.

8. By copying, installing or otherwise using Python, Licensee
agrees to be bound by the terms and conditions of this License
Agreement.

BEOPEN.COM LICENSE AGREEMENT FOR PYTHON 2.0
-------------------------------------------

BEOPEN PYTHON OPEN SOURCE LICENSE AGREEMENT VERSION 1

1. This LICENSE AGREEMENT is between BeOpen.com ("BeOpen"), having an
office at 160 Saratoga Avenue, Santa Clara, CA 95051, and the
Individual or Organization ("Licensee") accessing and otherwise using
this software in source or binary form and its associated
documentation ("the Software").

2. Subject to the terms and conditions of this BeOpen Python License
Agreement, BeOpen hereby grants Licensee a non-exclusive,
royalty-free, world-wide license to reproduce, analyze, test, perform
and/or display publicly, prepare derivative works, distribute, and
otherwise use the Software alone or in any derivative version,
provided, however, that the BeOpen Python License is retained in the
Software, alone or in any derivative version prepared by Licensee.

3. BeOpen is making the Software available to Licensee on an "AS IS"
basis.  BEOPEN MAKES NO REPRESENTATIONS OR WARRANTIES, EXPRESS OR
IMPLIED.  BY WAY OF EXAMPLE, BUT NOT LIMITATION, BEOPEN MAKES NO AND
DISCLAIMS ANY REPRESENTATION OR WARRANTY OF MERCHANTABILITY OR FITNESS
FOR ANY PARTICULAR PURPOSE OR THAT THE USE OF THE SOFTWARE WILL NOT
INFRINGE ANY THIRD PARTY RIGHTS.

4. BEOPEN SHALL NOT BE LIABLE TO LICENSEE OR ANY OTHER USERS OF THE
SOFTWARE FOR ANY INCIDENTAL, SPECIAL, OR CONSEQUENTIAL DAMAGES OR LOSS
AS A RESULT OF USING, MODIFYING OR DISTRIBUTING THE SOFTWARE, OR ANY
DERIVATIVE THEREOF, EVEN IF ADVISED OF THE POSSIBILITY THEREOF.

5. This License Agreement will automatically terminate upon a material
breach of its terms and conditions.

6. This License Agreement shall be governed by and interpreted in all
respects by the law of the State of California, excluding conflict of
law provisions.  Nothing in this License Agreement shall be deemed to
create any relationship of agency, partnership, or joint venture
between BeOpen and Licensee.  This License Agreement does not grant
permission to use BeOpen trademarks or trade names in a trademark
sense to endorse or promote products or services of Licensee, or any
third party.  As an exception, the "BeOpen Python" logos available at
http://www.pythonlabs.com/logos.html may be used according to the
permissions granted on that web page.

7. By copying, installing or otherwise using the software, Licensee
agrees to be bound by the terms and conditions of this License
Agreement.

CNRI LICENSE AGREEMENT FOR PYTHON 1.6.1
---------------------------------------

1. This LICENSE AGREEMENT is between the Corporation for National
Research Initiatives, having an office at 1895 Preston White Drive,
Reston, VA 20191 ("CNRI"), and the Individual or Organization
("Licensee") accessing and otherwise using Python 1.6.1 software in
source or binary form and its associated documentation.

2. Subject to the terms and conditions of this License Agreement, CNRI
hereby grants Licensee a nonexclusive, royalty-free, world-wide
license to reproduce, analyze, test, perform and/or display publicly,
prepare derivative works, distribute, and otherwise use Python 1.6.1
alone or in any derivative version, provided, however, that CNRI's
License Agreement and CNRI's notice of copyright, i.e., "Copyright (c)
1995-2001 Corporation for National Research Initiatives; All Rights
Reserved" are retained in Python 1.6.1 alone or in any derivative
version prepared by Licensee.  Alternately, in lieu of CNRI's License
Agreement, Licensee may substitute the following text (omitting the
quotes): "Python 1.6.1 is made available subject to the terms and
conditions in CNRI's License Agreement.  This Agreement together with
Python 1.6.1 may be located on the Internet using the following
unique, persistent identifier (known as a handle): 1895.22/1013.  This
Agreement may also be obtained from a proxy server on the Internet
using the following URL: http://hdl.handle.net/1895.22/1013".

3. In the event Licensee prepares a derivative work that is based on
or incorporates Python 1.6.1 or any part thereof, and wants to make
the derivative work available to others as provided herein, then
Licensee hereby agrees to include in any such work a brief summary of
the changes made to Python 1.6.1.

4. CNRI is making Python 1.6.1 available to Licensee on an "AS IS"
basis.  CNRI MAKES NO REPRESENTATIONS OR WARRANTIES, EXPRESS OR
IMPLIED.  BY WAY OF EXAMPLE, BUT NOT LIMITATION, CNRI MAKES NO AND
DISCLAIMS ANY REPRESENTATION OR WARRANTY OF MERCHANTABILITY OR FITNESS
FOR ANY PARTICULAR PURPOSE OR THAT THE USE OF PYTHON 1.6.1 WILL NOT
INFRINGE ANY THIRD PARTY RIGHTS.

5. CNRI SHALL NOT BE LIABLE TO LICENSEE OR ANY OTHER USERS OF PYTHON
1.6.1 FOR ANY INCIDENTAL, SPECIAL, OR CONSEQUENTIAL DAMAGES OR LOSS AS
A RESULT OF MODIFYING, DISTRIBUTING, OR OTHERWISE USING PYTHON 1.6.1,
OR ANY DERIVATIVE THEREOF, EVEN IF ADVISED OF THE POSSIBILITY THEREOF.

6. This License Agreement will automatically terminate upon a material
breach of its terms and conditions.

7. This License Agreement shall be governed by the federal
intellectual property law of the United States, including without
limitation the federal copyright law, and, to the extent such
U.S. federal law does not apply, by the law of the Commonwealth of
Virginia, excluding Virginia's conflict of law provisions.
Notwithstanding the foregoing, with regard to derivative works based
on Python 1.6.1 that incorporate non-separable material that was
previously distributed under the GNU General Public License (GPL), the
law of the Commonwealth of Virginia shall govern this License
Agreement only as to issues arising under or with respect to
Paragraphs 4, 5, and 7 of this License Agreement.  Nothing in this
License Agreement shall be deemed to create any relationship of
agency, partnership, or joint venture between CNRI and Licensee.  This
License Agreement does not grant permission to use CNRI trademarks or
trade name in a trademark sense to endorse or promote products or
services of Licensee, or any third party.

8. By clicking on the "ACCEPT" button where indicated, or by copying,
installing or otherwise using Python 1.6.1, Licensee agrees to be
bound by the terms and conditions of this License Agreement.

        ACCEPT

CWI LICENSE AGREEMENT FOR PYTHON 0.9.0 THROUGH 1.2
--------------------------------------------------

Copyright (c) 1991 - 1995, Stichting Mathematisch Centrum Amsterdam,
The Netherlands.  All rights reserved.

Permission to use, copy, modify, and distribute this software and its
documentation for any purpose and without fee is hereby granted,
provided that the above copyright notice appear in all copies and that
both that copyright notice and this permission notice appear in
supporting documentation, and that the name of Stichting Mathematisch
Centrum or CWI not be used in advertising or publicity pertaining to
distribution of the software without specific, written prior
permission.

STICHTING MATHEMATISCH CENTRUM DISCLAIMS ALL WARRANTIES WITH REGARD TO
THIS SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND
FITNESS, IN NO EVENT SHALL STICHTING MATHEMATISCH CENTRUM BE LIABLE
FOR ANY SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT
OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.

***************************************************************************
* aalloc.hpp                                                              *
***************************************************************************

/*
 * Copyright (c) 1992-2001 by P.J. Plauger.  ALL RIGHTS RESERVED.
 * Consult your license regarding permissions and restrictions.
 */

/*
 * This file is derived from software bearing the following
 * restrictions:
 *
 * Copyright (c) 1994
 * Hewlett-Packard Company
 *
 * Permission to use, copy, modify, distribute and sell this
 * software and its documentation for any purpose is hereby
 * granted without fee, provided that the above copyright notice
 * appear in all copies and that both that copyright notice and
 * this permission notice appear in supporting documentation.
 * Hewlett-Packard Company makes no representations about the
 * suitability of this software for any purpose. It is provided
 * "as is" without express or implied warranty.
 V3.10:0009 */

***************************************************************************
* avector.hpp                                                             *
***************************************************************************

/*
 * Copyright (c) 1992-2001 by P.J. Plauger.  ALL RIGHTS RESERVED.
 * Consult your license regarding permissions and restrictions.
 */

/*
 * This file is derived from software bearing the following
 * restrictions:
 *
 * Copyright (c) 1994
 * Hewlett-Packard Company
 *
 * Permission to use, copy, modify, distribute and sell this
 * software and its documentation for any purpose is hereby
 * granted without fee, provided that the above copyright notice
 * appear in all copies and that both that copyright notice and
 * this permission notice appear in supporting documentation.
 * Hewlett-Packard Company makes no representations about the
 * suitability of this software for any purpose. It is provided
 * "as is" without express or implied warranty.
 V3.10:0009 */

***************************************************************************
* bsdiff                                                                  *
***************************************************************************

/*
 * Parts of this library are derived from Colin Percival's bsdiff tool.
 *
 * Copyright 2003-2005 Colin Percival
 * All rights reserved
 *
 * Redistribution and use in source and binary forms, with or without
 * modification, are permitted providing that the following conditions
 * are met:
 * 1. Redistributions of source code must retain the above copyright
 *    notice, this list of conditions and the following disclaimer.
 * 2. Redistributions in binary form must reproduce the above copyright
 *    notice, this list of conditions and the following disclaimer in the
 *    documentation and/or other materials provided with the distribution.
 *
 * THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR
 * IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
 * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
 * ARE DISCLAIMED.  IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY
 * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
 * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
 * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
 * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
 * STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING
 * IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
 * POSSIBILITY OF SUCH DAMAGE.
 */

***************************************************************************
* OpenSSL                                                                 *
***************************************************************************

  LICENSE ISSUES
  ==============

  The OpenSSL toolkit stays under a dual license, i.e. both the conditions of
  the OpenSSL License and the original SSLeay license apply to the toolkit.
  See below for the actual license texts. Actually both licenses are BSD-style
  Open Source licenses. In case of any license issues related to OpenSSL
  please contact openssl-core@openssl.org.

  OpenSSL License
  ---------------

/* ====================================================================
 * Copyright (c) 1998-2007 The OpenSSL Project.  All rights reserved.
 *
 * Redistribution and use in source and binary forms, with or without
 * modification, are permitted provided that the following conditions
 * are met:
 *
 * 1. Redistributions of source code must retain the above copyright
 *    notice, this list of conditions and the following disclaimer.
 *
 * 2. Redistributions in binary form must reproduce the above copyright
 *    notice, this list of conditions and the following disclaimer in
 *    the documentation and/or other materials provided with the
 *    distribution.
 *
 * 3. All advertising materials mentioning features or use of this
 *    software must display the following acknowledgment:
 *    "This product includes software developed by the OpenSSL Project
 *    for use in the OpenSSL Toolkit. (http://www.openssl.org/)"
 *
 * 4. The names "OpenSSL Toolkit" and "OpenSSL Project" must not be used to
 *    endorse or promote products derived from this software without
 *    prior written permission. For written permission, please contact
 *    openssl-core@openssl.org.
 *
 * 5. Products derived from this software may not be called "OpenSSL"
 *    nor may "OpenSSL" appear in their names without prior written
 *    permission of the OpenSSL Project.
 *
 * 6. Redistributions of any form whatsoever must retain the following
 *    acknowledgment:
 *    "This product includes software developed by the OpenSSL Project
 *    for use in the OpenSSL Toolkit (http://www.openssl.org/)"
 *
 * THIS SOFTWARE IS PROVIDED BY THE OpenSSL PROJECT ``AS IS'' AND ANY
 * EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
 * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
 * PURPOSE ARE DISCLAIMED.  IN NO EVENT SHALL THE OpenSSL PROJECT OR
 * ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
 * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
 * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
 * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
 * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
 * STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
 * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED
 * OF THE POSSIBILITY OF SUCH DAMAGE.
 * ====================================================================
 *
 * This product includes cryptographic software written by Eric Young
 * (eay@cryptsoft.com).  This product includes software written by Tim
 * Hudson (tjh@cryptsoft.com).
 *
 */

 Original SSLeay License
 -----------------------

/* Copyright (C) 1995-1998 Eric Young (eay@cryptsoft.com)
 * All rights reserved.
 *
 * This package is an SSL implementation written
 * by Eric Young (eay@cryptsoft.com).
 * The implementation was written so as to conform with Netscapes SSL.
 *
 * This library is free for commercial and non-commercial use as long as
 * the following conditions are adhered to.  The following conditions
 * apply to all code found in this distribution, be it the RC4, RSA,
 * lhash, DES, etc., code; not just the SSL code.  The SSL documentation
 * included with this distribution is covered by the same copyright terms
 * except that the holder is Tim Hudson (tjh@cryptsoft.com).
 *
 * Copyright remains Eric Young's, and as such any Copyright notices in
 * the code are not to be removed.
 * If this package is used in a product, Eric Young should be given attribution
 * as the author of the parts of the library used.
 * This can be in the form of a textual message at program startup or
 * in documentation (online or textual) provided with the package.
 *
 * Redistribution and use in source and binary forms, with or without
 * modification, are permitted provided that the following conditions
 * are met:
 * 1. Redistributions of source code must retain the copyright
 *    notice, this list of conditions and the following disclaimer.
 * 2. Redistributions in binary form must reproduce the above copyright
 *    notice, this list of conditions and the following disclaimer in the
 *    documentation and/or other materials provided with the distribution.
 * 3. All advertising materials mentioning features or use of this software
 *    must display the following acknowledgement:
 *    "This product includes cryptographic software written by
 *     Eric Young (eay@cryptsoft.com)"
 *    The word 'cryptographic' can be left out if the routines from the library
 *    being used are not cryptographic related :-).
 * 4. If you include any Windows specific code (or a derivative thereof) from
 *    the apps directory (application code) you must include an acknowledgement:
 *    "This product includes software written by Tim Hudson (tjh@cryptsoft.com)"
 *
 * THIS SOFTWARE IS PROVIDED BY ERIC YOUNG ``AS IS'' AND
 * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
 * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
 * ARE DISCLAIMED.  IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
 * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
 * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
 * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
 * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
 * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
 * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
 * SUCH DAMAGE.
 *
 * The licence and distribution terms for any publically available version or
 * derivative of this code cannot be changed.  i.e. this code cannot simply be
 * copied and put under another distribution licence
 * [including the GNU Public Licence.]
 */

***************************************************************************
* MySQL-python                                                            *
***************************************************************************

Copyright 1991-1995 by Stichting Mathematisch Centrum, Amsterdam,
The Netherlands.

                        All Rights Reserved

Permission to use, copy, modify, and distribute this software and its
documentation for any purpose and without fee is hereby granted,
provided that the above copyright notice appear in all copies and that
both that copyright notice and this permission notice appear in
supporting documentation, and that the names of Stichting Mathematisch
Centrum or CWI or Corporation for National Research Initiatives or
CNRI not be used in advertising or publicity pertaining to
distribution of the software without specific, written prior
permission.

While CWI is the initial source for this software, a modified version
is made available by the Corporation for National Research Initiatives
(CNRI) at the Internet address ftp://ftp.python.org.

STICHTING MATHEMATISCH CENTRUM AND CNRI DISCLAIM ALL WARRANTIES WITH
REGARD TO THIS SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS, IN NO EVENT SHALL STICHTING MATHEMATISCH
CENTRUM OR CNRI BE LIABLE FOR ANY SPECIAL, INDIRECT OR CONSEQUENTIAL
DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR
PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER
TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
PERFORMANCE OF THIS SOFTWARE.

***************************************************************************
* StackWalker                                                             *
***************************************************************************

Copyright (c) 2007, Jochen Kalmbach

All rights reserved.

Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:

* Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.
* Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.
* Neither the name of the <ORGANIZATION> nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission.

THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
"AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR
PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING
NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

********************************************************************
*  GECKO                                                           *
********************************************************************

                          MOZILLA PUBLIC LICENSE
                                Version 1.1

                              ---------------

1. Definitions.

     1.0.1. "Commercial Use" means distribution or otherwise making the
     Covered Code available to a third party.

     1.1. "Contributor" means each entity that creates or contributes to
     the creation of Modifications.

     1.2. "Contributor Version" means the combination of the Original
     Code, prior Modifications used by a Contributor, and the Modifications
     made by that particular Contributor.

     1.3. "Covered Code" means the Original Code or Modifications or the
     combination of the Original Code and Modifications, in each case
     including portions thereof.

     1.4. "Electronic Distribution Mechanism" means a mechanism generally
     accepted in the software development community for the electronic
     transfer of data.

     1.5. "Executable" means Covered Code in any form other than Source
     Code.

     1.6. "Initial Developer" means the individual or entity identified
     as the Initial Developer in the Source Code notice required by Exhibit
     A.

     1.7. "Larger Work" means a work which combines Covered Code or
     portions thereof with code not governed by the terms of this License.

     1.8. "License" means this document.

     1.8.1. "Licensable" means having the right to grant, to the maximum
     extent possible, whether at the time of the initial grant or
     subsequently acquired, any and all of the rights conveyed herein.

     1.9. "Modifications" means any addition to or deletion from the
     substance or structure of either the Original Code or any previous
     Modifications. When Covered Code is released as a series of files, a
     Modification is:
          A. Any addition to or deletion from the contents of a file
          containing Original Code or previous Modifications.

          B. Any new file that contains any part of the Original Code or
          previous Modifications.

     1.10. "Original Code" means Source Code of computer software code
     which is described in the Source Code notice required by Exhibit A as
     Original Code, and which, at the time of its release under this
     License is not already Covered Code governed by this License.

     1.10.1. "Patent Claims" means any patent claim(s), now owned or
     hereafter acquired, including without limitation,  method, process,
     and apparatus claims, in any patent Licensable by grantor.

     1.11. "Source Code" means the preferred form of the Covered Code for
     making modifications to it, including all modules it contains, plus
     any associated interface definition files, scripts used to control
     compilation and installation of an Executable, or source code
     differential comparisons against either the Original Code or another
     well known, available Covered Code of the Contributor's choice. The
     Source Code can be in a compressed or archival form, provided the
     appropriate decompression or de-archiving software is widely available
     for no charge.

     1.12. "You" (or "Your")  means an individual or a legal entity
     exercising rights under, and complying with all of the terms of, this
     License or a future version of this License issued under Section 6.1.
     For legal entities, "You" includes any entity which controls, is
     controlled by, or is under common control with You. For purposes of
     this definition, "control" means (a) the power, direct or indirect,
     to cause the direction or management of such entity, whether by
     contract or otherwise, or (b) ownership of more than fifty percent
     (50%) of the outstanding shares or beneficial ownership of such
     entity.

2. Source Code License.

     2.1. The Initial Developer Grant.
     The Initial Developer hereby grants You a world-wide, royalty-free,
     non-exclusive license, subject to third party intellectual property
     claims:
          (a)  under intellectual property rights (other than patent or
          trademark) Licensable by Initial Developer to use, reproduce,
          modify, display, perform, sublicense and distribute the Original
          Code (or portions thereof) with or without Modifications, and/or
          as part of a Larger Work; and

          (b) under Patents Claims infringed by the making, using or
          selling of Original Code, to make, have made, use, practice,
          sell, and offer for sale, and/or otherwise dispose of the
          Original Code (or portions thereof).

          (c) the licenses granted in this Section 2.1(a) and (b) are
          effective on the date Initial Developer first distributes
          Original Code under the terms of this License.

          (d) Notwithstanding Section 2.1(b) above, no patent license is
          granted: 1) for code that You delete from the Original Code; 2)
          separate from the Original Code;  or 3) for infringements caused
          by: i) the modification of the Original Code or ii) the
          combination of the Original Code with other software or devices.

     2.2. Contributor Grant.
     Subject to third party intellectual property claims, each Contributor
     hereby grants You a world-wide, royalty-free, non-exclusive license

          (a)  under intellectual property rights (other than patent or
          trademark) Licensable by Contributor, to use, reproduce, modify,
          display, perform, sublicense and distribute the Modifications
          created by such Contributor (or portions thereof) either on an
          unmodified basis, with other Modifications, as Covered Code
          and/or as part of a Larger Work; and

          (b) under Patent Claims infringed by the making, using, or
          selling of  Modifications made by that Contributor either alone
          and/or in combination with its Contributor Version (or portions
          of such combination), to make, use, sell, offer for sale, have
          made, and/or otherwise dispose of: 1) Modifications made by that
          Contributor (or portions thereof); and 2) the combination of
          Modifications made by that Contributor with its Contributor
          Version (or portions of such combination).

          (c) the licenses granted in Sections 2.2(a) and 2.2(b) are
          effective on the date Contributor first makes Commercial Use of
          the Covered Code.

          (d)    Notwithstanding Section 2.2(b) above, no patent license is
          granted: 1) for any code that Contributor has deleted from the
          Contributor Version; 2)  separate from the Contributor Version;
          3)  for infringements caused by: i) third party modifications of
          Contributor Version or ii)  the combination of Modifications made
          by that Contributor with other software  (except as part of the
          Contributor Version) or other devices; or 4) under Patent Claims
          infringed by Covered Code in the absence of Modifications made by
          that Contributor.

3. Distribution Obligations.

     3.1. Application of License.
     The Modifications which You create or to which You contribute are
     governed by the terms of this License, including without limitation
     Section 2.2. The Source Code version of Covered Code may be
     distributed only under the terms of this License or a future version
     of this License released under Section 6.1, and You must include a
     copy of this License with every copy of the Source Code You
     distribute. You may not offer or impose any terms on any Source Code
     version that alters or restricts the applicable version of this
     License or the recipients' rights hereunder. However, You may include
     an additional document offering the additional rights described in
     Section 3.5.

     3.2. Availability of Source Code.
     Any Modification which You create or to which You contribute must be
     made available in Source Code form under the terms of this License
     either on the same media as an Executable version or via an accepted
     Electronic Distribution Mechanism to anyone to whom you made an
     Executable version available; and if made available via Electronic
     Distribution Mechanism, must remain available for at least twelve (12)
     months after the date it initially became available, or at least six
     (6) months after a subsequent version of that particular Modification
     has been made available to such recipients. You are responsible for
     ensuring that the Source Code version remains available even if the
     Electronic Distribution Mechanism is maintained by a third party.

     3.3. Description of Modifications.
     You must cause all Covered Code to which You contribute to contain a
     file documenting the changes You made to create that Covered Code and
     the date of any change. You must include a prominent statement that
     the Modification is derived, directly or indirectly, from Original
     Code provided by the Initial Developer and including the name of the
     Initial Developer in (a) the Source Code, and (b) in any notice in an
     Executable version or related documentation in which You describe the
     origin or ownership of the Covered Code.

     3.4. Intellectual Property Matters
          (a) Third Party Claims.
          If Contributor has knowledge that a license under a third party's
          intellectual property rights is required to exercise the rights
          granted by such Contributor under Sections 2.1 or 2.2,
          Contributor must include a text file with the Source Code
          distribution titled "LEGAL" which describes the claim and the
          party making the claim in sufficient detail that a recipient will
          know whom to contact. If Contributor obtains such knowledge after
          the Modification is made available as described in Section 3.2,
          Contributor shall promptly modify the LEGAL file in all copies
          Contributor makes available thereafter and shall take other steps
          (such as notifying appropriate mailing lists or newsgroups)
          reasonably calculated to inform those who received the Covered
          Code that new knowledge has been obtained.

          (b) Contributor APIs.
          If Contributor's Modifications include an application programming
          interface and Contributor has knowledge of patent licenses which
          are reasonably necessary to implement that API, Contributor must
          also include this information in the LEGAL file.

               (c)    Representations.
          Contributor represents that, except as disclosed pursuant to
          Section 3.4(a) above, Contributor believes that Contributor's
          Modifications are Contributor's original creation(s) and/or
          Contributor has sufficient rights to grant the rights conveyed by
          this License.

     3.5. Required Notices.
     You must duplicate the notice in Exhibit A in each file of the Source
     Code.  If it is not possible to put such notice in a particular Source
     Code file due to its structure, then You must include such notice in a
     location (such as a relevant directory) where a user would be likely
     to look for such a notice.  If You created one or more Modification(s)
     You may add your name as a Contributor to the notice described in
     Exhibit A.  You must also duplicate this License in any documentation
     for the Source Code where You describe recipients' rights or ownership
     rights relating to Covered Code.  You may choose to offer, and to
     charge a fee for, warranty, support, indemnity or liability
     obligations to one or more recipients of Covered Code. However, You
     may do so only on Your own behalf, and not on behalf of the Initial
     Developer or any Contributor. You must make it absolutely clear than
     any such warranty, support, indemnity or liability obligation is
     offered by You alone, and You hereby agree to indemnify the Initial
     Developer and every Contributor for any liability incurred by the
     Initial Developer or such Contributor as a result of warranty,
     support, indemnity or liability terms You offer.

     3.6. Distribution of Executable Versions.
     You may distribute Covered Code in Executable form only if the
     requirements of Section 3.1-3.5 have been met for that Covered Code,
     and if You include a notice stating that the Source Code version of
     the Covered Code is available under the terms of this License,
     including a description of how and where You have fulfilled the
     obligations of Section 3.2. The notice must be conspicuously included
     in any notice in an Executable version, related documentation or
     collateral in which You describe recipients' rights relating to the
     Covered Code. You may distribute the Executable version of Covered
     Code or ownership rights under a license of Your choice, which may
     contain terms different from this License, provided that You are in
     compliance with the terms of this License and that the license for the
     Executable version does not attempt to limit or alter the recipient's
     rights in the Source Code version from the rights set forth in this
     License. If You distribute the Executable version under a different
     license You must make it absolutely clear that any terms which differ
     from this License are offered by You alone, not by the Initial
     Developer or any Contributor. You hereby agree to indemnify the
     Initial Developer and every Contributor for any liability incurred by
     the Initial Developer or such Contributor as a result of any such
     terms You offer.

     3.7. Larger Works.
     You may create a Larger Work by combining Covered Code with other code
     not governed by the terms of this License and distribute the Larger
     Work as a single product. In such a case, You must make sure the
     requirements of this License are fulfilled for the Covered Code.

4. Inability to Comply Due to Statute or Regulation.

     If it is impossible for You to comply with any of the terms of this
     License with respect to some or all of the Covered Code due to
     statute, judicial order, or regulation then You must: (a) comply with
     the terms of this License to the maximum extent possible; and (b)
     describe the limitations and the code they affect. Such description
     must be included in the LEGAL file described in Section 3.4 and must
     be included with all distributions of the Source Code. Except to the
     extent prohibited by statute or regulation, such description must be
     sufficiently detailed for a recipient of ordinary skill to be able to
     understand it.

5. Application of this License.

     This License applies to code to which the Initial Developer has
     attached the notice in Exhibit A and to related Covered Code.

6. Versions of the License.

     6.1. New Versions.
     Netscape Communications Corporation ("Netscape") may publish revised
     and/or new versions of the License from time to time. Each version
     will be given a distinguishing version number.

     6.2. Effect of New Versions.
     Once Covered Code has been published under a particular version of the
     License, You may always continue to use it under the terms of that
     version. You may also choose to use such Covered Code under the terms
     of any subsequent version of the License published by Netscape. No one
     other than Netscape has the right to modify the terms applicable to
     Covered Code created under this License.

     6.3. Derivative Works.
     If You create or use a modified version of this License (which you may
     only do in order to apply it to code which is not already Covered Code
     governed by this License), You must (a) rename Your license so that
     the phrases "Mozilla", "MOZILLAPL", "MOZPL", "Netscape",
     "MPL", "NPL" or any confusingly similar phrase do not appear in your
     license (except to note that your license differs from this License)
     and (b) otherwise make it clear that Your version of the license
     contains terms which differ from the Mozilla Public License and
     Netscape Public License. (Filling in the name of the Initial
     Developer, Original Code or Contributor in the notice described in
     Exhibit A shall not of themselves be deemed to be modifications of
     this License.)

7. DISCLAIMER OF WARRANTY.

     COVERED CODE IS PROVIDED UNDER THIS LICENSE ON AN "AS IS" BASIS,
     WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING,
     WITHOUT LIMITATION, WARRANTIES THAT THE COVERED CODE IS FREE OF
     DEFECTS, MERCHANTABLE, FIT FOR A PARTICULAR PURPOSE OR NON-INFRINGING.
     THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE COVERED CODE
     IS WITH YOU. SHOULD ANY COVERED CODE PROVE DEFECTIVE IN ANY RESPECT,
     YOU (NOT THE INITIAL DEVELOPER OR ANY OTHER CONTRIBUTOR) ASSUME THE
     COST OF ANY NECESSARY SERVICING, REPAIR OR CORRECTION. THIS DISCLAIMER
     OF WARRANTY CONSTITUTES AN ESSENTIAL PART OF THIS LICENSE. NO USE OF
     ANY COVERED CODE IS AUTHORIZED HEREUNDER EXCEPT UNDER THIS DISCLAIMER.

8. TERMINATION.

     8.1.  This License and the rights granted hereunder will terminate
     automatically if You fail to comply with terms herein and fail to cure
     such breach within 30 days of becoming aware of the breach. All
     sublicenses to the Covered Code which are properly granted shall
     survive any termination of this License. Provisions which, by their
     nature, must remain in effect beyond the termination of this License
     shall survive.

     8.2.  If You initiate litigation by asserting a patent infringement
     claim (excluding declatory judgment actions) against Initial Developer
     or a Contributor (the Initial Developer or Contributor against whom
     You file such action is referred to as "Participant")  alleging that:

     (a)  such Participant's Contributor Version directly or indirectly
     infringes any patent, then any and all rights granted by such
     Participant to You under Sections 2.1 and/or 2.2 of this License
     shall, upon 60 days notice from Participant terminate prospectively,
     unless if within 60 days after receipt of notice You either: (i)
     agree in writing to pay Participant a mutually agreeable reasonable
     royalty for Your past and future use of Modifications made by such
     Participant, or (ii) withdraw Your litigation claim with respect to
     the Contributor Version against such Participant.  If within 60 days
     of notice, a reasonable royalty and payment arrangement are not
     mutually agreed upon in writing by the parties or the litigation claim
     is not withdrawn, the rights granted by Participant to You under
     Sections 2.1 and/or 2.2 automatically terminate at the expiration of
     the 60 day notice period specified above.

     (b)  any software, hardware, or device, other than such Participant's
     Contributor Version, directly or indirectly infringes any patent, then
     any rights granted to You by such Participant under Sections 2.1(b)
     and 2.2(b) are revoked effective as of the date You first made, used,
     sold, distributed, or had made, Modifications made by that
     Participant.

     8.3.  If You assert a patent infringement claim against Participant
     alleging that such Participant's Contributor Version directly or
     indirectly infringes any patent where such claim is resolved (such as
     by license or settlement) prior to the initiation of patent
     infringement litigation, then the reasonable value of the licenses
     granted by such Participant under Sections 2.1 or 2.2 shall be taken
     into account in determining the amount or value of any payment or
     license.

     8.4.  In the event of termination under Sections 8.1 or 8.2 above,
     all end user license agreements (excluding distributors and resellers)
     which have been validly granted by You or any distributor hereunder
     prior to termination shall survive termination.

9. LIMITATION OF LIABILITY.

     UNDER NO CIRCUMSTANCES AND UNDER NO LEGAL THEORY, WHETHER TORT
     (INCLUDING NEGLIGENCE), CONTRACT, OR OTHERWISE, SHALL YOU, THE INITIAL
     DEVELOPER, ANY OTHER CONTRIBUTOR, OR ANY DISTRIBUTOR OF COVERED CODE,
     OR ANY SUPPLIER OF ANY OF SUCH PARTIES, BE LIABLE TO ANY PERSON FOR
     ANY INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES OF ANY
     CHARACTER INCLUDING, WITHOUT LIMITATION, DAMAGES FOR LOSS OF GOODWILL,
     WORK STOPPAGE, COMPUTER FAILURE OR MALFUNCTION, OR ANY AND ALL OTHER
     COMMERCIAL DAMAGES OR LOSSES, EVEN IF SUCH PARTY SHALL HAVE BEEN
     INFORMED OF THE POSSIBILITY OF SUCH DAMAGES. THIS LIMITATION OF
     LIABILITY SHALL NOT APPLY TO LIABILITY FOR DEATH OR PERSONAL INJURY
     RESULTING FROM SUCH PARTY'S NEGLIGENCE TO THE EXTENT APPLICABLE LAW
     PROHIBITS SUCH LIMITATION. SOME JURISDICTIONS DO NOT ALLOW THE
     EXCLUSION OR LIMITATION OF INCIDENTAL OR CONSEQUENTIAL DAMAGES, SO
     THIS EXCLUSION AND LIMITATION MAY NOT APPLY TO YOU.

10. U.S. GOVERNMENT END USERS.

     The Covered Code is a "commercial item," as that term is defined in
     48 C.F.R. 2.101 (Oct. 1995), consisting of "commercial computer
     software" and "commercial computer software documentation," as such
     terms are used in 48 C.F.R. 12.212 (Sept. 1995). Consistent with 48
     C.F.R. 12.212 and 48 C.F.R. 227.7202-1 through 227.7202-4 (June 1995),
     all U.S. Government End Users acquire Covered Code with only those
     rights set forth herein.

11. MISCELLANEOUS.

     This License represents the complete agreement concerning subject
     matter hereof. If any provision of this License is held to be
     unenforceable, such provision shall be reformed only to the extent
     necessary to make it enforceable. This License shall be governed by
     California law provisions (except to the extent applicable law, if
     any, provides otherwise), excluding its conflict-of-law provisions.
     With respect to disputes in which at least one party is a citizen of,
     or an entity chartered or registered to do business in the United
     States of America, any litigation relating to this License shall be
     subject to the jurisdiction of the Federal Courts of the Northern
     District of California, with venue lying in Santa Clara County,
     California, with the losing party responsible for costs, including
     without limitation, court costs and reasonable attorneys' fees and
     expenses. The application of the United Nations Convention on
     Contracts for the International Sale of Goods is expressly excluded.
     Any law or regulation which provides that the language of a contract
     shall be construed against the drafter shall not apply to this
     License.

12. RESPONSIBILITY FOR CLAIMS.

     As between Initial Developer and the Contributors, each party is
     responsible for claims and damages arising, directly or indirectly,
     out of its utilization of rights under this License and You agree to
     work with Initial Developer and Contributors to distribute such
     responsibility on an equitable basis. Nothing herein is intended or
     shall be deemed to constitute any admission of liability.

13. MULTIPLE-LICENSED CODE.

     Initial Developer may designate portions of the Covered Code as
     "Multiple-Licensed".  "Multiple-Licensed" means that the Initial
     Developer permits you to utilize portions of the Covered Code under
     Your choice of the NPL or the alternative licenses, if any, specified
     by the Initial Developer in the file described in Exhibit A.

EXHIBIT A -Mozilla Public License.

     ``The contents of this file are subject to the Mozilla Public License
     Version 1.1 (the "License"); you may not use this file except in
     compliance with the License. You may obtain a copy of the License at
     http://www.mozilla.org/MPL/

     Software distributed under the License is distributed on an "AS IS"
     basis, WITHOUT WARRANTY OF ANY KIND, either express or implied. See the
     License for the specific language governing rights and limitations
     under the License.

     The Original Code is ______________________________________.

     The Initial Developer of the Original Code is ________________________.
     Portions created by ______________________ are Copyright (C) ______
     _______________________. All Rights Reserved.

     Contributor(s): ______________________________________.

     Alternatively, the contents of this file may be used under the terms
     of the _____ license (the  "[___] License"), in which case the
     provisions of [______] License are applicable instead of those
     above.  If you wish to allow use of your version of this file only
     under the terms of the [____] License and not to allow others to use
     your version of this file under the MPL, indicate your decision by
     deleting  the provisions above and replace  them with the notice and
     other provisions required by the [___] License.  If you do not delete
     the provisions above, a recipient may use your version of this file
     under either the MPL or the [___] License."

     [NOTE: The text of this Exhibit A may differ slightly from the text of
     the notices in the Source Code files of the Original Code. You should
     use the text of this Exhibit A rather than the text found in the
     Original Code Source Code for Your Modifications.]

     ----------------------------------------------------------------------

     AMENDMENTS

     The Netscape Public License Version 1.1 ("NPL") consists of the
     Mozilla Public License Version 1.1 with the following Amendments,
     including Exhibit A-Netscape Public License.  Files identified with
     "Exhibit A-Netscape Public License" are governed by the Netscape
     Public License Version 1.1.

     Additional Terms applicable to the Netscape Public License.
          I. Effect.
          These additional terms described in this Netscape Public
          License -- Amendments shall apply to the Mozilla Communicator
          client code and to all Covered Code under this License.

          II. "Netscape's Branded Code" means Covered Code that Netscape
          distributes and/or permits others to distribute under one or more
          trademark(s) which are controlled by Netscape but which are not
          licensed for use under this License.

          III. Netscape and logo.
          This License does not grant any rights to use the trademarks
          "Netscape", the "Netscape N and horizon" logo or the "Netscape
          lighthouse" logo, "Netcenter", "Gecko", "Java" or "JavaScript",
          "Smart Browsing" even if such marks are included in the Original
          Code or Modifications.

          IV. Inability to Comply Due to Contractual Obligation.
          Prior to licensing the Original Code under this License, Netscape
          has licensed third party code for use in Netscape's Branded Code.
          To the extent that Netscape is limited contractually from making
          such third party code available under this License, Netscape may
          choose to reintegrate such code into Covered Code without being
          required to distribute such code in Source Code form, even if
          such code would otherwise be considered "Modifications" under
          this License.

          V. Use of Modifications and Covered Code by Initial Developer.
               V.1. In General.
               The obligations of Section 3 apply to Netscape, except to
               the extent specified in this Amendment, Section V.2 and V.3.

               V.2. Other Products.
               Netscape may include Covered Code in products other than the
               Netscape's Branded Code which are released by Netscape
               during the two (2) years following the release date of the
               Original Code, without such additional products becoming
               subject to the terms of this License, and may license such
               additional products on different terms from those contained
               in this License.

               V.3. Alternative Licensing.
               Netscape may license the Source Code of Netscape's Branded
               Code, including Modifications incorporated therein, without
               such Netscape Branded Code becoming subject to the terms of
               this License, and may license such Netscape Branded Code on
               different terms from those contained in this License.

          VI. Litigation.
          Notwithstanding the limitations of Section 11 above, the
          provisions regarding litigation in Section 11(a), (b) and (c) of
          the License shall apply to all disputes relating to this License.

     EXHIBIT A-Netscape Public License.

          "The contents of this file are subject to the Netscape Public
          License Version 1.1 (the "License"); you may not use this file
          except in compliance with the License. You may obtain a copy of
          the License at http://www.mozilla.org/NPL/

          Software distributed under the License is distributed on an "AS
          IS" basis, WITHOUT WARRANTY OF ANY KIND, either express or
          implied. See the License for the specific language governing
          rights and limitations under the License.

          The Original Code is Mozilla Communicator client code, released
          March 31, 1998.

          The Initial Developer of the Original Code is Netscape
          Communications Corporation. Portions created by Netscape are
          Copyright (C) 1998-1999 Netscape Communications Corporation. All
          Rights Reserved.

          Contributor(s): ______________________________________.

          Alternatively, the contents of this file may be used under the
          terms of the _____ license (the "[___] License"), in which case
          the provisions of [______] License are applicable  instead of
          those above.  If you wish to allow use of your version of this
          file only under the terms of the [____] License and not to allow
          others to use your version of this file under the NPL, indicate
          your decision by deleting  the provisions above and replace  them
          with the notice and other provisions required by the [___]
          License.  If you do not delete the provisions above, a recipient
          may use your version of this file under either the NPL or the
          [___] License."

      *********************
      *********************
      *** SPECIAL NOTES ***
      *********************
      *********************
      *********************
      See The Directory Game\Mozilla\Patch For Specific Details
      No Changes Except For The Linden Patch Were Done To Gecko

********************************************************************
*  LLMOZLIB                                                        *
********************************************************************

                          MOZILLA PUBLIC LICENSE
                                Version 1.1

                              ---------------

1. Definitions.

     1.0.1. "Commercial Use" means distribution or otherwise making the
     Covered Code available to a third party.

     1.1. "Contributor" means each entity that creates or contributes to
     the creation of Modifications.

     1.2. "Contributor Version" means the combination of the Original
     Code, prior Modifications used by a Contributor, and the Modifications
     made by that particular Contributor.

     1.3. "Covered Code" means the Original Code or Modifications or the
     combination of the Original Code and Modifications, in each case
     including portions thereof.

     1.4. "Electronic Distribution Mechanism" means a mechanism generally
     accepted in the software development community for the electronic
     transfer of data.

     1.5. "Executable" means Covered Code in any form other than Source
     Code.

     1.6. "Initial Developer" means the individual or entity identified
     as the Initial Developer in the Source Code notice required by Exhibit
     A.

     1.7. "Larger Work" means a work which combines Covered Code or
     portions thereof with code not governed by the terms of this License.

     1.8. "License" means this document.

     1.8.1. "Licensable" means having the right to grant, to the maximum
     extent possible, whether at the time of the initial grant or
     subsequently acquired, any and all of the rights conveyed herein.

     1.9. "Modifications" means any addition to or deletion from the
     substance or structure of either the Original Code or any previous
     Modifications. When Covered Code is released as a series of files, a
     Modification is:
          A. Any addition to or deletion from the contents of a file
          containing Original Code or previous Modifications.

          B. Any new file that contains any part of the Original Code or
          previous Modifications.

     1.10. "Original Code" means Source Code of computer software code
     which is described in the Source Code notice required by Exhibit A as
     Original Code, and which, at the time of its release under this
     License is not already Covered Code governed by this License.

     1.10.1. "Patent Claims" means any patent claim(s), now owned or
     hereafter acquired, including without limitation,  method, process,
     and apparatus claims, in any patent Licensable by grantor.

     1.11. "Source Code" means the preferred form of the Covered Code for
     making modifications to it, including all modules it contains, plus
     any associated interface definition files, scripts used to control
     compilation and installation of an Executable, or source code
     differential comparisons against either the Original Code or another
     well known, available Covered Code of the Contributor's choice. The
     Source Code can be in a compressed or archival form, provided the
     appropriate decompression or de-archiving software is widely available
     for no charge.

     1.12. "You" (or "Your")  means an individual or a legal entity
     exercising rights under, and complying with all of the terms of, this
     License or a future version of this License issued under Section 6.1.
     For legal entities, "You" includes any entity which controls, is
     controlled by, or is under common control with You. For purposes of
     this definition, "control" means (a) the power, direct or indirect,
     to cause the direction or management of such entity, whether by
     contract or otherwise, or (b) ownership of more than fifty percent
     (50%) of the outstanding shares or beneficial ownership of such
     entity.

2. Source Code License.

     2.1. The Initial Developer Grant.
     The Initial Developer hereby grants You a world-wide, royalty-free,
     non-exclusive license, subject to third party intellectual property
     claims:
          (a)  under intellectual property rights (other than patent or
          trademark) Licensable by Initial Developer to use, reproduce,
          modify, display, perform, sublicense and distribute the Original
          Code (or portions thereof) with or without Modifications, and/or
          as part of a Larger Work; and

          (b) under Patents Claims infringed by the making, using or
          selling of Original Code, to make, have made, use, practice,
          sell, and offer for sale, and/or otherwise dispose of the
          Original Code (or portions thereof).

          (c) the licenses granted in this Section 2.1(a) and (b) are
          effective on the date Initial Developer first distributes
          Original Code under the terms of this License.

          (d) Notwithstanding Section 2.1(b) above, no patent license is
          granted: 1) for code that You delete from the Original Code; 2)
          separate from the Original Code;  or 3) for infringements caused
          by: i) the modification of the Original Code or ii) the
          combination of the Original Code with other software or devices.

     2.2. Contributor Grant.
     Subject to third party intellectual property claims, each Contributor
     hereby grants You a world-wide, royalty-free, non-exclusive license

          (a)  under intellectual property rights (other than patent or
          trademark) Licensable by Contributor, to use, reproduce, modify,
          display, perform, sublicense and distribute the Modifications
          created by such Contributor (or portions thereof) either on an
          unmodified basis, with other Modifications, as Covered Code
          and/or as part of a Larger Work; and

          (b) under Patent Claims infringed by the making, using, or
          selling of  Modifications made by that Contributor either alone
          and/or in combination with its Contributor Version (or portions
          of such combination), to make, use, sell, offer for sale, have
          made, and/or otherwise dispose of: 1) Modifications made by that
          Contributor (or portions thereof); and 2) the combination of
          Modifications made by that Contributor with its Contributor
          Version (or portions of such combination).

          (c) the licenses granted in Sections 2.2(a) and 2.2(b) are
          effective on the date Contributor first makes Commercial Use of
          the Covered Code.

          (d)    Notwithstanding Section 2.2(b) above, no patent license is
          granted: 1) for any code that Contributor has deleted from the
          Contributor Version; 2)  separate from the Contributor Version;
          3)  for infringements caused by: i) third party modifications of
          Contributor Version or ii)  the combination of Modifications made
          by that Contributor with other software  (except as part of the
          Contributor Version) or other devices; or 4) under Patent Claims
          infringed by Covered Code in the absence of Modifications made by
          that Contributor.

3. Distribution Obligations.

     3.1. Application of License.
     The Modifications which You create or to which You contribute are
     governed by the terms of this License, including without limitation
     Section 2.2. The Source Code version of Covered Code may be
     distributed only under the terms of this License or a future version
     of this License released under Section 6.1, and You must include a
     copy of this License with every copy of the Source Code You
     distribute. You may not offer or impose any terms on any Source Code
     version that alters or restricts the applicable version of this
     License or the recipients' rights hereunder. However, You may include
     an additional document offering the additional rights described in
     Section 3.5.

     3.2. Availability of Source Code.
     Any Modification which You create or to which You contribute must be
     made available in Source Code form under the terms of this License
     either on the same media as an Executable version or via an accepted
     Electronic Distribution Mechanism to anyone to whom you made an
     Executable version available; and if made available via Electronic
     Distribution Mechanism, must remain available for at least twelve (12)
     months after the date it initially became available, or at least six
     (6) months after a subsequent version of that particular Modification
     has been made available to such recipients. You are responsible for
     ensuring that the Source Code version remains available even if the
     Electronic Distribution Mechanism is maintained by a third party.

     3.3. Description of Modifications.
     You must cause all Covered Code to which You contribute to contain a
     file documenting the changes You made to create that Covered Code and
     the date of any change. You must include a prominent statement that
     the Modification is derived, directly or indirectly, from Original
     Code provided by the Initial Developer and including the name of the
     Initial Developer in (a) the Source Code, and (b) in any notice in an
     Executable version or related documentation in which You describe the
     origin or ownership of the Covered Code.

     3.4. Intellectual Property Matters
          (a) Third Party Claims.
          If Contributor has knowledge that a license under a third party's
          intellectual property rights is required to exercise the rights
          granted by such Contributor under Sections 2.1 or 2.2,
          Contributor must include a text file with the Source Code
          distribution titled "LEGAL" which describes the claim and the
          party making the claim in sufficient detail that a recipient will
          know whom to contact. If Contributor obtains such knowledge after
          the Modification is made available as described in Section 3.2,
          Contributor shall promptly modify the LEGAL file in all copies
          Contributor makes available thereafter and shall take other steps
          (such as notifying appropriate mailing lists or newsgroups)
          reasonably calculated to inform those who received the Covered
          Code that new knowledge has been obtained.

          (b) Contributor APIs.
          If Contributor's Modifications include an application programming
          interface and Contributor has knowledge of patent licenses which
          are reasonably necessary to implement that API, Contributor must
          also include this information in the LEGAL file.

               (c)    Representations.
          Contributor represents that, except as disclosed pursuant to
          Section 3.4(a) above, Contributor believes that Contributor's
          Modifications are Contributor's original creation(s) and/or
          Contributor has sufficient rights to grant the rights conveyed by
          this License.

     3.5. Required Notices.
     You must duplicate the notice in Exhibit A in each file of the Source
     Code.  If it is not possible to put such notice in a particular Source
     Code file due to its structure, then You must include such notice in a
     location (such as a relevant directory) where a user would be likely
     to look for such a notice.  If You created one or more Modification(s)
     You may add your name as a Contributor to the notice described in
     Exhibit A.  You must also duplicate this License in any documentation
     for the Source Code where You describe recipients' rights or ownership
     rights relating to Covered Code.  You may choose to offer, and to
     charge a fee for, warranty, support, indemnity or liability
     obligations to one or more recipients of Covered Code. However, You
     may do so only on Your own behalf, and not on behalf of the Initial
     Developer or any Contributor. You must make it absolutely clear than
     any such warranty, support, indemnity or liability obligation is
     offered by You alone, and You hereby agree to indemnify the Initial
     Developer and every Contributor for any liability incurred by the
     Initial Developer or such Contributor as a result of warranty,
     support, indemnity or liability terms You offer.

     3.6. Distribution of Executable Versions.
     You may distribute Covered Code in Executable form only if the
     requirements of Section 3.1-3.5 have been met for that Covered Code,
     and if You include a notice stating that the Source Code version of
     the Covered Code is available under the terms of this License,
     including a description of how and where You have fulfilled the
     obligations of Section 3.2. The notice must be conspicuously included
     in any notice in an Executable version, related documentation or
     collateral in which You describe recipients' rights relating to the
     Covered Code. You may distribute the Executable version of Covered
     Code or ownership rights under a license of Your choice, which may
     contain terms different from this License, provided that You are in
     compliance with the terms of this License and that the license for the
     Executable version does not attempt to limit or alter the recipient's
     rights in the Source Code version from the rights set forth in this
     License. If You distribute the Executable version under a different
     license You must make it absolutely clear that any terms which differ
     from this License are offered by You alone, not by the Initial
     Developer or any Contributor. You hereby agree to indemnify the
     Initial Developer and every Contributor for any liability incurred by
     the Initial Developer or such Contributor as a result of any such
     terms You offer.

     3.7. Larger Works.
     You may create a Larger Work by combining Covered Code with other code
     not governed by the terms of this License and distribute the Larger
     Work as a single product. In such a case, You must make sure the
     requirements of this License are fulfilled for the Covered Code.

4. Inability to Comply Due to Statute or Regulation.

     If it is impossible for You to comply with any of the terms of this
     License with respect to some or all of the Covered Code due to
     statute, judicial order, or regulation then You must: (a) comply with
     the terms of this License to the maximum extent possible; and (b)
     describe the limitations and the code they affect. Such description
     must be included in the LEGAL file described in Section 3.4 and must
     be included with all distributions of the Source Code. Except to the
     extent prohibited by statute or regulation, such description must be
     sufficiently detailed for a recipient of ordinary skill to be able to
     understand it.

5. Application of this License.

     This License applies to code to which the Initial Developer has
     attached the notice in Exhibit A and to related Covered Code.

6. Versions of the License.

     6.1. New Versions.
     Netscape Communications Corporation ("Netscape") may publish revised
     and/or new versions of the License from time to time. Each version
     will be given a distinguishing version number.

     6.2. Effect of New Versions.
     Once Covered Code has been published under a particular version of the
     License, You may always continue to use it under the terms of that
     version. You may also choose to use such Covered Code under the terms
     of any subsequent version of the License published by Netscape. No one
     other than Netscape has the right to modify the terms applicable to
     Covered Code created under this License.

     6.3. Derivative Works.
     If You create or use a modified version of this License (which you may
     only do in order to apply it to code which is not already Covered Code
     governed by this License), You must (a) rename Your license so that
     the phrases "Mozilla", "MOZILLAPL", "MOZPL", "Netscape",
     "MPL", "NPL" or any confusingly similar phrase do not appear in your
     license (except to note that your license differs from this License)
     and (b) otherwise make it clear that Your version of the license
     contains terms which differ from the Mozilla Public License and
     Netscape Public License. (Filling in the name of the Initial
     Developer, Original Code or Contributor in the notice described in
     Exhibit A shall not of themselves be deemed to be modifications of
     this License.)

7. DISCLAIMER OF WARRANTY.

     COVERED CODE IS PROVIDED UNDER THIS LICENSE ON AN "AS IS" BASIS,
     WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING,
     WITHOUT LIMITATION, WARRANTIES THAT THE COVERED CODE IS FREE OF
     DEFECTS, MERCHANTABLE, FIT FOR A PARTICULAR PURPOSE OR NON-INFRINGING.
     THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE COVERED CODE
     IS WITH YOU. SHOULD ANY COVERED CODE PROVE DEFECTIVE IN ANY RESPECT,
     YOU (NOT THE INITIAL DEVELOPER OR ANY OTHER CONTRIBUTOR) ASSUME THE
     COST OF ANY NECESSARY SERVICING, REPAIR OR CORRECTION. THIS DISCLAIMER
     OF WARRANTY CONSTITUTES AN ESSENTIAL PART OF THIS LICENSE. NO USE OF
     ANY COVERED CODE IS AUTHORIZED HEREUNDER EXCEPT UNDER THIS DISCLAIMER.

8. TERMINATION.

     8.1.  This License and the rights granted hereunder will terminate
     automatically if You fail to comply with terms herein and fail to cure
     such breach within 30 days of becoming aware of the breach. All
     sublicenses to the Covered Code which are properly granted shall
     survive any termination of this License. Provisions which, by their
     nature, must remain in effect beyond the termination of this License
     shall survive.

     8.2.  If You initiate litigation by asserting a patent infringement
     claim (excluding declatory judgment actions) against Initial Developer
     or a Contributor (the Initial Developer or Contributor against whom
     You file such action is referred to as "Participant")  alleging that:

     (a)  such Participant's Contributor Version directly or indirectly
     infringes any patent, then any and all rights granted by such
     Participant to You under Sections 2.1 and/or 2.2 of this License
     shall, upon 60 days notice from Participant terminate prospectively,
     unless if within 60 days after receipt of notice You either: (i)
     agree in writing to pay Participant a mutually agreeable reasonable
     royalty for Your past and future use of Modifications made by such
     Participant, or (ii) withdraw Your litigation claim with respect to
     the Contributor Version against such Participant.  If within 60 days
     of notice, a reasonable royalty and payment arrangement are not
     mutually agreed upon in writing by the parties or the litigation claim
     is not withdrawn, the rights granted by Participant to You under
     Sections 2.1 and/or 2.2 automatically terminate at the expiration of
     the 60 day notice period specified above.

     (b)  any software, hardware, or device, other than such Participant's
     Contributor Version, directly or indirectly infringes any patent, then
     any rights granted to You by such Participant under Sections 2.1(b)
     and 2.2(b) are revoked effective as of the date You first made, used,
     sold, distributed, or had made, Modifications made by that
     Participant.

     8.3.  If You assert a patent infringement claim against Participant
     alleging that such Participant's Contributor Version directly or
     indirectly infringes any patent where such claim is resolved (such as
     by license or settlement) prior to the initiation of patent
     infringement litigation, then the reasonable value of the licenses
     granted by such Participant under Sections 2.1 or 2.2 shall be taken
     into account in determining the amount or value of any payment or
     license.

     8.4.  In the event of termination under Sections 8.1 or 8.2 above,
     all end user license agreements (excluding distributors and resellers)
     which have been validly granted by You or any distributor hereunder
     prior to termination shall survive termination.

9. LIMITATION OF LIABILITY.

     UNDER NO CIRCUMSTANCES AND UNDER NO LEGAL THEORY, WHETHER TORT
     (INCLUDING NEGLIGENCE), CONTRACT, OR OTHERWISE, SHALL YOU, THE INITIAL
     DEVELOPER, ANY OTHER CONTRIBUTOR, OR ANY DISTRIBUTOR OF COVERED CODE,
     OR ANY SUPPLIER OF ANY OF SUCH PARTIES, BE LIABLE TO ANY PERSON FOR
     ANY INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES OF ANY
     CHARACTER INCLUDING, WITHOUT LIMITATION, DAMAGES FOR LOSS OF GOODWILL,
     WORK STOPPAGE, COMPUTER FAILURE OR MALFUNCTION, OR ANY AND ALL OTHER
     COMMERCIAL DAMAGES OR LOSSES, EVEN IF SUCH PARTY SHALL HAVE BEEN
     INFORMED OF THE POSSIBILITY OF SUCH DAMAGES. THIS LIMITATION OF
     LIABILITY SHALL NOT APPLY TO LIABILITY FOR DEATH OR PERSONAL INJURY
     RESULTING FROM SUCH PARTY'S NEGLIGENCE TO THE EXTENT APPLICABLE LAW
     PROHIBITS SUCH LIMITATION. SOME JURISDICTIONS DO NOT ALLOW THE
     EXCLUSION OR LIMITATION OF INCIDENTAL OR CONSEQUENTIAL DAMAGES, SO
     THIS EXCLUSION AND LIMITATION MAY NOT APPLY TO YOU.

10. U.S. GOVERNMENT END USERS.

     The Covered Code is a "commercial item," as that term is defined in
     48 C.F.R. 2.101 (Oct. 1995), consisting of "commercial computer
     software" and "commercial computer software documentation," as such
     terms are used in 48 C.F.R. 12.212 (Sept. 1995). Consistent with 48
     C.F.R. 12.212 and 48 C.F.R. 227.7202-1 through 227.7202-4 (June 1995),
     all U.S. Government End Users acquire Covered Code with only those
     rights set forth herein.

11. MISCELLANEOUS.

     This License represents the complete agreement concerning subject
     matter hereof. If any provision of this License is held to be
     unenforceable, such provision shall be reformed only to the extent
     necessary to make it enforceable. This License shall be governed by
     California law provisions (except to the extent applicable law, if
     any, provides otherwise), excluding its conflict-of-law provisions.
     With respect to disputes in which at least one party is a citizen of,
     or an entity chartered or registered to do business in the United
     States of America, any litigation relating to this License shall be
     subject to the jurisdiction of the Federal Courts of the Northern
     District of California, with venue lying in Santa Clara County,
     California, with the losing party responsible for costs, including
     without limitation, court costs and reasonable attorneys' fees and
     expenses. The application of the United Nations Convention on
     Contracts for the International Sale of Goods is expressly excluded.
     Any law or regulation which provides that the language of a contract
     shall be construed against the drafter shall not apply to this
     License.

12. RESPONSIBILITY FOR CLAIMS.

     As between Initial Developer and the Contributors, each party is
     responsible for claims and damages arising, directly or indirectly,
     out of its utilization of rights under this License and You agree to
     work with Initial Developer and Contributors to distribute such
     responsibility on an equitable basis. Nothing herein is intended or
     shall be deemed to constitute any admission of liability.

13. MULTIPLE-LICENSED CODE.

     Initial Developer may designate portions of the Covered Code as
     "Multiple-Licensed".  "Multiple-Licensed" means that the Initial
     Developer permits you to utilize portions of the Covered Code under
     Your choice of the NPL or the alternative licenses, if any, specified
     by the Initial Developer in the file described in Exhibit A.

EXHIBIT A -Mozilla Public License.

     ``The contents of this file are subject to the Mozilla Public License
     Version 1.1 (the "License"); you may not use this file except in
     compliance with the License. You may obtain a copy of the License at
     http://www.mozilla.org/MPL/

     Software distributed under the License is distributed on an "AS IS"
     basis, WITHOUT WARRANTY OF ANY KIND, either express or implied. See the
     License for the specific language governing rights and limitations
     under the License.

     The Original Code is ______________________________________.

     The Initial Developer of the Original Code is ________________________.
     Portions created by ______________________ are Copyright (C) ______
     _______________________. All Rights Reserved.

     Contributor(s): ______________________________________.

     Alternatively, the contents of this file may be used under the terms
     of the _____ license (the  "[___] License"), in which case the
     provisions of [______] License are applicable instead of those
     above.  If you wish to allow use of your version of this file only
     under the terms of the [____] License and not to allow others to use
     your version of this file under the MPL, indicate your decision by
     deleting  the provisions above and replace  them with the notice and
     other provisions required by the [___] License.  If you do not delete
     the provisions above, a recipient may use your version of this file
     under either the MPL or the [___] License."

     [NOTE: The text of this Exhibit A may differ slightly from the text of
     the notices in the Source Code files of the Original Code. You should
     use the text of this Exhibit A rather than the text found in the
     Original Code Source Code for Your Modifications.]

     ----------------------------------------------------------------------

     AMENDMENTS

     The Netscape Public License Version 1.1 ("NPL") consists of the
     Mozilla Public License Version 1.1 with the following Amendments,
     including Exhibit A-Netscape Public License.  Files identified with
     "Exhibit A-Netscape Public License" are governed by the Netscape
     Public License Version 1.1.

     Additional Terms applicable to the Netscape Public License.
          I. Effect.
          These additional terms described in this Netscape Public
          License -- Amendments shall apply to the Mozilla Communicator
          client code and to all Covered Code under this License.

          II. "Netscape's Branded Code" means Covered Code that Netscape
          distributes and/or permits others to distribute under one or more
          trademark(s) which are controlled by Netscape but which are not
          licensed for use under this License.

          III. Netscape and logo.
          This License does not grant any rights to use the trademarks
          "Netscape", the "Netscape N and horizon" logo or the "Netscape
          lighthouse" logo, "Netcenter", "Gecko", "Java" or "JavaScript",
          "Smart Browsing" even if such marks are included in the Original
          Code or Modifications.

          IV. Inability to Comply Due to Contractual Obligation.
          Prior to licensing the Original Code under this License, Netscape
          has licensed third party code for use in Netscape's Branded Code.
          To the extent that Netscape is limited contractually from making
          such third party code available under this License, Netscape may
          choose to reintegrate such code into Covered Code without being
          required to distribute such code in Source Code form, even if
          such code would otherwise be considered "Modifications" under
          this License.

          V. Use of Modifications and Covered Code by Initial Developer.
               V.1. In General.
               The obligations of Section 3 apply to Netscape, except to
               the extent specified in this Amendment, Section V.2 and V.3.

               V.2. Other Products.
               Netscape may include Covered Code in products other than the
               Netscape's Branded Code which are released by Netscape
               during the two (2) years following the release date of the
               Original Code, without such additional products becoming
               subject to the terms of this License, and may license such
               additional products on different terms from those contained
               in this License.

               V.3. Alternative Licensing.
               Netscape may license the Source Code of Netscape's Branded
               Code, including Modifications incorporated therein, without
               such Netscape Branded Code becoming subject to the terms of
               this License, and may license such Netscape Branded Code on
               different terms from those contained in this License.

          VI. Litigation.
          Notwithstanding the limitations of Section 11 above, the
          provisions regarding litigation in Section 11(a), (b) and (c) of
          the License shall apply to all disputes relating to this License.

     EXHIBIT A-Netscape Public License.

          "The contents of this file are subject to the Netscape Public
          License Version 1.1 (the "License"); you may not use this file
          except in compliance with the License. You may obtain a copy of
          the License at http://www.mozilla.org/NPL/

          Software distributed under the License is distributed on an "AS
          IS" basis, WITHOUT WARRANTY OF ANY KIND, either express or
          implied. See the License for the specific language governing
          rights and limitations under the License.

          The Original Code is Mozilla Communicator client code, released
          March 31, 1998.

          The Initial Developer of the Original Code is Netscape
          Communications Corporation. Portions created by Netscape are
          Copyright (C) 1998-1999 Netscape Communications Corporation. All
          Rights Reserved.

          Contributor(s): ______________________________________.

          Alternatively, the contents of this file may be used under the
          terms of the _____ license (the "[___] License"), in which case
          the provisions of [______] License are applicable  instead of
          those above.  If you wish to allow use of your version of this
          file only under the terms of the [____] License and not to allow
          others to use your version of this file under the NPL, indicate
          your decision by deleting  the provisions above and replace  them
          with the notice and other provisions required by the [___]
          License.  If you do not delete the provisions above, a recipient
          may use your version of this file under either the NPL or the
          [___] License."

      *********************
      *********************
      *** SPECIAL NOTES ***
      *********************
      *********************
      *********************
      See The Directory Game\Mozilla\Patch For Specific Details
      No Changes except for adding external files and fixing one
      compliation error done to llmozlib.

********************************************************************
*  Directx Samples                                                 *
********************************************************************
The BigWorld client contains some modified directx sample code. This
code is allowed to be distributed. The main requirements when
distributing this code are:

ii.	Distribution Requirements.  For any Distributable Code you distribute, you must
* add significant primary functionality to it in your programs;
* require distributors and external end users to agree to terms that protect it at least as much as this agreement;
* display your valid copyright notice on your programs; and
* indemnify, defend, and hold harmless Microsoft from any claims,
including attorneys' fees, related to the distribution or use of your programs.
iii.	Distribution Restrictions.  You may not
* alter any copyright, trademark or patent notice in the Distributable Code;
* use Microsoft's trademarks in your programs' names or in a way that suggests your programs come from or are endorsed by Microsoft;
* distribute Distributable Code to run on a platform other than the Windows platform;
* include Distributable Code in malicious, deceptive or unlawful programs; or
* modify or distribute the source code of any Distributable Code so that any part of it becomes subject to an Excluded License.  An Excluded License is one that requires, as a condition of use, modification or distribution, that
* the code be disclosed or distributed in source code form; or
* others have the right to modify it.

see the complete DirectX SDK EULA for full details.

********************************************************************
*  Adobe Flash                                                     *
********************************************************************
Adobe Flash Player. Copyright 1996 - 2008. Adobe Systems Incorporated. All Rights Reserved.
Patents pending in the United States and other countries.
Adobe and Flash are either trademarks or registered trademarks in the United States and/or other countries.

***************************************************************************
* nedalloc                                                                *
***************************************************************************

Boost Software License - Version 1.0 - August 17th, 2003

Permission is hereby granted, free of charge, to any person or organization
obtaining a copy of the software and accompanying documentation covered by
this license (the "Software") to use, reproduce, display, distribute,
execute, and transmit the Software, and to prepare derivative works of the
Software, and to permit third-parties to whom the Software is furnished to
do so, all subject to the following:

The copyright notices in the Software and this entire statement, including
the above license grant, this restriction and the following disclaimer,
must be included in all copies of the Software, in whole or in part, and
all derivative works of the Software, unless such copies or derivative
works are solely in the form of machine-executable object code generated by
a source language processor.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE, TITLE AND NON-INFRINGEMENT. IN NO EVENT
SHALL THE COPYRIGHT HOLDERS OR ANYONE DISTRIBUTING THE SOFTWARE BE LIABLE
FOR ANY DAMAGES OR OTHER LIABILITY, WHETHER IN CONTRACT, TORT OR OTHERWISE,
ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
DEALINGS IN THE SOFTWARE.

***************************************************************************
* zip                                                                     *
***************************************************************************

Copyright notice:

 (C) 1995-2004 Jean-loup Gailly and Mark Adler

  This software is provided 'as-is', without any express or implied
  warranty.  In no event will the authors be held liable for any damages
  arising from the use of this software.

  Permission is granted to anyone to use this software for any purpose,
  including commercial applications, and to alter it and redistribute it
  freely, subject to the following restrictions:

  1. The origin of this software must not be misrepresented; you must not
     claim that you wrote the original software. If you use this software
     in a product, an acknowledgment in the product documentation would be
     appreciated but is not required.
  2. Altered source versions must be plainly marked as such, and must not be
     misrepresented as being the original software.
  3. This notice may not be removed or altered from any source distribution.

  Jean-loup Gailly        Mark Adler
  jloup@gzip.org          madler@alumni.caltech.edu

If you use the zlib library in a product, we would appreciate *not*
receiving lengthy legal documents to sign. The sources are provided
for free but without warranty of any kind.  The library has been
entirely written by Jean-loup Gailly and Mark Adler; it does not
include third-party code.

If you redistribute modified sources, we would appreciate that you include
in the file ChangeLog history information documenting your changes. Please
read the FAQ for more information on the distribution of modified source
versions.

***************************************************************************
* libpng                                                                  *
***************************************************************************

This copy of the libpng notices is provided for your convenience.  In case of
any discrepancy between this copy and the notices in the file png.h that is
included in the libpng distribution, the latter shall prevail.

COPYRIGHT NOTICE, DISCLAIMER, and LICENSE:

If you modify libpng you may insert additional notices immediately following
this sentence.

libpng versions 1.2.6, August 15, 2004, through 1.2.22, October 13, 2007, are
Copyright (c) 2004, 2006-2007 Glenn Randers-Pehrson, and are
distributed according to the same disclaimer and license as libpng-1.2.5
with the following individual added to the list of Contributing Authors

   Cosmin Truta

libpng versions 1.0.7, July 1, 2000, through 1.2.5 - October 3, 2002, are
Copyright (c) 2000-2002 Glenn Randers-Pehrson, and are
distributed according to the same disclaimer and license as libpng-1.0.6
with the following individuals added to the list of Contributing Authors

   Simon-Pierre Cadieux
   Eric S. Raymond
   Gilles Vollant

and with the following additions to the disclaimer:

   There is no warranty against interference with your enjoyment of the
   library or against infringement.  There is no warranty that our
   efforts or the library will fulfill any of your particular purposes
   or needs.  This library is provided with all faults, and the entire
   risk of satisfactory quality, performance, accuracy, and effort is with
   the user.

libpng versions 0.97, January 1998, through 1.0.6, March 20, 2000, are
Copyright (c) 1998, 1999 Glenn Randers-Pehrson, and are
distributed according to the same disclaimer and license as libpng-0.96,
with the following individuals added to the list of Contributing Authors:

   Tom Lane
   Glenn Randers-Pehrson
   Willem van Schaik

libpng versions 0.89, June 1996, through 0.96, May 1997, are
Copyright (c) 1996, 1997 Andreas Dilger
Distributed according to the same disclaimer and license as libpng-0.88,
with the following individuals added to the list of Contributing Authors:

   John Bowler
   Kevin Bracey
   Sam Bushell
   Magnus Holmgren
   Greg Roelofs
   Tom Tanner

libpng versions 0.5, May 1995, through 0.88, January 1996, are
Copyright (c) 1995, 1996 Guy Eric Schalnat, Group 42, Inc.

For the purposes of this copyright and license, "Contributing Authors"
is defined as the following set of individuals:

   Andreas Dilger
   Dave Martindale
   Guy Eric Schalnat
   Paul Schmidt
   Tim Wegner

The PNG Reference Library is supplied "AS IS".  The Contributing Authors
and Group 42, Inc. disclaim all warranties, expressed or implied,
including, without limitation, the warranties of merchantability and of
fitness for any purpose.  The Contributing Authors and Group 42, Inc.
assume no liability for direct, indirect, incidental, special, exemplary,
or consequential damages, which may result from the use of the PNG
Reference Library, even if advised of the possibility of such damage.

Permission is hereby granted to use, copy, modify, and distribute this
source code, or portions hereof, for any purpose, without fee, subject
to the following restrictions:

1. The origin of this source code must not be misrepresented.

2. Altered versions must be plainly marked as such and must not
   be misrepresented as being the original source.

3. This Copyright notice may not be removed or altered from any
   source or altered source distribution.

The Contributing Authors and Group 42, Inc. specifically permit, without
fee, and encourage the use of this source code as a component to
supporting the PNG file format in commercial products.  If you use this
source code in a product, acknowledgment is not required but would be
appreciated.

A "png_get_copyright" function is available, for convenient use in "about"
boxes and the like:

   printf("%s",png_get_copyright(NULL));

Also, the PNG logo (in PNG format, of course) is supplied in the
files "pngbar.png" and "pngbar.jpg (88x31) and "pngnow.png" (98x31).

Libpng is OSI Certified Open Source Software.  OSI Certified Open Source is a
certification mark of the Open Source Initiative.

Glenn Randers-Pehrson
glennrp at users.sourceforge.net
October 13, 2007

***************************************************************************
* bsdiff                                                                  *
***************************************************************************

BigWorld Technology includes code derived from the bsdiff binary diff/patch
utility developed by Colin Percival. As per the licensing requirements, the
copyright notice and licensing conditions are reproduced below.

Copyright 2003-2005 Colin Percival

All rights reserved.

Redistribution and use in source and binary forms, with or without
modification, are permitted providing that the following conditions are
met:

  * Redistributions of source code must retain the above copyright
  notice, this list of conditions and the following disclaimer.

  * Redistributions in binary form must reproduce the above
  copyright notice, this list of conditions and the following
  disclaimer in the documentation and/or other materials provided with
  the distribution.

THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS
OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
DISCLAIMED. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT,
INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
(INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN
ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
POSSIBILITY OF SUCH DAMAGE.


BigWorld Technology External Libraries Licensing Issues

The BigWorld Technology incorporates multiple external libraries, each under their own licence. In order to comply with the different licensing requirements of these libraries the following files are provided:

  • The development_and_deployment_licensing.txt file contain licence agreements of external libraries included in the BigWorld server, server tools and client tools components.

  • The game_client_licensing.txt file contains the licence agreements of external libraries included in the BigWorld game client. This file should also be included in the documentation and/or other materials provided with any game which is created by BigWorld customers based on the BigWorld client. If Adobe Flash is not redistributed, the Adobe Flash section should be removed from this file before redistribution.

Flash Licensing Considerations

The BigWorld Technology Evaluation version includes the Adobe Flash Player component. This component is used to show Flash content as part of the evaluation version. Redistribution of the Flash Player component is done based on a licence coordinated with Adobe. Customers wishing to redistribute Adobe Flash Player should coordinate a similar licence using http://www.adobe.com/products/players/fpsh_distribution1.html or instead make sure their installer links to a page allowing to install Flash Player for Firefox (plugin based).

Following is the Flash Player Copyright:

********************************************************************
*  Adobe Flash                                                     *
********************************************************************
Adobe Flash Player. Copyright 1996 - 2008. Adobe Systems Incorporated. All Rights Reserved.
Patents pending in the United States and other countries.
Adobe and Flash are either trademarks or registered trademarks in the United States and/or other countries.

Use of Art Content Provided by BigWorld

Included in your BigWorld Technology package are art assets used to build the demonstration worlds. This includes models, textures, animations and particle systems. Most of these assets, but not all, are owned by BigWorld and can be freely used in any BigWorld Technology games created under license, and are provided as is, with no warranties as to their fitness or usability.

As a guideline only, assets in the following BigWorld Technology Demo spaces are copyrighted by BigWorld and are available for use under license:

  • Highlands (with the exception of art assets included in the OF3D house - these are owned by Original Force 3D, and use of those assets must be negotiated by the licence owner)

  • Urban (with the exception of some of the Art assets documented below)

  • Arctic

  • Desert

Assets not owned by BigWorld include:

  • All assets used to create the space "Exigent" - these are owned by Exigent, and use of those assets must be negotiated by the licence owner.

  • All assets included in the OF3D house in the Highlands space - these are owned by Original Force 3D, and use of those assets must be negotiated by the licence owner.

  • The following Urban assets:

    • fantasydemo/res/sets/urban/props/buildings/b_brownstone/model/b_brownstone_ground.model
    • fantasydemo/res/sets/urban/props/buildings/b_brownstone/model/b_brownstone_roof.model
    • fantasydemo/res/sets/urban/props/buildings/b_brownstone/model/b_brownstone_storey.model
    • fantasydemo/res/sets/urban/props/vehicles/car_charger/models/car_charger.model
    • fantasydemo/res/sets/urban/props/vehicles/car_charger/models/car_charger_lod01.model
    • fantasydemo/res/sets/urban/props/vehicles/car_convertible/models/car_convertible.model
    • fantasydemo/res/sets/urban/props/vehicles/car_convertible/models/car_convertible_lod01.model
    • fantasydemo/res/sets/urban/props/vehicles/car_toyota/models/car_toyota.model
    • fantasydemo/res/sets/urban/props/vehicles/car_toyota/models/car_toyota_lod01.model
    • fantasydemo/res/sets/urban/props/vehicles/car_vectra/models/car_vectra.model
    • fantasydemo/res/sets/urban/props/vehicles/car_vectra/models/car_vectra_lod01.model
    • fantasydemo/res/sets/urban/props/vehicles/truck/truck.model

MySQL Licensing Considerations

Customers installing the server with a MySQL database should consider purchasing a MySQL licence. Please review the licensing information at www.mysql.com for more details.

FMOD Licensing Considerations

BigWorld Technology includes the fmod audio library. Licensing considerations for this library should be coordinated with Firelight Technologies shortly before going live. See the fmod web site fmod for more details.