Help Attaching "hose nozzle" to the end of the rope

[Alberos]

Hi,

I'm using Obi rope to simulate a rubber tube. I'm trying to insert a head/nozzle at the end of the "rope". Think of it as a pump nozzle at the gas station. The nozzle is inserted into the tube and not just attached at the end. Because some part of the rigid nozzle is inside the tube, it make that section and a bit more running up the tube rigid and unable to bend.

In the past I can achieve the OK result by using Rod instead of Rope and using 2 attachment points, one at the extreme end and another a bit farther out (see my beautiful Paint drawing skill).
   
The black is the end piece model. The red dot is a static attachment. The grey line is the Obi Rod.

However, this time, I needed a Rope because I want to change its size at runtime. The tube will also be clear, which make it harder to hide stuff. Lastly, from what I understand, I need a dynamic attachment because I want to reel in the rope at the other end, dragging the head piece along with the rope. There is also a similar setup tube (in blue) branching off of a main clear tube. The End and EndPre control point and its dynamic attachment collider is set to not collide with each other. At least I want the rope to not do this:
   
The head piece (kind of like a plug) is not align with the tube. In some case it's worst than this (the plug is almost completely out of the tube)

Any advice to make the end piece stay inside the tube but not increasing performance cost too much? I'm really worried about the performance, I don't think using 4 dynamics would be OK in a mobile VR. I'm thinking of attaching the end piece to the rope particle instead (using particle position/rotation in code?) but this end piece do need to be able to be grabbed and moved by player (VR) so I fear if I do that it might not work.

I think I'm missing something here, any advice or correct way to do this kind of setup is greatly appreciated. I see myself doing this again in the future.


Solver setting (might need to be lowered in the future if the performance is not enough, ideally, keep it at least as possible):
Substeps: 8
Fixed timestep: 0.02

Distance: 2 (Sequential)
Bending: 1 (Parallel)
Particle collision / Queries: 1 (Sequential)
Collision: 1 (Sequential)
Pin: 4 (Parallel)
Stitch: 1 (Parallel)

Rope blueprint setting: 
Thickness: 0.005 (extremely thin, this is a very thin medical tube that goes.... into your nose)
Resolution: 0.5
Pooled Particle: 100

Thanks!

[josemendez]

In the past I can achieve the OK result by using Rod instead of Rope and using 2 attachment points, one at the extreme end and another a bit farther out (see my beautiful Paint drawing skill).

Hi!

If you're using a rod, should not be necessary to use 2 attachment points: a single attachment point with "constrain orientation" enabled should do, since rods explicitly simulate orientation/torsion, unlike ropes.

However, this time, I needed a Rope because I want to change its size at runtime. The tube will also be clear, which make it harder to hide stuff. Lastly, from what I understand, I need a dynamic attachment because I want to reel in the rope at the other end, dragging the head piece along with the rope. There is also a similar setup tube (in blue) branching off of a main clear tube. The End and EndPre control point and its dynamic attachment collider is set to not collide with each other. At least I want the rope to not do this:

The head piece (kind of like a plug) is not align with the tube. In some case it's worst than this (the plug is almost completely out of the tube)

[quote='Alberos' pid='14291' dateline='1684302669']
Any advice to make the end piece stay inside the tube but not increasing performance cost too much? I'm really worried about the performance, I don't think using 4 dynamics would be OK in a mobile VR. 

Attachments (both dynamic and static) are dirt cheap, they won't even show up in the profiler. Rope simulation and rendering are a lot more expensive comparatively, so I wouldn't worry about attachment performance at all.

I'm thinking of attaching the end piece to the rope particle instead (using particle position/rotation in code?) but this end piece do need to be able to be grabbed and moved by player (VR) so I fear if I do that it might not work.

If you want perfect alignment at all moments between the rope and the object, your best bet is to explicitly set the object's position to follow the rope. This of course won't allow you to pick up the object or interact with it, but you can pick up the rope directly instead using the particles API:

http://obi.virtualmethodstudio.com/manua...icles.html

For instance, detect whether certain particles are in contact with a collider (or inside a trigger), and then set their position to follow user input.

kind regards,

[Alberos]

Attachments (both dynamic and static) are dirt cheap, they won't even show up in the profiler. Rope simulation and rendering are a lot more expensive comparatively, so I wouldn't worry about attachment performance at all.

Yeah, you're right. I tried 4 dynamics on the device and it handles no problem. I think I got that impression back then from older version of Obi and possibly not configure to use Burst backend correctly.

If you want perfect alignment at all moments between the rope and the object, your best bet is to explicitly set the object's position to follow the rope. This of course won't allow you to pick up the object or interact with it, but you can pick up the rope directly instead using the particles API:

http://obi.virtualmethodstudio.com/manua...icles.html

For instance, detect whether certain particles are in contact with a collider (or inside a trigger), and then set their position to follow user input.

Hm.... that sounds complicated. I might let it slide this time, it's not looking so bad in headset since the tube is so small. I will keep this info in mind for future. Thanks for the suggestion.


Oh and on side note, do you have documentation for ObiStitcher component and its corresponding constraint in solver? I see only its API reference.

Thanks.