17-12-2019, 12:12 PM
(17-12-2019, 11:57 AM)josemendez Wrote: GetParticlePosition() now expects a solver index instead of an actor index. Same for all GetParticleX() methods.Yes i meant "sliding" hole. Thanks for the detailed explanation! I look forward to playing with the new 5.0!
ObiRope.RestLength has been renamed restLength.
ObiRopeCursor.normalizedCoord has been renamed cursorMu.
ObiRopeCursor.ChangeLength() stays the same.
It's pretty much the same. Having multiple solvers has a slight performance impact, but independent ropes are simulated in parallel regardless of where they are: same solver, different solver, doesn't matter.
You mean a "sliding" hole trough which rope can freely pass, right? It's in our to-do list, but isn't as easy to implement as it sounds. It needs to be a constraint over all rope particles, that dynamically changes its position along the rope. This is extremely useful for medical applications like suturing thread, catheters, etc (not our main interest, but many users have pointed it out), as you can ensure the rope passes trough a point without the need for collision detection.
Doable but wouldn't work as you expect. The thing with particle-based representations (or any discrete representation) is that convergence speed (roughly == rope stiffness) varies depending on resolution. So areas with higher resolution would be more elastic than areas with low resolution. To solve that, you're forced to either use a very small timestep (so that the highest-resolution zones behave correctly) or use continuum-dynamics, that are largely topology-agnostic. Both are quite expensive, so the point of adaptive resolution is moot if in order to have consistent behavior you need to calculate everything as if the entire rope was at the highest resolution.
Thanks lot for the ideas!