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. _______________________________________________ Bf-committers mailing list Bf-committers@blender.org https://lists.blender.org/mailman/listinfo/bf-committers