Development:Model Guidelines

Development

Introduction

The intention of this document is to give artists using the Vega Strike engine some suggested guidelines to follow in creating models. You may also wish to have a look at the corresponding texturing guidelines.

So you want to create a new ship for Vega Strike, do you? While virtually all models are welcome, well before you start cranking out wonderfully designed models we request that you first check what models are still required.

Alternatively, contact jackS or pyramid.

Modeling Pipeline Overview

Step	Input	Output	Tools	Requirements	Tutorials
Model Selection	-	required model	model task list	-	-
Conceptualization	selected model	model concept	pen & paper, artwork forum	artstyle guide	-
Modeling	concept	model mesh, obj files	blender, forum	many	-
Texturing	model mesh	textures	gimp, forum	texture requirements	-
Integration	model + textures	bfxm + dds textures	mesher + UnitConverter	-	-
Testing	bfxm model + dds textures	visual + behavior	vegastrike + modelview.mission	pass or rework	-
Submission	blender file + obj, master textures, bfxm + dds textures	archive or svn	mail, svn client	-	-

Model Requirements

Requirements Checklist

Considerations for a successful model submission:

• Model is in the requirements list ->
• Abides to faction visual guidelines
• Has approved concept
• Provides model source file (blender, Wings3D, ...)
• Provides OBJ file
• Has model mesh, shield mesh, LoD meshes, helper meshes
• Provides uncompressed textures in png format (and optionally faction textures)
• Provides texture source files (GIMP, ...)
• Provides HUD png image with correct orientation
• Provides units.csv file entry

Visual Guidelines

For particular aesthetic guidelines, please see the Artstyle guides page. Please note that many of the existing models are used because of expedience, not because they fit well with VS canon (i.e. if you make something new look like what's there, it still might not be what we're looking for). If in doubt, please ask on the Artwork & Content Vetting forum.

To absolutely sure, for new models, please create a drawing of your proposed concept and let it be discussed and approved on the Artwork & Content Vetting forum.

See also Development:Texture Guidelines

Model File Format

The preferred format for submission (for public disbursement - whatever native format is used inside your favorite modeling suite is fortunately a non-issue) is currently Wavefront OBJ file format, as this is the most easily converted between manipulation (assorted modeling tools) and presentation (currently BFXM, later to be the OGRE .mesh format). Model "source" therefore, is, at present (Sep. 2008), most usefully uploaded as .OBJ.

Until such a time as a visual model editing tool is completed, conversion to a game-ready format will likely pass through the .xmesh format for insertion of LOD references into top level mesh(es), correction of coordinate "handedness" (if the ordering of the coordinate axes is incompatible, as appears to happen with the output of some modeling tools).

See HowTo:Add_Ships for information on using mesher to convert to a presentation format (such as BFXM). Note that an old utility, objconv, is not mesher, and should not be used for this task. Source files for the mesher utility are included along with VS source. Windows users may download updated mesher binaries from their SVN interface of choice (the binary will be in the \bin directory).

Polygon/Vertex Count

In broadest terms, the desired polygon count for a particular model is dependent on three major factors:

• The amount of screen real-estate that the model is likely to be viewed at the majority of time that a user will be seeing it (i.e. a 2 meter long rocket doesn't deserve the same order of magnitude of attention to detail as a large base or vessel unless the rocket is expected to be mounted in front of a camera. Likewise, even at the same level of attention in terms of polygons per square meter, it would have far fewer total polygons.)
• The intrinsic surface complexity of the model. If one is modeling a box for freight cargo, one is not going to need as many polygons as if one needed to model one of the Vega Strike developers (not that we're necessarily model material ;-)). If you don't use enough polygons, no amount of texture magic can save a model from being ugly. That said, if you are modeling a cargo freight container and you use thousands of polygons, you're being negligent and wasteful of resources.
• Engine limitations. Engine limitations is a bit of a misnomer, as the performance of the graphical engine is more hardware dependent than anything else, but it's a good heading for lumping any non-artistic hurdles under. This is the most complicated of the three major factors, because it represents a moving target. Suffice it to say that in order to preserve playability on a broad range of systems, there is a premium placed on making a model aesthetically appropriate with the minimum number of polygons.

Rough guideline:

• Fighter: 15k triangles
• Corvette: 30k tris
• Cruiserer: 60k
• Carrier: 120k
• Space station: 250k

However, significant discression, and the possibility for using large numbers of polygons to prettify an object remain with the artist, provided they make appropriate use of LODs. The primary focus needs to be on making a model aesthetically appropriate, for an intended common viewing distance, and then catering to the needs of the engine by introducing lower LODs (if necessary) and catering to artistic desires by introducing higher LODs (if appropriate). There is also an element of minor future proofing that occurs with providing a robust range of LOD poly counts - namely, multiple versions of the data set can be constructed targeted at different hardware points by shifting up or down along the LOD set (although this currently isn't bothered with, if and when we develop a true source repository for models and textures, this will likely become more common, as postprocessing of submitted art will become tenable).

One more point to consider before attempting to set a polygon goal for a model is what the likely total contribution from all instances on screen of a given model will be - if the model represents something particularly rare, then it is likely that a few more polygons can easily be spared on its model than for more common objects of otherwise similar size, complexity, etc.

Above all, use common sense - if it's visually hideous because it doesn't have enough polygons, it's not your top level model, and if it's in the 5 digit range for polygon count, it's not your lowest level LOD. Take into consideration how much screen real estate, based on the intended in-game size of the model (and if you don't have any idea how big it's supposed to be - you're doing something wrong already) the model will be taking up at various distances, and calibrate detail appropriately (this will become a much easier task once there is a visual modeling tool from the VS side) - to belabor the obvious, the difference between 500 polygons and 5000 gets somewhat obscured when the object is only drawn using 64 pixels. Note therefore that larger objects will often necessitate higher polygon counts merely because there's more of them to see.

(Note that there is no need to continue adding LODs beyond a point of "diminishing artistic returns" - if adding more detail won't help, don't bother. If adding detail helps, but is too expensive to be practical, then it may still be worthwhile for later inclusion as hardware resources increase.)

For small to moderate craft and installations, something along the lines of either of the following is not inappropriate:

(Exponential Scaling)

• LOD 0 <= 500 tri's.
• LOD 1 <= 2000
• LOD 2 <= 4000
• LOD 3 <= 8000
• LOD 4 <= 16000
• LOD 5 >16000

(Quadratic Scaling)

• LOD 0 <= 500 tri's.
• LOD 1 <= 2000
• LOD 2 <= 4500
• LOD 3 <= 8000
• LOD 4 <= 12500
• LOD 5 <= 18000
• LOD 6 >18000

Larger models, such as capital vessels and large installations will likely follow a similar curve, but at a higher offset, due to increased size. Truly massive models should be partitioned into multiple meshes, each with its own set of LODs such that nearer portions of the model can be independently represented at higher LOD than more distant ones. Partitioning into multiple meshes may be preferable even for merely "largish" models so as to preserve reasonable correspondence between single pixels and the size of represented features when texturing.

Textures

Texture maps should also be made accordingly, although clearly artistic integrity trivially trumps the following rough guideline (if you need more pixels, use them) and the appropriate texture size may depend greatly upon the size of the model.

• LOD 1 128x128
• LOD 2 256x256
• LOD 3 512x512
• LOD 4 1024x1024
• LOD 5 and up having multiple 1024x1024 textures

Be careful with texture lodding abuse. Each LOD that uses its own texture will require more memory (video memory), and breaks batching between instances (slows down rendering of many instances of this model). Even so, texture lodding actually frees up memory most of the time, since only lesser versions are used in the distance. A general rule of thumb is to never have more than two or at most three versions of the same texture. Also take any opportunity to convert textures to greyscale when the color loss is not quite noticeable (most commonly with glow maps and specular maps).

Likewise, for larger models, do not neglect the potential addition of detail textures.

See also Development:Texture Guidelines and Development:Graphics_Requirements.

Faction Textures

To include and successfully test faction textures in your data, you need to:

• set the corresponding vegastrike.config variable (var name="faction_dependant_textures" value="1").
• prefix default textures with the faction name, e.g. when your default texture is called "tex_000.texture", to enable the faction texture for "pirates" you'll need to add the texture "pirates_tex_000.texture".
• change configuration to one of the 2 highest computer modes (512M+1GB or 1024MB).

Shield and Collision Meshes

Separate shield meshes are highly desirable. Shield meshes should also be done using LODs, although shield meshes should remain simple - that is, their top level meshes should not contain odious numbers of polygons for something that is only infrequently displayed.

Collision meshes need not (and cannot) have LODs. For complex models, it is wise to provide a dumbed-down version of the model that reasonably approximates its shape - minor features and greebles can be safely removed, for instance - to improve performance on the physics engine. Polycount should be kept to a minimum, without sacrificing any major features of the top-level LOD. Very small vessels (or appropriately shaped ones) may opt to not specify a collision mesh, which will make the physics layer treat this mesh as a spherical object (most efficient).

HUD Image

Provides perspective view of the model oriented with the nose towards the left-bottom corner of the image. The master image resolution should start at 256x256 pixels with transparency around the vessel.

See also

For an example of an entity that is composed of multiple meshes, uses LODs, and shield meshes, examine the Clydesdale. (Note that shield and collision meshes are specified in the units.csv file, not by the model.)

Model Creation

The first (and most enjoyable) job is to design and draw your model (the geometrical object) within your program.

Feel free to use any modeling program, but it must be able to export models in either (Wavefront) .OBJ or (Vega Strike) .xmesh format. If you don't know where to start, see Links:3D Applications for a list of modeling software. Wings 3D is recommended for modeling beginners. Blender is the tool of choice for VS artistic community.

Orientation

First off, do yourself a favor and line your model up correctly before you begin. For the purposes of Vega Strike, Z+ is forwards and Y+ is up. The model's nose should be pointing forward along the Z+ axis (so that the Z+ axis would theoretically be visible from the cockpit). The mesh should also be properly centered. Summing up:

• Z+ -> Forward direction
• Y+ -> Up direction
• Centered

Tutorials

Modeling Step	Blender	Wings3D
Create mesh	-	Creating a 3D-model
Smoothing	Smoothing Smooth Welding	-
Mesh cleanup	Beveling	-
Unwrapping	Unwrapping 1 Unwrapping 2 Ship unwrap	-
Radiosity Baking	Radiosity baking	-
Exporting	-	-

This articles are WIP, means still need to be reviewed and decided how to restructure them:

• Creating a 3D cockpit for your ship.
• Adding Levels of Detail
• Adding your ship to Vega Strike - An overview of how to create and add ships to the game
• HowTo:Create Models - Links to forum discussions. Page will become generic model creation tutorial.
• Modeling Tutorials: HowTos#Modeling

Blender Basics

• A basic Blender3D tutorial: Blender Basics - 3rd Edition - not specific to ships, though...

Other Software Basics

• Brad Mick's video tutorial on ship modeling - using Lightwave, but the concept is general: Rapid Prototyping

Texture Creation

Unwrapping

Please make non-overlapping UV unwraps for all future models. You can't bake a proper AO with overlapping islands.

Unsorted

(general guidelines, tips, best practices, app specific tutorials, ...)

• WIP VegaStrike texturing page by Major
• Texturing tutorial by Duality

For the time being, you may wish to have a look at the corresponding Texturing Guidelines.

• Guidelines for creating ship materials

• Adding per-pixel lighting to your 3D model
• Introduction to shaders, and what they mean for you --Bumpmaps, Normalmaps, Shininess maps ...

• Creating your own textures - A summary on how to make texture maps
• Texturing your model in Wings 3d
• Tips for realistic-looking textures
• Using animated textures on a model
• LaGrande Noodle
• AO and PRT bakes, using Blender and xNormal

Please remember that good bump/normal maps save a lot of performance - triangle count can be cut by orders of magnitude. Example: does this scene look like 265 000 triangles total? When much more detailed objects are baked into normalmaps, we may guess which parts are actually flat, but not see it. Even what seemed to be minor shortcomings in UV mapping from afar may become more realistic when close enough (the left pole).

Integration and Testing

Using UnitConverter to convert all files and edit the model stats for Vega Strike: Development:Tools:UnitConverter

Object Marker

In order to automatically create turret mounts, gun mounts, and engine thrusters placements in units.csv, please use the following marker:

The shape is 1 units wide in X, 2 units tall in Y, 4 units long in Z. Four vertices in total. The center between the two vertices on X is the origin; the vertex on Z marks the forward direction; the vertex on Y marks the up direction. The exported object names are ready and the forward and up directions are calculated from the marker dimensions. Thus, we don't need to worry about mesh rotations; we can deduce mesh rotation from the marker.

The dock marker for docking ports is an exception, since the docking square in game is always rendered facing the player, so the orientation doesn't really matter and only the center matters for the docking port position.

[author:chuck_starchaser]

• Here's the marker blend file (you could load and save as the default blender start):
  • modtools/UnitConverter/helper/mount_helper.blend
• Starts with a marker smack in the middle.
• You can move it to another layer, later duplicate it as needed to place copies at key locations.
• You can also import the marker into another blend file:
  • Open whatever.blend, go to File -> Append Or Link
  • Navigate to where UnitConverter/helper/mount_helper.blend is.
• Go to the "Objects" folder, and click on the "Marker" object.
• To duplicate an object, in object mode, select and shift-D.
• To rename your duplicated object, hit F9 and, towards the left, where it says OB:Marker click in the middle of it and then type "turret_heavy_0" or whatever.
• copy all markers to layer 2
• select layer 2
• select all markers with the A key
• export to obj using Edges, Objects

The above image shows the markers set as the centers of engine thrusts.

It is advisable to group the marker objects into a group called "marker". You are required to export all the markers into one obj file that needs to contain the name "marker" in it (letter case is unimportant, it can be "marker", or "Marker").

Object Helper naming convention: type_subtype_identifier

with type:

• pilot (currently unused)
• mount (currently unused)
• turret
• subunit
• engine
• dock

and subtype being optional (convention tbd), and identifier being either a number or a description and optional.

You may define for example:

• dock
• dock_auto_20
• mount_lightmedium_0
• turret_capmissile_frontleft
• subunit_1
• engine_retro_left

Updating Stats

• Putting ship and goods descriptions into the game
• Editing the Master_part_list.csv file

Technical Reference

Technical Specifications

• Editing BFXM files (format spec)
• Editing the xmesh file of a ship
• Editing units.csv
• Adding an engine glow to your 3D model

Scripts and Tools

See Scripts & Tools

• mesher converter obj <-> bfxm <-> xmesh
• UnitConverter

References

• WCpedia Modeling Page