Vehicle Hitpoint Creation – Arma 3

From Bohemia Interactive Community
Jump to navigation Jump to search
No edit summary
Line 5: Line 5:
Basic tips about building vehicle fire geometry and hit points. This article assumes you are already pretty competent at making vehicle addons for Arma 3.
Basic tips about building vehicle fire geometry and hit points. This article assumes you are already pretty competent at making vehicle addons for Arma 3.


=Damage vs. Penetration=
Take a look at these two images. They tell you a lot about fire geometry and hitpoint placement:
It's important to understand that penetration and damage are not exactly the same thing in Arma 3--they have a slightly indirect relationship. For damage to occur, a vehicle must have:
*[https://community.bistudio.com/wiki/LOD#Fire_Geometry Fire Geometry] modeled in its P3D file and
*[https://community.bistudio.com/wiki/LOD#Hit-points HitPoints] defined in its config.cpp file


'''Simply put: an attack must ''simultaneously'' penetrate ''both'' fire geometry and a hitpoint radius to cause (significant^) damage to a vehicle.'''


(^ In actuality, the game will perform a damage calculation as long as any fire geometry is hit--even if ''no'' hitpoint spheres are penetrated. However, the amount of damage caused by this effect is pretty negligible. So, while case D below produces no damage, case C produces some minimal damage.)
==Basic Rules==


[[File:damage summary diag 2.JPG]]
==Why Should You Follow These Rules?==


In the diagram above, attacks A-D are examples of direct attacks (indirectHit & indirectHitRange = 0). Attack E is an example of an indirectHit attack. As the diagram shows, armor (in the form of fire geometry) can protect against direct damage--but indirectHit damage can easily occur ''without'' penetration (especially when indirectHitRange is large). Only a hitpoint's minimalHit and explosionShielding values can protect against indirectHit reaching through armor to cause damage.
The consequences of the damage system for armor modeling is discussed [[#Armor_Methods_.26_Recommendations|later in this page]].


==Fire Geometry Placement==
==Fire Geometry Placement==

Revision as of 17:53, 28 October 2015

Template:Cfg ref

Intro

Basic tips about building vehicle fire geometry and hit points. This article assumes you are already pretty competent at making vehicle addons for Arma 3.

Take a look at these two images. They tell you a lot about fire geometry and hitpoint placement:


Basic Rules

Why Should You Follow These Rules?

Fire Geometry Placement

Some 'rules of thumb' regarding the preparation of vehicle FG:

  • Use the most detailed and accurate armor data you can when creating your vehicle's P3D FG (armor). Correctly calibrated weapons are only going to give realistic results if your armor settings are realistic.
    • Use accurate thicknesses, accurate angles, and accurate materials. Arma's penetration simulation is very detailed and takes all these factors into account to generate an accurate "line-of-sight" path of a projectile through vehicle materials/armor.
    • Of course, the FG model is simplified and does not need to contain every little piece of geometry. Use just enough detail to capture the key armor areas of the vehicle (the Samples_F T-72 tank is a reasonably good example--although it could be just a bit more detailed).
  • The material used for armor pieces should usually be "armour.rvmat" (with thickness is defined by your model geometry). Preset-thickness materials ("armour_plate", etc.) respect LOS thickness, so you can use those where necessary.
    • Regardless of what the real vehicle uses for armor (aluminum, composite, etc.), the best practice is to translate them into RHA-equivalent thickness. (To be specific, we are speaking here of "RHAe-KE": the equivalent thickness of rolled homogenous armor steel vs. kinetic attack).
  • Very thin components/armor (below 10mm thickness of the convex component) should be modelled via plate materials, as the penetration accuracy for full material like "armour.rvmat" is not enough for such thin components.
  • Avoid overlapping FG. Arma projectiles can skip through interpenetrating pieces of FG without noticing some of them. Arma projectiles tend to only "notice" the first piece of FG they hit if other FG is embedded within it. The greater the interpenetration, the more likely the error.
    • In fact, it's desirable to leave some space--at least a few cm--between pieces of FG that don't need to be directly touching.

General Hitpoint Placement & Armor

As discussed earlier, Hitpoints are required for a vehicle to take damage. The style of hitpoint placement affects how a vehicle takes damage with respect to things like armor and penetration. One of the reasons that (stock) Arma vehicles take damage in the somewhat puzzling way that they do is due to their choice of hitpoint placement.

Hitpoint Radii

Recall from the "Damage vs. Penetration section that an attack must simultaneously affect both fire geometry and a hitpoint to produce damage.

Consider the following two approaches to hitpoint placement for the same vehicle--the front view of a simplified AFV. The polygons represent FG and the purple circles represent the virtual spheres created by hitpoint vertices and their radii.

Old Arma Approach

armor-hp-1.jpg

Modified "Internal" Approach

armor-hp-2.jpg

In the first approach, the vehicle will take major damage from non-penetrating hits. This is because the hitpoint spheres poke through the vehicle's FG. In the second approach, the hitpoints are constrained to be inside the armor layer (blue polygons). The second vehicle will take only trivial damage from non-penetrating hits.

Obviously, if you have non-armored parts of a vehicle that should be damaged by non-penetrating hits (tires, glass windscreens, unarmored vehicle parts, etc.), then their hitpoint spheres should "poke through" the FG in the "old" manner.

Hitpoint Stacking

Now let's consider two different approaches to hitpoint "stacking":

Old Arma Approach to Stacking

armor-hp-4.jpg

Modified "Overlapping" Approach

armor-hp-3.jpg

In the first example, hitpoint spheres are stacked so they do not overlap. This occurs frequently in Arma 3 vehicles. The second approach allows the spheres to overlap, with two resulting benefits:

  • Generally a smaller number of (higher-radius) spheres can be used to define a volume.
  • There are less "holes" between the spheres where a projectile can pass through without causing damage.

There don't appear to be any negative side effects to the overlapping approach; for example, overlapping spheres do not cause "extra" damage when a projectile penetrates through the overlap. BI itself increasingly has been using overlapped hitpoints in their models, so this approach should be considered safe.

Hitpoint Placement Recommendations

In summary: combine the two "modified" approaches for improved armor and damage performance:

  • All hitpoint spheres should be "overlapping", and
  • Any hitpoint spheres protected by armor should be "internal"

Note: BI itself has been moving away from the "Old Arma" method of hitpoint placement. Looking at recent revisions of the game (2015), you will notice that their tanks in particular largely follow the "modified" approach.

Hitpoint Placement for Damage Consistency

The previous section focused on general hitpoint placement with respect to armor and the penetration sim. But your FG must also accommodate the way the damage sim works. It is extremely easy to get very random damage results if you don't build your damage-receiving fire geometry and hitpoint (spheres) according to some very specific rules.

hitpoint guide.JPG

The diagram above shows 3 different methods of assigning hitpoint spheres to fire geometry ("FG"). The red FG represents an area you want to receive damage, while the blue FG represents armor that should not cause damage when hit. The purple circles represent hitpoint spheres (P3D vertices with radii defined by hitpoint class config file).

  • A is the recommended way to handle FG. The damage-FG is separate from the armor FG and is evenly encased within hitpoint spheres. Whenever the damage-FG is hit, it will receive consistent, predictable damage.
    • To reiterate: the damage-FG should be fully inside the hitpoint spheres.
    • While you could accomplish this with one giant hitpoint sphere, that would likely overlap with lots of other FG/armor. So a greater number of smaller-radius spheres are preferable.
  • B is not ideal but can still work. It is not as predictable in its damage results as "A". In this case, the area without hitpoint spheres is intended to function as armor--receiving minimal/no damage. The rest of the geometry is encased in hitpoint spheres as in "A".
  • C is not an acceptable approach. It combines several problems, and hits on geometry like this will produce very inconsistent damage results:
    • the damage FG is not fully encased in spheres
    • the spheres are not evenly placed within the FG
    • several of the spheres are submerged inside the FG

Hitpoint Properties

The recommendations above will do nothing to make a vehicle safe from explosive damage--termed "indirectHit" damage in Arma terminology. IndirectHit damage reaches freely through fire geometry to damage hitpoints.

The only way to protect a vehicle from such damage is by adjusting minimalHit and explosionShielding properties. (These properties apply to hitpoint locations--BI has also recently added equivalent properties for global vehicle health called minTotalDamageThreshold and explosionShielding). Armored vehicles in particular should have a large enough minimalHit and small enough explosionShielding value to protect against minor indirectHit weapons. But they should not be so heavily protected that they are immune to large-scale indirectHit weapons (IED's, laser-guided-bombs, etc.).

Useful Links

(The VBS links are very useful, but do contain some obsolete/irrelevant information)

More Detailed Damage Description

VBS:Damage Modeling:Objects

VBS:CfgAmmo Reference

VBS:Damage Flowchart

VBS:Damage Modeling:Simulation Formulas

Config Properties Mega-List

Template:Cfg ref