Buffered states suggestion and questions about physics LOD

[ecosky]

Hi Norbo,

I've been using buffered states with my game and I really like the feature. I would like to suggest perhaps the Entity could have a GetCurrentWorldTransform(out Matrix) that would automatically call down into either the Entity.WorldTransform or the BufferedStates.States.WorldTransform depending on the setting in Space.BufferedStates.Enabled. This would make it so people wouldn't have to refactor code to explicitly use (or not use) the buffered states while trying out different things; I had several bugs related to (my) oversights on the use of Entity.WorldTransform when buffering is enabled which made me think that perhaps this would be well suited for a wrapper at the Entity level. On a related note, it would be nice if the various properties that refer to Matrix objects had out/ref method versions to reduce the copy overhead (I haven't tested this myself but it seems to be the consensus that returning matrices and even Vector3's by out parameter is faster than a property and is worth doing when possible).

The other question bordering on a suggestion is related to the way the Space is updated. It would be really helpful if there was some way to continue to do an update at a fairly high rate but have some objects in the distance or otherwise less visible or less important save some cycles by reducing the amount of work done for them at a cost of simulation accuracy. Basically, LOD the physics in some way. I was wondering if there would perhaps be some way to make an Entity provide a heuristic 0..1 that would cause the object to be updated less often or less accurately (between some minimum and full rate as controlled by this heuristic). This is approaching the edge of my familiarity with Bepu's internals but I'm thinking one part of this sort of thing could be along the lines of a PositionUpdater that does the full update for LOD-1 every frame, and less often for <LOD-1 instead doing interpolation to set the positions. Perhaps the collision islands could track the highest LOD value for the associated entities and make all the entities use that value to control update rates while they are part of the island. I'd guess this sort of thing could coexist with the existing buffering system (if it is possible in the first place). I don't really expect this kind of feature to happen but I am curious about your thoughts on if anything like this might be viable or if you have any suggestions for reducing the overhead for objects that perhaps don't need the same level of simulation accuracy as others.

The only other thing I can think of that might work without deep changes in Bepu is to maintain one scene per discrete LOD and migrate objects between them as necessary. Special objects like terrain would need to be set up so they can have an Entity per scene that refers to common data as much as possible to minimize the memory costs and general overhead.

Thanks again for the use of this excellent physics engine,

[Norbo]

I've been using buffered states with my game and I really like the feature. I would like to suggest perhaps the Entity could have a GetCurrentWorldTransform(out Matrix) that would automatically call down into either the Entity.WorldTransform or the BufferedStates.States.WorldTransform depending on the setting in Space.BufferedStates.Enabled.

The Entity.BufferedStates.(Interpolated)States getter properties check whether or not the buffer is active before attempting to return a buffered state. If the buffer isn't available, it returns the entity's value directly.

On a related note, it would be nice if the various properties that refer to Matrix objects had out/ref method versions to reduce the copy overhead (I haven't tested this myself but it seems to be the consensus that returning matrices and even Vector3's by out parameter is faster than a property and is worth doing when possible).

In general, yes, passing nontrivial value types using out parameters is faster than copying them through a return. However, the cost of copies through the externally visible API is vanishingly small compared to the work going on behind the scenes every time step (which is optimized to the point of ugliness and uses reference passing or inlining almost exclusively).

When I was considering this originally, the decision process looked like this:
1) Getters via out parameters would be faster.
2) Getters solely via out parameters complicate some usage patterns, so maintaining traditional return-based properties would be valuable for most users.
3) Having an out-getter and a return-getter for every state would make the API messy.
4) Pre-optimizing for accessor performance would save tiny fractions of frametime for most users, so the API mess (as trivial as it may be) is probably more important.
5) Users who stand to benefit substantially from out-getters probably have a extreme corner-case usage pattern which would be better suited to modifying the Entity class to make the states directly accessible without any accessor. The same users are probably advanced enough that a small source change would not be an issue.

I don't really expect this kind of feature to happen but I am curious about your thoughts on if anything like this might be viable or if you have any suggestions for reducing the overhead for objects that perhaps don't need the same level of simulation accuracy as others.

While conditionally limiting the update rate of individual entities can't fit without some fairly huge changes, I'd separate the problem into three main categories:

1) full quality simulated entities,
2) low quality but still interactive entities, and
3) noninteractive entities.

#3 is the easiest option- if the objects don't need to interact with the main simulation, putting them into a separate simulation (as you mention) with its own set of objects and update rate works well.

#3 also maps extremely well to GPU-side physics or simpler approximations of the physics. Considering everything to be little more than particles that may or may not interact with the ground can let you have immense 'simulations' of debris. So long as there's a few 'real' pieces of debris mixed in for the high quality simulation to handle, it tends to come out looking pretty impressive.

#2 is trickier. There's no great way to handle this automatically. The user can dirty their hands by yanking an object from noninteractive simulation up to full quality simulation when objects get near (like what you mentioned). Such direct interventions are probably the most effective options. Without update rate LOD, there's not a lot else to tune- aggressively reducing the quality of contact constraints created by certain objects would save a little time, but this would have to be done manually through event handlers and may not be worth the effort.

In the future, the direction I will likely take is to improve the performance of inactive objects. It's already very cheap, but if there's 40,000 inactive objects and only 300 active objects, its cost will still be large in relative terms. It seems probable that many simulations that benefit from LOD would also benefit significantly from cheaper sleep management (apart from those which are trying to simulate huge piles of imprecise debris). That combined with general performance optimizations (trying to eliminate the last couple of sequential operations) and other 'big world' related improvements will probably be necessary for some of the stuff we're building internally.

[ecosky]

Thanks Norbo. I appreciate seeing the reasoning behind your decisions.
Cheers