Snapshot of Space object

[snoozbuster]

Every once in a while, some object in my game will randomly populate a number of fields in its matrices with Infinity, which will cause a crash during space.Update(dt). This happens very sporadically, and being that the problem is very difficult to debug due to its rare and seemingly random occurance, I'd like to be able to take a "snapshot" of the Space object every minute or two, and then save it to a file (or maybe just hold it in RAM) so that I can recover the level with minimal loss if this happens. I know the better solution would be to identify and fix this problem, but being that I have no way of reproducing it or even an inkling of the cause, this is a nigh-impossible task.

Obviously, I'm going to need to edit the Space's source, but can you give me any pointers? I'm at least going to need deep copies of all the collision objects, although managers and whatnot I probably won't need to backup. Actually, would it work to make deep copies of the entities in space.Entities and in the event of this issue, clear the Space and readd the deep copies? In this case, what would be the best way to go about making deep copies of the entities? However, just backing up the entities wouldn't work for things such as StaticMeshes, which manager handles them?

Thanks for the help.

[Norbo]

I'm not sure that I can aid and abet such a heinous hack-fix in good conscience

Despite my misgivings: Copy the state of the world in a shallow manner, taking the smallest amount you can get away with. I would strongly recommend avoiding anything like deep serialization (with object graphs and all the rest). It is likely that you can do this without making a single change to the insides of the engine. You might not end up with the same accumulated impulses in a constraint, but that won't break the simulation. I can't tell you exactly what data you need to save; it depends on what the game needs. I would assume position, orientation, linear velocity, and angular velocity at a minimum. Don't bother storing ephemeral things like activity states and all that; it will just get reconstructed.

But- the crash bug should really, really, really, really, really be fixed directly Given the 'randomness' and corruptive manifestation, it sounds like invalid asynchronous access. You could try compiling BEPUphysics with CHECKMATH and just running the game until it crashes. If the validations don't get hit in a helpful way, you could just throw in a few hundred more validations throughout the project in likely places and restart the testing process.

[snoozbuster]

I could see async problems causing it, but I don't use multithreading anywhere (although I'm considering adding it to my loading screen so I can do nifty graphical things), and my computer is single-cored, so if I'm not mistaken the engine won't automatically use multithreading. Don't you have to specify that multithreading be enabled, anyway? When it occurs, I generally try to identify the object that gets borked, and it *seems* it's always a BoxShape, but I can't be totally sure of that. I'm also thinking (if I remember right) it's an Orientation quaternion that gets broken, which, of course, just makes everything explode. It hasn't happened to me in a few months (like I said, it's very rare), so my memory's a little fuzzy.
If it helps, it's always a Math.Sign() call in... I believe it's a one-line function involved with determining concavity, but I don't remember exactly which. Anyway, it's a Math.Sign() that's given Infinity as a parameter.
The other option (assuming I can't fix it) is to let the user know an exception occurred and attempt to continue the level without the offending object, but if it's not a box that's the issue, the level could quickly become unplayable (or incredibly easy). I'd love to fix it, but it could easily take a few hours of constant running to get it to crash, and I can't just leave it running either; I think it only occurs when boxes and other models with constraints interact in a very specific way (although I'm not sure what that way is), not to mention at any given time there could be 20-30 boxes onscreen and up to 10 contraptions they could be interacting with, and like I said, it's very difficult to identify the root of the problem, since it doesn't crash right when the Infinities show up, but later during Update().
Curiously enough, this used to happen more often, but I haven't encountered it for a while.

[Norbo]

If it helps, it's always a Math.Sign() call in... I believe it's a one-line function involved with determining concavity, but I don't remember exactly which. Anyway, it's a Math.Sign() that's given Infinity as a parameter.

The GetExtremePoint function in the BoxShape, likely called within the bounding box updater, does indeed catch infinities and NaNs after they infect a simulation. The bounding box update is a common catch all for corrupt entity states.

Unfortunately, removing the offending object may not be sufficient. It may merely be a symptom of the cancer infiltrating the simulation.

The ambiguity of that catch-all exception is why CHECKMATH exists. If you compile BEPUphysics with the CHECKMATH compilation symbol defined, it will throw an exception much closer to the source by including validation logic all over the place in common access points and processing stages. You can add more validations scattered any place you feel might be a candidate. Unfortunately, this has a performance impact, so it probably isn't suitable for release code.

so if I'm not mistaken the engine won't automatically use multithreading.

Correct, the engine only uses multithreading if explicitly told to do so by adding threads to the thread manager.

[snoozbuster]

If I get it again, I'll certainly try using CHECKMATH to locate it. Thanks for the help.