Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Help  Two Ropes sharing a Dynamic Target
#1
I'm trying to make a dynamic object with two ropes coming out of it and attaching two other dynamic objects. (A Multimeter with a positive and negative probe in VR)

I have one rope properly attached to both ends but the rope that is lower in the hierarchy fails to make the connection to the Multimeter. Can two ropes connect to the same dynamic object? 

P.S. I tried with child objects and each having its own collider and rigidbody but these rigidbodies fought with one another and caused drag when held in VR.

P.P.S. If I make it static it shoots down on the Y-axis. Static may work if I can get it to align but no matter how I rotate the rope path it juts out of the Obi particle attachment in an unnatural and undesirable way.
Reply
#2
(06-02-2023, 05:00 PM)Giantbean Wrote: I'm trying to make a dynamic object with two ropes coming out of it and attaching two other dynamic objects. (A Multimeter with a positive and negative probe in VR)

I have one rope properly attached to both ends but the rope that is lower in the hierarchy fails to make the connection to the Multimeter. Can two ropes connect to the same dynamic object? 

P.S. I tried with child objects and each having its own collider and rigidbody but these rigidbodies fought with one another and caused drag when held in VR.

Hi,

Yes, two ropes can connect to  the same "dynamic object" (I assume you're referring to a non-kinematic rigidbody). See the "FreightLift" sample scene for an example of 4 ropes connected to the same object.

Order of objects within a hierarchy does not matter to a solver, are you creating the attachments at runtime? if so, could you share your code to do this?
Reply
#3
(06-02-2023, 05:07 PM)josemendez Wrote: Hi,

Yes, two ropes can connect to  the same "dynamic object" (I assume you're referring to a non-kinematic rigidbody). See the "FreightLift" sample scene for an example of 4 ropes connected to the same object.

Order of objects within a hierarchy does not matter to a solver, are you creating the attachments at runtime? if so, could you share your code to do this?

I am not doing it with code. I will check the "FreightLift" sample. It is non-kinematic using gravity.


Attached Files Thumbnail(s)
   
Reply
#4
(06-02-2023, 06:13 PM)Giantbean Wrote: I am not doing it with code. I will check the "FreightLift" sample. It is non-kinematic using gravity.

If you’ve copied the attachment from one rope to the other, make sure to re-select the particle group from the dropdown. In case both ropes have identically named particle groups it can look like the attachment is referencing the correct one, but it will be trying to reference a group that does not exist. In this case, an error message will be logged to the console.

Kind regards,
Reply
#5
Thank you for your assistance. I'm still having issues getting it to work. I have labeled the start and end points as Positive Start and Positive end for the red rope and Start and End for the Black rope so I know they are not sharing particle groups. 
In the attached images the dynamic ropes hover a distance from the multimeter. The Static version shows at the multimeter but starts at a strange rigid angle (They both seem to have this strange starting angle?) I also attached an image of the rope's starting curves. I tried using two points A Start1 and Start2 like I saw the to "lower" on the ropes in the Freight lift example but it did not seem to make a difference.


Using a Start particle group that is static followed by a start 2 that is dynamic and has an end and end 2 that also mix dynamic and static is getting close but has terrible drag. Maybe I just need to adjust rigidbody weights.

...Except that makes the object jitter and "swim" across the floor when it is picked up and then set back down.


Attached Files Thumbnail(s)
                   
Reply
#6
(06-02-2023, 08:10 PM)Giantbean Wrote: Thank you for your assistance. I'm still having issues getting it to work. I have labeled the start and end points as Positive Start and Positive end for the red rope and Start and End for the Black rope so I know they are not sharing particle groups. 
In the attached images the dynamic ropes hover a distance from the multimeter. The Static version shows at the multimeter but starts at a strange rigid angle (They both seem to have this strange starting angle?) I also attached an image of the rope's starting curves. I tried using two points A Start1 and Start2 like I saw the to "lower" on the ropes in the Freight lift example but it did not seem to make a difference.


Using a Start particle group that is static followed by a start 2 that is dynamic and has an end and end 2 that also mix dynamic and static is getting close but has terrible drag. Maybe I just need to adjust rigidbody weights.

...Except that makes the object jitter and "swim" across the floor when it is picked up and then set back down.

Based on your description of the issue (ropes starting at a weird angle near the attachment, jittering and “swimming” when picking the rigidbodies up) my guess would be you’ve attached the rope inside a collider that’s also set to collide against the rope. As a result the rope tries to be simulateously inside and outside the collider, since this is physically impossible to achieve it gives rise to unnatural behavior.

This situation - along with the solution- is described in the manual’s page for attachments (see “attachments inside colliders”)
http://obi.virtualmethodstudio.com/manua...ments.html

This is also the reason why the FreightLift sample scene ropes have two control points near the platform: the one at the very end of the rope has its collision filters set to ignore collisions against the platform.

Let me know whether this helps,

Kind regards
Reply
#7
(06-02-2023, 09:31 PM)josemendez Wrote: Based on your description of the issue (ropes starting at a weird angle near the attachment, jittering and “swimming” when picking the rigidbodies up) my guess would be you’ve attached the rope inside a collider that’s also set to collide against the rope. As a result the rope tries to be simulateously inside and outside the collider, since this is physically impossible to achieve it gives rise to unnatural behavior.

This situation - along with the solution- is described in the manual’s page for attachments (see “attachments inside colliders”)
http://obi.virtualmethodstudio.com/manua...ments.html

This is also the reason why the FreightLift sample scene ropes have two control points near the platform: the one at the very end of the rope has its collision filters set to ignore collisions against the platform.

Let me know whether this helps,

Kind regards
Something is glitching.
I Set the ends to nothing and the next node to collide with everything but then when I tried to edit the rope again it showed the path on one cable but the nodes on the other and even though the positive-negative cable was selected editing it moved the negative cable. I deleted the rope but making a new rope gives me an InvalidOperationsException error when I say edit path.
Reply
#8
(06-02-2023, 10:55 PM)Giantbean Wrote: Something is glitching.
I Set the ends to nothing and the next node to collide with everything but then when I tried to edit the rope again it showed the path on one cable but the nodes on the other and even though the positive-negative cable was selected editing it moved the negative cable. I deleted the rope but making a new rope gives me an InvalidOperationsException error when I say edit path.

Hi,

Could you share the full error message so that I may help you? First time I hear of such behavior, sounds rather strange. The code that renders the nodes and the path of the rope both use the currently selected GameObject, so at least in theory it should be impossible for it to render another one.

kind regards,
Reply