Why do backwards collision triangles exist?

Triangles are more or less the same on both sides.

The main difference between the two sides is that one side is somewhat "fatter" than the other side so it can stop faster moving nodes trying to go through it. The bias between the two sides exists because it is a very frequent case to have faster objects coming from the "outside" and slower self-collisions coming from the "inside" of a vehicle.

 

Collision detection in general is very computationally expensive. The bigger the frequency of the physics engine, the greater the load on the collision detection subsystem. Due to the extreme frequency that BeamNG's physics engine runs (2khz or 2000 times per second), collision detection requires a considerable percentage of the total CPU budget. This used to be around 45-55% with previous versions of BeamNG, but due to optimizations it has been reduced to 35-45% with later versions.

The major reason that clipping happens is due to the collision subsystem not checking edge with edge collisions. It only checks for node with triangle collisions. I'm doing research on ways that this could be solved, but i have to be careful to not raise the collision subsystem's CPU cost. This isn't an easy problem, so it will take a while.

Now, for a node to be able to clip through a triangle's side it has to move fast enough, so that it'll "skip" from one side of the triangle to the other side. The "fatter" the triangle, is the harder for the node to skip from one side to the other.

Right now in BeamNG, collision triangles have a total width of 5cm (2.5cm on either side). The outer side occupies a significantly bigger % of this 5cm than the inner side. What in practical terms that means, is that the outer side is able to stop nodes that are moving faster (relative to it), than the inner side is able to. So the outer side should be able to stop a node approaching at ~350km/h and the inner side a node approaching at ~150 km/h.

 

I'll try to answer all the questions .

@Slayersen:

Micro-jitters and numerical precision problems might cause sticking because a node can momentarily manage to pass its allowed inner-threshold, and enter into the outside-threshold. When on the outside it is kept outwards. Increasing the inner side might be done in two ways. Either reducing the outside's width (which will make the outside more prone to clipping), or increasing the overall triangle's width. Increasing the overall width will make it more difficult for vehicle creators to design vehicles, because they'll need to keep bigger distances between triangles.

Edge detection would massively increase the CPU cost of the collision subsystem. It is something that bothers me (not having edge-edge detection) and i'm trying to find ways to solve it. It isn't an easy problem (especially at 2khz [*]), so i cannot promise anything about that.

@Scepheo:

What you are talking is the approach of using swept volumes/lines to do the collision detection. This is a requirement when a physics engine works at low hz. At high hz it isn't needed that much (things move a lot less in a given time dt). Even so i have experimented with these ideas. Lines only help when you first switch sides. After that they are problematic or you need to go to more complex solutions that increase the CPU cost. In previous work i've used the beam skeleton to be able to find which is the "correct" side (looking at which side the nodes with which the colliding node is connected with, are), but it led to a new set of problems and overall wasn't worth it.

@AmberPixel21:

With double the hz, the collision subsystem will be able to stop nodes going at double the speeds. The overall CPU cost will also double. We have done experiments at higher hz (4.5khz), but until the CPU/GPU technology advances some more (and propagates to the users), it'll be non realtime for most of the people.


[*] An easy way to understand what 2khz means, is to invert the meaning and look at it as msecs per physics step. 2khz = 0.5 msec per step, in which all the vehicle physics need to be calculated, collisions found, the work on multiple CPUs being orchestrated and so on. A CPU that runs at 3.4 ghz can do ~1.7 million operations (calculations and so on) in 0.5 msec. When a vehicle has 4000 beams that means that the core has ~425 CPU ops per beam to use (in reality these 425 ops are not only per beam but for all the nodes, the collisions and so on). So the CPU budget is pretty constrained.

 

Think what happens in the case, when a node is close at the boundary of the two sides and its "from previous position line" crosses this boundary [*]. If you use the "line logic" it'll tell you that the node should be on the previous side (the side of the triangle the node was on, previously), on the next frame, the line will be in the opposite direction signalling the opposite ... and so on. The end result is a node vibrating between the two sides of the triangle. So you'll need more complex "side choosing" logic to solve this problem (i actually know how to do that, i have coded it in the past). This more complex logic requires more CPU and memory traffic.

So the main question becomes, is that worth it? Considering that all this additional CPU and memory traffic cost will benefit mostly the inside side case (increasing the stopping speed from 150 km/h to 500 km/h), without solving the major clipping reason that is: missing edge-edge collisions. I've decided that it isn't worth it. I prefer to invest this processing budget to other things like simulating for example pressured tires and so on.

This does not mean that i won't ever add this logic in there. It is just that, when one faces a computational environment so tight, he has to constantly make trade-offs and very carefully choose the things where he'll put his scarce CPU cycles on.


[*] There is also the case of the node being completely stationary and the triangle speeding towards it. In this case the "from previous node's position line" logic doesn't help at all. There is a way for this case to be solved but it requires to consider the triangle's moving/rotating frame of reference which would only make the discussion more complex.