BEPUphysics

Hello,

We have some problems with performance in our application.
Here is the thing:

Our application simulates movement of rail vehicles (train-like).

We have decided to use Prismatic-Joints, to imitate vehicle-on-the-rail behaviour.

Our vehicles are bendable. Per vehicle we use 4 prismatic joints (to mount it to rail) and about 10 box or sphere entities (there are needed).
Than we use 6 SwiveHinge joints to assemble vehicle in the way we need.

Thanks to bepu mlutithreading (parallel looper), we can easily work with 200 vehicles, that means 800 prismatic joints, 1200
swive hinge joints and about 2000 entities. We need some other boxes inside application, so final entitiy count can be near 3000.

We care about switching collision modes as needed. Some entities are permanently set to NoBroadPhase.

We care abour maximum interation limit in solver. We tried even values 3,2,1. With no big effect.
(with value 1 joints started to fail - of course ).

We tried to set joints and entites that are not needed in the moment (about 80% elements) as not active (IsActive flag), wih no effect.

I am starting to affraid, that bottleneck is simply amount of elements, joints, enetites, in the simulation.
Does not matter how simple or inactive we make them, its just too many of them.

Is there some other space for optimization please? Or is my afraid right?

Maybe we forgot or dont know something, if there is some way please help.


Thanks a lot!!


PS: Bepu is a brilliant peace of work. Norbo rocks!

Is there some other space for optimization please? Or is my afraid right?

There may be hope!

We care abour maximum interation limit in solver. We tried even values 3,2,1. With no big effect.

How significant was the effect?

If the difference between an iteration limit of 10 and 1 was a tiny part (<10%-ish) of the simulation time, it suggests that the solver is a small fraction of the simulation time and that the bottleneck is elsewhere.

The position updater almost certainly isn't the bottleneck, either. That leaves the broad phase and narrow phase as the most likely culprits. If there's very complex geometry that all objects get tested against but rarely actually generate contacts with, the NarrowPhase is suspect. If there's tons and tons of static or inactive objects, the BroadPhase could start eating up time (at least until I get around to rewriting it).

It may be worth compiling BEPUphysics with the PROFILE compilation symbol. That would provide easy access to space stage timings. The most important ones are the BroadPhase, NarrowPhase, Solver, and PositionUpdater. The relative times of these stages should reveal hints about what to optimize. If these do not comprise the vast majority of each time step's cost, checking the remaining stage timings might reveal some shenangians.

We tried to set joints and entites that are not needed in the moment (about 80% elements) as not active (IsActive flag), wih no effect.

Something sounds fishy here- only 20% of the ~3000 objects were still active, and it was no different than when all objects were active? Or, were those objects already inactive, so re-deactivating them had no effect? Either way, something might not add up:

~600 active objects and another few hundred active joints should be fairly easy to simulate on a PC. On my 3770K@4.5ghz, based on simulations of similar overall complexity, I'd guess that would take somewhere around 3-4 milliseconds. How long does each time step take to simulate on your computer, and on what CPU? If your CPU is 1/4 or 1/5 as fast, taking 12-20 milliseconds might be expected.

PS: Bepu is a brilliant peace of work. Norbo rocks!

Why thank you