- 1 What's a LOD?
- 2 <resolution>
- 3 Edit
- 4 Geometry
- 5 Geometry Phys
- 6 Fire Geometry
- 7 Geometry Buoyancy
- 8 Hit-points
- 9 Memory
- 10 Paths
- 11 Roadway
- 12 LandContact
- 13 ViewGeometry
- 14 View - Cargo
- 15 View - Cargo - Fire Geometry
- 16 View - Cargo - Geometry
- 17 View - Commander
- 18 View - Commander -Fire Geometry
- 19 View - Commander -Geometry
- 20 View - Gunner
- 21 View - Gunner - Fire Geometry
- 22 View - Gunner - Geometry
- 23 View - Pilot
- 24 View - Pilot - Fire Geometry
- 25 View - Pilot - Geometry
- 26 ShadowVolume
What's a LOD?
LOD means Level of Detail, and is a method of defining, via different variations of a model, how high or low the viewable quality of the model should be, and how it should interact with the environment.
Note that having too many (30 or more) LOD's in total could cause the binarize process to crash.
Resolution LOD are those LOD that are visible in the game to the player from the outside view. There should always be more than 1 resolution LOD (unless it is a low poly object). In Open-World 3D Games (including all Arma Titles) it is standard practice to swap out high-resolution Models with medium- or low-resolution models at far distance from the observer. This is done to prevent excessive demand of computing ressources. Without the resolution LOD technique, the games would be unplayable due to bad performance.
The switching of different resolution LOD in OFP and Arma is automatic, based on various factors / in-game conditions (e.g. view-distance, number of objects, video quality, CPU utilization, etc.). In Arma 3 the number of the resolution LOD has no impact and there is no way to specify which LOD is to be used at which range. The algorithm needs enough different resolution LOD to be effective. Therefore the modeller needs to provide multiple resolution LOD with different polygon-density. They should be ordered according to their polygoncount (highest polycount has number 0 (or 1), second highest one number 1(or 2) and so on)
Arma 3 example:
|Model||res 1||res 2||res 3||res 4||res 5||res 6|
A common practice is to half the polygon amount for the next lower resolution LOD by ~2 As a guideline, the lowest resolution LOD should have a polygoncount of somewhere around 500 and as few sections as possible. If a resolution LOD has far below 500 Polygons, the amount of sections has a much bigger impact on performance then the Polygoncount (e.g. it doesnt really matter if a resolution LOD has 50 or 400 Polygons, it does matter alot more in this case if it has 1 section or 4 sections). This has to do with how draw-calls work (instructions that the CPU sends to the GPU). In addition to reducing the polygon density, it is best practice to also reduce shader complexity and the amount of textures used - because those too eat valuable ressources. The lowest resolution LOD won't need a normalmap and propably not even a specular or gloss map (test it for your object).
This LOD shouldn't contain any empty Named Selections which are used in animations or by the game engine (wheels, etc.), as that might cause the game to crash once the LOD becomes active. To demonstrate the complexity of the LOD selection, and the effect the resolution name has on LOD switching, a series of tests have been documented here: Resolution LOD Samples
The modelgeometry in each LOD needs to be below a "maximum polygoncount". This "maximum polygoncount" varies depending on how your model looks. The actual limit is based off vertex normals. The total amount of triangles you can use therefore depends on the Smoothing splits and UV splits in your model. According to some tests and documentation of DirectX9 the limit appears to be 2^15 = 32768 vertex normals in ArmA, Arma 2 and early Arma 3 (where DirectX9 is used). In a recent (Q1/2016) update, the .p3d format in Arma 3 was updated to version 70 and now has a higher limit (above 2^16 vertex normals). If you exceed the vertex normal limit, loading your model may crash the game or it simply won't display it. You can check it in Objectbuilder by loading up Bulldozer - if the LOD is not displayed, you are above the limit. Modern 3D modelling tools also offer native or user created tools to check the amount of vertex normals. Please remember that this is the absolute maximum you can use - this does not mean you should fully utilize it on every object.
The default Named Property for resolution LOD's is: LodNoShadow=1.
When using alpha textures inside the model, sometimes Ambient-Shadows of other objects shine through the entire model (instead of just the alpha mapped parts). To fix this, add the named Property "Forcenotalpha=1" to your Geometry LOD (not resolution LOD).
This is a LOD that you can use for temporarily storing models / model parts in the p3d. They are stored regulary like any other LOD. Please note that these LOD's will be included when binarizing, so before you release your mod, delete all edit LODs in your models.
Defines where the model will collide with other objects.
Should be very simple, and has to fulfill the following criteria in order to work:
- Object must be named ComponentXX (where XX is a consecutive number between 01 and 99).
- Must have 'Mass' (Alt-M).
- Must be closed and convex. Always validate your Geometry LOD. (Validating Geometries).
- Some object types require that every component must have some mass assigned in order to work properly. Does not apply to vehicles.
- It must be smaller then the size limit.
If the geometry LOD is larger then the size limit, it gets glitchy (collision does not work for example and the object may disappear at certain view angles). The exact value of the limit is not yet known, but it's somewhere around 50-60 meter from the center of origin (meaning that your object can be 100m wide/long at max if it is symmetrical to the center of origin). According to reports there is no limit skywards, so you could make a tower of 200m height. Note that if your object requires a roadway LOD, you need to stay within the roadway size limit, which is smaller.
Geometry objects should have a thickness of at least 0.5 meters in order to work properly.
- Geometry LOD is used for Collision if one of the colliding Objects is not a PhysX simulated Object. For example living Soldiers are not PhysX objects. Tank-Soldier Collision is therefore determined by Geometry LOD, even-though the Tank is a PhysX simulated Object.
- For PhysX Objects the Mass value and the Mass distribution is critically important for the Objects physical behavior [Keywords: "Inertia" and "Moment of Inertia" ]
- The default Named Properties for the Geometry LOD are: canocclude=0 and canbeoccluded=1 (for Vehicles, Characters and Weapons)
When creating terrain objects that have to be navigated or used by infantry, it's good to keep the infantry metrics in mind
Defines the collision model that is used in a collision between two PhysX Objects.
The same criteria like for the Geometry LOD apply. The difference is that Geometry Phys does not (should not) contain Mass information. The detail should be even lower then in the Geometry LOD if possible, as PhysX collisions are computationally more expensive. For helicopters, cut the blades and any non critical structures out of the PhysX LOD, otherwise the rotor blades can cause critical failure. For tanks or other vehicles with turrets/ large cannons it is best practice not to include the cannon barrel or long protruding turret parts in the PhysX LOD. The rotation of turrets is not limited by forces, therefore the collision of a barrel with the environment will cause the tank or other PhysX objects to move (often very violently, causing serious glitches and flying tanks).
Defines where the model will collide with bullets & rockets. If this LOD is not present the Geometry LOD will be used instead. Should be simplified as much as possible, but can be a bit more complex then Geometry or Geometry Phys
- Object must be named ComponentXX (where XX is a consecutive number between 01 and 99). (see Geometry LOD)
- Must be closed and convex (see: Validating Geometries).
Proxies for the driver & passenger must be present into this LOD as well (they can be copied from the Resolution LOD). Otherwise the units will be invincible. One should also do any geometry validation before adding the proxies, otherwise they will not be functional.
All Components should have a damage material applied. This defined the penetrability of the object and the impact effect type. There are two possibilities for Materials: Normal Materials or Plate Materials.
- Normal Materials only define material characteristics. The thickness is determined by the modelled component.
- Plate Materials have a pre-defined thickness value. The armor thickness check will take the defined thickness and the modelled thickness into account. It will always use the value that is lower.
Example1: A component representing a Wall with a thickness of 2m is modelled in the Fire Geometry. If we apply concrete.rvmat it will behave like a 2m thick concrete wall. If we apply concrete_plate.rvmat, it will behave like a 30mm thick concrete wall.
Example2: A component representing an armorpiece with a thickness of 50mm is modelled in the Fire Geometry. If we apply armour_plate_100mm.rvmat it will behave like a 50mm thick armorpanel (modelled thickness is lower than defined thickness). If we apply armour_plate_30mm.rvmat, it will behave like a 30mm thick armorpanel (defined thickness is lower than modelled thickness)
- If no materials are applied, Arma 3 will default to a nonpenetrable material with dirt impact effect type
- If during binarization, the P: drive is not properly set up the referenced materials won't be found -> default to dirt impact type
- Arma 3 has many materials that can be used directly or as base for custom materials, they can be found in "...\arma3\addons\data_f.pbo\penetration\"
- Arma 3 Plate materials are usually 30mm thick. Armour plate materials are the only ones with different thicknesses.
- The penetration system does not work reliably for modelled plate thicknesses below 10mm. If you want plate thicknesses smaller then 10mm, model firegeometry with at least 10 to 20 mm but apply custom plate materials for decreased thickness.
- If you have a case where 2 armor plates (or other Firegeometry) are ontop of each other, they should be modelled as 1 piece. Otherwise the second plate might get ignored by a bullet due to close proximity, which is caused by limited bullet simulationstep and therefore limited bullet simulation accuracy. Might be fps dependant.
For more details on how Damage&Penetration interact see Arma 3 Damage Description
For calculating buoyancy of ships and amphibious vehicles. To enable this LOD you must create a named property "buoyancy = 1" in the Geometry LOD (not Geometry Buoyancy) Similar to PhysX LOD, it should be extremely simple and have as few objects as possible. It must be convex and triangulated. Multiple objects should not intersect each other (otherwise the intersecting volume is calculated twice).
Hit-pointLODs define, via unconnected named vertexes, where certain destroyable parts of a model are (e.g. wheels, lights, etc.).
NOTE: The spacing between the points needs to be tuned in close correlation with the Hitpoint Config Class in the Objects Config and the Fire Geometry
For more details on how Damage&Penetration interact see Arma 3 Damage Description
With the Marksman DLC, we got a platform update that introduced a new hitpoint dependency feature for better soldier protection. Arma_3_Soldier_Protection Note that this dependancy feature is not only usable for soldiers, but for regular vehicles as well.
You can animate Memory LOD Selections via model.cfg just like any ordinary LOD. However, it is not guaranteed that this will work for the thing you intent to. Particles for example ignore animated memorypoints, they always use the default position from Objectbuilder. Same holds true for gun/cannon Memorypoints on vehicle turrets. Vehicle Reflector class lights however do animate properly.
Important LOD for AI path finding. With the help of this LOD the AI can find its way through objects (such as buildings). Not required for objects that don't require AI pathfinding. It consists of an interconnected mesh. All path vertices's must be connected by polygons.
Vertices where the AI can stop must be defined by named selection with ascending number ("posXX" where XX is the number). Those points can be used by scriptcommand <link>buildingpos and in the Mission editor for placing Units. Name selections called "inXX" (where XX is a number) serve as AI access points (doorways, ramps, etc) to the building. These "inXX" points must be above the terrain surface for the AI to be able to see them. The A3 sample house shows how it can be set up, using multiple "entry-fan's" with one raised point to allow access to the building, independant of terrain slope.
AI ignore the Geometry LOD when on a pathway. This means that they can walk through walls if you dont set up your pathway to lead around obstacles. The AI follow connected vertices but it is somewhat imprecise when following a path, so leave enough clearance to walls, corners and so on.
Paths are best to be 10cm above the roadway/walkway/ground surface. Entry points (named selections "in#") are simply entry points onto the path network, and don't necessarily have to be positioned outside the doorways of models. According to user reports, path vertices may be hidden via animation, which stops the AI from using the hidden path points.
If a units is supposed to be able to stand on top of a model, that surface has to be defined by a RoadwayLOD.
Make sure that a RoadwayLOD doesn't overlap with a GeometryLOD, or the unit will start to wobble at those points.
The roadway LOD does not work if components are further away from the center of origin then 36 meter. Therefore you can make 72m long bridges at most. If that is not sufficient for your object then you need to split your model into multiple smaller segments with a seperate .p3d modelfile each.
This LOD is used to determine the sound environment effects the player hears. The used environment effect are defined by the texture of the roadway LOD surface the player are standing on. The texture name corresponds to the file="<string>" property in CfgSurfaces classes.
Where the object touches the ground. (Defined by a single vertex per contact point.)
The visible geometry of the model.
As an example: If you have an object with this LOD properly configured, you will not be able to spot other units through the model. AI will not be able to spot other units through the model.
View - Cargo
What a cargo passenger can see of the model.
In vehicles of the class "Car", the player will always see this view, whether he's the driver, co-driver or cargo. (Unless the "View - Pilot" is defined. Then that view is taken for any position inside the vehicle.)
View - Cargo - Fire Geometry
View - Cargo - Geometry
View - Commander
What the commander can see of the model.
In vehicles, this will be the commander's first person view of the model.
View - Commander -Fire Geometry
View - Commander -Geometry
View - Gunner
What the gunner can see of the model.
In vehicles, this will be the gunner's first person view of the model.
View - Gunner - Fire Geometry
View - Gunner - Geometry
View - Pilot
What the pilot/driver can see of the model.
In vehicles of the class "Car", the player will always see this view, whether he's the driver, co-driver or cargo. Players position in the LOD is determined by his proxy position.
View - Pilot - Fire Geometry
View - Pilot - Geometry
This LOD is used to cast shadows on the ground, other objects and on the object itself. Shadow LOD should be simplified compared to resolution LOD, but can be more detailed then Geometry/Fire Geometry LOD. Shadow LOD must be slightly shrinked compared to resolution LOD (in 3dsmax you can use a push modifier to do this), otherwise the Model may look partly or completely shaded in the game. There are usually two Shadow LOD's - one detailed for close range and one very simple one for long distances. LOD must be:
- Sharp Edges
ArmA/OFPE only: Typically named ShadowVolume 0.000 (Few features) and ShadowVolume 0.100 (same amount of features as the main visual model (i.e. equipment, weapon systems, etc).(Also see this article)