collision/physics not working

[3dken]

I'm working with bullet.js JavaScript port and doing some optimization experiments. For this, I cloned the code path between processAllCollisionPairs() (the near phase collision detection top loop in JS) and getClosestPoints() . This intermediate code path sets up each collision pair with an input and resultOut object. Input is created new for each pair (closestPointInput type), and resultOut is obtained from the dispatcher.nearCallback.contactPointResult which is ManifoldResult type.

I did some unraveling of the objects and their members in the several methods that are called in the original code path: handleCollision, processCollision, processOverlap. I think these are all correctly extracted but when I run the two code paths, the original path behaves normally but my new path has physics and collision turned off for non-static bodies. The exception is that the latest processed object (e.g. add a projectile to the sim) appears to have physics and collisions working (mostly OK, there may be some issues). This leads me to suspect that resultOut, the ManifoldResult object which is owned by the dispatcher, needs to stay assigned to each pair as the pair goes through the rest of the sim loop (physics, update position etc).

I'm going to start this test now, assigning/retaining the input and resultOut objects to each collision pair specifically. I had tried it briefly a few days ago and it didn't help, but I only kept the input/resultOut references in the overlappingPairCache list and didn't assign resultOut to the dispatcher (where it lives in the original code path). I think maybe the dispatcher is being used in the rest of the sim loop and since it retains the resultOut for the final pair that was processed, then the rest of the overlappingPairCache list is not correctly handled.

Any thoughts, advice or insight on this issue?

thanks

[3dken]

I did track down incorrect usage of object types and fixed the contactPointResult/resultOut and manifoldPtr member objects. Gravity and physics is not yet identical to the original code path, but I'm looking at that now.

[trollington]

I had odd "almost exact behavior" issues when I tried grouping the pre-broadphase steps (apply gravity, save kinematics state, integrate velocities, predict motion, etc) together into one big loop -- turns out all of them seem to work pretty well together in any order, except for updating AABBs, which has to be done separately before running the broadphase...

Note that I haven't jumped too deep into the specifics of the broad/narrowphase algorithms and don't use the JS version, so I don't know if this is helpful...