17-12-2019, 10:55 AM
(16-12-2019, 05:09 PM)josemendez Wrote: Note that in 5.0, a lot of things have changed. Rope editing workflow is completely different (read as 'better'). If you're just starting a project, go ahead, but I'd advise against upgrading mid-project!
So I've looked at the new 5.0 rope documentations and it looks neat (like the multiple cursors on one rope which I currently have in a hacked solution
). If i can get 20-30% performance increase i think it is worth it (ropes are basically the essential and most performance heavy part of the project). I'm past the first prototype of the project and already had in mind rebuilding some of the ropes for better performance. I'm currently only relying on handles and the following Obi methods:ObiRope.GetParticlePosition(i);
ObiRope.RestLength
ObiRopeCursor.normalizedCoord;
ObiRopeCursor.ChangeLength();
Are any of these methods changed (drastically) in 5.0?
Also a side question; is it better performance wise to have multiple solvers if the ropes are not supposed to interact with each other?
A few suggestions I've written down during the past month working with Obi Rope:
It would be nice to have a "tether" or "handle" for ropes which does not lock to particles but rather works as a "via" point for the rope curve. To do this now I have to fiddle around with collisions and on an Oculus Quest I can't hold a particle resolution high enough for the collisions to make sense.
So I'm forced to use handles and either manipulate each side of the handled particle to maintain the correct amount of particles across the whole rope, or split the rope up into two separate ropes and manipulate them separately.
Furthermore, it would be nice to have different resolutions or smoothing levels across a rope. This way I can make nice looking simulations at critical points (like the issue above with collisions) or at areas closest to the player.