Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
dynamic particle attachment issue
#1
I have attached a rigidbody with two ropes at both ends using dynamic particle attachment (compliance = 0) and apply a force on that body just like in the video in the given link
https://1drv.ms/v/s!AkGarI_8WKB3hmT3xPkH...j?e=Ksh2X6
when I released the force the rope doesn't look attached and a little slower than the body just like in the video
kindly answer...
Reply
#2
(18-04-2020, 03:50 PM)noman fareed Wrote: I have attached a rigidbody with two ropes at both ends using dynamic particle attachment (compliance = 0) and apply a force on that body just like in the video in the given link
https://1drv.ms/v/s!AkGarI_8WKB3hmT3xPkH...j?e=Ksh2X6
when I released the force the rope doesn't look attached and a little slower than the body just like in the video
kindly answer...

Hi,

This depends on a lot of things, so few questions:

- Do you have solver interpolation enabled?
- Does your rigidbody have interpolation enabled?
- What kind of updater component are you using?
- Are you using more than 1 substep?
Reply
#3
(19-04-2020, 09:59 AM)josemendez Wrote: Hi,

This depends on a lot of things, so few questions:

- Do you have solver interpolation enabled?
- Does your rigidbody have interpolation enabled?
- What kind of updater component are you using?
- Are you using more than 1 substep?

Thanks for your response.
Now I have used Fixed Late Updater and problem is not visible when subset is one but when it is three this issue becomes clearly visible. Is it a constraint or any way to solve this issue for greater subsets?
Reply
#4
(19-04-2020, 10:50 AM)noman fareed Wrote: Thanks for your response.
Now I have used Fixed Late Updater and problem is not visible when subset is one but when it is three this issue becomes clearly visible. Is it a constraint or any way to solve this issue for greater subsets?

Have you checked “substep unity physics”? This is necessary if using substepping in conjunction with unity’s own physics.
Reply
#5
(19-04-2020, 11:01 AM)josemendez Wrote: Have you checked “substep unity physics”? This is necessary if using substepping in conjunction with unity’s own physics.

In Obi Fixed Updater checked or unchecked “substep unity physics” didn't make any difference. While in Obi Late Fixed Updater there is no checkbox for “substep unity physics”.
Reply
#6
(19-04-2020, 09:52 PM)noman fareed Wrote: In Obi Fixed Updater checked or unchecked “substep unity physics” didn't make any difference. While in Obi Late Fixed Updater there is no checkbox for “substep unity physics”.

Hi noman,

Can you share the code you're using to apply forces to the rigidbody? I'm unable to reproduce this issue.
Reply
#7
(20-04-2020, 09:58 AM)josemendez Wrote: Hi noman,

Can you share the code you're using to apply forces to the rigidbody? I'm unable to reproduce this issue.

the code is very simple and one liner

void FixedUpdate()
    {
        GetComponent<Rigidbody>().AddForce(Vector3.down * Thrust);
    }
Reply
#8
The issue is that you're applying the force in FixedUpdate, and using ObiFixedUpdater too.

The order in which Unity calls events (Update(), FixedUpdate(),etc) for multiple scripts is arbitrary. This means that the ObiFixedUpdater might be called before your script's FixedUpdate(), so you apply the force after the rope simulation is done. This introduces a 1-frame delay, causing the rope to always work with out of date physics data. See:
https://docs.unity3d.com/Manual/ExecutionOrder.html

Using ObiLateFixedUpdater fixes the issue as you discovered, because it ensures the rope simulation is done after you've applied the force (hence the "Late"). However, since it cannot substep Unity physics (as they have already happened right before it had a chance to update the solver), both engines work with different timestep lengths and get out fo sync, causing a new issue if the amount of substeps > 1.

So the solution is to ensure your force is applied before rope simulation takes place. You could write your own Updater component that performs simulation exactly when you need, but there's an easier way:  simply subscribe to the solver's OnBeginStep event, which is always called right before the solver advances a timestep. This way you can keep using ObiFixedUpdater and substepping:

Code:
using System.Collections;
using System.Collections.Generic;
using UnityEngine;
using Obi;

public class FixedUpdateForce : MonoBehaviour
{
   public float Thrust;
   public ObiSolver solver;

   private void OnEnable()
   {
       if (solver != null)
           solver.OnBeginStep += Solver_OnBeginStep;
   }

   private void OnDisable()
   {
       if (solver != null)
           solver.OnBeginStep -= Solver_OnBeginStep;
   }

   private void Solver_OnBeginStep(ObiSolver solver, float stepTime)
   {
        GetComponent<Rigidbody>().AddForce(Vector3.down * Thrust);
   }
}
Reply
#9
(21-04-2020, 08:21 AM)josemendez Wrote: The issue is that you're applying the force in FixedUpdate, and using ObiFixedUpdater too.

The order in which Unity calls events (Update(), FixedUpdate(),etc) for multiple scripts is arbitrary. This means that the ObiFixedUpdater might be called before your script's FixedUpdate(), so you apply the force after the rope simulation is done. This introduces a 1-frame delay, causing the rope to always work with out of date physics data. See:
https://docs.unity3d.com/Manual/ExecutionOrder.html

Using ObiLateFixedUpdater fixes the issue as you discovered, because it ensures the rope simulation is done after you've applied the force (hence the "Late"). However, since it cannot substep Unity physics (as they have already happened right before it had a chance to update the solver), both engines work with different timestep lengths and get out fo sync, causing a new issue if the amount of substeps > 1.

So the solution is to ensure your force is applied before rope simulation takes place. You could write your own Updater component that performs simulation exactly when you need, but there's an easier way:  simply subscribe to the solver's OnBeginStep event, which is always called right before the solver advances a timestep. This way you can keep using ObiFixedUpdater and substepping:

Code:
using System.Collections;
using System.Collections.Generic;
using UnityEngine;
using Obi;

public class FixedUpdateForce : MonoBehaviour
{
   public float Thrust;
   public ObiSolver solver;

   private void OnEnable()
   {
       if (solver != null)
           solver.OnBeginStep += Solver_OnBeginStep;
   }

   private void OnDisable()
   {
       if (solver != null)
           solver.OnBeginStep -= Solver_OnBeginStep;
   }

   private void Solver_OnBeginStep(ObiSolver solver, float stepTime)
   {
        GetComponent<Rigidbody>().AddForce(Vector3.down * Thrust);
   }
}

Thanks for probing into this problem. Done this but nothing changed.  Confundido
Reply
#10
(21-04-2020, 10:07 PM)noman fareed Wrote: Thanks for probing into this problem. Done this but nothing changed.  Confundido

Hi Noman,

We're unable to reproduce any issues with this code, rigidbodies and rope move in perfect sync. Is it possible for you to share your project with us?
Reply