Models

From BISim Wiki - Mirror I
Jump to: navigation, search

Should be merged into other articles (e.g. LOD), and split into separate pages.


Contents

LODs

Visual

These are LODs which are rendered by the GPU and are visible to the player, sometimes called resolution LODs, but it would be better to say that visual LODs can have a number of resolutions, each becoming progressively more simplistic. Unlike in VBS1, the VBS2 engine does not consider the index number of the visual LODs, instead it simply expects that each visual LOD will be half as detailed as the previous, and it will switch these LODs in the scene as necessary to preserve an acceptable framerate.

The engine will make LOD changes to based on the assumption that each resolution LOD is 50% lower in face count than the previous one. The number of LODs needed varies based on object complexity but usually 4 to 6 visual LODs is enough and the last and lowest detail LOD should be around 200 faces.

There are also special visual LODs used only in first person view inside vehicles. If you are creating a vehicle model which is missing all of these LODs, your vehicle will cause VBS2 to crash to desktop when you try to sit in the driver's seat. There are three types of special view LODs:

View - Cargo

This is used when a special level of detail is needed to present crew members with a high detail interior of a vehicle which isn't needed in the normal visual LODs. Any parts that can't be seen by any passengers can be removed to reduce file size. All vehicles at least need a View - Cargo LOD, but the following two view LODs are optional.

View - Pilot

This is used when a special level of detail is needed to present a vehicle driver with high detail cockpit instrumentation which isn't needed to be seen by other crew members or external players. This is only used when vCargo isn't good enough, for example, the cockpit of a C130 should be done in View - Pilot and the cargo area is done in View - Cargo since they are distinctly separated areas. When View - Pilot is missing the engine will use View - Cargo instead.

View - Gunner

This is used when a special level of detail is needed to present the gunner with a high detail turret area or gun position which isn't needed by the rest of the vehicle crew. Usually the gunner proxy in View - Gunner will be included in the elevation animation of the gun instead of just the traverse animation, so that his hands stay locked on the gun's handles. When View - Gunner is missing from the model, the engine will use vCargo instead. A turned out gunner currently always uses the 1st visual LOD instead of View - Gunner.

Common errors: There are a few errors that occur in resolution LODs that must be fixed. It's a really good idea to clean the 1st LOD before making the others, so that you don't clone the errors into more LODs. To get the error report in O2, use Automation > Check All. This script will check the whole model and output the results to the script console.

Geometry

Collision detection has a much higher fidelity in VBS2 than it had in VBS1, so we can use smaller shapes without getting strange results. However, the number of components used must be kept as low as possible. Especially the collision geometry, should be kept as simple as possible. The Geometry LOD has a special representation of vertices, it shows grey boxes that represent the vertex weighting. Vertex weighting in a Geometry LOD is used to distribute mass. The mass toolbar only works in the Geometry LOD.

Fire Geometry is only added when the normal Geometry isn't detailed enough to act for hit detection. If you have a crate, and collision is just a box, then it's also enough for hit detection and you don't need a Fire Geometry. Fire Geometry is where penetrable materials are applied, to control how easily bullets will penetrate a surface, or if thrown objects will pass through (grenades) such as a tent wall. There has been some development of penetrable materials, these are RVMATs which are applied to geometry components, they contain info on material type and density, and this should be applied to the Fire Geometry only.

View Geometry is used to block the view of AI, so if enemy are hiding behind View Geometry they might not be detected. It's also used in some form for occlusion, so objects behind this might not be drawn. If units are disappearing through windows or behind ladders, this is usually the case. This LOD only added when Geometry isn't good enough to do the job. This is used to block the AI's view of targets.

Common errors:

ShadowVolume

This set of LODs is used only to produce stencil shadows, and we can have resolutions here too. Normally we only use two shadow volume LODs, the first around 2000 triangles and the second around 500 triangles. Since this shape will be used to block light, it must be just slightly smaller than the resolution LODs, and can sometimes work well when faces are inverted, but always inspect results in buldozer to make sure it's working as expected. Double-sided faces are allowed (like untextured polyplane) and these are very important to making realistic shadows while keeping face count low. All components in shadowVol must be:

General Guidelines

Some general guidelines followed by specific usage for different model types:

(Note: The following guidelines refer to some named properties that should be added to the geometry LOD)

People:

Vehicles:

Buildings:

Plants:

Common errors:

Hit-Points

Hit points are used to specify weak points of a vehicle which have a different armor rating than the general hull armor value given in the config. These can be configured per vehicle, but some standard values which will already work in VBS2 are:

LandContact

Land contact points should be placed under wheels of wheel type vehicles (4 points), or averaged in the case of tanks (6 points). The points must be connected to the wheel dampers so that the vehicle maintains proper traction over rough ground.

Paths

Paths are essential for the AI to find ways through difficult terrain like a village or the interior of a building. Paths can be useful to any structure that has a walkway or a complicated layout. Besides the movements there is a further tactical aspect, the positions. Positions can be assigned via editor (waypoints) or in-game from leaders directly to any AI agent. The AI agent will stay on this position and will act from here until there is a new order given. Now some more points, especially for developers:

Roadways

Roadways provide a surface upon which people and vehicles can travel. Typical use of roadways is in road models, bridge decks, and the floors, stairs, and rooftops of buildings. For a working roadway, all that is needed is a single-sided plane with normals pointing upwards. When a roadway has no texture assigned, it will have default friction and default sound effects, but special registered textures (CfgSurfaces) can be applied to roadways so that they have additional dust, friction, and sound effects. If you have created a bridge or other type of model for vehicles to drive on, and it seems to slow you down more than it should, check that there are no textures assigned in the roadway LOD.

Edit

These are lods for storing WIP meshes, or reference models etc. They are discarded during binarization so it's a way to keep development materials in the raw P3D model without having unnecessary data in game. There is currently a bug in the pipeline so that that Edit LODs are included in the calculation of the bounding box so they should not have geometry which exceeds the bounds of the actual object in other LODs.

Memory Points

Memory points are single points in a the Memory LOD which have named selections. They are used for positions of effects like smoke, lights, and weapon firing vectors, etc. They are also used as pivot points for animated named selections. The most useful reference will be looking at sample models for the object class you are making.

Named Properties

Named properties are simple parameters which can be included directly into LODs. Some properties have specific effects on the LOD where they are found, others are general named properties which affect the whole model. The general properties should be located in the Geometry LOD which makes it easier to find them.

Geometry LOD

Notes

Placement
"slope"
"slopez" // change slope just in z-dir
"slopex" // change slope just in x-dir
"slopelandcontact" // take first two or three land-contacts and change slope according to them... 

As far as I can read out of the code if one od these is set in shape the code using Keep Height is skiped and the skew is done differently.

So both "placement" and "Keep Height" methods work but "placement" overrides use of "Keep Height".

Flyman says that "Keep Height" along with the matrix skewing also does a shape cutting for better slope alignment and obviously this is quite consuming process.

Frequent

From news:isl9cu$ima$2@new-server.localdomain 

To clarify, the main purpose of property "frequent" is that it extends size limit of allocated vertex buffer from 8000 vertices to 32000 vertices. Apart of that we cannot have more than 45 items in the instancing chain.

This particular model of building (let's consider the worst LOD) has got 32 vertices, which means that even 45 instances have just 1440 vertices and it makes no sense to use property "frequent" in their case.

It would start to be interesting if the LOD would have 200 vertices - we could afford only 40 instances then and with bigger numbers the difference would be bigger.

Hard to say how big improvement the "frequent" propery brings in our real scenes. Our rough LODs are usually modeled much under 200 vertices and maybe our scenes are dense enough, so that we don't see too many models in finer LODs to take advantage of the improved instancing with "frequent" property.

In any case, please keep using the "frequent" property as it was up to now as an advice to engine for possible optimalizations.

From what I understand, we don't see the original problem (performance decrease with "frequent" property) anymore (which would be very strange).

Resolution LOD

Named Selections

IMPORTANT! Selection should no longer be nested as they were in VBS1. Now the heirarchy is done through the model.cfg and will use proper forward kinematics from parent bone to child bones.

General vehicles

(indicator/reverse lights go here)

Helicopters

Planes

Instruments

Buildings

Retrieved from "http://www.contrex.ca/wiki/Models"
Personal tools
Namespaces
Variants
Actions
Navigation
Toolbox