Changes between Initial Version and Version 1 of ArtDesignDocument

Timestamp:

Jan 7, 2009, 2:09:31 AM (15 years ago)

Author:

Jason

Comment:

--

ArtDesignDocument

@@ +1 @@
+'''[ INTRODUCTION]'''
+
+'' ''
+
+'''__[ PURPOSE]__'''
+
+Welcome to the 0 A.D. project.  This document is intended to be a comprehensive guide on how to create artistic content for 0 A.D., a game created by Wildfire Games (WFG).  Wildfire Games is a group of hobbyist game developers with a common goal of creating a historical real time strategy game that is set in the ancient era of the Roman Empire.  The game engine is custom built and given the name Pyrogenesis.  Pyrogenesis is a modular, data driven engine that will hopefully serve as a foundation for many more freeware games in the future.
+
+This document will introduce you to the processes and tools required to create artistic content.  We will begin with this introduction and then take you through the various stages of development, beginning with creating a concept to committing the art assets to the SVN repository; complete with all the steps in between.  This is a lot of information to digest, if you have any questions please contact the WFG developers via forums, instant messenger, or email.
+
+'''__ __'''
+
+'''__[ THE VISION OF 0 A.D.]__'''
+
+[[BR]] NOTE: The following section is a short extract that will aid you in understanding what 0 A.D. is all about.
+
+0 A.D. is a historical ''(historically based)'' real time ''(non stop action)'' strategy ''(decisions affect the outcome, not chance)'' game ''(fun and enjoyable)''. I believe we say it best with the 0 A.D. creed:
+
+''It is a moment in time that never was. [[BR]] It is the spring of the world, and the dawn of history.[[BR]] It is a glimpse into an era when the empires of the world are at their zenith.[[BR]] It is but a breath of an age when mighty rulers wield rods of iron and brazen swords;[[BR]] to demonstrate that they are indeed the greatest ancient civilization! ''
+
+Let's break this creed down piece by piece.[[BR]] [[BR]] '''''It is a moment in time that never was.'''''
+
+It is important to note that "0 A.D." is a period in time that historically never actually existed. Historians go directly from 1 B.C. to 1 A.D. and skip over “0 A.D.” So, what are we saying? We are specifying that this time period is a fictional time period.[[BR]] [[BR]] '''''It is the spring of the world, and the dawn of history.'''''
+
+History is defined as an account of a chronological chain of events. People started recording history during the time period of our game. It is this history that has been passed down to us, two millennia later. The western world as we know it was born during this time.
+
+The Roman historian Tacitus (55 - 120 A.D.) stated: “The principle office of history I take to be this: To prevent virtuous actions from being forgotten...”
+
+This game reflects on the heroes that lived and conquered during the timeframe of our game. It tells their stories in a fun and entertaining way.[[BR]] [[BR]] '''''It is a glimpse into an era when the empires of the world are at their zenith.'''''
+
+0 A.D. is a slice in time. Imagine if all the ancient worlds (at the peak of their civilizations) were pitted one against another. We are plucking major civilizations out of their linear timeframe and placing them in the slice of time, which is 0 A.D.[[BR]] [[BR]] '''''It is but a breath of an age when mighty rulers wield rods of iron and brazen swords;'''''
+
+Combat in the game plays the major role. Economic and political roles take a back seat to strategic warfare. Are we glorifying war for entertainment purposes? Uh… Yep.[[BR]] [[BR]] '''''to demonstrate that they are indeed the greatest ancient civilisation! '''''
+
+Out of the 6 civilizations, which is the best? Well, we don't know! That decision is put in the hands of the player. It is up to them to either recreate or rewrite history.[[BR]] [[BR]] '''''2000 Years Ago'''''
+
+The game will draw people back 2000 years. This could be a bit difficult because nobody really knows for sure how things were exactly. Much information was lost during the dark ages. We are therefore basing most everything on what our historians have been able to dig up for us. We are taking a great effort to avoid stereotypical imagery and notions, in an effort to give our players a realistic world.
+
+As far as the look goes, our world will be a heightened representation of reality. Colors will be a bit more saturated, vegetation will slightly Edenic, structures will appear in a livable state, units will be battle-torn, and the resources will be bountiful. We will try to make it as pleasing to the eye as possible.
+
+'''__ __'''
+
+'''__[ Artistic Theme]__'''
+
+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.
+
+__Exaggeration__
+
+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.
+
+__Phases__[[BR]] 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''''''__
+
+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.
+
+__Player Color__''''''
+
+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 aren't 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.
+
+'''General Rules'''
+
+
+ * 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.
+
+Examples:
+
+celt_isw_a_01.dds – Meaning: Advanced Celtic Infantry Swordsman, Variation 01 Texture
+
+kart_hc.pmd – Meaning: Carthaginian Health Center Model
+
+[[BR]]  
+
+
+||'''General'''[[BR]]   ui - User Interface[[BR]]   prop - prop[[BR]]   wrld – world[[BR]][[BR]]If none of the above, do not   use[[BR]]   [[BR]]   '''Civ'''[[BR]]   rome - roman[[BR]]   hele - hellenes[[BR]]   celt - celt[[BR]]   pers - persian[[BR]]   kart - carthaginians[[BR]]   iber - iberians[[BR]]   brit - britons[[BR]]   gaul - gallic[[BR]]   pole - poleis [[BR]]   mace - macedonians[[BR]]   [[BR]]   '''Extra'''[[BR]]   b - basic[[BR]]   a - advanced[[BR]]   e - elite[[BR]]   f - fall[[BR]]   s - summer[[BR]]   p - spring[[BR]]   w - winter[[BR]]   #- numbers[[BR]]   etc...[[BR]][[BR]]||'''Type'''[[BR]]   ''__Buildings__''[[BR]]   cc - civilization center[[BR]]   ho - house[[BR]]   fc - farm center[[BR]]   fv - farm - vegetation[[BR]]   fa - corral - animal[[BR]]   rc - resource center[[BR]]   tf - free standing tower - scout tower[[BR]]   wc - wall[[BR]]   wg - wall gate[[BR]]   wt - wall tower[[BR]]   pc - port center[[BR]]   mc - military center[[BR]]   tc - trade center[[BR]]   hc - health center[[BR]]   ff - fortress[[BR]]   sb - special building [[BR]]   ''__Units__''[[BR]]   isw - infantry swordsman[[BR]]   isp - infantry spearman[[BR]]   ijv - infantry javelinist[[BR]]   isl - infantry slinger[[BR]]   iar - infantry archer[[BR]]   csw - cavalry sword[[BR]]   csp - cavalry spear[[BR]]   cjv - cavalry javelin[[BR]]   car - cavalry archer[[BR]]   fem - female worker[[BR]]   med - healer[[BR]]   trd - trader[[BR]]   sr - siege - rock thrower[[BR]]   sp - siege - spear/bolt thrower[[BR]]   sr - siege - ram[[BR]]   mer - merchantman ship[[BR]]   bir - bireme[[BR]]   tri - trireme[[BR]]   qui - quinquereme[[BR]]   su1 - super unit 1[[BR]]   su2 - super unit 2[[BR]]   su3 - super unit 3[[BR]]   hr1 - hero 1[[BR]]   hr2 - hero 2[[BR]]   hr3 - hero 3[[BR]]   scn - scenario unit||
+
+'''__[[BR]] [ Art Pipeline]__'''
+
+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.
+
+'''1)      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.
+
+'''2)      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.
+
+'''3)      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.
+
+'''4)      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.
+
+'''5)      Rigging/Animation'''
+
+Non-static models require rigging and animation.  This is a complex process that is discussed in more detail in the Animation section.
+
+'''6)      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.  
+
+'''7)      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.
+
+'''[[BR]] '''[[BR]]'''[ CONCEPTS]'''
+
+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. [[BR]] [[BR]] 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.[[BR]] [[BR]] Refer often to the civilization design documents:
+
+
+ * [http://www.wildfiregames.com/forum/index.php?showtopic=365 Carthaginians]
+ * [http://www.wildfiregames.com/forum/index.php?showtopic=323 Celts]
+ * [http://www.wildfiregames.com/forum/index.php?showtopic=305 Hellenes]
+ * [http://www.wildfiregames.com/forum/index.php?showtopic=343 Iberians]
+ * [http://www.wildfiregames.com/forum/index.php?showtopic=1098 Persians]
+ * [http://www.wildfiregames.com/forum/index.php?showtopic=222 Romans]
+
+ 
+
+The historical reference site here is also useful: http://www.wildfiregames.com/users/art/history/ [[BR]] [[BR]] 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.
+
+''' '''
+
+'''[[BR]] '''[[BR]]'''[ Models]'''
+
+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.[[BR]] [[BR]] Here is what I’m looking for in models:
+
+
+ * '''Poly counts '''- Low as possible! Here are the suggestions:[[BR]]      ''Humanoid Bodies'' – 500[[BR]]      ''Animal Bodies'' – 700[[BR]]      ''Humanoid and Building Props'' – 50[[BR]]      ''World Objects'' – 150[[BR]]      ''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/%7Eart/pmdexp6.rar http://www.wildfiregames.com/~art/pmdexp6.rar]
+
+ 
+
+'''__[ 3D ToolS]__'''
+
+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:
+
+[http://en.wikipedia.org/wiki/Maya_%28software%29 Maya] (using [http://www.feelingsoftware.com/content/view/55/72 ColladaMaya])
+
+[http://en.wikipedia.org/wiki/3D_Studio_Max 3D
+Studio Max] (using [http://www.feelingsoftware.com/content/view/65/79/lang,en/ ColladaMax])
+
+[http://en.wikipedia.org/wiki/Softimage_XSI Softimage|XSI]
+
+[http://en.wikipedia.org/wiki/MeshLab MeshLab]
+
+[http://en.wikipedia.org/wiki/SketchUp SketchUp]
+
+[http://en.wikipedia.org/wiki/Blender_%28software%29 Blender]
+
+[http://en.wikipedia.org/wiki/Gmax Gmax] (export W3D, import W3D into 3dsmax)
+
+ 
+
+'''__[ COLLADA
+EXPORT]__'''
+
+Note: Currently this has only been tested with 3ds Max. Some work may be needed to support other programs.
+
+'''Blender'''
+
+
+ * In      Blender, select the "Triangles" option in the exporter, and make      sure it's only exporting one mesh (e.g. with "Only Export      Selection").
+
+'''3ds Max'''
+
+
+ * Download      and install !ColladaMax, from [http://www.feelingsoftware.com/ Feeling
+     Software] (registration required) or from [http://wildfiregames.com/users/code/libraries/ColladaMax_302.exe 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 won't 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.
+
+'''XSI'''
+
+
+ * 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.
+
+'''General'''
+
+
+ * 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.
+
+ 
+
+'''__[ PYROGENESIS IMPORT/EXPORT]__'''
+
+This plug-in is only tested to work on 3ds Max Release 6[[BR]] [[BR]] You may download from here:[[BR]] http://www.wildfiregames.com/users/art/pmdexp6.rar [[BR]] [[BR]] 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).
+
+1.      '''Function:''' Creates Prop points [[BR]] '''Access:''' In the Command Panel - Create => Helpers => PS Helpers => Prop Point[[BR]] '''Extra:''' Export with the .pmd file, modify the name as desired, but precede with “prop-“, example prop-r_hip
+
+2.      '''Function:''' Export .pmd files [[BR]] '''Access:''' File => Export or File => Export Selected[[BR]] '''Extra:''' Select mesh and any props and export[[BR]] Don't forget to save the file in all lower case
+
+3.      '''Function:''' Export .psa files [[BR]] '''Access:''' File => Export or File => Export Selected[[BR]] '''Extra:''' Select the bip node and export[[BR]] Don't 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.[[BR]] [[BR]] Helpful hints while using the PMD/PSA plug-in and usage in 3ds Max:
+
+
+ * Save      the prop helper with the PMD
+ * Don't      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      don't 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]__'''
+
+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'''[[BR]][[BR]][[BR]] * 5x5 - Civic Centre (Village Centre=>Town        Centre=>City Centre)[[BR]] * 2x2 - House[[BR]] * 3x3 - Farmstead[[BR]] * 3x6 - Field[[BR]] * 3x6 - Corral[[BR]] * 3x3 - Mill[[BR]] * 1x1 - Outpost[[BR]] * 1x4 - Wall Section[[BR]] * 1x1 – Tower[[BR]] * 1x2 - Gate||''' '''[[BR]][[BR]]''' '''[[BR]][[BR]]'''TOWN PHASE STRUCTURES'''[[BR]][[BR]][[BR]] * 4x4 - Dock[[BR]] * 4x4 - Market[[BR]] * 4x4 - Barracks[[BR]] * 3x3 – Temple[[BR]][[BR]]'''CITY PHASE STRUCTURES'''[[BR]][[BR]][[BR]] * 5x5 – Fortress[[BR]][[BR]] ||
+
+ 
+
+ 
+
+'''__[[BR]] [ 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[[BR]] ''Animal Bodies'' – 700[[BR]] ''Humanoid and Building Props'' – 50[[BR]] ''World Objects'' – 150[[BR]] ''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.
+
+'''__[ ORIENTATION]__'''
+
+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.
+
+'''__[ PROPS]__'''
+
+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.
+
+ 
+
+'''__[ PROPping 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 [http://www.wildfiregames.com/%7Eart/pmdexp6.rar HERE].
+
+ 
+
+What propping does is allows us to transform this:
+
+
+||||VS.||||
+
+ 
+
+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 [[BR]] 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.
+
+[[BR]]  
+
+
+||'''Step 1 - Attaching'''[[BR]][[BR]] [[BR]][[BR]]The next step is to select the structure and attach all [[BR]]   the props:[[BR]][[BR]] [[BR]][[BR]] [[BR]][[BR]]You will see the following menu pop up, just hit OK.[[BR]][[BR]] [[BR]][[BR]] [[BR]][[BR]] ||'''Step 2 - Pivot   Placement'''[[BR]][[BR]] [[BR]][[BR]]Now, all your props will be included in one object. We [[BR]]   next should move our object to the centre of the 3dsmax world. In order to do   that we need to make sure our pivot point is in the correct location.[[BR]][[BR]] [[BR]][[BR]]Click   on the hierarchy tab, then click the pivot button, then the "Affect   Pivot Only" button.[[BR]][[BR]] [[BR]][[BR]] [[BR]][[BR]] [[BR]][[BR]]Centre   your pivot (X,Y) to the centre of your structure (or where you want it to be   anchored in the game).[[BR]][[BR]] [[BR]][[BR]] [[BR]][[BR]] [[BR]][[BR]] [[BR]][[BR]] [[BR]][[BR]]The Z   is a bit different; we want to position this to the bottom of the structure.   If we put it in the middle, then your structure would be 'buried' halfway in   the game's terrain. Not good.[[BR]][[BR]]Ok, you're now done moving your pivot. Turn off the   'Affect Pivot Only' button.[[BR]][[BR]] [[BR]][[BR]] ||
+
+ 
+
+[[BR]]  
+
+
+||'''Step 3 - Detaching'''[[BR]][[BR]] [[BR]][[BR]]Now, let's move our structure to the centre of the world.   You can do this by just inputting zeros in the world coordinates at the   bottom of the screen.[[BR]][[BR]] [[BR]][[BR]] [[BR]][[BR]]The   next step is to separate the props again from the object. So first we select   all the prop objects like this image to the left.[[BR]][[BR]] [[BR]][[BR]] [[BR]][[BR]] [[BR]][[BR]]Then we detach them.[[BR]][[BR]] [[BR]][[BR]] [[BR]][[BR]]A new window will pop up.[[BR]][[BR]] [[BR]][[BR]] [[BR]][[BR]]I'm going to go ahead and properly name it right here.[[BR]][[BR]] [[BR]][[BR]]While I'm at it, I'll go ahead and properly name the   structure too.[[BR]][[BR]] [[BR]][[BR]] ||'''Step 4 - Setting   the Prop Point'''[[BR]][[BR]] [[BR]][[BR]]Now, it's time to work with the prop point. First, we need   to create one.[[BR]][[BR]] [[BR]][[BR]] [[BR]][[BR]]Click on the 'create' tab, then the helper object button, [[BR]]   then scroll down and you will see a choice of 'PS Helpers'. Select that.[[BR]][[BR]] [[BR]][[BR]] [[BR]][[BR]]Now our prop tab looks a bit different. Go ahead and place   a prop point. Once you place it, it will look like this:[[BR]][[BR]] [[BR]][[BR]] ||
+
+[[BR]]  
+
+
+||'''Step 5 - Exporting'''[[BR]][[BR]] [[BR]][[BR]]It is time to export! select both the prop point and the [[BR]]   structure.[[BR]][[BR]] [[BR]][[BR]] [[BR]][[BR]]Go to File => Export Selected[[BR]][[BR]] [[BR]][[BR]] [[BR]][[BR]]Now go ahead and export your structure.[[BR]][[BR]] [[BR]][[BR]] [[BR]][[BR]]And that's it! You just exported an object with a prop   point included! Repeat the same export for the prop point.[[BR]][[BR]] [[BR]][[BR]] ||'''Step 6 - xml code'''[[BR]][[BR]] [[BR]][[BR]]You're all done in 3dmax. Now it is time to look at the [[BR]]   xml code.[[BR]][[BR]] [[BR]][[BR]] [[BR]][[BR]]In this code snippet:[[BR]][[BR]] [[BR]][[BR]]We have given it the proper name (the name that will   appear in Atlas). We are also pointing to the newly created *.pmd file. We   call up the texture.[[BR]][[BR]]We name the prop point and tell it what actor is supposed   to go there.[[BR]][[BR]] [[BR]][[BR]] [[BR]][[BR]]In this code snippet:[[BR]][[BR]] [[BR]][[BR]]We have given it the proper name (that will be 'called up'   by the code above). We are also pointing to the newly created PMD file. We   call up the texture.[[BR]][[BR]] [[BR]][[BR]]'''Summary'''[[BR]][[BR]] [[BR]][[BR]]The tutorial above probably has some unneeded steps, but   for the beginner, this is a good way to start. You will find yourself   refining your procedures with experience.[[BR]][[BR]] ||
+
+ 
+
+ 
+
+'''[[BR]] [ 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.
+
+[[BR]] 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 Tool]__'''
+
+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:
+
+[http://en.wikipedia.org/wiki/Adobe_Photoshop Adobe
+Photoshop] – Commercial
+
+[http://en.wikipedia.org/wiki/Adobe_Photoshop_Elements Adobe Photoshop
+Elements] – Commercial
+
+[http://en.wikipedia.org/wiki/Corel_Paint_Shop_Pro_Photo Corel Paint Shop
+Pro] – Commercial
+
+[http://en.wikipedia.org/wiki/Corel_Painter Corel
+Painter] – Commercial
+
+[http://www.righthemisphere.com/ Deep Paint 3D]- Commercial
+
+[http://en.wikipedia.org/wiki/GIMP GIMP] – Open Source, Free
+
+[http://en.wikipedia.org/wiki/GIMPshop GIMPshop] – Open Source, Free
+
+[http://en.wikipedia.org/wiki/Paint.NET Paint.NET] – Open Source, Free
+
+ 
+
+DDS plugins:
+
+[http://developer.nvidia.com/object/photoshop_dds_plugins.html nVidia 8BF
+plugin] – Free plugin that is useful for software that utilizes 8BF plugins
+
+[http://developer.nvidia.com/page/tools.html nVidia’s
+Developer Tools] – Other useful DDS tools
+
+ 
+
+'''__[ Graphics
+Formats]__'''
+
+·        '''BMP'''[[BR]] 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.
+
+·        '''TGA'''[[BR]] 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 can't 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.
+
+·        '''JPEG'''[[BR]] DO NOT USE THIS FORMAT.
+
+·        '''DDS'''[[BR]] 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.
+
+[[BR]] '''Recommendation'''[[BR]] 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.[[BR]][[BR]]
+
+'''__[ 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.[[BR]] [[BR]] 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).[[BR]] [[BR]][[BR]]
+
+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 image to the left demonstrates that with a bit of flipping,   rotating, and resizing you can position the tile to look like this image to   the left.  This allows seamless   transitions between the torso and legs if needed.  After a texture is complete simply retrace   your flipping and rotating steps to return to the original.||
+
+ 
+
+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.[[BR]] [[BR]] Here are more resources:[[BR]] [[BR]] http://www.wildfiregames.com/users/art/wijit/dude.rar [[BR]] http://www.wildfiregames.com/users/art/wijit/dude_accesory.rar [[BR]] [[BR]] In the dude accessories you'll 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]__'''
+
+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:
+
+ \binaries\system\textureconv
+
+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.
+
+ 
+
+The images on the far right show how the engine uses the player color to change between various colors.
+
+'''__[[BR]] [ Object COlor]__'''
+
+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]__'''
+
+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.
+
+ 
+
+'''__[ Other]__'''
+
+'''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.
+
+'''Original Files'''
+
+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.
+
+'''Texture Size'''
+
+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.
+
+'''Terrain Textures'''
+
+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.
+
+ 
+
+'''Terrain Blends'''
+
+            
+
+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.
+
+'''Skybox Textures'''
+
+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:
+
+http://www.wildfiregames.com/users/art/skyboxtexturetest.rar
+
+'''Water Textures'''
+
+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 3^rd^ 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.
+
+[[BR]] '''[[BR]] [ Animation]'''
+
+ 
+
+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.[[BR]] [[BR]] 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
+
+'''__ __'''
+
+'''__[ Tools]__'''
+
+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.
+
+ 
+
+<edit below>
+
+3.6 Animation
+
+3.6.1 Rigging
+
+Rigs can be created with either Biped or standard Max Bones. The use of Biped is recommended for character animation, due it is character animation features and tools. Custom rigs can be created by combining Bones with Biped or completely new rigs from Bones.
+
+We will be using the Skin modifier in Max, not the Physique modifier. Skin is a little faster and a lot more forgiving than Physique. The Skin weight-table is fast and easy to understand, allowing for quick manual adjustments. Skin is compatible with both Ma Bones and Biped. Furthermore, due to the constraints of the engine, many of the more advanced features of
+
+Physique cannot be implemented.
+
+Physique is not supported by the current version of the exporter, however, as stated earlier, there is a plug-in to convert Physique to Skin. It produces excellent results, though its use is not recommended. Artists should rig with Skin to begin with, not get into the habit of using the converter.
+
+All vertex weighting should be rigid with only one (1) bone per vertex, vertex weight blending is not supported. In the event that there are blended bone weights on a vertex , the bone with the highest relative weight gets priority. Only the Bones specially listed in the Skin Modifier will be exported, so any bones which do not have any vertices weighted to them should be removed from Bones listing in the Skin dialog box .
+
+3.6.2 Bone/Biped Structures
+
+It is possible, and advisable, to reuse Bone and Biped structures from model to model. The <blah> 3D format stores the geometry and bone animation data separate from each other, making it possible to use one set animation data for several different models. This should be exploited when ever possible, as it will reduce the work in Animation and it will also reduce system requirements for the engine.
+
+Note, however, that the <blah> animation structure stores both rotation and position. This means if you rig several models to one bone structure, you cannot change the size of any of the bones to fit the model. The rig must be exactly the same for each model, otherwise the model will be distorted and the animation will be incorrect and unusable.
+
+3.6.3 Bones/Biped Limits
+
+There is a maximum total of twenty-five (25) bones per object. More bones than this are not supported by the engine, and will not be accepted as a valid animation file in the engine. The exporter will warn you if you are over the limit.
+
+3.6.4 Character Animation
+
+For animated models, the geometry data is exported separately from the animation data. Each animation cycle will be exported separately from Max and will be cued at run-time from the game engine. The idle, walking, running animation should be seamlessly looping animations. The first and last frame of every other animation cycle should usually match the first frame of the idle animation.
+
+3.6.5 Frame Rate and In-Game Interpolation
+
+Advanced Topic: The 3dsmax exporter takes a position and rotation keyframe for every bone at every frame of the animation. However the <blah> game engine actively interpolates between keyframes, and stores keytimes separately making it is possible to conserve animation file space by adjusting the 3dmax frame rate to a value lower than 30 fps.
+
+By sampling the animation at a lower rate, the file size of the animation is also reduced and due to in-game interpolation the animation will not become jerky. By setting the fps to 15, you effectively cut the size of the animation file size and memory requirements in half, the side effect is that the animation is only sampled on every other frame. Setting the fps to a value too low will adversely affect the integrity of the animation.
+
+Also note that because the engine uses linear interpolation (for speed), if you turn in a wide arc between frames you'll see noticeable changes in the speed it’s moving. This is only recommended if you are comfortable with more advanced features of both 3dmax and the engine. If you are in doubt, just leave the 3dmax frame rate at the default of 30 fps.
+
+3.6.6 Initial Default Animation Lists
+
+Note from Constantin: Every unit will have its personal list of animations. Below is just a generic run-down. Added Emotion Animation list, made available by animation blending.
+
+3.6.6.1 Essential Animation List
+
+3.6.6.2 Emotion Animation List
+
+ 
+
+'''[[BR]] [ ACTORS]'''
+
+__ __
+
+'''__[ WHat is an actor?]__'''
+
+            <need to fill out>
+
+'''__ __'''
+
+'''__[ Actor Editor]__'''
+
+            <need to fill out>
+
+ 
+
+'''__[ Actor Viewer]__'''
+
+            <need to fill out>
+
+'''__ __'''
+
+'''__ __'''
+
+'''[[BR]] [ SVN]'''
+
+'''__Definitions__'''
+
+'''Subversion; SVN:''' [http://subversion.tigris.org/ Link] (''!http://subversion.tigris.org/'')
+
+
+ * It records the history and      manages changes to a repository of files by multiple users.
+ * It takes care of ensuring      that we don't overwrite each other's files when we commit files to it, and      checks what you've already downloaded against what's in the repository so      that it'll only download things that have changed since your last update.
+
+'''TortoiseSVN:''' [http://tortoisesvn.tigris.org/ Link] (''!http://tortoisesvn.tigris.org'')
+
+
+ * "A free/open-source      client for the Subversion version control system."
+ * An easy-to-use tool that      integrates with Windows Explorer. It is used to access the Subversion      repository.
+
+'''Repository:'''
+
+
+ * Files are stored in a      central repository. The repository is much like an ordinary file server,      except that it remembers every change ever made to your files and      directories. This allows you to recover older versions of your files and      examine the history of how and when your data changed.
+
+'''__[ Section 1:
+Creating Your Account]__'''
+
+Request an account from '''Jason Bishop''' (Wijitmaker) or''' '''he will have already created one for you and has sent that information to you. You will also be given a User Name (typically the school you represent followed by your first initial and your last name.  Example: wfg_jbishop). This will be used as your personal login to access the SVN repositories.
+
+'''__Section 2: Getting and Installing TortoiseSVN__'''
+
+You can obtain TortoiseSVN from [http://tortoisesvn.net/downloads here] (''!http://tortoisesvn.net/downloads''). Select the latest version available for your operating system. Follow the standard installation procedure and reboot when asked.
+
+ 
+
+'''__Section 3: Making your first Checkout__'''
+
+Now we need to point you to the correct SVN URL and checkout the current SVN source tree onto your harddrive. The current SVN trunk url is:
+
+__[http://svn.wildfiregames.com/svn/art/trunk http://svn.wildfiregames.com/svn/art/trunk]__
+
+''I also suggest creating a unique directory. I use the directory C:\0adart, but feel free to use whatever directory you see fit.''
+
+''The directory you check the game out to should ideally have no spaces in its path. For example, C:\My Documents\0AD may cause problems.''
+
+Next, follow these steps to checkout the SVN tree.
+
+'''1''' In Windows Explorer, navigate to the directory where you want to check the SVN tree out to.
+
+'''2''' Right click to bring up the context menu. Select 'Checkout...' in the SVN section of the menu:
+
+'''3''' In the 'Url of repository' field enter the URL above. Leave all other fields at their defaults (note that the image below uses the incorrect URL – '''USE URL AS DIRECTED ABOVE'''):
+
+'''4''' After pressing OK, a dialog referring to caching the CVS server's host key could come up. Accept that key if it does.
+
+You should then be prompted for your account login. Enter the username and password you have requested. In some cases you may be asked for your password twice.
+
+Once your password has been successfully entered, you should see the repository beginning to download:
+
+Note: This will take a while. That's perfectly normal. You're checking out over a hundred megabytes of stuff. Leave it to get on with it, and go do something else for a while.  If it errors, give it a moment and repeat the checkout steps.
+
+Checkout puts a lot of strain on the server. If it times out, try checking out sub-sections of the repository at a time, or try again later when less members are downloading.
+
+'''__[ Section 4:
+Updating your files]__'''
+
+A key component to any version control system is the ability to update your files to the latest versions available in the repository. Much like the rest of your everyday SVN operations, TortoiseSVN makes this extremely easy. The following steps will detail how this is done:
+
+'''1''' Select the file, files or directories that you want to update ('''NOTE:''' I suggest updating entire modules of the project at a time. For instance, update the entire 'source' or 'binaries' module, or both. This will keep your entire source base in sync with the Subversion tree. If you have a reason to only update a subset of the projects objects, then you may do that as well)
+
+'''2''' Right click to bring up the context menu. In the SVN section of the menu, select 'Update...':
+
+'''3''' You should immediately see a status dialog detailing what SVN is updating:
+
+The next two sections describe how to add to or change the repository contents, and are only available to accounts with write access (artists and programmers).
+
+'''__Section 5: Making your first commit__'''
+
+Once you have made some changes and are ready to check them in, you will need to commit them. You can commit an entire directory (and all of its sub-directories), a group of files, or a single file. Use the following steps to commit files to Subversion:
+
+'''1''' Select the file, files or directories that you want to commit.
+
+'''2''' Right click to bring up the context menu. Select 'Commit...' in the SVN area of the menu:
+
+'''3''' Enter appropriate comments about the changes in the 'Enter Log Message' dialog:
+
+'''4''' Press 'OK'. The commit should begin and you should see the following status dialog:
+
+'''__Section 6: Adding files to the repository__'''
+
+Before you can commit a new file to the repository, you must first add it. Adding files to the repository is much like committing them, just use the following steps:
+
+'''1''' Select the file, files or directories that you want to add.
+
+'''2''' Right click to bring up the context menu. Under the 'TortoiseSVN' sub-menu, select the 'Add...' option:
+
+'''3''' Confirm which files you want to add to the repository:
+
+'''4''' Press 'OK'. You will see a status dialog detailing what was added to the SVN repository:
+
+'''NOTE:''' To finalize the addition of files to the SVN repository you must '''commit''' the files you added! Follow the section on committing files above to see how that is done.
+
+'''__[ Section 7:
+Locking a folder for your use alone]__'''
+
+'''__ __'''
+
+In some cases it is advantageous to lock a specific folder or file so that only you are able to modify that.  This is sometimes required to maintain configuration control or possibly you were given a specific assignment and you did not want other to interfere with your work.  '''____'''
+
+'''1''' Select the file, files or directories that you want to lock.
+
+'''2''' Right click to bring up the context menu. Under the 'TortoiseSVN' sub-menu, select the 'Get Lock...' option:
+
+ 
+
+'''3''' Enter appropriate comments about the changes in the 'Enter a message desribing why you lock the file(s)' dialog:
+
+ 
+
+ 
+
+'''4''' Press 'OK'. SVN will proceed to lock the file(s) as specified.   To reverse the process, use the SVN dialog to ‘Release
+
+'''__[[BR]] __[ Folder Structure]'''
+
+ 
+
+DATA
+
+  ╚MODS
+
+     ╚OFFICIAL
+
+       ╚ART
+
+          ╠'''ACTORS'''
+
+          ║ ╠FAUNA
+
+          ║ ╠FLORA
+
+          ║ ╠GEOLOGY
+
+          ║ ╠PROPS
+
+          ║ ║ ╠FAUNA
+
+          ║ ║ ╠FLORA
+
+          ║ ║ ╠GEOLOGY
+
+          ║ ║ ╠STRUCTURES
+
+          ║ ║ ╠TEMP
+
+          ║ ║ ╚UNITS
+
+          ║ ╠STRUCTURES
+
+          ║ ╠TEMP
+
+          ║ ╚UNITS
+
+          ╠'''ANIMATION'''
+
+          ║ ╠BIPED
+
+          ║ ╠GAIA
+
+          ║ ╠MECHANICAL
+
+          ║ ╠QUADRAPED
+
+          ║ ╚SIMPLE
+
+          ╠'''MATERIALS'''
+
+          ╠'''MESHES'''
+
+          ║ ╠GAIA
+
+          ║ ╠PROPS
+
+          ║ ╠SKELETAL
+
+          ║ ╠STRUCTURAL
+
+          ║ ╠TEMP
+
+          ║ ╚TEST
+
+          ╠'''SKELETONS'''
+
+          ╚'''TEXTURES'''
+
+            ╠ANIMATED
+
+            ╠CURSORS
+
+            ╠PARTICLES
+
+            ╠SKIES
+
+            ╠SKINS
+
+            ║ ╠GAIA
+
+            ║ ╠PROPS
+
+            ║ ╠SKELETAL
+
+            ║ ╠STRUCTURAL
+
+            ║ ╠TEMP
+
+            ║ ╚TEST
+
+            ╠TERRAIN
+
+            ║ ╠ALPHAMAPS
+
+            ║ ╚TYPES
+
+            ╚UI
+
+ 
+
+'''[[BR]] [[BR]] '''
+= [ Appendix A] =
+
+= [ PMD File Format] =
+PMD files store a model, which includes vertex positions, normals and texture coordinates, faces (all faces are triangles), rest state bone transformations (if bones are used), and prop point positions and transformations (where other models may be propped onto this one).
+
+All types are stored in little-endian format. Text is always ASCII. The following is the version 2 PMD format:
+
+
+{{{
+PMD {
+}}}
+{{{
+   char magic[4];  // == "PSMD"
+}}}
+{{{
+   u32 version;  // == 3
+}}}
+{{{
+   u32 data_size;  // == filesize-12
+}}}
+{{{
+ 
+}}}
+{{{
+   u32 numVertices;
+}}}
+{{{
+   Vertex vertices[numVertices];
+}}}
+{{{
+ 
+}}}
+{{{
+   u32 numFaces;
+}}}
+{{{
+   Face faces[numFaces];
+}}}
+{{{
+ 
+}}}
+{{{
+   u32 numBones;
+}}}
+{{{
+   BoneState restStates[numBones];
+}}}
+{{{
+ 
+}}}
+{{{
+   u32 numPropPoints;
+}}}
+{{{
+   PropPoint propPoints[numPropPoints];  // note: PropPoint has variable size (see below)
+}}}
+{{{
+}
+}}}
+{{{
+ 
+}}}
+{{{
+Vertex {
+}}}
+{{{
+   Vector3D position;  // in world space, matching the restStates pose
+}}}
+{{{
+   Vector3D normal;
+}}}
+{{{
+   float u, v;
+}}}
+{{{
+   VertexBlend blend;
+}}}
+{{{
+}
+}}}
+{{{
+ 
+}}}
+{{{
+VertexBlend {  // represents the set of bones affecting a vertex
+}}}
+{{{
+   u8 bones[4];  // bone indices; 0xFF in any position indicates "no bone" for vertices with fewer than 4 bones
+}}}
+{{{
+   float weights[4]; // add up to 1.0 (0 is used for unused bones)
+}}}
+{{{
+}
+}}}
+{{{
+ 
+}}}
+{{{
+Face {
+}}}
+{{{
+   u16 vertices[3];  // vertex indices; all faces are triangles
+}}}
+{{{
+}
+}}}
+{{{
+ 
+}}}
+{{{
+BoneState {
+}}}
+{{{
+   Vector3D translation;
+}}}
+{{{
+   Quaternion rotation;
+}}}
+{{{
+ 
+}}}
+{{{
+   // the bone's final transform matrix is translation * rotation
+}}}
+{{{
+}
+}}}
+{{{
+ 
+}}}
+{{{
+PropPoint {
+}}}
+{{{
+   u32 nameLength;
+}}}
+{{{
+   char name[nameLength];
+}}}
+{{{
+ 
+}}}
+{{{
+   Vector3D translation;
+}}}
+{{{
+   Quaternion rotation;
+}}}
+{{{
+ 
+}}}
+{{{
+   u8 bone;
+}}}
+{{{
+ 
+}}}
+{{{
+   // the prop point's final transform matrix is boneTransform * translation * rotation,
+}}}
+{{{
+   // where boneTransform is that of the given bone or identity if no bones are used
+}}}
+{{{
+}
+}}}
+{{{
+ 
+}}}
+{{{
+Vector3D {
+}}}
+{{{
+   float x, y, z;
+}}}
+{{{
+}
+}}}
+{{{
+ 
+}}}
+{{{
+Quaternion {
+}}}
+{{{
+   float x, y, z, w;
+}}}
+{{{
+}
+}}}
+Some meshes also use PMD version 1. The only difference between this and version 2 is that no prop points are specified (there is no numPropPoints and no propPoints array).
+
+Some use PMD version 2. These store vertex positions/normals already transformed by the inverse of restStates. That can only work correctly when !VertexBlend has only a single non-zero weight, so PMD version 3 stores vertices in world space instead.
+
+The algorithm for calculating vertex data under a skeletal animation is:
+
+
+{{{
+pos = (0,0,0)
+}}}
+{{{
+norm = (0,0,0)
+}}}
+{{{
+for i = 0 to 3:
+}}}
+{{{
+  if blend.bones[i] != 0xFF:
+}}}
+{{{
+    inverseRestMatrix = (restStates[blend.bones[i]].translation * restStates[blend.bones[i]].rotation) ^ -1
+}}}
+{{{
+    animatedPoseMatrix = animatedBoneStates[blend.bones[i]].translation * animatedBoneStates[blend.bones[i]].rotation
+}}}
+{{{
+    pos  += blend.weights[i] * animatedPoseMatrix * inverseRestMatrix * (position,1)
+}}}
+{{{
+    norm += blend.weights[i] * animatedPoseMatrix * inverseRestMatrix * (normal,0)
+}}}
+{{{
+norm = normalise(norm)
+}}}
+{{{
+ 
+}}}
+'''[[BR]] '''
+= [ Appendix B] =
+
+= [ PSA File Format] =
+PSA files store a skeletal animation, which consists of bone states at a number of keyframes (see Appendix A). Animations can only be applied to models with the same number of bones in the same order (no bone names are used, only indices). Although PSA contains a name field and a frame length field, these are no longer used in the game since animation variants and total animation lengths (so the same animation can be reused with different lengths) are given in the actor XML files.
+
+All types are stored in little-endian format. Text is always ASCII. The following is the version 1 PSA format:
+
+
+{{{
+PSA {
+}}}
+{{{
+   char magic[4];  // == "PSSA"
+}}}
+{{{
+   u32 version;  // == 1
+}}}
+{{{
+   u32 data_size;  // == filesize-12
+}}}
+{{{
+ 
+}}}
+{{{
+   u32 nameLength;
+}}}
+{{{
+   char name[nameLength];  // no longer used in the game
+}}}
+{{{
+ 
+}}}
+{{{
+   float frameLength;  // no longer used in the game, not valid for most of the animations
+}}}
+{{{
+ 
+}}}
+{{{
+   u32 numBones;
+}}}
+{{{
+   u32 numFrames;
+}}}
+{{{
+ 
+}}}
+{{{
+   BoneState boneStates[numBones * numFrames];
+}}}
+{{{
+ 
+}}}
+{{{
+   // the state of bone b at frame f is stored in boneStates[f * numBones + b]
+}}}
+{{{
+}
+}}}
+{{{
+ 
+}}}
+{{{
+BoneState {
+}}}
+{{{
+   Vector3D translation;
+}}}
+{{{
+   Quaternion rotation;
+}}}
+{{{
+ 
+}}}
+{{{
+   // the bone's final transform matrix is translation * rotation, as in PMD
+}}}
+{{{
+}
+}}}
+{{{
+ 
+}}}
+{{{
+Vector3D {
+}}}
+{{{
+   float x, y, z;
+}}}
+{{{
+}
+}}}
+{{{
+ 
+}}}
+{{{
+Quaternion {
+}}}
+{{{
+   float x, y, z, w;
+}}}
+{{{
+}
+}}}
+{{{
+ 
+}}}
+{{{
+ 
+}}}
+{{{
+ 
+}}}
+