Instead of Modelling the real thickness of the armor plates, it might be sufficient to have very few additional components that are relatively large in the firegeometry. Combined with a small change in bullet ballistics and damage relationship. Let me demonstrate how the hit geometry would look first.
This is the regular hitbox model of a standard A3 character (from sample model).
And this is how the body armor hitbox model for chestarmor could look. 2 Boxes. Why 2? to conform to skeleton deformations. Depending on size it could also be just one.
Here is how a helmet could look.
The reason why the protruding armor is possible, is because if a bullet hits a volume of the fire geometry, it will ignore all other volumes until it left the first volume. There needs to be a minimum distance between 2 volumes for it to recognize both materials, i don't know that distance however (may depend on bulletspeed, no idea).
So if we imagine a plate carrier with front and back plate (like modelled here), and you hit the body from the side, the "meat" material of the body will be the only material considered. Hits from the front only consider the armor for penetration.
The problem why we cant do it like that currently is this: Model Fire geometry consists of simplified shapes of the model, and their ballistic materials. But it does only determine bullet flight through the model itself. It does not damage the model. For this you have to define hitpoints.
One hitpoint is a single point in the model and has a spherical radius around it (defined via config). For an object to receive damage, a projectile must hit the fire geometry of the model AND the point of impact has to be within at least one hitpoint-sphere.
And this is the problem with modelling bodyarmor currently. The hitpoint spheres are fairly large, so even with the protruding armor (like shown) version, the hitpoint spheres are above it.
If you hit the armor model, the character will get damaged just like if you would hit the unprotected bodypart. But the bullet will travel slower on exit (or not even enter).
Making the hitpoint spheres smaller won't help, as only the point of impact on the fire geometry counts. If you define a hitpoint sphere within a firegeometry volume, it does nothing, because only the point of impact counts.
What could be done to solve this?
An information link between the hitpoint system and the bullet penetration system could be established in the code.
If a bullet impacts on fire geometry within a hitpoints "detection sphere", the calculator doing the damage stuff needs to know on which material the impact occured on for that hitsphere. I can't imagine that this would be too performance costly, as the information is already there, the projectile has it to determine ballistic behaviour after all.
With this implemented, a body armor could have 2 different config settings. Softarmor and Hardarmor.
Softarmor works like the armor system does atm, it protects entire bodypart. This can be used for simulating kevlar layers and so on.
Hardarmor only has an effect if the armor material defined in the firegeometry model was struck.
Whether a more sophisticated solution with checking for penetration/not penetration can be easily done that way idk, might be something to consider. Even with just Soft and Hardarmor config values it would be a huge step forward.