Categories

RSS

When I do the “ask me a question” things, I generally stick to questions I can actually answer. But in this case I think what the curious person is looking for is a rough overview, not a detailed white paper. This being the case, I think I can help. As always, remember that my understanding is probably a few years out of date.

The basics of a physics engine are easy to grasp. The finer details are beyond me. Let’s start with the essentials. You can see the ultimate demonstration of basic physics at work in the bridge builder game.

The idea is pretty simple: It’s a simulation of points in space. You have a bunch of points and you subject them to gravity and collision. The trick is that you link the points together. Let me swipe a screen shot from the bridge game:

The goal is to subject the points to gravity and collision, with the requirement that all of the lines between them remain the same length. Now, you can’t insist that all lines remain exactly the same length. Simple rounding errors and limits on precision make that impossible, or at least a pain in the ass to code. If you try to make the links 100% rigid then you’ll end up with all sorts of nonsense behavior, division by zero problems, or other unwanted side-effects.

So what you do is you make each line have a desired length. The more it deviates from that length, the harder it will push to return to the desired size. Internally, this is a multi-pass excercise:

Gravity and momentum. Look at each point, see if it’s moving and how fast, and have it try to maintain that speed, as objects in motion tend to do. Also inflict gravity on it. Again, we’re just doing this to points and ignoring the lines for now.

Do collision. Keep the points from going through things. If a falling point hits the ground, make it stop.

Pass over the simulation on a per-line basis. Have each line try to correct its length. If it’s too long, it will pull its two endpoints together, and if it’s being crushed or compressed it will try to push them apart. Don’t apply these changes right away. Save them until you’re done processing all lines.

Take all of the “corrections” generated in the previous step and apply it to your points. For example check out the top-most point of the bridge in the screenshot above. Gravity will pull it down a bit, moving it closer to the three points to which it’s joined. Those three lines will push back, holding the top-most point up but also pushing down on the lower points, thus letting the “weight” of the upper point rest on them.

Now, in a perfect world you’d be done at this point. But here we have the thorny problem that maybe some of those corrections we just applied have created a need for more collision detection. Points may have been shoved into the ground, for example. We can do another round of collision if we want, which will lift those points out of the ground. But doing this will create a need for us to go back and process all the lines again, which might push points into the ground, which…

We could be here all freakin’ day, is what I’m saying. How you handle this very much depends on what’s important to your simulation and how much you value the speed vs. accuracy tradeoff. Right here is generally where things seem to get kind of glitchy. If you’ve ever stepped out of your car in Saints Row The Third and saw your tire was half-buried in the street and was jittering up and down in an attempt to dislodge itself, then you were probably seeing a problem with this part of the simulation.

Ignoring this thorny issue, we now have everything required to make our own bridge builder game. That’s it. Everything else: Sagging, balance, center of gravity, weight distribution… it’s all emergent. Following these simple rules will make it possible to build a lopsided tower and have it fall over as expected. It’s actually kind of beautiful how such simplicity can create such a robust set of behaviors.

However, this presents the programmer with a bit of a trap. They see these simple rules and how amazing the results are, and they assume that just a few more rules can yield even more amazing results. (And to be fair, in a AAA game you would need a bit more than this. In the system I’ve outlined, all points weigh the same, which can lead to undesirable outcomes. Also, collision is a bit more complicated in a real game environment, but I’m trying to keep this simple.) And so the hapless coder blunders into the dangerous waters of oversimulation.

At any rate, everything we’re doing can be applied to 3D just as easily as 2D. So now we have the makings of a physics engine. This is probably not the only approach, but it’s the one I’m familiar with.

How much “play” your lines have in them will determine how our physics object behaves. If the lines try to stay as close to their desired length as possible, then you’ll have a very rigid object. If the lines don’t start pushing back until they’re far from the original size, then your object will be very rubbery. If lines resist stretching but ignore compression, then you’ll have something that behaves like it’s made out of rope. If you have lines that are rigid until they undergo enough compressing force, after which they will compress and then treat their new, smaller size as the new “proper” size, then you will have an object that can be crumpled up like a soda can.

For making objects move in a game, an artist usually creates the visible model. This is then joined to our scaffolding of physics points and lines. Similar to how a 3D character model will be animated by a skeleton, our model will move according to what the physics object is doing.

As always, there’s a trade-off at work here. You can make a simple eight-cornered cube and make that the physics model for the entire pickup truck. The result will not be particularly convincing. If you want a good simulation then you’ll make the body of the physics model out of many, many points. You’ll use very rigid links for most of the body, and more “rubbery” ones for the link between the car body and the axle. (Or the wheels. Depends on how meticulous you are about your car simulation. The fidelity requirements of Gran Turismo are obviously very different from, say, Burnout.) Do this right and you’ll have a working suspension system and you’ll be able to see the car rock and shift as it corners and brakes. However, the more points and lines you use, the more CPU power you need.

As for making the body of the visible model crumple up like that? How does it know when to crumple up the fenders, when to shear them off, or when to have them detach entirely?

I have no idea. I mean, I could take a guess and muse over how I’d research such a problem, but it would be all conjecture and hard for me to relate in non-technical terms. And above all, it would probably be wrong.

I have to say, when I read the title of this post I was kind of hoping that we could see Shamus implementing this stuff into project Octant.

I’m currently building a very simple physics engine (actually a ‘cloth simulation engine’ but the idea’s the same) as an assignment and yeah, it’s fascinating to see a couple of very simple rules and formulas create a complex-looking simulation like this.

And, not that it really matters, Rigs of Rods is developed independently (http://en.wikipedia.org/wiki/Rigs_of_Rods) and is being incorporated into Crytek. Since it's a standalone open-source engine, Shamus totally could incorporate it into Project Octier!

Skyrim has probably the classic example for when rigid-body physics go wrong, when an unstoppable force tries to pass through an immovable object (although that specific case is likely more due to “leave it in, it’s hilarious”). If CryEngine can actually do that sort of soft-body physics in realtime then that’s pretty impressive.

Replace “Skyrim” with “every Bethesda Gamebryo game ever made” and you are correct. I used to think that the problem lied with the Havok engine, but games made by more competent programmers don’t have this problem.

Kind of fascinating how such a simple ruleset can create such believable outcomes, but when you add more rules things start to unravel and behave strangely, leading to more rules with more exceptions and more weird behaviour until it’s just an unfixable mess.

Very much so and it a common problem in programing (see: Shamus complaining about coding libraries). The nice thing about physics engines is that must of the hard work has been done already by these people called physicists, who have been around for a very long time (see: Sir Issac Newton). They’ve already been defining things in terms of relatively simple equations so all that left for programers is the implementation.

Most problems arise when programers start trying to do a physicists job for them.

Simple newtonian mechanics is a great place to start from, but it doesn’t have all the answers. One big problem happens because a game has to work on a finite framerate. A fast-moving object could be out in the open in one frame, and then halfway inside another object in the next frame. Working out how to resolve stuff like that in a way that always makes sense is pretty tricky.
It gets even worse if you add lag to the equation, since that object might have needed to bounce several frames ago but just kept on going.
Also actually implementing proper physics for everything would require a near-infinite amount of computing power (see: the universe) so you have to take shortcuts everywhere.

“You have the equations so all you have is to implement it”. Computers represents numbers with a finite precision, and Newton dynamics is highly chaotic ie. a small error will have big consequences. Just predicting the trajectory of planets past a few millions years is still a very hard problem to compute, precisely because of this. Also because of this precision issue, things that in physics are taken for granted, like energy conservation, does not apply to a numerical simulation. Like, conserving energy on a simulated system, ho boy, that’s quite a mess. Compare
Euler integration (http://en.wikipedia.org/wiki/Euler_method) => “I don’t care about floating point precision”
Beeman integration (http://en.wikipedia.org/wiki/Beeman%27s_algorithm) => “I use astute computation to minimize the amount of spurious energy introduced due to numerical imprecisions”

Yep it does! Usually grenades are just very dense or heavy points that are moving really fast. One of the fun parts of physics simulations is that you can actually toy with things and simulate the impossible such as a 2 ton piece of paper or a 5 pound lamborghini, or set friction to -9…

How much better would the final sections of Alan Wake been if the Darkness had just turned the friction to -9 on all the objects in the woods? Forget the tornado, running through the woods while random craziness flew threw the trees would have been outright freaky!

There’s a script file used to compile the projectile for use in the engine which dictates its mass and elasticity, while the shape of the collision box(es) created from the “points” Shamus illustrated is defined by a very basic 3D model exported from a 3D modeling program. Source only deals in convex collision hulls, so you need multiple boxes to make a concave shape.

There’s something of an art to knowing (literally) where to cut corners with these simple collision models. Certain rules apply based on what the object is: cover should always be more precise than other props; common obstacles the player will be shooting around/through should always err on the side of being too small; structures, walls, and things intended to be walked on should always err on the side of being too big.

If you’ve ever played a game where bullets pinged off of thin air ten centimetres from a lamp post, or fallen clear through a protruding strut of a building you intended to jump to, you’ve been the victim of poorly-planned collision meshes.

Anyone else feel like the car is a bit on the rubbery side? Not much, and certainly better than the overtly rigid cars in the past, but still.

I seem to remember reading years ago about physics in an old game, so it’s unlikely it’s the same being used here, where they were basically using the change in movement speed as a base for calculating how much force there was, then checking line collisions before finally using those to calculate deformation. I think the lines in physics model had “resistance”, which mitigated the effect.

I don’t think it did the soft body thing at all. I suspect it was at the level of deformation physics in Carmageddon 2.

What I find most unrealistic is that the passenger compartment seems to be made of the same physics material as the rest of the body. It should be more rigid, because cars are made this way in order to save the passengers from getting crushed. It’s still possible, but not as likely.
P.S. Of course, it doesn’t seem to be a problem with the engine, just a need for some material adjustments. Also, the windshield bending without ill effects. It’s laminated glass, so it wouldn’t lose integrity, but it would partially or completely dislodge and become semi-transparent as the glass inside shatters. It does that in one case, but it should do it more easily.

I get the same feeling. At first I thought it was the messed up collision detection they warn about, but the truck just seems a little too bouncy and squishy. It gives me the uncanny valley feeling, so close to real world physics that the little flaws feel far more glaring.

Cars are actually rubbery in reality. Steel compresses and rebounds. To get steel or anything else to collapse the modulus of elasticity has to be exceeded . Then the smaller size is the new size. Before that value is achieved the steel will rebound. The other thing to consider is EACH of those components absorb some of the energy. As each piece fails the energy that has to be dealt with is reduced for the next component. This is a significant engineering effort in racing.

Plus on real cars a lot of the connections between components are rubber. And the pickup had three major components depending on how they were modeled. The frame, passenger compartment, bed and possibly the engine compartment. Modern cars use the engine compartment as a crush zone to protect the passengers. Add the minor bits; wheels, suspension, bumpers, drive train, doors and the entire mess looks like it is flapping in the wind. When a corner is hit, the bumper takes damage, then the fender, then the wheel, then the suspension which may deform or the bolts holding it on may shear and so on down the line until the energy needing dispersal is zero. Which is what game engines normally screw up, they need a simple, fast method. Accuracy is less then in real life. So you get cars that sink into the ground and parked cars that jump into the sky. Or characters for that matter.

The only thing I saw that drew me out of the video was the very first collision had penetration. The hood or fender moves into the object it hit and then recovers. A very common video game issue.

Now imagine having to use a game physics engine to simulate a sub implosion. Yup, that sucker is on its way to Mars.

I know that steel has some elasticity, but usually it’s not visible to me in a casual observation, which is why it strikes me as odd. The most suspect part is where the car is going over the bumps and the bed clearly twists compared to the front so much that it just doesn’t look natural.

If pick-up trucks have a round joint that allows rotation like that, then okay, but it still looks strange.

Also the car falls and crashes it bounces like in old films where they either used a miniature or removed the engine before pushing it off a cliff. There’s enough momentum so it keeps moving, so I’m assuming it has mass, but that just adds to the rubbery feeling.

It looks that way because it is a poor approximation. No insult intended, but a “good” approximation can take hours to run through. The quality of the approximation is limited entirely to the assumptions made, i.e. types and numbers of materials, and the resoltion and type of models, i.e. 1-D, 2-D, or 3-D; and making fewer assumptions or using a higher resoltion model can increase computation time by orders of magnitude. Looking this good and doing this in real time is just amazing. It isn’t any good from a real world design position, but for use in a game? This will be hard to beat for may years to come. The only other big things to model after this are thermal dynamics and fluids dynamics.

“Following these simple rules will make it possible to build a lopsided tower and have it fall over as expected. It's actually kind of beautiful how such simplicity can create such a robust set of behaviors.”

Ah, but isnt that the beauty of it? Reality itself runs on exactly the same simple set of rules, it just has infinite* precision and instaneous processing to work with!

The big “Holy Grail” for physicists is that somewhere there is a single equation that can explain everything in the universe. Currently most of them believe that it exists on the quantum level or maybe somewhere lower than that.

The uncertainty principle relates more to the problem of defining properties finely enough to consider them measurable: When we describe something at a point in time, we cannot talk about speed or other derivatives with respect to time: How steep is a grain of sand on a sand dune?

No, the uncertainty principle states the impossibility of measuring two paired variables simultaneously such that the product of their uncertainties is below a certain value. No problems with defining e.g. momentum.

In English: It says there is a limit to how well certain things may be measured, and it is not an issue with definitions.

AFAIK, that pair is actually *impulse* (momentum = velocity times mass) and position.
The difference in either-or terms isn’t very interesting (if you measure one precisely, you can’t measure the other at all), until you get to objects that weight zero or infinity.
Zero-mass object: with velocity-position, you can still measure both with some bounded inprecision (say, withing 1 meter/second and 1 meter).
With momentum-position, your momentum is
a) for finitely fast object (or even infinitely, if that infinity is not infinite enough): zero momentum, which is known precisely, and therefore you can’t know where the object is, or
b) non-zero momentum – requires infinite speed, and therefore the object is everywhere at the same time (that can be interpretted either as “we know exactly where it is and at the same how fast it is and therefore this option is impossible” or “we don’t know at all where it is”).

Actually, that equation already exists. It is just that there is a certain part which has yet to be proven, which is the reason why the LHC is searching for the Higgs-Boson, because if it does not exist the specific part of the equation is wrong (and thus maybe even more…).

Well, not really IMO. The Standard Model has stuff it doesn’t really touch. Even if they find the Higgs. The nature of time. What the bleep is dark matter, anyway? Stuff. I’m not clear for that matter that just having a particle that gives things mass really integrates the particle level with the whole relativity thing. And then there’s that whole string-theory-ish “What are all those little particles made of?” question.
Plus I guess it depends what you mean by “in the universe” too. What was there before the Big Bang? Can new universes start up the same way ours did? Would we notice? Would their rules be tweaked different from our rules? Why are the physical constants set at the particular level they happen to be set? Is the “many universes” hypothesis correct?

Basically, “Absolute Zero” isn’t an arbitrary thing, it’s what we call it when there’s no motion/energy left. It’s like the minimum mass is zero when there’s nothing there, and so you measure mass starting from that point. Similarly, temperature is zero when there is no heat, and you measure starting from there. What else would you do?

I suppose I am not getting the “for optimisation purposes” part. When temperatures get to the low kelvin (or fractions of kelvin), physics can get very strange. Still, within the framework of the conversation, guess no-one bothered checking what happens at the edge-cases of the simulation (when temperature -> 0K) ;-)

Well except that even reality might not have infinite precision. It seems that the universe itself is actually “grainy” and there is a smallest distance as well as a smallest time span, called Planck Length / Planck Time (which might speculatively be interpreted as the resolution of a higher level universe running ours as just a simulation).

Hmm, from looking at the way the truck moves, I suspect they gave each individual truck part several “attachment” points to other truck parts, and presumably if enough force hits on/near those attachment points, they may snap, causing the truck part to partially or completely fall off.

I think that’s part of the reason why the truck looks a bit “rubbery”, because the truck bed seems to be attached to the cab in the center and rotates around that point when it bounces.

So maybe their innovation here has less to do with changing collision and more to do with coming up with a novel method for tying lots of semi-independent bits together?

If I remember correctly, a lot of truck beds aren’t actually firmly attached to the cab, so the behavior of the truck bed jostling about relative to the cab is actually fairly realistic, especially for such a rough road.

Most of the innovation here will be to do with the parts that crumple and bend, especially if they can do that in real-time in a real game. Just having the truck attached to the wheels by springs is fairly old – it’s pretty similar to what Shamus describes in the article – and I’m surprised they devoted so much of the video to showing that off.

Sometimes. I worked with an mechanical engineer and early in his career he designed a structure out of steel. Every thing was cool until the main support beam bent … under its own weight. Which he had forgotten to include as he only had the weight at the end points where the system worked fine. Just the middle of the beam was causing the problem.

What you describe here is “particle-based physic engine”, which take the approach of considering that all is made of particles linked with bars :)
About the bars:
– One can handle the linking bars as springs. Stronger springs = more rigid bars, stronger forces, more stressful for that poor floating point calculations. Floating point is *EVIL*. Less strong springs, well, easier to compute, but your objects will behave like if they were made of jelly.
– One can handle the linking bars as constraints. Move the points so that distance constraints are enforced. Integrating acceleration/speed/positions with what is called Verlet scheme can cope with that nicely. That’s what made a paper by Jakobsen famous (Jakobsen, Thomas. “Advanced Character Physics.”). With a few very simple animation involving 3 particles, one can see that this method introduce fictional forces and velocities. The objects might jitter or float randomly.

With the “particle-based physic engine” approach, one object, say a car, will be represented as made of several particles linked together. One particle itself is just a 3d point.

Rigid body simulation works a bit differently… Let’s say one car would be one single particle, but each particle got a hull (the shape of the car) and 6d informations (3d for position, 3d for orientation).

The video got me thinking.. how about using a soft-body simulation for large scale structures – building and stuff. Don’t simulate every brick, just every wall separately. Simulate reebar and metal with soft joints. Set a much smaller tolerance for tear and compression. Allow surfaces to split (somehow). Spawn rigid bricks and bits of objects where there is a break. For larger blocks (like the walls of a concrete bunker), divide them into octrees and break the into chunks. Would this work?

The dev over at crypticsea.com(incidentally the guy who seems to own the IP for Pontifex 3, the yet to be released game in the series that Bridge Builder belong to) is working towards structural damage simulation on his game but so far his buildings are completely rigid and merely spawn bricks when hit with shells or explosions.

I’d love to play an fps and see a building fall around me. There would be a random, but completely deterministic change I would survive based on what I do. It would fit in a procedural-gameplay style sandbox.

It definitely sounds possible, although how good you could make it would basically depend on how many chunks you could spawn which would depend on your hardware. It’d be a lot like detonating a ton of TNT in minecraft or a stack of barrels in crysis in that there would be a set amount of stuff you could do before everything just freezes up.

Octrees specifically wouldn’t work – they’re really hard to animate and/or move around. I think I know what you mean, though, where stuff gets broken into big and small chunks, maybe into some sort of fractal pattern.

You can get an almost as good effect by doing all the hard processing during development and pre-recording the explosions, like in Battlefield 3. That ends up being much easier on the hardware, too, and looks great but it can end up looking a bit stale if you recognise the same explosions happening each time.

I’m pretty sure things wouldn’t be quite so interesting if you just set it to zero – those videos have friction set negative, meaning that cars gain energy when they collide with things. Set it to zero and they’d just slide around like they were on oil or ice or something; much less fun to watch.

So, that demo does seem pretty impressive. And maybe it’s as awesome as it looks. But be clear – this is the developer showing off something they built. I doubt any of it’s faked, but if you were putting together a tech demo, you’d make sure you only showed the things that worked. And if something didn’t, you wouldn’t leave that in (maybe you’d go tweak your engine to remove that bug).

This is like watching a gameplay trailer that’s spliced together from in-engine footage. Yes, it’s “real”, but is it representative? The stuff they’re doing is cool and impressive, but I’d like to play with this a bit myself, making the truck do things *I* find interesting before I’d draw any conclusions.

Interesting, and looks neat. Does it add much value to a game, though? I suspect this method is still way too intensive to be applied to the entire environment – you probably won’t see the world react to physical events as well as a single playerdriven car…

As far as car collision & damage models.. Eh, GTA4’s was basically enough for me. I bet a lot of racing games have way more advanced cardestruction mechanics already. In other words, I don’t really see the big breakthrough here.

Shamus, regarding your last question: “How does it know when to crumple up the fenders, when to shear them off, or when to have them detach entirely?”

In the model you describe, simply setting a threshold tension and/or compression force on a link, and then breaking the link when force exceeds that threshold (removing any constraints imposed by the link), will result in stuff shearing off and detaching completely when all links to an object are broken.

If you want to get really fancy, you can also weaken each link slightly by an amount proportional to changes in force experienced in both directions. This will simulate fatigue that eventually leads to breaking.

I think the difficulty comes in making it so that whole parts come off, rather than the model tearing at random. I suppose you could just ‘glue’ each model together with some links with a threshold tenshion though.

Hm, not really, imo. Truly “random” tearing across any possible object into two/several emergent non-predetestined pieces is the hardest of the two to actually implement, imo, compared to “just break at predesigned point X if force>1000″/”if force>2000, remove detail C”. Doubly so if the tearline doesn’t actually match a pre-existing polygon splitline, but goes straight over a flat face.

You can still jigger the treshold randomly in a certain interval (either jigger on each test, or each few frames, oslt): “if force > 1000+200*rand()”.
And then consult another rand() when deciding what exactly happens to the overstressed part (deform in variety of ways, break off in a/another direction, slide off while throwing sparks, …).

Actually it’s easy to make whole parts come off in the way I describe. A bumper, for example, would be attached at just a couple of points, and the combined forces concentrating on those points will make them easier to over-stress and fail, resulting in parts actually breaking off rather than tearing. As you said, gluing together parts with some links having threshold breaking forces and others with threshold crumple forces as Shamus described would result in combined crumpling and shearing-off effects.

And remember, once you break one link, the remaining links have to absorb the forces, making them more likely to break, and when another link breaks, the cascade continues.

In my initial post here I was careful to write “and/or” because you may want things to break only with tension, or only with compression, or both. Glass, for example, can survive tension better than compression, so one could make a glass window out of pre-defined shards that shatter under a compression load.

There must be a disconnect (if you’ll pardon the expression) between what gets coded in the physics engines for driving games, and the resulting effects that cause pieces to fall off of cars if your avatar looks at them funny or you rotate the game’s camera too fast.

I seriously doubt that glass can actually handle tension better than compression. That would be virtually unheard of in material science. You’re probably talking about bending, which is a complicated combination of tension, compression, and shear, and yeah, glass is brittle.

When in engineering school we actually had a bridge builder game that we used in the intro civil engineering class. It exaggerated the degree of stress (and gave a false color where blue was tension and red was compression) to let you see where all the forces went. It also had a simulated truck drive over it and you could watch as the stresses happened.

Naturally this lead to the engineering students making huge pillars of the softest steel so that the entire bridge would distort off the screen without breaking as the truck drove over.

The random element comes plenty enough from player agency. Different speeds, different angles, different cars, etc. etc. already provides the randomization – I suspect you’d actually want the reaction to those randomized factors to be certain and mostly predictable, for it to be at least selfconsistently logical.

Several other major problems with physics simulation are over-penetration, damping, and “sleep” threshholds.
Over-penetration gets stuff stuck together (or pass right through each other) like the dancing cars. Damping (friction) can help a lot with this, but it has its own problems, and makes the simulation feel sluggish. Sleep threshholds are super important for keeping stuff on tables from jiggling around when “at rest” but again hard to tune.
It seems a lot of modern game engines are not well guarded against over-penetration, improperly damped, and don’t go to sleep soon enough. But as you point out, it doesn’t start off complicated… it just ends up that way somehow.

I’m impressed. You managed to get all the way through that discussion without once mentioning World of Goo.

One thing that I think would be interesting – in a sytem that is inevitably based on lines, points, and polygons – is the idea of doing crumple physics by actually introducing new points / polygons. So if you put enough side stress on a line segment, you introduce a new point in the middle of the segment, dividing the triangle into 2. Obviously you can’t do this too often or your poly count skyrockets, but most things in the real world don’t crumple much, except when introduced to unusual stresses (like PCs.)

Much like bridge builder, it’s in 2D, and you’ve got springs, masses (mass points, to be precise), fixed points an “muscles”, which is springs with a “relaxed” length that varies over time. There are some pretty things that can be built this way, and it’s dynamic, too :)

Incidentially, the “connected sticks” model is also what much much more advanced FEM software uses (that’s a crude simplification!) to compute stresses in material. Just imagine the piece you have is made of lots of springs, featuring the elasticity of the material that you’re regarding. Even if the material can be regared as 100% stiff for all practical purposes, the spring analogy will allow you to solve a bunch of problems you otherwise wouldn’t be able to.

“As for making the body of the visible model crumple up like that? How does it know when to crumple up the fenders, when to shear them off, or when to have them detach entirely?”

I’d guess it treats the physics joints/lines connecting them kind of like bones? if the line to which vertices belong is shortened, then it crumples said vertices along that line (trying to keep distance between them the same, thus pushing them up/down/to the sides), if the force is applied perpendicular (or close to it) and strong enough, it separates that part of the mesh from the joints. Roughly…. approximately… something like that?