Content Creation Guidelines
From Leadwerks Developer Wiki
This article provides some information on how to get your assets into Leadwerks Engine 2.0.
Contents |
Tutorials
Tutorials worth reading concerning this topic:
Mesh Pipeline
The Leadwerks Engine SDK includes utilities to convert many 3D model formats to the proprietary gmf format. See Game Model Format for further information.
Other File Formats
Textures have to be converted to the .dds format (an image format specially designed for the holding texture and mip-maping data) for use with Leadwerks Engine. For RGB textures with no alpha maps you should always use DDS. DXTC1 compression. For textures with transparency (or normal maps with specular info encoded in the alpha channel) DXTC5 compression can be used. This will not produce as small of files, but can store alpha channel information. Make sure you always generate all mip-maps when converting textures. For images, you can also use uncompressed encodings.
Leadwerks .phy physics files store collision shapes and are created with the Phygen tool. These can be loaded as body entities using LoadBody and they're automatically loaded and assigned as a physics body if a mesh is loaded using LoadModel, if the .phy file has the same name is the mesh. If there's no .phy file available for a mesh loaded as a model, a static collision tree representing the mesh's geometry will be automatically created. See Models for further information.
For sounds and music, the WAV and OGG formats are supported. OGG supports dynamic bitrates, high compression rates with very low quality loss, high dynamic range, and streaming. For spatialized sounds (=3D positional sounds) in Leadwerks Engine, mono format must be used. Stereo format can be used for non-positional music and ambient soundtracks. OGG format can be created with the free audio editor Audacity for example.
Materials
The textures assigned to meshes in the 3D modeling application are only used to determine the name of the corresponding Material (.mat) file which will be used instead to describe the appearance of specified surfaces in the manners of textures, colors and shaders. See Materials for further information.
Model Scale
Because Leadwerks Sandbox uses a base-ten grid by default, and because the metric system makes measurements and aligning objects very simple, you should try to always use a base-ten number for dimensions of any object. This is not always possible, but dimensions like 1.5 or 0.1 are still always preferable to random numbers. This is especially important for sets of modular pieces that need to fit together in the editor.
You may wish to create a simple scene demonstrating use of your meshes. A simple "helper_human" file sized 1.8 units/m can be useful for getting an idea of the scale of things in Sandbox.
To make a realistic game it is important that the objects used in your game match the size of objects in the real-world. Unless you follow real-world sizes carefully your objects will start to look out of scale compared to each other. However, measurements in the real world, particular structures, do not always match our preferred system of base-ten measurements. It is acceptable to round commonly used measurements off to a base-ten number, in order to make content production more managable. Below are some recommended measurements to rely on.
Human male height = 1.8 meters Character collision radius = 0.4 meters Doorway = 1 x 2.1 meters Ceiling height = 2.5 meters Interior/thin wall thickness = 0.15 meters Exterior/thick wall thickness = 0.25 meters Stair rise = 0.25 meters (ten stairs to rise one floor) Stair run = 0.3 meters (length of staircase is 3 meters per floor) Stair case width = 1.5 meters
Naming
Leadwerks Sandbox categorizes meshes by a prefix, indicated as follows:
prefix_name.extension fence_post01.gmf
When more than one version of a mesh or texture are present, it is convenient to always use two digits to specify a version number, i.e. "fence_post02.gmf"(not "fence_post2.gmf"). This will reinforce consistency and avoid problems should additional versions of the item be added later. If two color variations of the same textures are present, add a letter to the end of each version and keep the same number, like so:
plaster_wall03a.dds plaster_wall03b.dds
Source files should always match final file names, except in the case where one source file is used to export multiple versions of the same item. For example:
fence_segment_large.max fence_segment_large.u3d fence_segment_large.gmf
fence_post.max fence_post.u3d fence_post01.gmf fence_post02.gmf
Normal maps should be named the same as the diffuse texture, with the suffix "dot3" added. For example:
concretewall01.dds concretewall01dot3.dds
When two diffuse textures use the same normal map, naming should be as follows:
fence_post01.dds fence_post02.dds fence_postdot3.dds
These are not strict rules the engine enforces, but rather suggestions for maintaining consistency.
Asset Distribution
Always include all source files used in a zip file named "source.zip". This includes original .max or other files, .u3d files used during conversion (if applicable), as well as any photoshop or other image files used to make the final DDS textures. Also include any OBJ files used to generate PHY collision files. Make sure all source file names match the final file names. When you look at the package again in three months, you will be glad you did. It is worth including all source files even if you make frequent backups of your work. Later on it will be difficult to find the source files on your hard drive, or on archive CDs, and even when you do you won't be sure which version of the source file matches the final media you produced. Saving all files together in one package can eliminate a lot of confusion.
Package the folder up into a zip file with a descriptive name, usually the prefix used in the file naming, and rename the file extension to PAK. Leadwerks Engine will load the files straight from the compressed archive without ever having to extract the contents to the hard drive.
Before deleting your original files, try extracting a file from the source.zip file in the pak archive, just to make sure no files were corrupted during compression. It is unlikely this will happen, but it's worth making sure you don't lose all your hard work.
It is also nice to include a screenshot of your content to show what it should look like.
Finally, include a readme.txt text file including information on the author(s), revision number, contact info, and license terms.
