Obi Official Forum - Jitter on small linked objects

Hello!

I'm trying to create a rope that the user would be able to grab and interact with in VR from basically any place, not only the start and end. So I figured the simples way to do that would be to add a bunch of rigidbodies and connect them via ropes. Similar to the RopeNet example. I also need to sync that over the network, that's another reason I used a couple of rigidbodies, they are very simple to sync over Fusion with NetworkObject.

What I did is I took the RopeNet example script and made my own that generates the same thing, but in a line instead of a net and adds a couple of components for interactivity to the rigidbody objects.

Since it should still look like a rope and not a buoy line, these objects should be reasonably small (the smaller the better) and with a pretty low distance between them for usability. But when I make the objects small, the ropes start to detach and jitter (the RopeNet example does that too, on the top ones).

Attached a low fps gif of the jitter (it is way more spazzy in Unity).

Can anybody help me remove the jitter or point me in the right direction if my approach is flawed?

If anyone has a similar problem, seems like it was because of the issue described here: http://obi.virtualmethodstudio.com/manua...l#fighting

I played around with the offsets for the rope creation and pins and removed the jittering issue. Another thing I had to do is to make sure that only one part of the rope handles the gravity. So either the rigidbodies have gravity and the ropes don't or the other way around.

The result I got right now is pretty stable and looks like this:
[broken image]

Still the issue of gaps left, which I couldn't solve yet, because of the issue mentioned above. They are also compounded by all the rbigidbodies pulling the top ones, making the gaps on top larger. Will be greatful for any ideas on this one

Now I'm facing another issue - dynamically spawned ropes have no collisions. You can see that in the RopeNet example, the ropes that are spawned from code with generated blueprints are not colliding.

Seems to be somehow connected with blueprints, because if I set a blueprint (for example short rope) to the rope object, it starts colliding. Which is extremely weird considering that blueprints don't have any collision parameters.

(17-03-2023, 10:50 PM)Crazo Wrote: [ -> ]If anyone has a similar problem, seems like it was because of the issue described here: http://obi.virtualmethodstudio.com/manua...l#fighting

I played around with the offsets for the rope creation and pins and removed the jittering issue.

Tinkering with the attachment position / offset is a very hit-and-miss solution, the proper way to set this up is using collision filters as the manual instructs you to do:
http://obi.virtualmethodstudio.com/manua...l#fighting

Quote:The solution is to use categories and masks to filter out collisions between the pinned particle and the collider. See the collisions page for more information on how to set up collision filtering.

(17-03-2023, 10:50 PM)Crazo Wrote: [ -> ]Still the issue of gaps left, which I couldn't solve yet, because of the issue mentioned above. They are also compounded by all the rbigidbodies pulling the top ones, making the gaps on top larger. Will be greatful for any ideas on this one

This sounds like slow convergence. Just use more substeps in your ObiFixedUpdater component.

(17-03-2023, 10:50 PM)Crazo Wrote: [ -> ]Now I'm facing another issue - dynamically spawned ropes have no collisions. You can see that in the RopeNet example, the ropes that are spawned from code with generated blueprints are not colliding. [...] Which is extremely weird considering that blueprints don't have any collision parameters.

Blueprints do in fact have a very important collision parameter: collision filters, which determine which objects/actors specific particles in the blueprint are allowed to collide against. See "collision filtering" in the manual's "collisions" page: http://obi.virtualmethodstudio.com/manua...sions.html. In the case of ropes, collision filters are specified on a per-control point basis (both when editing the rope in-editor using the path editor, and when generating the blueprint at runtime in a script).

In the RopeNet scene, all blueprints generated at runtime are explicitly set up to not collide with anything. In the RopeNet.cs script you can see that all control points in the blueprints have their collision filter set to "1", which means they are set in category 1 and not allowed to collide with colliders/actors in any category.

Passing ObiUtils.MakeFilter(ObiUtils.CollideWithEverything, 1); instead of just "1" will allow the blueprints to collide with colliders/actors in all collision categories. Like this:

Code:
int filter = ObiUtils.MakeFilter(ObiUtils.CollideWithEverything, 1);

blueprint.path.AddControlPoint(pointA, -direction, direction, Vector3.up, 0.1f, 0.1f, 1, filter, Color.white, "A");

blueprint.path.AddControlPoint(pointB, -direction, direction, Vector3.up, 0.1f, 0.1f, 1, filter, Color.white, "B");

For information on how to deal with collision filters in scripts, see "Collision filters" in the collisions scripting page: http://obi.virtualmethodstudio.com/manua...sions.html

let me know if you need further help! Sonrisa

kind regards,

(18-03-2023, 02:13 PM)josemendez Wrote: [ -> ]This sounds like slow convergence. Just use more substeps in your ObiFixedUpdater component.

Blueprints do in fact have a very important collision parameter: collision filters, which determine which objects/actors specific particles in the blueprint are allowed to collide against. See "collision filtering" in the manual's "collisions" page: http://obi.virtualmethodstudio.com/manua...sions.html. In the case of ropes, collision filters are specified on a per-control point basis (both when editing the rope in-editor using the path editor, and when generating the blueprint at runtime in a script).

In the RopeNet scene, all blueprints generated at runtime are explicitly set up to not collide with anything. In the RopeNet.cs script you can see that all control points in the blueprints have their collision filter set to "1", which means they are set in category 1 and not allowed to collide with colliders/actors in any category.

Passing ObiUtils.MakeFilter(ObiUtils.CollideWithEverything, 1); instead of just "1" will allow the blueprints to collide with colliders/actors in all collision categories. Like this:

Gamechanger! The convergence seems to not be the issue, though. It's most likely because of the offsets and colliders,I'm sure when I setup the filtering masks properly, I'll fix that issue.

Filters helped a lot!

Maybe a suggestion, you could probably comment the properties or make some visible in the inspector. I think that would be really helpful for people who are playing around with them. If you don't see that particular documentation page (I didn't, heh), you look at the blueprints and their control points in the inspector and you see only the position and their references between each other. That makes you think that it's a very basic position structure. Even though I looked in the code, I didn't make the connection between filters and collisions, even though I did think that they were probably filtering out.

Anyways, thanks a lot, with your help I achieved the desired result Sonrisa