30-03-2023, 07:39 AM
(This post was last modified: 30-03-2023, 07:43 AM by rohit_dhak.)
(29-03-2023, 01:23 PM)josemendez Wrote: Setting the stretching scale to 0.1 will tell the rope to try and keep their length at 10% of their rest length. Should be left to 1 (100%) unless you're going for some special effect.
If your ropes are sagging, either:
- Use more substeps (10-15 is completely fine). This will ensure ropes reach their target rest length during simulation. The manual contains an in-depth explanation of how iterations and substeps affect simulation quality: http://obi.virtualmethodstudio.com/manua...gence.html
- Decrease rope resolution. Less constraints will result in faster convergence and less spurious compliance (that is, less elastic ropes). A resolution of 0.6 means particles will slightly overlap each other, which means there's a lot of particles. Since your ropes are very long, that will require a rather high amount of substeps for the simulation to be accurate.
You can combine both: use lower-resolution ropes with more substeps.
Note you can use surface collisions in case your rope resolution needs to be low and gaps appear in-between particles.
kind regards,
So I am noticing one thing which I would like to get clarified.
I have following changes:
Sample code for 1 cable:
Code:
public void set_c2()
{
if (c2_len > c2_control_ip + cable_threshold)
{
cursor_2.ChangeLength(c2_len - speed * time_dt/10);
}
else if(c2_len < c2_control_ip - cable_threshold)
{
cursor_2.ChangeLength(c2_len + speed * time_dt/10);
}
else
{
Debug.Log("Current Length and Control input are the same for Cable 2");
}
}
cable_threshold = 0.01f
time_dt (Timestep) = 0.01
Cable Obi Fixed updater substeps = 30
The thing that I am not understanding is,
I am giving the condition to get c2_len which is rope2.CalculateLength() set to the control input c2_control_ip
However when I logged the restLength, c2_len and c2_control_ip I saw that the c2_len is trying to set to restLength instead of c2_control_ip
Am I misunderstanding something?