Ropes frozen in standalone build

[mr-matt]

Strange issue following on from my last post about a null error on particle attachments that only occurred in standalone builds, but not the editor.

My ropes are frozen in place and the dynamic pin constraint appears to have no affect only in the standalone build.



In this screenshot the ropes ends are supposed to be connected to the pallet with dynamic pin constraints.

My code:

Code:

// m_Ropes is an array of 4 ObiRopes
for (int i = 0; i < m_Ropes.Length; i++)
{
    // Create a new blueprint
    var blueprint = ScriptableObject.CreateInstance<ObiRopeBlueprint>();
    blueprint.path.Clear();
    blueprint.path.AddControlPoint(m_Ropes[i].transform.InverseTransformPoint(m_HelicopterAnchorPoints[i].position), m_HelicopterAnchorPoints[i].up, -m_HelicopterAnchorPoints[i].up, m_HelicopterAnchorPoints[i].up, 0.1f, 0.1f, 1, 1, Color.white, "Start");
    blueprint.path.AddControlPoint(m_Ropes[i].transform.InverseTransformPoint(anchorPoints[i].position), anchorPoints[i].up, -anchorPoints[i].up, anchorPoints[i].up, 0.1f, 0.1f, 1, 1, Color.white, "End");
    blueprint.path.FlushEvents();

    blueprint.GenerateImmediate();

    // Set the same phase as the colliders
    for (int x = 0; x < Mathf.Min(blueprint.phases.Length, m_EndParticleCollisionFilterCount); x++)
    {
        blueprint.phases[x] = m_EndParticlePhase;
    }

    for (int x = blueprint.phases.Length - 1; x > Mathf.Max(blueprint.phases.Length - 1 - m_EndParticleCollisionFilterCount, 0); x--)
    {
        blueprint.phases[x] = m_EndParticlePhase;
    }

    m_Ropes[i].ropeBlueprint = blueprint;
    maxLength = m_Ropes[i].restLength;

    // Get components
    mainAttachments[i] = m_Ropes[i].gameObject.AddComponent<ObiParticleAttachment>();
    palletAttachments[i] = m_Ropes[i].gameObject.AddComponent<ObiParticleAttachment>();

    // Find the particle groups
    var groups = m_Ropes[i].blueprint.groups;

    mainAttachments[i].Awake();
    palletAttachments[i].Awake();

    // Attach sub rope to main rope
    mainAttachments[i].target = m_ObiCollider.transform;
    mainAttachments[i].particleGroup = groups[0];
    mainAttachments[i].attachmentType = ObiParticleAttachment.AttachmentType.Static;

    // Attach the rope to the pallet
    palletAttachments[i].target = m_Pallet;
    palletAttachments[i].particleGroup = groups[groups.Count - 1];
    palletAttachments[i].attachmentType = ObiParticleAttachment.AttachmentType.Dynamic;

    m_Ropes[i].gameObject.SetActive(true);
}

There are no errors or warnings in the output log file.

[josemendez]

What's your target platform?
What solver backend are you using?

There are no errors or warnings in the output log file.

Are you 100% positive? If the ropes are frozen in place, this usually means the physics solver isn't running at all. This can be due to a DllNotFoundException (in case you're using the Oni backend in an unsupported platform) or no Burst support for your target platform (in case you're using Burst).

[mr-matt]

Switching to Oni backend worked, I don't recall ever switching it to Burst. Could this have happened when I updated the package?

EDIT: nevermind it failed again. This is on windows and there are definitely no errors or warnings in the output log.

[josemendez]

Switching to Oni backend worked, I don't recall ever switching it to Burst. Could this have happened when I updated the package?

EDIT: nevermind it failed again. This is on windows and there are definitely no errors or warnings in the output log.

Hi Matt,

I'm unable to get this to happen. Standalone builds work fine for me, Windows, both Oni and Burst, Unity 2019.3.1. Also haven't had any similar reports. At this point I think the most efficient way to get this resolved is for me to take a look at your actual project, would that be possible?

kind regards,

Edit: here's a link to a windows build of the sample crane scene, using Oni. Can you try it?: https://we.tl/t-T6sIxJoToP

[mr-matt]

New discovery, I was using a third party tool to manage my builds: Super Unity Build. I use this to build for multiple distributions and automatically upload the builds all in one go.

When I build normally with the native build menu in Unity the ropes work fine. When I build with Super Unity Build the ropes freeze. I know Super Unity Build modifies the custom defines, are there any defines that Obi uses that could break if the defines weren't present? Anything else that happens during the build process that could cause this issue that you're aware of?

[josemendez]

New discovery, I was using a third party tool to manage my builds: Super Unity Build. I use this to build for multiple distributions and automatically upload the builds all in one go.

When I build normally with the native build menu in Unity the ropes work fine. When I build with Super Unity Build the ropes freeze. I know Super Unity Build modifies the custom defines, are there any defines that Obi uses that could break if the defines weren't present? Anything else that happens during the build process that could cause this issue that you're aware of?

The Oni backend requires the appropriate native lib to be added to the build (depending on the build target), Unity does this automatically as far as the libs are in the correct folder: (Obi/Plugins/<targetplatformfolder>). If the libs are not present, the physics engine won't run, no errors shown as there's no physics engine to raise any error.

The Burst backend uses version defines in the Obi assembly definition file to determine whether there should be support for Burst or not. Also this is automatically managed by Unity. If the appropriate version defines aren't there, it conditionally compiles out all Burst code from the build (and again the physics engine won't run, with no errors/warnings, as it is just not present at all in the build).

As fast as Super Unity Build properly handles native plugins and assembly definition files w/version defines (both are standard, mature Unity features), there should be no problem with either backend. I'd contact the Super Unity Build support team and ask them about this.

[mr-matt]

Issue resolve by adding OBI_ONI_SUPPORTED custom define to Super Unity Build. I think maybe it clears the defines set manually in the Unity settings?

[josemendez]

Issue resolve by adding OBI_ONI_SUPPORTED custom define to Super Unity Build. I think maybe it clears the defines set manually in the Unity settings?

OBI_ONI_SUPPORTED is automatically re-added to the defines list if not present every time the editor is started. So it really should be there.

Code:

foreach(var group in supportedBuildTargetGroups)
{
       var defines = GetDefinesList(group);
       if (!defines.Contains("OBI_ONI_SUPPORTED"))
       {
             defines.Add("OBI_ONI_SUPPORTED");
             PlayerSettings.SetScriptingDefineSymbolsForGroup(group, string.Join(";", defines.ToArray()));
       }
}

In case Super Unity Build clears all defines and replaces them with its own at build time, it could explain this problem. This is quite a risky operation though as it can inadvertently break a lot of stuff, IMHO the appropriate thing to do by a build system would be to append defines to existing ones at build time instead of replacing them, or at least let the user choose between append/replace. Glad you resolved it!