Mesh Compositing in Unreal Engine 3

blastpointslogo

BlastPoints

Mesh Combining and Composite Textures in UE3

Document created by Chad Mulroney

Version 1.0 Revision 2. 20/03/2012

[The following document constitutes the process and procedure for the development and deployment of art and visual game artifacts for BlastPoints. Its contents are subject to change.]

 

1.     Mesh Combination

What is Mesh Combination?

Mesh combination is a feature in the Unreal Engine that allows for the combination of a collection of meshes to create a new geometry. The key feature is the ability to create new meshes in real time within the game.

Why are we using it for BlastPoints?

Mesh combination in Unreal increases render efficiency in the game. It results in a fewer draw calls over alternative methods.

How are we using it for BlastPoints?

We will be using Mesh Combination to construct unique player ships from various meshes during runtime. A player ship will have:

  • 1 Main body mesh
  • 1 Engine mesh attached twice
  • 1 Primary Weapon attached twice
  • 1 Secondary Weapon attached twice

A player will be able to customise a ship and swap out engines/weapons as they see fit.

Requirements for combining meshes

Source mesh requirements [UDN]

  • The bone hierarchies for all of the source meshes must match
  • Make sure that there is minimal overlap between the source skeletal mesh pieces
  • LOD levels are also merged, but only up to the highest LOD level common to all source meshes
  • The mesh origins and rotation from each of the source meshes must match
  • Sockets must match
  • Mirror table must match

The Rig

Each playership and attachable mesh component need to have the same rig.

The rig we will be using has ’20’ Bones as shown in Figure 1.

figure01

Figure 1: The Complete Playership Rig

The following section applies only to the bones in Figure 2.

When the ship is brought into the engine and loaded up for game the weapon and engine bones will then be moved into place through an idle animation. The idle animation for each ship will need to be made on a ship by ship basis by the person modelling/rigging the ship.

NOTE: When the ship is exported for use in the game the key bones in the rig MUST be in the default position. They will be animated into place using the idle animation you create when they are loaded up.

figure02

Figure 2: Key Bones

B_Root

 B_Engine_POS_L

 B_Engine_POS_R

 B_Engine_ROT_L

 B_Engine_ROT_R

 B_Secondary_POS_L

 B_Secondary_POS_R

 B_Secondary_ROT_L

 B_Secondary_ROT_R

 B_Primary_POS_L

 B_Primary_POS_R

 B_ Primary _ROT_L

 B_ Primary _ROT_R

We have two bones per attachment and a Root bone. The attachments have one bone for translation and another for rotation. We can resize the bones as we needed to match the location and direction of attachment points but this must be done through an animation. When we export the ship or attachment mesh it will need to be in the default position as per the following image.

figure03

Figure 3: Sample ship showing the skeletal rig in the default position.

The 3D artist will need to create an animation that moves the bones into their appropriate positions for the ship they are working on. The following image shows the result of the animation to position the bones

figure04

Figure 4: Result of an animation to position the bones to the appropriate points on the Playership

The bones are now in the position they will be in for gameplay. There are attachment points for two each of Engine Components, Secondary Weapon Components, and Primary Weapon Components.

NOTE: It is important to ensure that the pivot points for all the attachment bones are identically aligned with reference to the world space. Failure to do this will result in attachments being misaligned to the ship when animated into position.

 

Figure 3 is an example of the rig post animation showing the positions of each of the Mesh components. The components will be attached to the rig separately as needed. That will be covered in more detail later on.

To summarise, each Playership base mesh must have the following:

  • Correctly named and positioned default skeletal rig
  • Idle Animation for moving the key bones into the appropriate position.
  • Correctly aligned pivot points.
figure05

Figure 5: Top down view of the Rig showing the location of the component attachment points

Each of the Component Meshes will need to have the same rig as the base mesh. Take for example an engine mesh. Figure 6 shows a basic engine mesh attached to the ‘B_Engine_ROT_L’ and ‘B_Engine_ROT_R’ bones. All Attachment meshes will need to be exported with the Playership rig in the default position (As was the case with the Playership base mesh). They will then be animated into position via their own idle animation at runtime as shown by Figure 7.

figure06

Figure 6: Engine mesh component shown in the default position

figure07

Figure 7: Completed idle animation showing engine mesh in place.

figure08

Figure 8: Completed idle animation showing two engine meshes attached in one place.

2.     Composite Textures

What are Composite Textures?

Once you have combined meshes, composite textures allow the texture samples for the various meshes that were combined to be put into a single texture, reducing it to a single draw call.

To allow this to work, the source textures need to be set up in a particular way, which is explained and detailed below.

figure09

Figure 9: Composite texture showing division

You can see that the texture space has been divided into two areas, one for the Lolly and one for the Stick. Now if we have 10 different Lolly textures and 10 different stick textures then we have 100 different texture combinations. If we made 100 unique textures then our memory usage would increase. If we decided to split our lollipop into two textures, then we would have to store two textures at run time which increases overhead. Instead we can use a single composite texture.

figure10

Figure 10: A complete Lollipop texture.

The above texture is a single 512×512 stored in memory. Using the composite texture feature in Unreal allows us to modify a texture during run time by swapping out various areas of the texture. This allows us a greater level of flexibility as it means that rather than storing 100 complete lollipop textures, we only need the 10 lolly components and the 10 stick components.

figure11a figure11b figure11c figure11d

Figure 11: Two different Lolly and stick textures

The above images represent two of the ten component textures for the Lollipop. When creating our composite texture we can use any combination of Lolly and Stick (one Stick and one Lolly) to create the single composite texture. This texture can then be applied to the mesh in the usual fashion.

Why are we using them for BlastPoints?

The use of composite textures allows us to save memory overhead in the form of draw calls. More importantly, it allows us to do this while maintaining a high level of customisable content and texture detail. The Lollipop example was a very simple one. If scaled the benefits would become more apparent. For BlastPoints we will be using composite textures with mesh combining to allow for a potentially unlimited combination of weapons and engines for a player ship.

figure11a

How are we using them for BlastPoints?

We are using composite textures for the Playership meshes as these will be fully customisable by the player. We will also be using the Material channels available to us in the Unreal Engine in the following way:

Diffuse:

The Diffuse map is the primary texture for the ship. It will need to be rendered out at 2048×2048. We can scale it down from there as needed.

Normal:

A normal map will need to be created for each ship. The normal map needs to be baked out at 2048×2048. We can scale this back as needed.

Emissive:

Emissive mask. The emissive colour will be decided by using a Universal Colour Texture

Mask:

A specular map will need to be made and rendered out at 2048×2048. This will be assigned to the specular channel within UE3.Alternatively we could just use the R,G or B channel to pop out a spec.

Universal Colour Textures:

To allow us to easily change out the emissive colours for the ship and any attachments, we will need a collection of 4×4 textures of different colours. These can then be sized up as needed providing they are not dithered or interlaced.

texturemaps

Requirements for creating source Textures

Source texture requirements [UDN]

Because there is no format conversion or scaling that occurs and the source texture data is copied directly into the mips of the composite texture, there are certain restrictions for the set of source textures:

  • Source textures must be the same size (width,height)
  • Source textures muse be of the same format
  • There should be no overlap in the regions specified, and you should make sure that the regions fill the entire surface
  • Currently only supported on non streamable textures. Set NeverStream=True for each of the source textures
  • If LODBias is used then the lowest available mip level common to all source textures is used

Player ship base texture

The entire texture space is 2048×2048.

figure12

Figure 12: Proposed texture division

It is very important to ensure that you are creating your textures within the bounds of the divided texture space. If you are creating a Primary weapon mesh then the UV’S MUST be within the allocated Primary Weapon Space. When creating the texture for the mesh components they must all be rendered out at the same resolution as the base texture.

figure13

Figure 13: Ship texture space (TR=0)

figure14

Figure 14:Engines texture space (TR=1)

figure15

Figure 15: Primary weapon texture space (TR=2)

figure16

Figure 16: Secondary weapon texture space (TR=3)

The white areas in figures 11 through 15 represent the usable texture area for each of the different mesh component types. Any area that is not used for a component mesh texture should be black.