Help Obi Collision Detection

[meryemekinci]

I have objects with ObiCollider & Obi Rigidbody on them, and they are forced to move at some point. I need to limit their movement, and I also need them to be destroy after a while, in my case when they hit the collider at the top(You can see the colliders in the image below). But Unity's trigger methods seems not working in my case.

[josemendez]

ObiCollider & ObiRigidbody are just wrappers over Unity's own collider and rigidbody components, that allow them to interact with Obi particles. Collision detection between colliders and rigidbody physics are entirely handled by Unity. You should ask this question in the Unity forums.

[meryemekinci]

Hello,

I am still having issues with the rope changing the length.

1. The rope's moves are too jiggly. I need its movements to be more settled, because when I make sudden moves to any corner of the screen, it loses contol. 

2. The distance between the particles are not equal all the time. It is always tighter near the cursor. I need them to be equally away from each other. Because that causes unexpected spaces between some particles and the connection with a joint breaks.

What I do to change the length is;

• To compare the rest length of the rope and the expected distance/length
  
• To change the rope length by using Cursor.ChangeLength(expectedLength*)
  

*expectedLength: calculated depending on the change of mouse cursor's points.

Here is a video of screen recording while I'm playing with the rope.

I made a Prefab from ObiRope. These are other Obi related settings from the project.

Blueprint Settings:



ObiSolver Settings:



ObiRope Settings:

[meryemekinci]

Any ideas?

[josemendez]

1. The rope's moves are too jiggly. I need its movements to be more settled, because when I make sudden moves to any corner of the screen, it loses contol.

Increasing damping should help with "jigglyness", as it increasing the rate at which particles lose energy. I see that you have it set quite high already, though. A possible solution could be allowing the user to only indirectly control the rope's end trough forces or other means, not allowing instant or near-instant teleportation to any point of the screen. See the included "WrapTheRope" scene for reference, which is basically the same game you're attempting to replicate.

Also, our rope has way too many particles. This will result in less-than-ideal performance, and force you to use a lot of iterations/substeps to keep in taut, resulting in even worse performance.

You should try to reduce rope resolution as much as you can, while keeping collision detection robust enough. Making the pegs thicker could help.

The distance between the particles are not equal all the time. It is always tighter near the cursor. I need them to be equally away from each other. Because that causes unexpected spaces between some particles and the connection with a joint breaks.

As explained in the manual (http://obi.virtualmethodstudio.com/tutor...olver.html), sequential evaluation is order-dependent. Constraints are grouped in batches to allow for efficient parallelization, but this results in particles that separate different distances from each other when the simulation can't converge (that is, when the rope stretches too much).

Using parallel evaluation solves this, at the cost of slower convergence. Which one to use is up to you and the results you want to get.

[meryemekinci]

Increasing damping should help with "jigglyness", as it increasing the rate at which particles lose energy. I see that you have it set quite high already, though. A possible solution could be allowing the user to only indirectly control the rope's end trough forces or other means, not allowing instant or near-instant teleportation to any point of the screen. See the included "WrapTheRope" scene for reference, which is basically the same game you're attempting to replicate.

Also, our rope has way too many particles. This will result in less-than-ideal performance, and force you to use a lot of iterations/substeps to keep in taut, resulting in even worse performance.

You should try to reduce rope resolution as much as you can, while keeping collision detection robust enough. Making the pegs thicker could help.


As explained in the manual (http://obi.virtualmethodstudio.com/tutor...olver.html), sequential evaluation is order-dependent. Constraints are grouped in batches to allow for efficient parallelization, but this results in particles that separate different distances from each other when the simulation can't converge (that is, when the rope stretches too much).

Using parallel evaluation solves this, at the cost of slower convergence. Which one to use is up to you and the results you want to get.

Thank you for your detailed answer, Jose. I really appreciate it. I will try and check the results right away. I just have a simple question related to the particles. Is it possible to change pooled particle count in run time? The reason I set it high, I will need the rope to be longer in later chapters of the game.

Thank you in advance. Have a nice day!

[josemendez]

Thank you for your detailed answer, Jose. I really appreciate it. I will try and check the results right away. I just have a simple question related to the particles. Is it possible to change pooled particle count in run time? The reason I set it high, I will need the rope to be longer in later chapters of the game.

Thank you in advance. Have a nice day!

Hi,

The whole reason behind pooling particles is to avoid having to allocate memory at runtime and avoid GC spikes. You're supposed to pre-allocate as many particles as you will possibly need. Note that pooled particles have no impact on the simulation.

When I said the rope had too many particles, I was referring to particles per length unit. You would get better results with slightly lower rope resolution.

[meryemekinci]

Hi,

The whole reason behind pooling particles is to avoid having to allocate memory at runtime and avoid GC spikes. You're supposed to pre-allocate as many particles as you will possibly need. Note that pooled particles have no impact on the simulation.

When I said the rope had too many particles, I was referring to particles per length unit. You would get better results with slightly lower rope resolution.

I have changed the rope resolution to a lower number and I have also changed the structure to control the rope, now my game does not allow any instant move on the rope. Eveything seems working better. Thank you, Jose! I really appreciate your time and work.

[meryemekinci]

Hi Jose,

I am using the OnEnter, OnExit methods to understand collisions in my project right now. But I am having another challenge. (You can see a video of gameplay from the game in the previous replies (#13), if it's not visible, I can send another one.)

The issue is that when I roll the rope around two joints once and I try to roll around already-contacting joint again, OnEnter is not going to be called. But since the length of the rope is expected to be changed according to number of contacting joints, this problem makes my calculation not work properly. 

How can I know that the rope contacts with an already-contacting joint?

Thank you in advance.

[josemendez]

Hi Jose,

I am using the OnEnter, OnExit methods to understand collisions in my project right now. But I am having another challenge. (You can see a video of gameplay from the game in the previous replies (#13), if it's not visible, I can send another one.)

The issue is that when I roll the rope around two joints once and I try to roll around already-contacting joint again, OnEnter is not going to be called. But since the length of the rope is expected to be changed according to number of contacting joints, this problem makes my calculation not work properly. 

How can I know that the rope contacts with an already-contacting joint?

Thank you in advance.

Hi there,

You can't use the OnEnter event for this, because it will only be triggered the first time a collider touches the rope. Enter/Exit/Stay behave the same way as Unity's contact events.

You will need to use the raw collision callbacks (http://obi.virtualmethodstudio.com/tutor...sions.html). Keep track of a list of all colliders in contact with the rope, in chronological order. When you detect a new collision with a collider already in the list (that is, same collider index, but different particle index), check if it's the last one or not. If it's the last one, the rope is still wrapping around the same collider. If it's not, it means the rope is wrapped around a different collider, but has returned to wrap around a collider it was already in contact with. To clarify:

Case 1: current collider list is A, B, C, D, a new contact with collider D has been detected. The rope is still wrapping around D. Nothing to do.
Case 2: current collider list is A, B, C, D, a new contact with collider B has been detected. The rope is wrapping around B a second time, add B to the list (so it becomes A, B, C, D, B).

This is the first idea that comes to mind, there might be other ways to do it. hope this helps. cheers!