29-09-2023, 11:56 AM
(This post was last modified: 29-09-2023, 12:02 PM by josemendez.)
Hi,
Disabling the ObiRope component won't make it continue its life cycle, it disables it entirely. When you re-enable the rope, it will be re-enabled and its state copied from the blueprint data.
To keep the rope from rendering but otherwise keep simulating, disable its ObiRopeExtrudedRenderer instead (or whichever renderer you're using).
This is because changing the length of a rope does not actually change its shape (that is, it does not move particles around) - it only changes its length by adding or removing particles from the pool and placing them at the cursor's "source mu" position. Otherwise, the rope keeps its current shape. If you need the rope particles to be placed at a specific place (for instance in a straight line that joins both players), you need to do this yourself using the particles API.
See for instance the RopeGrapplingHook sample scene: when initially extending the hook, it does so in a straight line. This is accomplished by setting particle inverse masses to zero (to temporarily make them kinematic) and explicitly setting each particle's position.
This will only increase simulation accuracy (and negatively affect performance), but won't fix the flawed logic in your approach.
If the rope is disabled, attachments won't work because there's no rope to attach. When re-enabling the rope, particles will be re-attached causing the rope to jump. Again, the solution to this is to explicitly set particle positions.
kind regards,
(29-09-2023, 11:38 AM)Alexander34 Wrote: The thing is that when I disable ObiRope and turn off collisions, so that it continues its life cycle, but visually it is not visible.
Disabling the ObiRope component won't make it continue its life cycle, it disables it entirely. When you re-enable the rope, it will be re-enabled and its state copied from the blueprint data.
To keep the rope from rendering but otherwise keep simulating, disable its ObiRopeExtrudedRenderer instead (or whichever renderer you're using).
(29-09-2023, 11:38 AM)Alexander34 Wrote: But there is a problem. Players move all the time, and ObiRope.restLentght should always be = Vector3.Distance(player1.transform.position, player2.transform.position). I change its length via cursor and everything would be fine, but - when I turn on the rope rendering and set cursor.ChangeLength(Vector3.Distance(player1.transform.position, player2.transform.position)) there are constantly jerks.
This is because changing the length of a rope does not actually change its shape (that is, it does not move particles around) - it only changes its length by adding or removing particles from the pool and placing them at the cursor's "source mu" position. Otherwise, the rope keeps its current shape. If you need the rope particles to be placed at a specific place (for instance in a straight line that joins both players), you need to do this yourself using the particles API.
See for instance the RopeGrapplingHook sample scene: when initially extending the hook, it does so in a straight line. This is accomplished by setting particle inverse masses to zero (to temporarily make them kinematic) and explicitly setting each particle's position.
Quote:I increase and decrease the number of sub-steps in distance and in solver, but it either heavily loads the hardware or behaves very unstable.
This will only increase simulation accuracy (and negatively affect performance), but won't fix the flawed logic in your approach.
(29-09-2023, 11:38 AM)Alexander34 Wrote: at the same time you should take into account that when you completely disable ObiRope, ObiRopeAttachment also do not follow the players and when you turn on there is a strong jump rope.
If the rope is disabled, attachments won't work because there's no rope to attach. When re-enabling the rope, particles will be re-attached causing the rope to jump. Again, the solution to this is to explicitly set particle positions.
kind regards,