Help Rope Particle Positioning C#

[VirtualCucumber]

Generally when moving I would set the ropes particle invMass[] to 0 and the positions[] to the position I want through that ropes solver but with this new projec I want these ropes all under one solver and would like to assign the positions of these rope particles when I need to using ObiRope.positions[] type instead of ObiSolver.positions[] since I want to refer to a certain rope instead of the solver that controls all.

When I do this however it acts weird like its operating on local positioning (IDK relative to what, maybe solver positioning). Was wondering more details on this matter, why it acts like this and if this is the not thee way of doing this, if there was a way. I would like to access certain ropes/actors and their particles positions/mass when they are all under one solver.

[josemendez]

Generally when moving I would set the ropes particle invMass[] to 0 and the positions[] to the position I want through that ropes solver but with this new projec I want these ropes all under one solver and would like to assign the positions of these rope particles when I need to using ObiRope.positions[] type instead of ObiSolver.positions[] since I want to refer to a certain rope instead of the solver that controls all.

When I do this however it acts weird like its operating on local positioning (IDK relative to what, maybe solver positioning). Was wondering more details on this matter, why it acts like this and if this is the not thee way of doing this, if there was a way. I would like to access certain ropes/actors and their particles positions/mass when they are all under one solver.

particle positions/velocities/etc in the actor's arrays (actor.positions, actor.velocities...) are expressed in the actor's local space. These are converted to solver space when you call PushToSolver(), so solver.positions, solver.velocities... are expressed in solver space.

Solver space can either be world space  (if the solver has "simulate in local space" disabled), or the solver's local space (if the solver has "simulate in local space" enabled).

Easiest and most efficient way to change per-actor particles is to find out what their index in the solver is, then directly modifying the solver data:

Code:

var solverIndex = actor.particleIndices[index];
actor.solver.positions[solverIndex] = <your position in world or local (solver) space>.

[VirtualCucumber]

particle positions/velocities/etc in the actor's arrays (actor.positions, actor.velocities...) are expressed in the actor's local space. These are converted to solver space when you call PushToSolver(), so solver.positions, solver.velocities... are expressed in solver space.

Solver space can either be world space  (if the solver has "simulate in local space" disabled), or the solver's local space (if the solver has "simulate in local space" enabled).

Easiest and most efficient way to change per-actor particles is to find out what their index in the solver is, then directly modifying the solver data:

Code:

var solverIndex = actor.particleIndices[index];
actor.solver.positions[solverIndex] = <your position in world or local (solver) space>.

With Obi Rope 5 how would you translate from local to world since the Solver operates in local now.


Also the new update(s) are awesome!!!

[josemendez]

With Obi Rope 5 how would you translate from local to world since the Solver operates in local now.


Also the new update(s) are awesome!!!

If you mean transforming particle positions/velocities from local (solver) space to world, same way you do with any other transform: solver.transform.InverseTransformPoint(), or InverseTransformDirection() if dealing with vectors.

If you're going to batch transform a lot of things, caching transform.localToWorldMatrix and multiplying by it is faster than using the Transform() methods.

(Glad you like 5.0! )