Art Workflow 3D

From DungeonHack

This is a WIP draft of instructions for the 3D art asset workflow.

Here is an overview of the process from start to finished model:

1. Choose a 3D Art Task
   • Should be from the Roadmap or tasked to you by Art Dept. Lead
   • You can come up with your own idea, and it might be accepted. But we appreciate your focus on just what the next release needs.
2. Build the Mesh and Textures Properly
   • We have simple, consistent file naming rules
   • You will learn a lot about making models that render without shading errors, are lightweight on the graphics hardware, and thus can look their best
   • You will learn a lot about lighting in games and using diffuse, specular, shininess, and also normal mapping to make your models look their best
3. Animate the Model Properly (if not a static model)
   • At present we have only limited, hardcoded animation names
4. Choose a License
   • CC-BY-SA v3.0 is recommended
   • We'll accept any license that lets us include your work in-game royalty free, make changes to it later if needed, and will be accepted as "free" by the open-source repositories we want to distribute our game.
5. Get Your Model Evaluated
   • Pictures or videos are good for aesthetic feedback
   • The source files will be needed for technical evaluation
6. Package a Repository and a Runtime Version
   • We keep a Masters Repository of editable source files in case a model needs to be adapted or re-textured even if the artist has left the project
   • The runtime files will be added to the game media

Contents 1 Choose a 3D Art Task 2 Build the Mesh and Textures Properly 2.1 Metrics 2.2 Proper Meshes 2.3 Proper Unwrapping 2.4 Proper Textures and Mapping 2.4.1 Diffuse + Specular < 1 2.4.2 Dielectric or Metallic 2.5 Polygon and Texture Budgets 3 Animate the Model Properly 4 Choose a License 4.1 Readme 5 Get Your Model Evaluated 6 Package a Repository and a Runtime Version

Choose a 3D Art Task

Please check our roadmap for an asset the project is needing. The list can be sorted by category to make it easy for you to find 3D art tasks. There are short-range goals for the next release, and we have a list of future content creation tasks.

To succeed, we need most effort directed toward what's needed for the next release. Sometimes our Art Department Lead or Project Leader will also ask artists to work on particular models we need quickly.

We also welcome models where the idea is the artist's own. They'll be evaluated and given feedback the same as any other. But if time is scarce, priority will probably be given to models we already planned for. You should also look our moodboard for inspiration and concept art to generate ideas that fit with the game.

For characters and moving objects, we have to use prerecorded animations rather than procedural animation at runtime. Animated objects need to be able to move through spaces and architecture without clipping errors or other visibly impossible movements. Before modeling such spaces, you must review the animation section of this guide.

Build the Mesh and Textures Properly

This is the core of the workflow, so there's a lot to read. Stick with it, and we'll stick by you.

Don't be intimidated by what you don't know. Our art team is very particular about doing things properly, but they (and all of us) are very appreciative and supportive of anyone who's willing to learn their techniques and contribute to the team.

Every 3D artist can learn to build, unwrap, and texture their models. And it's liberating to finally be able to do, for yourself, all that's required before your work can ever be seen in the game. You don't want to remain dependent, for no good reason, on another texture artist or unwrap specialist in order to have that reward. And with practice, it doesn't even take that long to make great looking models that are lightweight on the graphics hardware. If you make the effort to learn, we will cheer you on.

Some of our rules are simply conventions to keep things consistent and usable within our project. But the technical knowledge you can gain here is based on rigorous research on how graphical performance is actually impacted by different techniques in model construction. You'll have to let go of some old habits, like relying on polygon counts as the universal benchmark of how "heavy" a model is to render.

There's always more to learn, including for us. What we already have to teach we're confident will benefit you greatly though.

In short, our file naming rules are:

• All of a model's file names start with the same name_###
  • "name" is kind of thing the model is ("sword_001" rather than "katana_001") and not a default or generic name ("tube_001")
  • "###" is the lowest available number from 001-999

This is most easily done by naming the project files name_###

• Details of the file's use are included after "name_###_"

Example: a normal map would be named name_001_norm

Metrics

In short, our rules are:

• 1 unit = 1 meter
• +X is "right", +Y is up, and +Z is toward the screen
• All measurements are discussed in Metric units, not Imperial (British/US)
• Mesh's origin should be at the center of mass if the model is dynamic, and at the base if the model is static

In a 3D editor, like Blender, a model is just a shape which can be scaled or rotated in any way and still look the same. In our game, all models must have the same scale and rotation. We require all contributors to understand our measurement standards because inconsistent scaling or XYZ-orientation would add unnecessary extra work for someone to correct manually before contributed models could be used in-game.

In our game world, positive-Y is up and positive-Z points toward the screen, as shown in this picture...

Make sure that your bisected amputee beetle model doesn't end up eating dirt.

While neither OGRE or your 3D editor of choice enforces any particular coordinate system (left-hand, right-hand), one of our dependencies, Paged Geometry, presumes +Y is up. One standard for all models makes development easiest, so we defined one that works with Paged Geometry. Keep in mind that in Blender this does not mean that you must work with the specified coordinate system or save your file this way, just make sure you enable "Fix up axis to Y" in the exporter when you export your model. (NOTE: at present, interior scenes use a different orientation than the rest of the game. Interiors will be corrected to fit with the above rules, so follow them.)

Regardless of what model editor you use, it has an internal scale based on generic "units". For us one unit equals one meter.

We describe all measurements in Metric units both for in-game geometry and any real-life examples. If you need to work with Imperial (US) measures for your own sake, you could use the Online Conversion site. But only Metric measures are to be used in discussing or archiving models.

The origin (coordinate 0,0,0) of a mesh should be at the bottom if it is going to be placed on top of something, such as the ground, or another piece of a building. This is generally the case with all static meshes which will not move and will not be affected by physics (essentially they have infinite mass in our engine). The origin at the bottom makes less work defining offsets for placing static meshes in a scene. For dynamic models that will move and will be affected by physics, place the origin point at the center of mass. The position of dynamic models is solved by the physics system. Having the origin at the center of mass makes for less errors in placing objects.

Proper Meshes

In short, our mesh construction rules are:

• In-game vertex count trumps triangle count
• No hidden faces
  • Overdraw causes the worst performance hit
• No double-sided polygons
• Edges/lines should be shared by at most two faces/polygons
• Make your mesh using quads
  • Make triangles sparingly; let the engine split quads
  • Discuss model stats in faces, not triangles
• Use smooth shading, not flat shading
  • Edge-split manually anywhere and only where a hard line is needed

Try to learn smooth-bevels to make the best looking, lightest weight models.

We have particular standards for proper construction of models. This is based on deep knowledge of how models are actually rendered by graphics hardware and how various techniques impact framerates. The point is to create a single manifold body of polygons with all and only the polygons you need, to avoid shading artifacts, and to never have overdraw from hidden faces.

We also will be using automated methods to manage and maintain the media for the game, and irregular naming of files would make it more difficult to code tools to do useful things.

Proper Unwrapping

In short, our rules are:

• No overlapping islands
• No Mirroring
• Islands must be proportionate to their area of the 3D mesh
• Minimize warping of UV faces, but warp as necessary
  • Don't unwrap each face individually
• Place seams along edges in the mesh

Making a 3D mesh is rewarding since you see something being created. The UV mapping, or "unwrapping", is the link between that 3D shape and the 2D texture that gives it life and color. Without it, a mesh can't become a model and can't appear in-game. Many people have fun creating the mesh, but fail to complete the journey to true 3D Artist because the unwrap seems too challenging and tedious for them to learn. But their creations can't make it into the game without this. And no one will be volunteering to dedicate their spare time to doing only this "work before the work" for other people, leaving no creative imprint of their own. 'You have to do this. Every enterprise has its grunt work, and it's not so bad. You won't be alone; our team is happy to explain parts you don't understand yet.

The UV map is 2D and its dimensions are always square, from 0 to 1 on each side. It's a map is of UV faces matched to 3D faces of the mesh. But UV space is independent of 3D space. Each UV face only needs to reference the same vertexes (or "points" if you prefer) and lines as the 3D face it represents. So the shape and size of a UV face (relative to other faces) can differ from its 3D face. And one UV face can (but shouldn't) reference more than one 3D face. An island is a group of connected UV faces (sharing lines). On the UV map, the UV faces can be in separate islands even if the 3D faces they're paired to are all connected and contiguous.

For each 3D face on the mesh we need one UV face on the UV map. Overlapping is when a UV face, which will be matched to a corresponding area of the texture, is used for more than one 3D face on the mesh. Overlapping can be done manually or automatically with mirroring, which is a technique done on symmetrical models telling the game to use the same texture mapped for one side to be used on the other.

Since the 3D faces don't have the same normals, the textures work improperly because they're being told the wrong things about what angle the surface is that the light is reflecting off of there. It also prevents baking normal maps and ambient occlusion. Ideally for us, a model uses texture normals contained in the normalmap. If you don't know what that means, don't worry about it now.

Warping is almost impossible to avoid without unwrapping each face individually, creating many seams. A seam is a line which is used by only one face. Visually, seams in the UV map have no effect, but they do increase the data size of a model. With practice, you'll find a good way of balancing the need to keep faces together with the need to minimize warping of those faces needed to keep them connected. A good rule is to place seams along edges in the mesh, such as where you used edge-splits or smooth-bevels.

There are various tutorials to learn the basics of the unwrap interface for your 3D editor. Much of our particular techniques come from the Vega Strike: Unwrap in Blender tutorial. One thing to do for sure is, under View, make sure you have "Draw Faces" and "Draw Shadow Mesh" selected.

Proper Textures and Mapping

In short, our rules are:

• Textures use relative paths within the project file (.blend, .obj, .3ds)
• Diffuse + Specular < 1
• Texture dimensions should be square (x=y)
• Texture sizes should be powers of 2
• Place seams along edges in the mesh

Texturing is often more creative and immediately rewarding than unwrapping. The change from 3D editing to 2D editing shouldn't be too hard, but too many mesh-makers assume it is. Your model will look best if you become a full 3D Artist able to create with mesh and texture in a complete creative process. If an artist's goal was to create a painting, but they were afraid to learn steps beyond their mastery of drawing, it'd be odd to expect someone else to color within their lines to complete it. Why limit yourself when our team and community will coach and cheer you on?

First, all textures and mappings work together describing different aspects of light. We don't see diffuse, specular, or any texture as the "main texture". And we don't draw shading, highlights, or other details into a texture; we use textures and maps in a way that lets the game create these effects as they should appear when they should appear. These techniques are based on optical research and testing in computer rendered environments. This article on light physics and materials is a good overview.

All textures should be in square dimensions sized in a power of two. This is because of compatibility issues that occur even with recent graphics hardware. Acceptable sizes include 64x64, 128x128, 256x256, 512x512, 1024x1024, and 2048x2048.
Work on the original "Masters" version in as large a size as you like. But you should optimize the texture to be used for the in-game "runtime" version, which should be submitted along with your editable Masters files.

Diffuse + Specular < 1

All objects are seen by light reflecting off them. Of that light, some percent will be Diffuse Reflection and the rest is Specular Reflection. The smoother the material's surface at a microscopic level, the more specular the reflection.
But nothing reflects all light received. Everything absorbs some light. So diffuse plus specular must equal less than 100% of the light received. Likewise, everything reflects some light. So diffuse plus specular must be greater than 0%.

The red, blue and green channels respectively of both diffuse and specular, can not exceed 255 (100% white). Examples of accepted values:

A chalk would have something like:
250, 250, 250 in diffuse,
001, 001, 001 in specular.

A shiny gold coin might have something like:
022, 022, 000 in diffuse,
220, 220, 000 in specular.

Dielectric or Metallic

All opaque materials can be classed as dielectric except for a minority that can be classed as metallic. Polished metals are metallic. Almost all other materials-- like wood, skin, or even plastic-- are dielectric. Note, transparent materials are something else entirely.

All dielectrics must have grayscale specular textures. A dielectric's color is in the diffuse texture, even if that color happens to be gray.

All metallics have colored (RGB) specular textures. Their diffuse is basically the same color but radically darker, almost black. Ideally their diffuse has Red, Green, and Blue values each equal to the square root of their specular's RGB values each times n. Don't worry so much about the math though, just make it the same color but darker. The right color for most metals is obvious, but it's worth noting that polished iron is a slightly bluish grey. And oxides (rust, corrosion) are not metallic. Any oxidized areas of a metal object need those parts of their textures treated as dielectrics (keeping them in separate layers while editing is advised).

Polygon and Texture Budgets

We focus more on proper construction of models, knowing that in reality the performance hit created by a model isn't always caused by polygons or always by texture size. But we also know that spending your time and effort a model with no idea whether it will be accepted or rejected is poor motivation. So we give the following budget ranges for polygons and texture dimensions for various example models more as suggestions than as limits. If you need more, use it. But use only as much as you need to do a proper job. By keeping a Masters Repository, we have the option to optimize later if it's needed. We avoid pre-mature optimization, and using lower LOD (Level Of Detail) versions/impostors handles much of the issues we expect in our large-scale world.

Generally 5,000-12,000 polygons are fine, but detail level should count.

Exact guidelines on texel densities and texture size optimization are still evolving, but 256x256 is a generally accepted dimension for weapon textures. (NOTE: Table needs to be formulated. Bug del_diablo and Phlogios.)

Animate the Model Properly

Some static models need to consider the requirements for animated models, such as any static architecture that characters are meant to move through.

Characters, vehicles, and machines need to move through spaces and architecture they're intended to without clipping errors or other visibly impossible movements. So we have set size limits for characters and the spaces they are to move through. We strive to provide maximum flexibility, but with procedural animation being too computationally expensive, we have to use pre-made animations used with appropriately sized architecture and objects, like a building code for the game.

NOTE: Currently animation is limited to hardcoded names in the source code. This system is being rewritten entirely. Meanwhile, some modifications to the original will be made to advance demos until the replacement is done. An initial proposal can be found here.

• Maximum size for any human is 2.0m high x 0.8m wide x 0.8m front-to-back
• Minimum size for doorways/archways and any space humans walk through is 2.2m high x 0.9m wide
• Most rooms should be 2.3m minimum height and typically be 2.5m to 2.9m from floor to ceiling
• Floor-to-floor height for an entire storie/flat should be 2.5m minimum and typically be 2.7m to 3.2m
  • This includes a typically real-world acceptable 0.25m thick sub-floor
• Stair steps should ideally be 0.1778m high
  • Can range from 0.18m to 0.2m

For supporting evidence, see:

• Stairbuilding Basics
• Standards for Stairs and Doors

Choose a License

Our concerns are being able to freely use the content, having our game accepted by the big open-source software repositories with your models included, and being able to edit the model if needed even if you no longer have time to work on our project. We recommend CC-BY-SA version 3.0 licensing for all art assets. In essence, it is the media equivalent of true open-source software.

For a more complete overview of licensing and legal issues, please read our project's copyrights page.

Readme

We also need some info about the model put in a name_###_readme.txt file.

Generic license template:

Author: Name <e-mail or web address>
Model: Item name
License: Choose an appropriate license
Purpose: A few words about the intent of the asset
Notes: Anything else that needs to be mentioned

For the Author field, feel free to give as much or as little information as you wish. Just remember that if your licensing isn't a non-attribution license (like CC-SA, Public Domain, or the new CC-Zero) then it's not valid if you don't put your name in, and we can't legally use it because authors automatically have legal rights to their works, and no one else does except by permission.

Example template:

Author: Karl 'Cleveralias' Karlsson <karl@example.com>
Model: Apple
License: CC-BY-SA 3.0
Purpose: A decorative and edible fruit item
Notes: Has several textures for different varieties of apples 

Get Your Model Evaluated

Our team and our community aims to be candidly honest but also considerate of the fact you're contributing your time and effort for a common cause. We all give aesthetic feedback, but only our Art Dept. Lead and our advisor on graphical standards (Phlogios) can give the technical sign-off to approve an otherwise good-looking model. You may want to see our Moodboard and our Gallery for inspiration on the look and complexity we're looking for.

Make a forum post with pictures while the work is in-progress. We prefer you to upload them here on our wiki; files uploaded to hosting services are easily lost to us. And final versions make for great additions to the Gallery (more likely if the picture is already here).

For technical evaluation, you'll need to get the .blend (or whatever editable format you're using) file to our Art Department Lead or our graphical standards advisor Phlogios. The best way to do this is by uploading it to our forums, or to a reliable open-source art community like OpenGameArt.org. We may also need your textures, and smaller runtime formats like .png are better than editable source files.

Once the model has aesthetic and technical approvals, it is to quickly be packaged up for our Masters Repository and for addition to the game's runtime media.

Package a Repository and a Runtime Version

We can't expect every artist to stick around for the duration of the project. So, in open-source spirit, we keep a Masters Repository containing editable source files for each model. They also need to have a readme citation so we know what we're looking at and what license it's under. These are the full-size, unoptimized assets, including layers used in your texture-editor of choice (such as GIMP or Adobe Photoshop). They should have the same name as their runtime counterparts, just different file types (.png is NOT an editable source file to us).

Runtime versions are those the game will use and players will see. They are to be optimized, with all layers flattened into one. Again, the files need to be named logically according to our rules so we know where to put them and have the option of automated operations on game files in the future.

Exporting models from your 3D editor to OGRE's runtime formats might not be possible directly from your editor. For Blender, we have a model export and import guide.

• A minimally complete list of master/source files for a model "name_001" (assuming you use Blender and GIMP to edit) is:

name_001.blend
name_001_diff.xcf
name_001_readme.txt

• A minimally complete list of runtime files for a model "name_001" is:

name_001.mesh
name_001_diff.png

More typically, you will also have a specular and normal map, and that means the runtime files will need a .material file to tell OGRE which file to use for what.

• Masters files for "name_001"

name_001.blend
name_001_diff.xcf
name_001_spec.xcf
name_001_norm.xcf
name_001_readme.txt

• Runtime files for "name_001"

name_001.mesh
name_001.material
name_001_diff.png
name_001_spec.png
name_001_norm.png