Sweep Test hangs with PlatformTarget x86

[DavidRobb]

I need to interface my Windows console app project to a 32bit dll so have platform target set as x86 in the project file.

This works fine with a Debug build but sometimes hangs in a Release build. I've isolated the problem to the tree sweep test when bodies overlap, which either loops forever, runs out of memory or causes an invalid access exception.

So is
x86
a valid thing to add to the csproj with this library and how / why is it different from selecting x86 from the drop down run configuration box (Which appears to work fine for the library but does not allow me to access my 32 bit dll)

Any ideas how to fix this?

The following simple test causes the problem

        public struct SceneSweepResult : ISweepHitHandler
        {
            public Vector3 HitLocation;
            public Vector3 HitNormal;
            public float T;

            [MethodImpl(MethodImplOptions.AggressiveInlining)]
            public bool AllowTest(CollidableReference collidable)
            {
                return true;
            }

            [MethodImpl(MethodImplOptions.AggressiveInlining)]
            public bool AllowTest(CollidableReference collidable, int child)
            {
                return true;
            }

            [MethodImpl(MethodImplOptions.AggressiveInlining)]
            public void OnHit(ref float maximumT, float t, Vector3 hitLocation, Vector3 hitNormal, CollidableReference collidable)
            {
                //Changing the maximum T value prevents the traversal from visiting any leaf nodes more distant than that later in the traversal.
                //It is effectively an optimization that you can use if you only care about the time of first impact.
                if (t < maximumT)
                    maximumT = t;
                if (t < T)
                {
                    T = t;
                    HitLocation = hitLocation;
                    HitNormal = hitNormal;
                }
            }

            [MethodImpl(MethodImplOptions.AggressiveInlining)]
            public void OnHitAtZeroT(ref float maximumT, CollidableReference collidable)
            {
                maximumT = 0;
                T = 0;
                HitLocation = Vector3.Zero;
                HitNormal = Vector3.Zero;
            }
        }

// Then in a Demo class

        public override void Initialize(ContentArchive content, Camera camera)
        {
            camera.Position = new Vector3(0, 10, 40);
            camera.Yaw = 0;
            camera.Pitch = 0;
            Simulation = Simulation.Create(BufferPool, new DemoNarrowPhaseCallbacks(new SpringSettings(30, 1)), new DemoPoseIntegratorCallbacks(new Vector3(0, -10, 0)), new SolveDescription(8, 1));

            var basePos = Vector3.Zero;
            var baseBox = new Box(1, 1, 1);
            var baseInertia = baseBox.ComputeInertia(1000);
            var baseMeshIndex = Simulation.Shapes.Add(baseBox);

            var baseHandle = Simulation.Bodies.Add(BodyDescription.CreateDynamic(basePos, baseInertia, baseMeshIndex, 0.01f));
            var baseHandle2 = Simulation.Bodies.Add(BodyDescription.CreateDynamic(basePos, baseInertia, baseMeshIndex, 0.01f));

            var boundingBox = new Box(10f, 10f, 10f);
            SceneSweepResult hitHandler = default;
            hitHandler.T = float.MaxValue;
            Simulation.Sweep(boundingBox, basePos, new BodyVelocity { Linear = Vector3.Zero }, 1, BufferPool, ref hitHandler);

            Console.WriteLine("Done Sweep!!!!!!!!!");

[RossNordby]

This is an odd one!

So is
x86
a valid thing to add to the csproj with this library and how / why is it different from selecting x86 from the drop down run configuration box (Which appears to work fine for the library but does not allow me to access my 32 bit dll)

It's different because I never paid attention to the x86 config, apparently. Despite using the x86 build configuration, the demos run as AnyCPU which for all my systems becomes x64. That should be fixed in 7820d9c.

It should work with x86, although I don't know what the detailed status of the x86 JIT is. There may be performance differences, because clearly there are some differences.

Given the debug/release split and my testing so far, this issue looks like it may be JIT related. I'm saying that in hopes that the cosmos will now swoop in and retrocausally make it a trivial bug in my code.

[RossNordby]

Alas, it appears that explicitly noting that you're invoking cosmic retrocausal bug patching disables that feature:
dotnet/runtime#95043
(though maybe, now that I've submitted an issue, it'll kick in?)

I added a temporary workaround to 2.5-beta16. Hurts performance on x86, though. May want to check the relative performance on a representative simulation to see if it's worth updating the dependency if that's possible.

[DavidRobb]

Wow. That's a super fast response. Thank you. The temporary workaround works for me and doesn't cause any noticeable slow down for my use case. (a crane simulator using huge legacy triangle meshes, rope modelling, collision detection and ray casting). Thanks for making this truly awesome physics library available to all. :-)