Development:Model Guidelines
 Development
|
Contents
Model Guidelines
Introduction
The intention of this document is to give artists using the Vega Strike engine some suggested guidelines to follow in creating models. These are not fixed rules, and those of you with experience will appreciate that many of these can be broken. 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.
Technical Specification
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, soon 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).
Polgon/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
Likewise, for larger models, do not neglect the potential addition of detail textures.
Shield and Collision Meshes
Seperate shield meshes are highly desireable. 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).
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.)
Development:Texture Guidelines
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).
