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.

Note: If you wish to contribute a new or updated model (ship, installation, turret, cockpit, ..) to the game Vega Strike, please see the 3D Models page for models requiring attention.

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 + mtl 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	bfxm + dds textures	vegastrike + modelview.mission	pass or rework	-
Submission	blender file (obj + mtl), 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

Model Requirements Details

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.

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.

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.

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

Note: The tutorials overview is not complete. Many of the available tutorials have not yet been integrated into this page. Refer also to the How-Tos Tutorials page for additional 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...

Wings3D Basics

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, ...)

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

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:

[author:chuck_starchaser] Here's a blend file people could load and save as the default blender start. 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. http://wcjunction.com/temp_images/cinemut/goodstart.blend You can also import the marker into another blend file: Open whatever.blend, go to File -> Append Or Link Navigate to where goodstart.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 "gunmount_0_light_medium" or whatever.

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:

pilot
pilot_john
mount_lightmedium_0
turret_capmissile_frontleft
subunit_1
engine_retro_left

Updating Stats

Submission and Vetting

Technical Reference

Technical Specifications

Scripts and Tools

See Scripts & Tools

mesher converter obj <-> bfxm <-> xmesh

References

WCpedia Modeling Page

Development:Model Guidelines

Contents