|Version 15 (modified by jason, 4 years ago) (diff)|
Table of Contents
- Artistic Theme
- File Naming Conventions
- Art Pipeline
- 3D Tools
- COLLADA EXPORT
- PYROGENESIS IMPORT/EXPORT
- OTHER 3DS MAX Plugins
- Scale and Proportions
- Polygon Count Limits
- LEVEL OF DETAIL
- PROPing with pyrogenesis 3ds max plugin
- Skins and Textures
- Graphics Formats
- BASIC HUMAN TEMPLATE
- Player Color
- Object Color
- Folder Structure
It is important to have a cohesive visual theme for the game. Each piece of art will be reviewed by the art department lead and provide acceptance and feedback to the artists. Below are topics of discussion that effects the art department and the artistic theme of the game.
Culture, History, and Realism
The visual designs of the art in the game should hint at a deeper culture than simply what is seen on the surface. It is important that each of the civilizations have a sense of culture and history; that they have and truly did exist outside of the context of the game. The tools, homes and armor of a race should match the unique gameplay that the civilization offers.
An example: the Iberians (native to the peninsula of Iberia, modern day Spain and Portugal). They are fierce defenders of their homeland. Strength does not lie in numbers but in the skilled tactics of guerilla warfare. The weapons given to a unit are therefore numerous and versatile. Units often serve a dual purpose role and are equipped as such. Their amour and garments are practical with colors alluding to their ability to camouflage with their surroundings. Their buildings are strong and practically built.
History and its usage in the game are paramount. When in doubt ask a WFG historian.
Realism is always an interesting topic of discussion. Realism, while important does take a back seat to a more important player – Gameplay. Gameplay trumps Realism when the two topics disagree. Realism might dictate that a phalanx formation included over 500 soldiers, but gameplay only allows so many units on the screen at one time – not to mention the serious pathfinding and control issues so many units in the game would cause. Therefore gameplay dictates that we limit the formation to 20 or so units. Numerous examples such as this may be found in the game design discussions. We are creating a game after all, not a simulation.
This, at first may seem in direct contraction to our attempt to attain realism, and that may be true. Although all the entities in the game should be based in reality that does not mean that you should disregard exaggeration. These figures featured in the game are many times larger than life. Exaggeration in the game can best be described as a heightened sense of reality.
The game does not advance through Ages (like the Age of Empire series games), but rather phases of growth. In the interests of reducing art workload, building models are not replaced with upgraded versions when a player advances from one phase to another. Therefore only one set of structure models is needed per civilization.
Citizen soldiers are entities (units) that change appearance as they are played in the game. They upgrade based on combat experience. Their appearance changes when this upgrade is complete. Here is the general guide for appearance based on a unit’s rank:
- BASIC: Economy focused, light to little or no armor
- ADVANCED: Light trooper, lower/middle classed soldier, with moderate arms
- ULTIMATE / ELITE: Veteran warrior, the elite status. They possess the best weapons and the best armor.
Colors on the units should be neutral (skin tones, browns, grays, golds, bronze, etc...), because bright and saturated color will be used as a player’s color to show ownership. Player color usually is found on decorative elements of a texture. Learn more about how to create player color in the texture and skin section of this document.
Building Shape Consistency
It is important to have the building types of civilizations be roughly the same shapes for easy recognition by the players across civilizations. You will always know that a building is of a certain type because they all have some feature in common. Usually it is they way the buildings are laid out, but we also use size to make distinctions.
0 A.D. Theme
- Above average color saturation (compared to the real world)
- Contrasting - shadows and highlights within textures
- Relatively realistic in terms of world/nature and history
- Humans arent true to the real world in scale, but exaggerated to look like humans at greater distances. Men are burly and broad shouldered, and women are very… womanly.
- Exaggerate the animations - like theatre but not to the point of silliness. We need to make sure players know what actions they are doing.
- Exaggerate the traits of the Civs - Celts were colorful (so in the game they will be very colorful) - Greeks had fancy architecture (so many of their buildings will be fancier than in real life), etc...
File Naming Conventions
All filenames should follow the naming conventions described below.
- No spaces in the file name are allowed
- No capital letters are allowed
- XML, PMD, PSA, DDS files should use these rules. For any file-formats not specially mentioned here, follow similar naming rules to fit the file type.
- If using numbers always use two digits. Example: 01, not 1
- Use underscore ( _ ) to separate portions of the file name
- Use this order <general>_<civ>_<type>_<extra>_<variation>
- If the folder path to the file already defines one portion of the name, exclude that from the file name.
celt_isw_a_01.dds – Meaning: Advanced Celtic Infantry Swordsman, Variation 01 Texture
kart_hc.pmd – Meaning: Carthaginian Health Center Model
ui - User Interface
prop - prop
wrld – world
If none of the above, do not use
rome - roman
hele - hellenes
celt - celt
pers - persian
kart - carthaginians
iber - iberians
brit - britons
gaul - gallic
pole - poleis
mace - macedonians
b - basic
a - advanced
e - elite
f - fall
s - summer
p - spring
w - winter
cc - civilization center
ho - house
fc - farm center
fv - farm - vegetation
fa - corral - animal
rc - resource center
tf - free standing tower - scout tower
wc - wall
wg - wall gate
wt - wall tower
pc - port center
mc - military center
tc - trade center
hc - health center
ff - fortress
sb - special building
isw - infantry swordsman
isp - infantry spearman
ijv - infantry javelinist
isl - infantry slinger
iar - infantry archer
csw - cavalry sword
csp - cavalry spear
cjv - cavalry javelin
car - cavalry archer
fem - female worker
med - healer
trd - trader
sr - siege - rock thrower
sp - siege - spear/bolt thrower
sr - siege - ram
mer - merchantman ship
bir - bireme
tri - trireme
qui - quinquereme
su1 - super unit 1
su2 - super unit 2
su3 - super unit 3
hr1 - hero 1
hr2 - hero 2
hr3 - hero 3
scn - scenario unit
The following diagram displays the basic flow of art pipeline as content is created for the game. It starts up in the top left and is completed at the bottom right. The remainder of this document will be used to describe these processes in more detail. This section’s intent however is to provide you with a brief overview.
- Design Document
The design document dictates the design of the game. Game designers have pooled their efforts with the game’s historians to create a written description for every entity in the game. This written design concept is created with the purpose of directing the concept artist. The written design concept might refer to reference images to aid in visually describing the entity.
- Concept - Next, the written concept goes to the concept designers for their first draft. As with some things in the Art Department, there is no set limit to the number of revisions a concept designer will do to ‘get it right’. It is a hit or miss process guided by feedback from the lead until you get close or nail it on the head. Once a concept is deemed complete for the character, a front and side character design should be rendered to aid the modelers and textures.
- Modeling - Based on the concept or written description, a 3D model is then made fitting the concept as close as possible within the restraints of the modeling specifications found later in this document. The modeling process also includes unwrapping and exporting a uvw map for use by the texture artist.
- Texture - A skin (or texture) for the 3D model is then created. This may be created from scratch, using reference textures, or even utilizing the concept to make the best possible texture. Close attention is made to the texture to give it a worn and used appearance. Artificial shadows are created on the texture to fill in the details that a low poly mesh is not capable of doing. In some cases player color or transparency is used on the texture. In this case the alpha channel utilized to accomplish this. More details to follow later in the document.
- Rigging/Animation? - Non-static models require rigging and animation. This is a complex process that is discussed in more detail in the Animation section.
- Export - Finally, the models and textures need to be exported and implemented into the game engine. TGA and BMP files are converted to DDS files (if not already exported as a DDS). DAE files are exported to the /mesh and /animation folders.
- Actor - Actor files are an XML file that defines the visual properties of an entity in the game. These actor files in essence are the glue that puts parts together. The file points and references the mesh, texture, and animations of a unit. They also specify object color, player color, and shadow properties. Any mesh or animation created won’t be recognized by the game engine unless it is referenced by an actor XML file.
Concepts are very important to designing a game. One large reason is that we can all view the collective ‘vision’ behind the artwork in the game before it goes through entire art pipeline. This gives it all a sense of collectiveness. After-all this is one game and not a hodge-podge of artistic styles that very from individual to individual.
Concepts are the foundation of the rest of the artwork that we will be doing for the game. What is created by the concept artists will move down the ‘assembly’ line to the modelers and skinners.
Refer often to the civilization design documents:
The historical reference site here is also useful: http://www.wildfiregames.com/users/art/history/
Here are key points to address for concepts:
· Look - Black and white images (later colored if there is a specific point of detail that can’t be described with simply words)
· Title Block - http://www.wildfiregames.com/users/art/titleblock.jpg . Top box is the name, version in the middle left, and date on the right, your name at the bottom.
· Descriptions – feel free to draw arrows and write text in the image for anything you want to draw attention too
· Auxiliary view - If there is something to relate to the modelers that you couldn’t capture in one view, feel free to sketch a picture to the side from another angle.
· Citizen Soldiers – If it is a unit that upgrades (basic, advanced, elite) then three sketches are required.
· Backup – Back up all your work in the art SVN in case something bad happens to your computer – compressed please (ZIP, RAR)
These are great examples of some good concept art created for 0 A.D.
The (Ultimate – the highest ranked of this citizen soldier type) Roman Triarius was drawn by Brenden Keough. Note how he drew two different views of the unit so that there isn’t any question of what certain features that would otherwise be missed by the texture artist (like the greeves that only go halfway around the shin, and the extra detail seen in the helmet. This unit also has a few props included with the concept to ensure that they are represented with this unit as well. The other great thing about this concept is the detail. There is so much detail that it could actually be cut and pasted directly into a unit texture.
The civil center is another fine example of a concept created by Michael Hafer. Now this concept didn’t need to be colored because he so accurately described various features with notes. This is perfectly acceptable and actually preferred because it is a much quicker process than coloring an entire concept. Note also his overhead image in the lower right hand corner to help show exactly where the building are positioned about the complex structure.
Models are the next stage. Models are pretty important because they form the shape of the characters in our game world. The key to our models (because this is a full 3d game) is to rely on our skins for the details of the objects in the world and not the geometry. The industry buzz word for this is ‘low poly’. We will try to keep our polygon (tri) count down as low as possible. We can do to this by taking advantage of the opacity maps, removing polygons nobody will ever see (bottom polys), and relying on the skin for detail.
Here is what I’m looking for in models:
- Poly counts - Low as possible! Here are the suggestions:
Humanoid Bodies – 500
Animal Bodies – 700
Humanoid and Building Props – 50
World Objects – 150
Buildings – 800
- Unwrapping - Unwrap your own 3d models as best you can – they can be tweaked by the skinner later, but don’t force the skinners to do your job for you.
- Formats – *.max or *.3ds is preferred in a zipped file uploaded to your art FTP – Contact me about other formats. Final approved file will be exported as a *.pmd (Pyrogenesis model data).
- Scale – See the http://www.wildfiregames.com/forum/index.php?showtopic=793. Builidngs/trees are about 2/3rds the scale of humans. Props should match the scale of humans.
- Joints – if you unit is going to be animated, make sure there is enough vertexes around the joint to bend with minimal distortion.
- Think Ahead! – Try to imagine how you would skin the model and use opacity maps where you can.
- Backup – Backup all your work in the art SVN in case something bad happens to your computer – compressed please (ZIP or RAR)
- Needed Files - .pmd export plugin for R6 http://www.wildfiregames.com/~art/pmdexp6.rar
3D Studio Max release 6.0 and above is the recommended 3D modeler and animation package used for the Pyrogenesis Engine. Pyrogenesis models in the game are defined by custom file formats PMD (Pyrogenesis Model Data) and PSA (Pyrogenesis Animation). See Appendix A and B for more details describing these formats. The development pipeline previously used a custom export 3d Studio Max plug-in that exported files in these formats. However, the game now supports COLLADA’s DAE files which allow users to create content in a variety of software programs
Recommended 3D software options:
Note: Currently this has only been tested with 3ds Max. Some work may be needed to support other programs.
- In Blender, select the "Triangles" option in the exporter, and make sure it's only exporting one mesh (e.g. with "Only Export Selection").
- Download and install ColladaMax, from Feeling Software (registration required) or from our site (version 3.02). Requires 3ds Max 9, 8, or 7 SP1.
- Open/create a model in Max. If it is a skeletal model, it should have our standard structure and be named Bip01.
- If there is more than one mesh in the scene, you need to indicate which one should be exported:
- Either: select one of the meshes, then do File -> Export Selected (and remember to select the right mesh each time you export);
- or open the Properties dialog for one of the meshes, and set the User Defined Properties to export, and then do File -> Export. The other meshes will still be exported, but ignored when loaded into the game.
- When selecting the filename to export, specify the lowercase extension .dae. The default is uppercase, which wont work.
- Place the file into the game in the same way as you would with PMD or PSA files (in the /meshes and /animations directories, respectively).
- Actors can point to the .dae file as a mesh or animation, and the game will load them automatically. If there are problems while loading, the game's log file (binaries/logs/mainlog.html) should say what was going on.
- Use XSI 6.0.
- For skeletal models/animations:
- Rename the skeleton to Biped (so the root object is called Biped_GlobalSRT), so the game knows what skeleton structure to use.
- Export with File -> Crosswalk -> Export -> Format = COLLADA 1.4.1.
- Enable Export XSI Normals. Enable Convert Geometry to Triangles if the mesh is not already triangles.
- The animation should be 30fps. The first and last frames of the animation should be identical. The animation should play at the speed you would expect to use in the game.
- Any object attached directly to the skeleton will be treated as a prop point. If you want to add extra objects for testing the animation, link them to the existing prop points instead of to the skeleton.
- Meshes must be made of triangles.
- There may be some issues with scaling and rotating the skeleton - please provide any relevant information you find about problems or solutions.
- Prop points should be defined by creating an object (e.g. a Dummy helper in 3ds Max) named prop-whatever, where the whatever is the name of the prop point. The file data/tools/atlas/lists.xml lists the standard prop attachment points. That object should then be attached to a bone.
This plug-in is only tested to work on 3ds Max Release 6, WFG used this tool and format before COLLADA.
You may download from here:
Essentially this tool allows users to export PMD (Pyrogenesis Model Data) and PSA (Pyrogenesis Animation) files directly from 3ds Max R6. This process skips the exporting of a DAE (COLLADA) file that is later converted to a PMD or PSA file in the future. This method is not preferred. The tool is broken in that it does not blend weighted vertexes in animation, it also only allows biped/physique methods to animation (bones/skin do not work).
- Function: Creates Prop points
Access: In the Command Panel - Create => Helpers => PS Helpers => Prop Point
Extra: Export with the .pmd file, modify the name as desired, but precede with “prop-“, example prop-r_hip
- Function: Export .pmd files
Access: File => Export or File => Export Selected
Extra: Select mesh and any props and export
Dont forget to save the file in all lower case
- Function: Export .psa files
Access: File => Export or File => Export Selected
Extra: Select the bip node and export
Dont forget to save the file in all lower case
Currently you must center the mesh to the origin of the world before you export it (X=0, Y=0, Z=0); as it retains its global position when exported from Max, which moves the mesh to some undesired position in the game.
Helpful hints while using the PMD/PSA plug-in and usage in 3ds Max:
- Save the prop helper with the PMD
- Dont need to save the prop helper with the PSA
- Save BHP files to transfer animations to another biped
- Need to include the hip/bip node in the PSA
- It matters what bone the prop is attached to when you export the PMD.
- You dont have to have it in the default pose when you export the PMD.
- You must NOT be in figure mode when you export the PMD.
- Mirroring does weird things
- PSprop Z points up generally
- PSprop X points right generally
- PSprop Y points back generally
- Can put UVW modifier on top of Physique
- Can modify poly under Physique (triangulation and smoothing groups)
- Layers of animation work nicely to slightly alter a motion
OTHER 3DS MAX Plugins
3D Studio Max, while powerful, does have useful additional features/settings that may be added to the default installation and prove to be helpful for creating art content.
Texporter - A useful plug-in by Cuneyt Ozdas, Texporter allows UV maps to be exported from 3DS Max as a bitmap. Then use this template for texturing in Photoshop or similar 2D paint program. Download from http://www.cuneytozdas.com/software/ Install texporter3.dlu in the 3dsmax/plugins folder
MAX2OBJ and OBJ2MAX - These plug-ins were created by Harald A. Blab. They were useful in previous versions of 3ds Max that did not have the functionality of importing and exporting OBJ files. MAX2OBJ generates an Alias|Wavefront OBJ and MTL file from a 3DS Max scene. OBJ2MAX imports Alias|Wavefront OBJ and MTL files into 3DS Max. This version adds new options handling pivot points and OBJ smooth group import. If the importer crashes, do not use normals on import. This is useful for earlier versions of max to communicate with other software programs and retain more detail than a 3DS file is able to. OBJ’s, as mentioned, are capable of retaining smoothing groups.
SCRIPTS – There are a few scripts I’ve included that are useful.
orientator.ms – this script is really useful for props. It allows you to quickly orientate one object to the same orientation as another (matching both position and rotation). For example, you can select a sword, and quickly snap it to the position of the hand prop point helper. Once it is in position you are able to parent it to the point to move with it throughout animation.
rotaterzero.ms – this script quickly zeros out the rotation in x, y, and z. Useful just prior to exporting.
zero.ms - this script quickly zeros out the position in x, y, and z. Useful just prior to exporting.
Clear materials – I haven’t created a script for this, but you can simply paste this into the max command bar and it will remove all the materials of the selection. $*.material=undefined This is useful to export a file and avoid other receiving errors that they are unable to find textures or materials.
Scale and Proportions
Proportions in the game, in general, will not be true to the real world. Humans will take on the proportions of a hero. Animals will be formed with a slightly exaggerated eye. Structures in comparison to units will be roughly ¾ the size (though roughly 7/8 scale is given to windows and doors to aid in the transitional illusion of scale)
Scale is defined as thus: Height of a Man ˜ 2 meters = 4 generic units in 3ds Max = 1 square tile width in Pyrogenesis.
Structure footprint scale (in tiles) is as follows:
|VILLAGE PHASE STRUCTURES|
* 5x5 - Civic Centre (Village Centre=>Town Centre=>City Centre)
* 2x2 - House
* 3x3 - Farmstead
* 3x6 - Field
* 3x6 - Corral
* 3x3 - Mill
* 1x1 - Outpost
* 1x4 - Wall Section
* 1x1 – Tower
* 1x2 - Gate
TOWN PHASE STRUCTURES
* 4x4 - Dock
* 4x4 - Market
* 4x4 - Barracks
* 3x3 – Temple
CITY PHASE STRUCTURES
* 5x5 – Fortress
Polygon Count Limits
Pyrogenesis supports real time strategy games. RTS games have large numbers of entities on the screen at one time at a small scale. Due to this small scale, the total polygon limits are rather low compared to the average first person shooter. This is a list of recommended max poly counts for 3D Modelers to take into account with making 3D models.
Humanoid Bodies – 500
Animal Bodies – 700
Humanoid and Building Props – 50
World Objects – 150
Buildings – 800
Note: Engine DOES NOT support Double-Sided polys - don`t use them. If double sided polys are required, duplicate geometry must be created with the normals flipped.
LEVEL OF DETAIL
Because the models in the game will be small on screen and because the poly counts must be kept low, anything smaller than a human hand should not be modeled but included in texturing.
The orientation of models in the game follows standard max views. When viewing from the max Front view it would display the front facing view of the model. In other words, the model should be looking along the negative Y axis.
Pyrogenesis uses a system that is called propping. It is also defined in the computer world as a parent/child or master/slave relationship. In 0 A.D. we call it a body/prop relationship. Props are objects that are separated from the parent and have the ability to be used independently in whatever circumstance deemed fit.
They are ‘attached’ in the actual game by the engine by a designation in an XML file. Every bone in a skeleton is capable of having a prop point attached to it as a child. That prop point is a ‘node’ that can be identified in an XML file and a prop may be assigned to that node. The prop orientates and positions itself to the prop point node in the game. The prop follows the movement (if any) of the bone it was attached to.
The advantage this gives us is versatility and variety. It also cuts down on the downloaded size of the game. Instead of making 200 totally unique units, we simply create 8 basic shared body types, 50 or so props, create unique skins, and create combinations of these basic elements to allow for a host of options to developers and gamers/modders! This proves to be a very versatile system for creating content for the 0 A.D. world. To reiterate, armor and weapons are not to be included in the base mesh of the unit except under very special circumstances (we have yet to see it, but never say never).
Here are some examples of props: helmets, weapons, shields, capes, quivers, pottery, barrels, baskets, vegetation.
PROPing with pyrogenesis 3ds max plugin
This tutorial teaches on how to use the Prometheus 3ds Max propping tools. This will enable you to use the propping feature while doing your modding for 0 A.D. Well, if we are going to work with 3ds Max, we are going to need a plug-in and you can download that HERE.
What propping does is allows us to transform this:
This is an important tool because in 0 A.D. we only allow one texture per model. We also made an effort to conserve the texture database size by reducing the quality of textures in the game. This also, in the long
run, sped up the development process and encouraged visual cohesion.
So, what is a prop? Well a prop is an actor with its own attributes and behaviours. In this example, here is a a better view of the above images that shows what in the image are props:
We have a crate, barrel, anvil, dummy, shield, windows, door trim, and a chimney. Now, in the game, we can create multiple prop points. This can be useful because you could add variety with a random function that swaps out prop actors with every new entity created in the game. So, for example, with this one, we could have that shield actor switch out with a collection of shield props. However, for the purpose of this tutorial we will consider this collection of props as one prop.
So lets get started!
This is how the building looks on our 0 A.D. max file template. You can see the building is properly scaled for a 3x3 tile size and all the props are so far unique actors. Even though the props are separate objects (at the moment), they are sharing the same textures. Again, if a prop has a separate texture, it must be attached separately with its own prop point. Here is the texture that these props are skinned with:
The first thing we want to do is get everything orientated in one common location. The reason being is that each prop is anchored by a prop point. When we export the prop object, its orientation is based off its local axis. So, the idea is - we need the prop objects pre-positioned to ensure proper alignment in the game.
Skins and Textures
This is such a critical topic because it is the texture of a skin that really gives the game its ‘look’. 0 A.D.’s theme could be described as a hyper-realistic look. This is a historical game and not a fantasy or futuristic game. Our colors will be slightly more saturated than the real world. We also want to reflect the ‘realness’ of our world by NOT making things look totally new like you just purchased them off a store shelf, but rather: used, weathered, worn, ‘real’. It is very important to follow the concept, do not make creative liberties. The concept has been approved by the art department lead and the historian, your idea in your creative mind has not been. Make sure the viewer always knows what they are looking at. Also, pay particular note to details! The more detail that can be added to a texture, the better.
Here are some key elements of what makes up a good skin:
- Historical foundations – work with history, don’t create your own history
- Color – slightly more saturation than the real world
- Theme – heighten and enhance the purpose of mesh through your skin
- File Formats – Always save your originals in a lossless layered format (PSD, PSP or equivalent). We will be using DDS for the majority of all skins. Refer down below for more information on DDS files.
- Size – Power of 2 (2^n)! must be used for the dimensions of the images. These include 8, 16, 32, 64, 128, 256, and 512. DDS files require this. Both rectangular and square varieties may be used by mixing and matching the widths and heights using the above numbers.
- 64x64 – unit props
- 128x128 - typical units
- 256x256 - hero units
- 512x512 – structures (shared), and terrain textures
Keep in mind that the size of the texture should reflect the relative size in the game. There is no reason to make a texture for a flower to be 256x256 when in the game it will never been seen up so close to see such detail.
- Methods – Method 1 (Recommended) - start with a larger original sample, and then shrink. For example, if your target size is 256, then start with a 512 and then shrink by half and sharpen. Method 2 – Some believe that you are creating unnecessary detail and waste time to use Method 1, so they work with the texture at it’s final resolution (most artists are not this good however).
Use Layers! Layers are your friend. Save your layers! You never know when a belt used on one texture might be useful to share with another. Using the texture template you are able to share certain features across textures. If the elements of a texture are separated by layers, this job is much easier.
- Player color – Player color is achieved through the Alpha Channel of the DDS file. The visual data within the RGB channels should be desaturated (made to black and white). More on this topic further on in this document.
- Backup – Backup all your work in the art SVN repository in case something bad happens to your computer – compressed your source (uncompressed) files (MAX, PSD, BMP, TGA) please, use ZIP or RAR.
- Communicate! - If you need help or you would like some links to some good tutorials, feel free to ask questions of your fellow workers and the art department lead.
Preferred 2D Tools
There really isn’t any preferred graphical editing software that is capable of opening and saving BMP files may be used to create textures for Pyrogenesis. Software that is capable of supporting alpha channels and saving files in DDS format would be advantageous.
Recommended 2D software options:
Adobe Photoshop – Commercial
Adobe Photoshop Elements – Commercial
Corel Paint Shop Pro – Commercial
Corel Painter – Commercial
Deep Paint 3D- Commercial
GIMP – Open Source, Free
GIMPshop – Open Source, Free
Paint.NET – Open Source, Free
nVidia 8BF plugin – Free plugin that is useful for software that utilizes 8BF plugins
nVidia’s Developer Tools – Other useful DDS tools
Lossless and uncompressed, a large file that is bigger than a TGA, and lacks alpha channel support. The most basic format that may be saved and converted to a .dds file using a WFG conversion tool. Alpha layer tools are not required.
It is a lossless format, and supports alpha content via alpha channels. A 24-bit TGA will be converted to a DXT1 DDS file, and a 32-bit (alpha) TGA will be converted to a DXT3 DDS file. NOTE: Photoshop 7.0 has a bug where you cant save alpha in TGA. You should upgrade to Photoshop 7.1 or Photoshop CS. Because this format does contain alpha layers it requires software that takes advantage of this feature. This may also be converted to a .dds file using a WFG conversion tool.
DO NOT USE THIS FORMAT.
This is the format that is used by the game, no conversion is needed, subsequently loading times are extremely fast, in the order of 5x faster than any other format. This format gives you full control over the texture attributes and color format, it also supports alpha channels. This format is therefore recommended for maximum performance and control.
DirectX Texture Compression : DXTC is the native, compressed texture format used in DirectX 9. In many cases, DXTC reduces texture memory usage by 50% or more over palettized, 8-bit textures, allowing for twice the textures at the same resolution, or the same number of textures at twice the resolution. Three DXTC formats are available. You can see a detailed comparison on the different types of texture compression here: http://udn.epicgames.com/pub/Content/TextureComparison/ The color channels are all the same DXT1, DXT3, and DXT5 - in terms of compression and quality. The difference lies in the alpha channel.
· DXT1 is a four-bit compressed color format that allows for opaque, and one-bit alpha (DXT1a) textures; that is, textures with no transparency at all, and textures with a single transparent color.
· DXT3 adds support for a four-bit explicit alpha channel, on top of DXT1's color compression. Four-bit explicit alpha allows for sixteen distinct alpha values, making it good for textures with 'sharply contrasting translucent/opaque areas. DXT2 textures assume the color data is pre-multiplied by the alpha channel.
· DXT5 support a four-bit interpolated alpha channel. Three bits are used to determine explicit alpha values, and two eight-bit values are used to interpolate gradually between them. This makes the format especially suited for soft gradients and other textures where the alpha areas’ variance is mild. DXT4 assumes colors are pre-multiplied by the alpha channel.
· 32-bit RGBA is the obese godfather of textures. While extremely powerful, it's also terribly overweight. It features full 24-bit color, plus an 8-bit alpha channel, but takes up four bytes for every pixel; a 256x256 texture will require 256k of memory.
Use DXT1 textures as much as is possible because the greatest space savings can be had with them (any texture without an alpha transparency layer). If watching for rendering artifacts is not an option, DXT5 supports the most flexible alpha channels, while not increasing memory usage beyond that of a normal 8-bit palletized texture (for textures that require the use of the alpha layer – player color, transparency, object color). Use full RGBA only when DXT3/5 do not suffice in the both the color and alpha quality department, in highly visible expanses, such as skies box textures and user interface elements.
NOTE: A hardware bug in all nVidia chipsets, including the NV20 (!GeForce3), potentially makes DXT1 textures gross and ugly. Specifically, decompression is performed in 16-bit color mode internally, making the resulting texture potentially unacceptable for use, especially when combined with other operations. Test your DXT1 textures on nVidia hardware before committing to their use. All other DXTC formats on nVidia hardware are okay, as textures are decompressed in 32-bit color internally.
BASIC HUMAN TEMPLATE
A basic human template can be found here: http://www.wildfiregames.com/users/art/mythos/textures/newdude-newUVmap.psd
The base texture (affectionately named dude) looks like this:
To the left is the base texture was designed to provide the most basic layer of what will be used in the game. Most all of the game unit art is built of this this skin. This is the standard. The upper left portion is the legs, the upper right is the arms. The lower middle is the body.
The texture is tileable. What do we mean by tileable? Well the textures edges match up to aid you in lining up your texture seams.
To the right you is how the texture is broken down by quadrents. Also note that the integers are based on powers of 2. (though 384 is not).
Notice how the following images wrap and tile as you offset them:
Torso tile now centered about the back rather than the Chest.
Here are the arms tiled and rotated 90 degrees to help visualization.
Here are the legs tiled and rotated 90 degrees to help visualization.
The goal is to eliminate the seams in our textures and this template will do that.
The texture is designed to make maximum use of the texture space. The negative side of this is that the scale is sometimes disproportionate. If you want to make something on their body that is vertically and horizontally symmetrical, you need to do this. Crop just the lower half (the red section in the quadrent image above). Then resize this layer so that it’s 512x580. See the image to the right.
Here are more resources:
In the dude accessories youll find a few examples of some things:
- necklines that line up
- sleeveless template
- sleeve template
- sample boots
- sample belt
- sample shirt
- sample pants
- circle representation
- sample bracers
It is advantageous to use the template in a paper doll fashion. Each of these steps is a layer. The artist starts with the base, next the tunic is added. Then add the breastplate, then the leather loin protectors, and finally the weapon strap. Because these are independent layers, they can be used on other models as well. Note that the color of the tunic is grayscale, this is because it is used as player color; more on that in the next topic.
Player color is a special attribute of the game to serve the purpose of showing player ownership. It uses the alpha channel of a texture to apply a multiplied color layer (defined by the game, and player) in real time during the game. These textures can be made several different ways. One way is to use the photoshop DDS plugin noted above. The preferred method is to save a TGA (if you are working directly with alpha channels) or a BMP (if you are working with a flat texture with no alpha), and process it with the Pyrogenesis texture converter found in game’s developer tools. This may be found here in the game’s binaries:
The folder contains a readme.txt file with specific instructions for us. Note the image to the left has the RBG channel above at the top. The lower channel is a representation of the alpha layer (You are actually able to convert in this manner with a BMP file and the texture converter tool). What the game does is it uses that layer to designate what areas of the texture would receive color and what doesn’t. Black means it is player color and white means it is opaque RBG. Grays are a degree of transition between opaque and player color. The game then ‘multiplies’ the player color with the RBG layer’s gray tones. Compare the left image below to the right. It basically adds the RGB pixel color values between the 2 ‘layers’.
Notice how the player color depth is brought out by the color multiplication in comparing the two images on the left.
These images show how the engine uses the player color to change between various colors.
Object color is much the same as player color. It’s purpose is to offer a variety of color other than player color. For example, by using one single texture one is able to create a human head texture with a variety of hair colors: blonde, dirty blond, brown, gray, and black. Horse pelts also use this feature. We are able to use one texture for this purpose rather than multiple which saves space and texture memory for the game. It is designated specifically in the Actor XML file.
Transparency, like player color and object color, uses the alpha channel for it’s definition. The same methods are used for creation. This is probably the usage of the alpha channel that most are familiar with, so it doesn’t require much explanation. The Actor file that uses the texture must however tell the engine the texture has transparency and is called out as such in the Actor file.
UV Coordinates and Texturing
Pyrogenesis supports only one (1) UVW channel and Material per object. Only UVW Channel 1 will be used by the exporter and game engine. Multi-sub object texturing should not be used and is not supported. Objects should be textured with just one material, represented in 3D Studio Max as the diffuse texture channel.
DDS will be used for the final texture format in Pyrogenesis, However, it is also recommended that textures be created in Photoshop, Paintshop Pro, or Gimp (etc.) also be saved as Photoshop Documents PSD files, with their layer information intact, so that later revisions can be made. This will also serve as an easier way to make variations and modifications in the future.
256x256 for heroes
128x128 for citizen soldiers
64x64 for props
512x512 for shared structure textures and terrain textures
Some find that working at double the intended game resolution size in your 2D software package then scaling the final version down is useful. Others say that you waste time creating unused detail. The decision will be yours to make.
Terrains must tile. Meaning the left<=>right and top<=>bottom must seamlessly tile with each other. Terrain textures are in a large size because they are such a huge portion of what is visible on the screen. Care should be taken to avoid distinguishable repeating patterns on textures that have a high likely hood of more than 50% of the texturing being seen on the screen at a time (grass, dirt, sand, etc...). Recognizing repeating textures in unique aspects of terrain (cliff, rocks, roads, etc....) are not as critical. A texture spans approximately 11x11 tiles in the game. Scale your details on the texture accordingly.
This terrain texture is for a guide for shadows. If there is a feature on the terrain (such as a rock, or a stick) that would benefit from a shadow, place the shadow to the left of that feature (not the shadow on the blue ball). This would be in line with the shadow position for the default angle and location of the sun in the game world.
This image is an example of how textures blend together in our game. There is a calculation performed by the game engine that recognizes the primary and secondary texture adjacent to tile in question itself. Based on that information it applies a suitable alpha mask. There are eleven possible different options. This template was created to help one see those options and create more transitions based on it.
To use this image, you are free to modify any part of the blend aside from the pixels on the edges of the grid. It could be a simple gradient as is seen here or it could be made blotchy, or feathered. Remember that the blends must interface with one another so their border blends should match.
A skybox is an interesting graphical feature of the world. It is for the most part unimportant to the game, but goes a long way to beautifying the world. The skybox is just that. It is a large cube in the game world that does not move relative to the camera. It is comprised of five textures for all faces excluding the bottom. The textures location is: art\textures\skies\<name>. The five textures are named front, back, left, right, and top. The files are saved as 32 bit RBGA DDS files. Reason being is that there is no file compression which means there are no artifacts on the textures. The textures were created in 3DS max by setting up a 5 camera’s each facing a direction. A textured halved sphere was created. All five camera’s render an image. You can test your images in this small program:
Water textures use normal mapping. They are a series of 60 images that are displayed one after another to give the illusion that water is moving. The movement is simply by the design of the texture. The textures were created by a 3rd party texture generating program. Once they were rendered in black and white they were used as a ‘height map’ and processed by NVIDIA’s DDS Photoshop plug-in to apply the normal map’s color code information to them.
Animations are typically created by two means either key framing or importing motion capture files. Because all our humanoid characters will be sharing the same proportions and skeleton we will be able to assign common and shared animations to human. The goal is to build up a library of animations, just like a library of props and we will just ‘play’ the animations as defined in the actor xml file in real time throughout the game.
Here is what we are looking for in animations:
- Exaggerate – your character is very small on the screen. Make sure the gamer knows the difference between swinging a sword and waving hello.
- Starts and Stops – The animation must be played in cycles and they loop. The pose you start the animation with must be identical to the last frame (except for death animations). Your starting pose should also be the same or similar to those animations of the same type and class. This is to ensure the transition from a standing, to a fidget, to a walk, or an attack will appear seamless.
- File Formats: Save your original files. All animations will be exported with the COLLADA plugin for the game.
- Backup – Backup all your work in the WFG art SVN in case something bad happens to your computer – compressed please (ZIP or RAR)
The key animation types are as follows:
Idle – a very subtitle movement simply to let the user know the unit is not a stone.
Attack – if capable of attacking, 2-3 variations would be nice
Walk – a simple walk cycle
Run – if capable, a run cycle
Death – when the unit’s hit points reach zero, the unit must die. 2-3 variations
Foraging – if capable, two types: picking berry bushes, and picking fruit from trees
Mining – if capable, swinging a pick axe
Logging – if capable, swinging an axe
Farming – if capable, swinging a hoe
Discreet's Character Studio has been the primary character animation tool for character animation. However with the use of COLLADA to export animations, a variety of software packages may be used as long as the skeleton, mesh, and animation use the same scale and bones. Standard 3DS Max Bones may also be used when a custom rig is necessary, though the total number of bones in a rig must not exceed 25.
Above is the image of the hierarchy and naming convention of the basic Biped that is used for all humanoid animation in the game (Note: ignore the green boxes and the footsteps). If an alternative is desired that does not match this structure, contact the developers for support.
Rigging <need to fill out> Bone/Biped? StructuresBones/Biped Limits <need to fill out> Character Animation <need to fill out> Animation Frame Rates <need to fill out> PASAP Animation List <need to fill out> Non Essential Animation List <need to fill out>
What is an actor?
<need to fill out>
<need to fill out>
<need to fill out>
For instructions on comitting your work, see here?.
¦ ¦ ¦FAUNA
¦ ¦ ¦FLORA
¦ ¦ ¦GEOLOGY
¦ ¦ ¦STRUCTURES
¦ ¦ ¦TEMP
¦ ¦ +UNITS