how to set bounce like a game of billiards

[SourceCoder-2017]

I have set some properties, such as setting the bounce
to 1, but I found that when the white ball is launched to hit other balls, the movement direction of the other balls is inconsistent with what I calculated. Is it that the actual collision ball radius is not completely in accordance with the input setting?

For example, the two direction lines shown in the figure are calculated by myself based on the speed direction, radius, and collision point, but the actual movement direction of the red ball may be different from this.
What causes this phenomenon? Are there any parameters that affect this collision?

[RossNordby]

The interplay between angular motion and friction during and following an impact can be pretty complicated. There may be other differences, too, but an estimate excluding those would definitely not match.

[RossNordby]

While an idealized and simplified simulation with no friction will see the impacted ball's linear velocity align with the collision normal, the presence of friction introduces tangential contributions to the ball's linear velocity even without rotation.

Angular motion further complicates the prediction of the immediately-post-impact linear velocity by modifying the relative velocity at the impact point that friction responds to.

[SourceCoder-2017]

I've drawn the trajectory of the ball's movement in Unity, and this physics system calculates the reflection angle based on standard elastic collisions. The real cause of the issue I mentioned earlier is actually collision penetration. Almost all collisions have some degree of penetration, which leads to incorrect angles after the collision.

In the image I uploaded, the white ball and white line represent the path simulated by the physics system, but the red ball and green line indicate the actual position and path where the collision should have occurred.

Is there any parameter that can make this collision occur at a very precise position?

In a billiards game, the accuracy of such collisions is crucial. Otherwise, even if you aim correctly at the pocket, the path deviation caused by collision penetration can result in a poor experience.

[RossNordby]

You can enable CCD by changing the PositionUpdateMode, but in v1 that's still going to allow some penetration by design and it introduces motion clamping artifacts (which may or may not be noticeable). The easiest, but potentially expensive, option is to increase the simulation update frequency.

[SourceCoder-2017]

I tried it and set the update frequency to 1 or 2 milliseconds, and the penetration was not so obvious. But I don't know if 1 millisecond update will bring greater performance pressure. Does the v2 version solve this problem? But I am currently using the bepuphysics1int version. If the v2 version wants to change to this kind of deterministic physics simulation, do I just need to change the numeric types in it to Fix64 to achieve it, or do I need to make some changes in the logic?

[RossNordby]

Running at 500-1000hz will indeed cost more, but for billiards-scale simulations that might be fine. You may want to try a combination of lower rates (60-300hz) plus CCD.

Regarding v2:

1. v2 changes how CCD works significantly. With the swept CCD mode enabled, it would get a precise pairwise time of impact and compute a collision normal accordingly. Note that a precise pairwise TOI+normal is not the same thing as a globally correct TOI+normal. A "true" solution here would look like full conservative advancement which neither library supports and tends to be impractical for larger simulations.
2. v2 also changes how restitution is handled. A damping ratio and frequency for contact springiness can reproduce coefficient of restitution-like behavior, but will tend to damp more of the bounce out without high substepping rates.
3. v2 can be made locally deterministic by setting the Simulation.Deterministic flag to true, but it is not cross platform deterministic (which is usually what people are looking for with fixed point math). Moving v2 to fixed point would require an enormous amount of work and is not a realistic option. (Cross platform determinism is more easily achieved with software implementations of the remaining platform-specific math like trig.)
4. v2 is much faster than v1 but only for nontrivial simulations. Billiards is too small for the advantage to really matter.