Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Help  Rope end caps
#1
How do I add end caps to the rope extruded renderer?

Now I'm adding an extra control point to the ends of the rope with 0 thickness, this blocks off the view to the inside of the rope but I don't know if this is bad for the simulation or something. 

At the moment it seems fine.
Reply
#2
(21-09-2026, 03:39 AM)mechabit Wrote: How do I add end caps to the rope extruded renderer?

Hi!

You can simply retrieve the position at the end of the rope and place an arbitrary object there. You can do this in a variety of ways, the usual ones are the particles API or ObiRopePathSmoother.GetSectionAt() - which returns an orthonormal frame at any point along the rope, giving you position/orientation/size simultaneously.

There's a couple example components included that will help you do this without any custom code:

- ObiRopeAttach, you add it to the object you want to place in the rope and select the mu (normalized coordinate, between 0 and 1) of the point along the rope you want it to be placed in.
- ObiRopePrefabPlugger, used in the ElectricalWires sample scene. This will place a prefab of your choice at the rope's ends and in any intermediate tear points, in case your rope can be cut/torn.

kind regards,

(21-09-2026, 03:39 AM)mechabit Wrote: Now I'm adding an extra control point to the ends of the rope with 0 thickness, this blocks off the view to the inside of the rope but I don't know if this is bad for the simulation or something. 

A particle with zero radius will tunnel trough basically anything, so it's not an ideal thing to have if you want proper collision detection. Better to have normal-sized particles and place custom cap objects there.

kind regards,
Reply
#3
Thanks, that works

I would add a cap ends options to the rope renderer though, probably would be more performant that way
Reply
#4
(21-09-2026, 01:48 PM)mechabit Wrote: Thanks, that works

I would add a cap ends options to the rope renderer though, probably would be more performant that way

Adding a special case to the rope renderer (if at start or end of a rope segment, do something entirely different) means poor cache coherency in CPU (cache needs to flush its contents to bring in new data for the cap, then flush again to bring regular segment data after), non-coalesced memory accesses (consecutive threads no longer access consecutive memory) and more thread divergence (threads in the same warp do not execute the exact same code) in GPU, negatively affecting performance.

That, along with flexibility - the fact that you could need caps to be arbitrary GameObjects - are the reasons why the renderer doesn't do its own caps.
Reply