06-05-2020, 07:57 AM
(This post was last modified: 06-05-2020, 08:06 AM by josemendez.)
Hi there,
You're adding constraints to a blueprint. Existing instances of the blueprint won't be updated if you modify it, so if your ropes are already there in the scene, modifying the blueprint will have no effect at all. Blueprints behave exactly like prefabs, as both are assets: once instantiated at runtime, the instances retain no memory of what prefab they were instantiated from, so modifying the prefab will have no effect on the existing instances. Only on instances you create after modifying it. Same for blueprints. See:
http://obi.virtualmethodstudio.com/tutor...cture.html
Note this is not a Obi-only thing, it's how the concept of prefabs/instances (around which a big part of Unity is built) works. It's very important that you understand it.
When an actor is instantiated in a solver, new indices are assigned to its particles, and these indices are stored in the actor's solverIndices array:
http://obi.virtualmethodstudio.com/tutor...icles.html
So even if multiple rope instances share the same blueprint, at runtime their particles will have different solver indices (the ropeIndex you pass into your function), and they won't all be pinned to the same collider if that's what you meant.
Solution: instead of adding new pins to the blueprint, add them to the actor itself.
Also, I see you're passing transform.localPosition as the pin offset. This is quite likely not what you want. The offset is the position of the pin constraint, expressed in the collider's local space. However transform.localPosition is the position of whatever object contains the OnRopeCollision() method, expressed in its parent's local space, so two completely different things. I can't be certain for sure this is not intentional (in the grappling hook sample code it is, since we use the position of the hook launcher as the constraint position for the character), but in your context it looks like a mistake to me.
You're adding constraints to a blueprint. Existing instances of the blueprint won't be updated if you modify it, so if your ropes are already there in the scene, modifying the blueprint will have no effect at all. Blueprints behave exactly like prefabs, as both are assets: once instantiated at runtime, the instances retain no memory of what prefab they were instantiated from, so modifying the prefab will have no effect on the existing instances. Only on instances you create after modifying it. Same for blueprints. See:
http://obi.virtualmethodstudio.com/tutor...cture.html
Note this is not a Obi-only thing, it's how the concept of prefabs/instances (around which a big part of Unity is built) works. It's very important that you understand it.
When an actor is instantiated in a solver, new indices are assigned to its particles, and these indices are stored in the actor's solverIndices array:
http://obi.virtualmethodstudio.com/tutor...icles.html
Quote:Actor particle indices run from 0 to the amount of particles in that actor. However, since particle data for an actor might be scattered across the solver arrays, you need to map from actor index to solver index. You can map from actor particle indices to solver particle indices using the actor's solverIndices array.
So even if multiple rope instances share the same blueprint, at runtime their particles will have different solver indices (the ropeIndex you pass into your function), and they won't all be pinned to the same collider if that's what you meant.
Solution: instead of adding new pins to the blueprint, add them to the actor itself.
Also, I see you're passing transform.localPosition as the pin offset. This is quite likely not what you want. The offset is the position of the pin constraint, expressed in the collider's local space. However transform.localPosition is the position of whatever object contains the OnRopeCollision() method, expressed in its parent's local space, so two completely different things. I can't be certain for sure this is not intentional (in the grappling hook sample code it is, since we use the position of the hook launcher as the constraint position for the character), but in your context it looks like a mistake to me.