PostSolveJacobians results are ignored by Havok physics?

Hey,

I’m modifying MotionVelocities array in PostSolveJacobians, however it seems to have no effect with Havok physics. Is it intended?

Can you share what your intentions are with it?

There are limitations, mostly the fact that Havok works with its own internal data and modifying MotionVelocities during Havok step can’t affect the behavior. You can only modify physics runtime data (MotionData and MotionVelocity) after the step and before export.

Also, at the moment PostSolveJacobians when using Havok actually means post integrate, since we weren’t able to expose the exact point before integration.

But please share what the use case is so that I can try to help out with more advice.

Hey petarmHavok, I’m prototyping a game about destroying castles brick by brick. Tall constructs made of tens of thousands of stacked blocks. PhysX version was quite uninspiring, so been tinkering with DOTS for a while. There are obviously two issues - stacking stability and amount of collisions. Latter can be dealt with in multiple ways, of which I want to mention composites which then shatter into smaller parts, and my own heuristic for sleeping - thus I was really happy to discover the PostSolveJacobians way and it really helps to cut off unnecessary simulations.

Stacking stability, however, is painful. Both Havok and Unity Physics produce massive jelly with true physical simulation of a brick wall, even with the recently added ContactSolverStabilization. It was the case for PhysX as well, so I did a custom activation event propagation system and turned on physics only for the bricks which are moving or about to move; it also involved faking on the render side - mesh didn’t move visually until the related collider moved far enough. So for stacks I detect the collisions and then for colliding bricks I’m getting their velocities to determine whether the brick should move at all (clamping) and whether applied momentum is large enough to shatter it.

PostSolveJacobians really helps in many ways. But Havok is better for my case for solving some other artifacts of Unity Physics.

1 Like

So my advice (when using Havok) is to wait for StepPhysicsWorld to end, and then (before ExportPhysicsWorld), do your sleeping logic. It won’t stop the bodies from moving in this frame, but it will help stability for sure.

Also, for Unity Physics, try increasing the aggressiveness of the contact solver stabilization. It works on some default values that can be increased, just don’t go too crazy. :slight_smile:

But would it mean that I can extract MotionVelocities after the StepPhysicsWorld and then manually move back some/all entities, effectively replicating the Unity Physics behavior of clipping MotionVelocities in PostSolveJacobians?

Thanks for the heads up! It doesn’t solve the stack stability issue, but it provides some nice results with the residue jitter.

Yes, unfortunately that’s the only way to replicate similar behavior to what you can achieve with Unity Physics.

You can also try a few more things, like increasing number of solver iterations, linear and angular damping, increasing inertia of bodies, friction, decreasing gravity…

For completeness, here is the ClipMotionAuthoring behavior from the demo in the Unite Now video.

using Unity.Burst;
using Unity.Collections;
using Unity.Entities;
using Unity.Jobs;
using Unity.Mathematics;
using Unity.Physics;
using Unity.Physics.Systems;
using UnityEngine;

public class ClipMotionAuthoring : MonoBehaviour
{
    //public bool EnableSystem = false;
    public float LinearThreshold = 1E-4f;
    public float AngularThreshold = 1E-6f;
    public bool MassInvariant = false;

    ClipMotionAuthoring() { }

    private void OnEnable() { OnValidate(); }

    void OnValidate()
    {
        var world = BasePhysicsDemo.DefaultWorld;
        if (world != null)
        {
            var system = BasePhysicsDemo.DefaultWorld.GetOrCreateSystem<ClipMotionSystem>();
            if (system != null)
            {
                system.Enabled = this.enabled;
                system.LinearThreshold = LinearThreshold;
                system.AngularThreshold = AngularThreshold;
                system.MassInvariant = MassInvariant;
            }
        }
    }
}


[AlwaysUpdateSystem]
[UpdateBefore(typeof(StepPhysicsWorld))]
public class ClipMotionSystem : JobComponentSystem
{
    public float LinearThreshold = 1E-4f;
    public float AngularThreshold = 1E-6f;
    public bool MassInvariant = false;

    StepPhysicsWorld m_stepPhysicsWorld;

    protected override void OnCreate()
    {
        Enabled = false;
        m_stepPhysicsWorld = World.GetOrCreateSystem<StepPhysicsWorld>();
    }

    [BurstCompile]
    struct ClipMotionDataJob : IJobParallelFor
    {
        public float linearThreshold;
        public float angularThreshold;
        public bool massInvariant;
        public float3 gravityDir;

        public NativeSlice<MotionVelocity> MotionVelocities;

        public void Execute(int index)
        {
            var pv = MotionVelocities[index];
          
            float3 linearEnergy = pv.LinearVelocity * pv.LinearVelocity;
            float3 angularEnergy = pv.AngularVelocity* pv.AngularVelocity;
            if(!massInvariant)
            {
                linearEnergy *= math.rcp(pv.InverseMass);
                angularEnergy *= math.rcp(pv.InverseInertia);
            }

            if (math.lengthsq(linearEnergy) < linearThreshold)
            {
                var gravityComponent = math.dot(pv.LinearVelocity, gravityDir) * gravityDir;
                pv.LinearVelocity = gravityComponent;
                if (math.lengthsq(angularEnergy) < angularThreshold)
                {
                    pv.AngularVelocity = float3.zero;
                }
            }

            MotionVelocities[index] = pv;
        }
    }

    protected override JobHandle OnUpdate(JobHandle inputDeps)
    {
        if (Enabled)
        {
            SimulationCallbacks.Callback clipMotionsCallback = (ref ISimulation simulation, ref PhysicsWorld world, JobHandle inDeps) =>
            {
                return new ClipMotionDataJob
                {
                    gravityDir = math.normalizesafe(GetSingleton<PhysicsStep>().Gravity),
                    linearThreshold = LinearThreshold,
                    angularThreshold = AngularThreshold,
                    massInvariant = MassInvariant,
                    MotionVelocities = world.MotionVelocities,
                }.Schedule(world.NumDynamicBodies, 64, inDeps);
            };
            m_stepPhysicsWorld.EnqueueCallback(SimulationCallbacks.Phase.PostSolveJacobians, clipMotionsCallback, inputDeps);
        }

        return inputDeps;
    }
}
2 Likes

Thank you @petarmHavok , @steveeHavok , got it working perfectly.

creamyspottedcockatiel

Here’s the profiler screen while using UnityPhysics:

Key bottleneck is the BodyPairsJob. Basically I’m doing my own heuristics in order to improve framerate, and part of that involves dealing with colliding entities. The only ways I found to achieve it are either IBodyPairsJob or ICollisionEventsJob.

Problems with the IBodyPairsJob:

  • single threaded
  • does not expose the nativearray of colliding bodypairs
  • it blocks all parallel threads, being called from a SimulationCallbacks.Callback. Though I’m not modifying pairs and just do my own non-blocking stuff.

Problems with the ICollisionEventsJob:

  • single threaded
  • does not expose the nativearray of colliding shapes
  • considerably slow; it takes ~1ms to spin up a 1000 of Execute methods. With mere 30.000 colliders it means 30ms spent only on ICollisionEventsJob.Execute calls internally, saying goodbye to 60fps.

There are also some quite sparse areas on the profiler screen, mainly after the Jacobians job. Not sure whether I can do anything to speed it up.

I am really missing the CollisionsExclude tag, in line with the PhysicsExclude. Right now I’m just removing PhysicsCollider component, but restoring collider would be painful if required.

Also I think I’ve seen somewhere that there were plans to expose a slider “accuracy vs performance”; it would be great for a game such as mine. I don’t need pixel-perfect collisions but I’d like to reduce the time spent in that dreaded narrow phase - up to 50% on Android.

I tinkered a bit with HavokPhysics as well. The good thing is that it’s even faster on PC, but being the black box, it’s quite hard to do custom heuristics. Key issue was that entities put to sleep stopped generating any events and I found no way to detect such sleeping entities. Also it seems that multithreading is not that good with Havok, which is an issue on Android - when the cores are relatively slow and utilizing all threads is a must.

2 Likes

Just to add on the CollisionsExclude tag - you actually have this, just set CollisionResponse.None on the material of the collider and that’s it. :slight_smile:

Tried that - no performance gain, unfortunately. Only hard removal of PhysicsCollider provided a boost.

Yeah, I understand that hard removal is the most efficient since it effectively removes the body from the world, but this should also give you a solid boost since collision detection and solving are skipped. I’m surprised you got no boost there…

I didn’t explore it thoroughly as removing the collider entirely worked like a charm, but AFAIR in order to set CollisionResponse.None per entity I also had to mark all colliders as unique, probably that’s what negated the effect. So per-entity CollisionsExclude tag still sounds like the best option.

1 Like