Asset files

Art Practices

Naming conventions

Basic asset naming

base name

Use short, descriptive names for the base name. Also, use a capital letter for the first letter of a word, and don�t put an underscore between words. Names like Lantern, FootBridge, and Canteen work well.

variations

Assets that have multiple variations should have the same base name. The name should then be followed by an underscore and either a descriptive word or a number. You should use a descriptive word when the assets are significantly qualitatively different and use numbers when the variation is minor (textural or geometric change). For example, you might have two versions of a bucket, a wood one and a metal one. The geometry and the texture are different on the two versions. In this case you would call them Bucket_Wood and Bucket_Metal. And if you had a barrel that had a couple of variations that only involved a texture swap, you could call them Barrel_01, Barrel_02, and Barrel_03. You can also use Lg, Md, and Sm for large, medium, and small as a variation designation.

national designation

With assets that it is important that they belong to either the U.S. or Japan, use an underscore and either US or JP.

shorthand

US � U.S.

JP � Japan

Lg, Md, Sm � large, medium, and small

the underscore

The underscore should be used only to separate the base name, nation designation, and any variation designations. The underscore should not be used within a base name. This way the underscore is meaningful and not just used willy nilly.

order

The order for the naming is this: Name_Nation_Variation

A few more suffixes

Destroyed versions of textures

If you have a plane or something that gets destroyed, it will need a second texture. In those cases, just add an �_d� to the end of the name of the texture. For example: Kate.tga and Kate_d.tga. Note that there should only be 1 gr2 for a vehicle that gets destroyed. That gr2 will have a second renderable that is the destroyed version. But there will be 2 textures: the regular version and the destroyed version.

Normal maps

If you have something that uses a normal map, the normal map should have the same name as the texture it is based on, but with an �_nm� suffix. For example: Kate.tga, Kate_nm.tga, Kate_d.tga, and Kate_d_nm.tga.

Foliage asset naming

Foliage should use the same naming conventions as non-foliage assets, but should be preceded by the name of the folder it resides in. For example Tree_BigFluffy, or Bush_Spikey.

Cover asset naming

base name

Use short, descriptive names for the base name. Also, use a capital letter for the first letter of a word, and don�t put an underscore between words. Names like Rock, and Stump work well.

height specification

The following shorthand will be used:

H = hide: a minimum of 96 game units tall (1.92m)

This is something you will be completely covered by when you are standing behind it.

S = stand: a maximum of 72 game units tall (1.44m)

This is something you can stand behind and shoot over. If you crouch behind this, you will be covered.

C = crouch: a maximum of 40 game units tall (0.80m)

This is something you can crouch behind and shoot over. If you go prone behind this, you will be covered.

P = prone: a minimum of 15 game units tall (0.30m)

This is something that only provides any kind of cover when you�re prone.

Some cover objects will have combinations of 2 or more of these heights. Those can be specified by a series of height shorthand (H,S,C,P) separated by underscores. So you might have a rock that you could stand and shoot over half of it and crouch and shoot over the other half, and that would be written like this: Rock_S_C.

Rules for variations

If you have variations of the same cover object, just put the variation designation at the end just like regular assets. Using the same rock example, it would be: Rock_S_C_01 and Rock_S_C_02.

Moving or renaming assets

These rules have to be followed strictly or work will be lost!

Moving .gr2�s

When moving a .gr2, please consider the following:

A .hag file points to a directory of a .gr2

For instance models/test/test.hag has a line that says:

��

setup

{��

�� path models/test

�� skelmodel test.gr2

}

if we move test.gr2 to models/test/new/test.gr2 the test.hag WILL NO LONGER WORK, it points at the wrong directory!

Therefore if you move a .gr2� please look to see if it has a .hag file�if it does change the path in the .hag reflect� new directory.

Renaming

Redirect Radiant to the new location or name through the text file Game/main/data/RadiantMappings.txt. This is done by typing into the last line of the text file, the old path, a space, and the new path. The paths start at the �models� directory. For example:

models/common/manmade/sake_bottle.gr2 models/common/manmade/props/SakeBottle.gr2

In this example there was a move from the manmade folder to the manmade/props folder. There was also a name change from sake_bottle.gr2 to SakeBottle.gr2.

Collision Naming Conventions

For ease of use, name all collisions with the same name as the mesh they are the collision for plus an �_c�.

�� Examples:

�� Box

�� Box_c

�� Crate_chunk

�� Crate_chunk10_c

�� Tail_wing_rt_Version2_temp

�� Tail_wing_rt_Version2_temp_c

**if a mesh has multiple collisions follow the same convention, add an incrementing number BEFORE the �_c�

�� Examples:

�� Complex_box

�� Complex_box01_c

�� Complex_box02_c

�� Donut

�� Donut00001_c

�� Donut00002_c

�� Donut00003_c

UV practices

Sometimes we reuse texture space in order to get the most resolution out of our texture that we can. The only thing to be aware of when doing this is to keep from welding the overlapping uvs. Keep the uvs separate. For example, if you have a plane and you want to use the same texture space for both wings, you should be able to grab the uvs for one wing and drag them apart from the uvs for the other wing. The reason behind doing this is that it makes it easier to lightmap those objects. It�s true that you wouldn�t want to lightmap a plane in most cases, but it is a good practice to have so that you have the potential to lightmap any object easily.

MOHPA Material shadow map settings

It is important for lighting purposes to give a material the appropriate projected shadow map. That can be done through MilkShape�s material editor. When you create a new mohpa material, you have this setting to set:

The projected shadow map setting determines which shadows an object will receive. In MOHPA, we create these large sheets of shadows that cover the whole world. The lowest level shadow map is the one that goes on the terrain and a few objects that are meant to blend perfectly with the terrain. The next 3 layers apply to objects with different heights (bushes then trees then really tall trees).

Here are the guidelines to setting the shadow map properly:

shadowmap_terrain - Anything that would fill holes in the terrain or receive shadows from objects in shadowmap_1

shadowmap_1 - Anything less than the height of a man. These objects would not cast a shadow on the character

shadowmap_2 � Anything taller than a man, but lower than the tallest objects in a level. The range kind of depends. This would include the trunks of tall trees when the fronds or leaves of the trees are shadowmap 3 (only if the trunk is on a separate texture from the leaves already)

shadowmap_3 � These would be the tallest objects on a map. They cast shadows onto everything below them.

Instance vs. Unique Object Consideration

Typically, the team has been told �the fewer the textures, the better�. So, in response to this, bg artists have been forced to create large textures and strange geometry in order to tile the large textures. Point in case, the trenches in mission 5. This is not always the best solution.

�� Instanced objects should have as few textures as possible (usually only 1), because the vertex list is loaded up and then all the instances are rendered through in as few passes as possible. So, the more textures that are in the model, the more passes there are, or the slower they are, and that is generally not advised, due to there usually being a large volume of instanced models (i.e. bushes, rocks, etc).

�� Unique geometry, however, only draws the one time, and since it is only seen in a specific case, can make use of multiple textures, mirrored and tiled to achieve the same result, but with much less texture space, as well as a lot less modeling headache. This sounds like a lot of whatever, so here it is in pictorial form, using the trenches from mission 5.

Current trench:

badass.

Current trench textures:

This is a 1024x1024 texture�� This is a 512x512 texture

�� So, we can see that the trench model is taking that much space in memory (1024x1024 + 512x512). Since textures are our big problem, it would be better if these were used differently. By breaking up the textures and utilizing them differently, we can achieve similar results, without any breakdown in resolution, but with less memory usage and possibly, less geometry.

New trench textures:

128x256
256x256
128x256
128x256
256x256
512x256

So, here, we have the textures that comprise the new scene. Textures 2 and 5 tile against each other at all sides, and 3 and 4 line up to any side of 2 and 5 to create their edges. Here is the result:

�� weee

�� The geometry has been changed slightly to accommodate the new texture layout, but for the most part, things remain the same. The texture has been modified a little bit here and there, but since I did this awhile ago, I don�t remember exactly what and why. Now, due to the exporter still not supporting multi-sub objects at this point in time, objects must still be defined by materials, but I�m sure MSub support will be in soonish.

Anyways�

�� There are small differences in the visuals, but here is an idea of the memory usage:

holy communion batman!

The top two images are the old way of mapping, and the bottom right corner is the new way. Pretty big savings. Like, almost 75%. That makes programmers extra happy. This also gives us a little bit more room to use textures for other things. Provided we have the time. Never mind.

�� Anyways, I�m sure a lot of you have already figured stuff like this out and been wondering why we haven�t done this previously. I have no idea. There must have been some breakdown in communication.

Render Types

There are three render types in the MOHPA engine: normal, replicant, and compressed replicant. The render type is chosen for a gr2 in the model manager under base properties.

Normal should be chosen for unique objects or objects that there won�t be more than 5 or 6 of in a scene. For instanced objects, there are two choices: replicant and compressed replicant. Most instanced objects will be replicants. Replicants are treated differently than normal objects. The biggest difference is that when several of the same replicant are in the same view, the engine groups them together and treats them like 1 whole object instead of several small objects. This reduces the number of draw primitive calls dramatically. Compressed replicants are like replicants, but are more restricted in the features they can have. They can�t have procedural wind applied to them. They can�t be havok objects. They can�t have collision. Pretty much all they can do is just sit there. They are only used for decoration purposes.

�� So be sure to set your render type appropriately. It could mean great savings in the engine.