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.

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 conceppt 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.

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 [Terminology:LODs|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 grayscale when the color loss is not quite noticeable (most commonly with glowmaps and specmaps).

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

See also Development:Texture Guidelines

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

(with blender, wings, max, lightwave, ..., including export requirements)

• Adding your ship to Vega Strike - An overview of how to create and add ships to the game
• HowTo:Create Models - A summary on how to create a new model for Vega Strike
• Brad Mick's video tutorial on ship modeling - using Lightwave, but the concept is general: Rapid Prototyping
• Creating a 3D-model using Wings3D - includes general guidance for other modeling programs
• A basic Blender3D tutorial - not specific to ships, though...
• Understanding "Smooth Groups" - a Blender tutorial on splitting smooth groups...
• Getting bevels to look good - a Blender tutorial on smooth shading and beveling...
• Smoothly Welding complex shapes - a Blender tutorial on smooth welding...
• Unwrapping your model - How to UV-map your ship so it can be textured
• Using Blender to unwrap your model - A blender UV-mapping tutorial
• Full ship unwrap tutorial (Blender) - Full ship UV unwrap, from A to Z
• Creating a 3D cockpit for your ship.
• Radiosity baking in Blender

Model Creation with Blender

Basic Blender Tutorial: Blender Basics - 2nd Edition

Modeling Tutorials: HowTos#Modeling

Model Creation with Other Software

• 3DSMax
• Lightwave

Texture Creation

(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

Integration and Testing

See in particular HowTo:Add_Ships#New_method

• Editing BFXM files (format spec)
• Editing the xmesh file of a ship
• Adding Levels of Detail
• Adding an engine glow to your 3D model
• Editing units.csv
• Putting ship and goods descriptions into the game
• Editing the Master_part_list.csv file

Object Placement Helper

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

[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. See if the exported obj has the object names.

Object Helper naming convention: type_subtype_identifier

with type:

• pilot (currently unused)
• mount
• 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

Technical Reference

Scripts and Tools

See Scripts & Tools

References

• WCpedia Modeling Page