[Bf-committers] Ridged bodies

[Sergej Reich]

Hi, 

you can reach me by email.
I guess I just respond here inline.

Am Dienstag, den 08.01.2019, 20:24 +0100 schrieb Knapp:
> Sergof, I was sent this and thought it might be useful to you. I
> could not
> find a better way to contact you so posted it here. Hope it is
> useful.
> 
> Andy Sellers
> <https://www.facebook.com/andrew.m90.sellers?fref=gc&dti=2207257375>
> I did
> a project with Rigid Bodies a while back, and found a few things that
> could
> be improved. 1.There is no way to get an over-view of constraint
> hierarchy,
> to see which objects are controlled by other (sometimes multiple)
> objects,
> which then control still others. This makes debugging a complex
> simulation
> difficult, when getting just one constraint property wrong, among
> hundreds,
> can cause the simulation to explode.

The way rigid bodies and constraints work is not optimal, If I would do
things again I'd change quite a lot. Currently working with few objects
and especially few constranits works best. Improving things here would
require quite a lot of work, at least if you wanted to get things
right.

> 2.Many of the physical properties
> don't use standard units, or in some cases the manual just doesn't go
> into
> much detail on what they mean. (Friction, Bounciness, Damping,
> Impulse,
> Spring Stiffness. These properties seem to just use arbitrary values,
> and
> it took quite a bit of trial and error to find the right ones.)

The main reason units aren't mentioned is because bullet, the library
we use, doesn't mention them either. For the most part those are
standard SI units though, not sure where non standard units are
supposed to be used.
Of course things like bounciness (coefficient of restitution), friction
and rigid body damping don't have units.
For things like spring stiffness, even knowing the units wouldn't help
you since those are generally pretty unintuitive (typically kg/s for
stiffness and kg/s² for damping), depend on other attributes and
can't really be changed independently. We could still tell users what
they are of course.
Add to that the fact that using realistic values is not a good idea for
the kind of simulations we're worknig with anyway (especially high mass
ratios work poorly), trial and error is the name of the game here
regardless.

> 3.General
> improvements to the documentation and tooltips would be very helpful.
> (I'm
> pointing a finger at myself here, because I could help with this.) 

Documentation can always be improved.

> 4.The UI
> for Rigid Bodies in both 2.7 and 2.8 could be better organized.
> Currently,
> there is quite a bit of jumping around to change this or that
> property. I
> expect the planned Node-Based Physics will improve this.

Definitely, again there's some fundamental changes that would be needed
to get to a place I'd consider good. I'm not aware of any concrete
plans for node based physics, so can't say how that would improve
things.

> 5.This would be an
> entirely new feature; a graph to visualize various
> forces/speed/acceleration acting on objects in the simulation over
> time.
> For example, you could have an object start the simulation in the
> air,
> free-fall to a sloped ground, and then start to roll. The graph would
> show
> how much force gravity had on the object when it started to fall, a
> sudden
> spike when it collides with the ground, and then increasing
> centrifugal
> force as it begins to roll down the slope. Blender already has all
> this
> information; 1 data-point for every step in the simulation. Putting
> all
> that in a graph where the user can see the raw data would be very
> useful
> for error checking when the simulation goes haywire, or for building
> a
> simulation that meets pre-defined force/speed/acceleration goals.

Graphing things could be useful I guess (although I'm not sure how
much). The motion paths feature does something in that vein, but I
don't really have an opinion here.

Regards, Sergej.