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.

Note: If you wish to contribute a ship to the game Vega Strike, please see the 3D Models page and/or contact jackS or pyramid.

Model Guidelines

Model Requirements

Format

The preferred working format (for public disbursement - whatever native format is used inside your favorite modeling suite is fortunately a non-issue) is currently Wavefront OBJ + .mtl files, as those are 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 (12/05), 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 CVS 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 minumum 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 polycounts - namely, multiple versions of the dataset 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 particulary 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.

Texture maps should also be made accordingly, although clearly artistic integrity trivially trumps the following rough guideling (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 breakes 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 oportunity 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.

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

Textures

Development:Texture Guidelines

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 meshes are specified in the units.csv file, not by the model.)

Visual Guidelines

For particular aesthetic guidelines, please see the Artstyle guides page. Please note that many of the existing models are used because of expediance, 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).

See also

Development:Texture Guidelines

Modeling Workflow

Model Creation

Model Creation with Blender

Basic Blender Tutorial: Blender Basics - 2nd Edition

Modeling Tutorials: HowTos#Modeling

Model Creation with Other Software

• 3DSMax
• Lightwave

Texture Creation

For the time being, you may wish to have a look at the corresponding texturing guidelines.

Model Conversion

See in particular HowTo:Add_Ships#New_method

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

Object Placement 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

References

This is just asset collection for the restructuring of this page

• Guidelines for creating ship materials
• 3D models list and status
• 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 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
• Editing BFXM files (format spec)
• Editing the xmesh file of a ship
• Adding Levels of Detail
• Adding an engine glow to your 3D model
• Adding per-pixel lighting to your 3D model
• Editing units.csv
• Creating a 3D cockpit for your ship.
• Introduction to shaders, and what they mean for you --Bumpmaps, Normalmaps, Shininess maps ...
• Radiosity baking in Blender
• Putting ship and goods descriptions into the game
• Editing the Master_part_list.csv file

• WIP VegaStrike texturing page by Major
• Texturing tutorial by Duality
• WCpedia Modeling Page