Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Bug / Crash  2D Rope Rotation
#1
I've been encountering a glitch ever since the newest update of the OBI rope (I don't think it happened with 6.4, but I could be wrong) where the rope will sometimes rapidly flatten and unflatten itself so that it basically looks like it is flickering. I can get it to happen consistently, but only with a weird setup where the rope is laid across the top of a box in the right way. There is a chance that I'm doing something wrong on my end, but I don't know what I could have done that causes this behavior. I've posted screenshots below of the rope in both states. It was hard to get the second screenshot as it only flattens for a split second at a time.

Rope Not Flat:

[Image: Y4pA2MM.png]

Rope Flat:

[Image: Xkq66zR.png]
Reply
#2
Hi!

Nothing has changed between 6.4 and 6.5 regarding rope rendering. Which rendering component are you using, ObiRopeExtrudedRenderer or ObiRopeLineRenderer? on a ObiRope or a ObiRod?

Can you give some more additional details or steps to reproduce this? I can't seem to get it to happen using ObiRopeLineRenderer + ObiRope.
Reply
#3
(14-12-2022, 02:26 PM)josemendez Wrote: Hi!

Nothing has changed between 6.4 and 6.5 regarding rope rendering. Which rendering component are you using, ObiRopeExtrudedRenderer or ObiRopeLineRenderer? on a ObiRope or a ObiRod?

Can you give some more additional details or steps to reproduce this? I can't seem to get it to happen using ObiRopeLineRenderer + ObiRope.

It probably was happening with 6.4 and I just didn't notice it. It's on an ObiRope with the ObiExtrudedRenderer. I did a bit more testing and it seems to happen when the rope comes to a stop/near stop with a really low sleep threshold. I had it set to 0 in that first post, though, by setting it to 0.0001, I got it to get stuck in that flattened state as long as it remained still.

(14-12-2022, 02:26 PM)josemendez Wrote: Hi!

Nothing has changed between 6.4 and 6.5 regarding rope rendering. Which rendering component are you using, ObiRopeExtrudedRenderer or ObiRopeLineRenderer? on a ObiRope or a ObiRod?

Can you give some more additional details or steps to reproduce this? I can't seem to get it to happen using ObiRopeLineRenderer + ObiRope.

I just tested it with the ObiRopeLineRenderer and this glitch only seems to happen with the ObiRopeExtrudedRenderer.
Reply
#4
(14-12-2022, 09:00 PM)DragonControl Wrote: It probably was happening with 6.4 and I just didn't notice it. It's on an ObiRope with the ObiExtrudedRenderer. I did a bit more testing and it seems to happen when the rope comes to a stop/near stop with a really low sleep threshold. I had it set to 0 in that first post, though, by setting it to 0.0001, I got it to get stuck in that flattened state as long as it remained still.


I just tested it with the ObiRopeLineRenderer and this glitch only seems to happen with the ObiRopeExtrudedRenderer.

Hi,

Just took a look at your other post (the "Look rotation viewing vector is zero") and I think both are related. The extruded rope renderer uses something known as "parallel frame transport" that requires calculating the direction from each particle in the rope to the next one. If there's two particles in the exact same position, it will be impossible to calculate a direction from one to the other, so the rope mesh will be incorrectly calculated. As the rope moves around these particles might sometimes separate enough that the direction can be correctly calculated.

This will throw off any calculations that involve calculating the local direction of the rope, and both extruded mesh generation and cursor gizmo drawing depend on it.

The only way I can think of for two particles to overlap each other is to generate a rope blueprint with multiple identical control points. Is this rope procedurally generated?(have you created it trough a script?)

kind regards,
Reply
#5
(15-12-2022, 09:05 AM)josemendez Wrote: Hi,

Just took a look at your other post (the "Look rotation viewing vector is zero") and I think both are related. The extruded rope renderer uses something known as "parallel frame transport" that requires calculating the direction from each particle in the rope to the next one. If there's two particles in the exact same position, it will be impossible to calculate a direction from one to the other, so the rope mesh will be incorrectly calculated. As the rope moves around these particles might sometimes separate enough that the direction can be correctly calculated.

This will throw off any calculations that involve calculating the local direction of the rope, and both extruded mesh generation and cursor gizmo drawing depend on it.

The only way I can think of for two particles to overlap each other is to generate a rope blueprint with multiple identical control points. Is this rope procedurally generated?(have you created it trough a script?)

kind regards,


I use the path editor when setting up the rope's blueprint and there doesn't appear to be multiple particles overlapping each other. It was not procedurally generated/created through a script. Is there a way for me to fix this? Should I just remake the blueprint.

Thank you so much for the help.
Reply