26-12-2017, 10:10 PM
(This post was last modified: 26-12-2017, 10:14 PM by josemendez.)
Hi there,
Upon initialization, the initial distance between the rope particles is used to set as the "relaxed" state of the rope. Changing the distance constraints "scale" parameter will make the rope longer or shorter right after initializing it, causing it to suddenly elongate or contract. This of course will make the rope spring back to the size dictated by the scale.
If you want the rope to keep a given initial shape, set the control points of the Catmull-Rom curve accordingly. (This thread is relevant: http://obi.virtualmethodstudio.com/forum...hp?tid=233)
The method outlined in http://obi.virtualmethodstudio.com/forum...hp?tid=175 works when "teleporting" a rope to a different place in the scene, usually you do not want the abrupt change in location to affect the physics of the rope. It works by disabling the rope, changing its transform, and then re-enabling it. However it will not work in your case as (afaik) you're not changing the rope transform (position/rotation/scale), but the constraint properties. Applying this method will have no effect.
Regarding rope elasticity: have you tried to simply increase the amount of distance/pin constraint iterations in the solver, or reduce Unity's physics timestep? This should be tried before resorting to tethers. Tethers (also known in physics jargon as LRAs or long range attachments) are useful when dealing with large mass ratios (heavy objects pinned to light ropes), as they give iterative solvers a really hard time. This doesn't seem to be your case.
If you want to use the fix/add tethers/unfix method, make sure tether constraints are enabled both in the rope and the solver!
I've tried to add multiple ropes to the same solver with no issues. Can you share the code you used to do this?
Having multiple solvers in the same scene will incur a slight performance cost for each additional solver. The best approach is usually to group ropes by spatial proximity under the same solver, that way they can be culled together. If your ropes are scattered across the level, then it's best to use a single solver for each one (hint: use prefabs).
cheers!
Quote:When the simulation starts, the rope springs like a rubber band that’s just been let go and then settles down. I'd like to have everything begin in a resting state (unmoving). In this thread: http://obi.virtualmethodstudio.com/forum...hp?tid=175 the solution suggested is disable the rope and wait for the next FixedUpdate before reenabling. I’ve tried to implement that in my script, but it doesn’t seem to be having any effect.
Upon initialization, the initial distance between the rope particles is used to set as the "relaxed" state of the rope. Changing the distance constraints "scale" parameter will make the rope longer or shorter right after initializing it, causing it to suddenly elongate or contract. This of course will make the rope spring back to the size dictated by the scale.
If you want the rope to keep a given initial shape, set the control points of the Catmull-Rom curve accordingly. (This thread is relevant: http://obi.virtualmethodstudio.com/forum...hp?tid=233)
The method outlined in http://obi.virtualmethodstudio.com/forum...hp?tid=175 works when "teleporting" a rope to a different place in the scene, usually you do not want the abrupt change in location to affect the physics of the rope. It works by disabling the rope, changing its transform, and then re-enabling it. However it will not work in your case as (afaik) you're not changing the rope transform (position/rotation/scale), but the constraint properties. Applying this method will have no effect.
Quote:Next, I would like the ropes to be as non-elastic as possible. I realize that the recommended way of doing this is via tethers, but because my ropes aren’t fixed, tethers wouldn’t seem to be an option. However, in this thread: http://obi.virtualmethodstudio.com/forum....php?tid=6 there’s a method described in which the rope is fixed, tethers are generated, then the rope is unfixed. Once again, I’ve tried to implement this in my script, but it doesn’t seem to be having any effect.
Regarding rope elasticity: have you tried to simply increase the amount of distance/pin constraint iterations in the solver, or reduce Unity's physics timestep? This should be tried before resorting to tethers. Tethers (also known in physics jargon as LRAs or long range attachments) are useful when dealing with large mass ratios (heavy objects pinned to light ropes), as they give iterative solvers a really hard time. This doesn't seem to be your case.
If you want to use the fix/add tethers/unfix method, make sure tether constraints are enabled both in the rope and the solver!
Quote:Finally, I’ve found that each individual rope has to have its own dedicated solver; if I try to share a single solver across multiple ropes, Unity immediately crashes. I’m guessing this has something to do with removing and adding multiple pin constraints from the solver simultaneously/asynchronously? (Just a guess). Anyway, my question is whether there will be any problems (like a performance hit) by having upwards of 100 solvers in a single scene.
I've tried to add multiple ropes to the same solver with no issues. Can you share the code you used to do this?
Having multiple solvers in the same scene will incur a slight performance cost for each additional solver. The best approach is usually to group ropes by spatial proximity under the same solver, that way they can be culled together. If your ropes are scattered across the level, then it's best to use a single solver for each one (hint: use prefabs).
cheers!