I already have thickness assigned to my terrain. Can you make it really large? I have it around 2 meters right now.
Yup, it would work fine so long as there's nothing beneath the terrain which would care about the fact that it's now inside a terrain
I would like to implement quick-save/quick-load. It would be great if quick load would be 100% deterministic, as in loading a scene with objects in collision resulted from player interaction before scene would yield the same result, no matter how many time you load it. My idea was to save the movement related properties of all active entities and just the transforms for inactive ones. At load, inactive ones are placed inactive into their position and active ones get their movement properties restored. Would something like this work? Could you tell me what properties I should store for entities so I can restore them?
Position, orientation, linear velocity, angular velocity, and activity would be the primary properties. You could indeed omit velocity for inactive objects. Those five would likely produce a roughly reproducible simulation in many cases.
Unfortunately, perfect determinism is going to be extremely difficult to maintain. In fact, for the sake of development time, it might be a good idea to treat it as impossible:
-Objects must be added to the space in the same order.
-Cached data must be identical. To proceed deterministically from a previous simulation, it must be replicated down to the level of individual contacts, warm-starting impulse magnitudes, and contact manifold state.
-The pair generation order must be the same, which means the broad phase was constructed in exactly the same way.
-The solving order must be the same, which means the solver's permutation index must be controlled (easy enough).
-Multithreading must be disabled for a variety of performance sensitive stages (the biggest one being the solver).
And even if all of that is dealt with, it still isn't guaranteed to be deterministic across different platforms due to subtle differences in floating point behavior that can't all be controlled from C#. The JIT has some freedom. It might happen to work on two platforms, but relying on it to always be true would be extremely dangerous.
Other than 'don't bother', the most common solutions for this problem are usually replacing floating point with fixed point math, or implementing floating point operations in software. For a real time physics engine, this could be problematic.
Should I switch to the dev branch? How is 1.3 coming along? What are the new features?
Yes, it would definitely be a good idea to update (though the 'dev' branch was deleted, and the main branch is the updated version of the former dependency free branch.). You can see the changes in v1.3.0 on the
XNA fork (they're in the
main dependency free fork too, but codeplex seems to hide the pre-merge changesets.)
The largest single new feature would be the inverse kinematics system. It's the same system that I ported to C++ for use with the
BEPUik blender plugin. I haven't given it a formal spot in the API yet, but I'll probably put it into its own library soon.
The most noticeable behavioral change is likely the new collision softness support via CollisionResponseSettings.Softness. It's an extremely small change in terms of code, but stacks and other difficult collision-related configurations should behave a lot better now. It's not quite done, though; allowed penetration margins cause odd behavior in some cases. The old behavior is equivalent to setting CollisionResponseSettings.Softness = 0.
Other than that, there have been quite a few bug fixes, behavior improvements, and organizational changes. Most significantly for the purposes of porting is the existence of a separate BEPUutilities project which BEPUphysics depends upon. It contains all the general helpers that are used by BEPUphysics but are not specific to physics.
Another thing that I'll need to do is speed up level loading, which means speeding up StaticGroup creation. I think this can't be done without modifying BEPU, so I'll start using a self compiled version ...
I will consider the level made up out off several static "islands", each a static group. I want o go over this group and store all data, structure and relations raw on disk. Then at load, I want to restore it without doing any calculations, thus loading taking as much time as needed to read from disk plus allocating memory and filling in some data. Would something like this work? I need to speed up loading by at least an order of magnitude.
Persisting the internal hierarchies would indeed require some custom modifications. Careful management of persistence could probably get you the needed boost.
However, the hierarchies are in for a significant overhaul in the
not-hugely-distant future. In addition to some new mutable hierarchies and better memory access behavior/performance in general, part of that overhaul will probably introduce high performance hierarchies designed for offline building. They will require some amount of built-in persistence management since they'd take too long to build at runtime. It may not be wise to wait on me to get that done, but keep it in mind.
And finally, I'm going to need a way of removing a single static mesh from an already filled in StaticGroup. This is related to terrain deformation. A lot of the clutter on top of the terrain is static, so you can collide with it but no other interactions are available. But when you modify the height of the terrain, you need to adjust the position of some of the clutter objects. My idea was to remove them from the group and add them separately to the space. Further down the line, once in a while a piece of code could run during a low CPU use period that would pick up close isolated statics and recombine them, so during execution eventually one single static group would probably be split into multiple smaller groups. On a level load, these subgroups would be merged back again to avoid broad phase pollution.
StaticGroups were built with mutability in mind for the future, but they do not yet support it. That would come along with the previously mentioned hierarchy overhauls. For now, removes and topology changes in general would require a hierarchy reconstruction.
It sounds like you might not need to modify topology, though. If an object is merely moving a little bit, you could scoot it while keeping it in the StaticGroup, and then call the StaticGroupShape.CollidableTree.Refit function. It's extremely fast compared to a full reconstruction. After lots of significant displacements, it might be a good idea to eventually call a Reconstruct just to improve performance, but that will be rare.