Loading scene from state files breaks the simulation when there's a motor involved

[AimHere]

Attempting to continue a simulation using a state file when there's a motor driving rigid objects in the scene (specifically TargetPositionMotorSliderJoint in my case, but I'm guessing it's an issue for other joints) breaks the simulation, due to the driven rigid object being momentarily teleported to the start position of the object for a single tick. If fluid particles have now moved into the space where the rigid object was at time=0, then it manifests itself as some horrendous explosion of particles.

As far as I can tell, it's because when loading from a state file, the time in the SPH::TimeManager class is set correctly, but not for the PBD::TimeManager one. Having two singletons with the same name seems counterproductive, somehow!

I needed to work around it myself, so to fix it, I inserted a function called immediately after the line loading the time from the state file in SPH::SimulatorBase::loadState ("TimeManager::getCurrent()->loadState(binReader);"), which firstly, synced PBD::TimeManager::setTime with the value that SPH::TimeManager has just been loaded with, and secondly, because the joint targets are still based on the initial 0 time, run the portion of the PBD::TimeStepController::step function that updates the targets, which is almost everything after the 'update motor joint targets' comment. I'm not familiar enough with the code base to know if this is the Right Thing to do, but hopefully whoever does know this stuff can figure that out.

[janbender]

Hm, I think I never tested this case. I will take a look at that.

[janbender]

I just tested this using the Motor scene and for me it works. The time and the step size are set in each simulation step in the PBDWrapper.cpp lines 76-77. So PBD should never have the wrong time or step size. Did you use the latest version?

[AimHere]

I did pull straight from the repo before testing and making the bug report.

I'm not seeing the issue with your motorscene either so it's surely dependent on the joint type (the bundled MotorScene has a velocity-based target sequence; having the velocity momentarily be set to the wrong value won't catastrophically break everything the way that rubberbanding the position will - so the bug is likely still there, but nobody will notice). The bug manifests itself with the variant of the motorscene I used to work out how the TargetPositionMotorSliderJoint constraints worked. I've attached the file (and you may have to alter the filename back to .json to get past the Github uploader filter). Set the state file export to 2fps and try loading from the saved state at t=0.5

The issue isn't quite with the time setting, but with the joint targets being initialized to the values at t=0. The current joint target values are only updated after the rigid body positions/velocites are updated based on the target values, so rigid objects are forever targeting themselves at joint positions based on the time of the previous tick (or the initialized value if it's the first tick, hence the bug).

MotorSceneTest.json.txt

[janbender]

Thanks for the info. I will test it and try to find a solution.