Performance in Unity BEPU vs PhysX

Discuss any questions about BEPUphysics or problems encountered.
Post Reply
WVlad
Posts: 3
Joined: Sun Nov 10, 2013 9:43 am

Performance in Unity BEPU vs PhysX

Post by WVlad »

I compared bepu performance with Unity3D legacy physics. Physics step and solver iterations count was equal but bepu showed very bad performance.

Here is bepu web demo: https://dl.dropboxusercontent.com/u/571 ... puweb.html
And the same legacy demo: https://dl.dropboxusercontent.com/u/571 ... puweb.html

Unity project:
bepu_performance.zip
(1.94 MiB) Downloaded 389 times
To switch bepu/legacy use Player Settings -> Conditional compilation -> type "LEGACY_PHYSICS" without quotes for PhysX or anything another like "LEGACY_PHYSICS1" for bepu.

Why does BEPU's performance is so bad?
Norbo
Site Admin
Posts: 4929
Joined: Tue Jul 04, 2006 4:45 am

Re: Performance in Unity BEPU vs PhysX

Post by Norbo »

A few notes, some of which have been pulled from the e-mail for other readers:
1) The most noticeable difference is probably caused by using internal time stepping in BEPUphysics. Space.Update(dt) takes as many steps as necessary to simulate the accumulated time passed in as a parameter. So, if a single time step takes longer to compute than the Space.TimeStepSettings.TimeStepDuration, it will end up entering a vicious cycle limited only by the Space.TimeStepSettings.MaximumTimeStepsPerFrame. The result is lowered framerate until the simulation can be simulated in full real time again.

Calling Space.Update() without a parameter simulates a single time step of length Space.TimeStepSettings.TimeStepDuration. Calling that instead would avoid the vicious loop, making actual performance a little easier to see.

The PhysX implementation may also be using the equivalent of internal time stepping. If it is, it would be a good idea to turn it off for clarity even if it has no effect in this particular simulation.

2) I'm not familiar with Unity web player/mono performance characteristics; they might affect performance. Ruling them out would be helpful. Try setting up a simulation in the raw .NET BEPUphysicsDemos and checking the performance. That will also make it easier for me to analyze if a notable performance issue remains.

3) It's hard to pick fully equivalent settings between different physics engines. While there is a good bit of common ground between implementations, tuning for performance can require deeper investigation.

For example, the same number of iterations may not produce the same level of quality, or it may be simply different in behavior. BEPUphysics's solver does some tricks which trade per-iteration performance for a bigger boost in quality, so sometimes fewer iterations are required.

Another example could be in threading. BEPUphysics has a fairly strong focus on high performance multithreaded simulation, sometimes at the cost of single threaded performance. Given the use cases of the CPU version of PhysX, it may focus more on single threaded performance over multithreaded scaling. This particular demo appears to be strictly singlethreaded.

(I am mostly ignorant of the inner workings of PhysX- these particular examples might be totally invalid.)

4) I haven't done direct benchmark comparisons, but I would assume that PhysX would be faster in a totally fair comparison. PhysX has been worked on for many years by many skilled people and has the advantage of full native code. I know of a set of theoretical optimizations which could reasonably double BEPUphysics performance (or better) without involving offline optimizing compilers or SIMD, so I assume the smartyguys working on PhysX have covered similar ground. If I heard that PhysX was something like twice as fast, I would not be super surprised.
WVlad
Posts: 3
Joined: Sun Nov 10, 2013 9:43 am

Re: Performance in Unity BEPU vs PhysX

Post by WVlad »

1) In the demo TimeStep of BEPU = TimeStep of PhysX
2) Yes, it might. But the point is that I need to run it via unity mono runtime. I don't need it for MS .NET.
3) Ok, so how to tune BEPU in this particular case? What settings do I need to use?
4) I think it would make a sense to do that direct comparsion. It really matters)
Norbo
Site Admin
Posts: 4929
Joined: Tue Jul 04, 2006 4:45 am

Re: Performance in Unity BEPU vs PhysX

Post by Norbo »

1) In the demo TimeStep of BEPU = TimeStep of PhysX
To clarify, the time step duration is not the same thing as internal time stepping; internal time stepping is making BEPUphysics take multiple steps each time Update is called, causing extremely low framerate. Internal time stepping or its equivalent should be off in both engines for comparison.
2) Yes, it might. But the point is that I need to run it via unity mono runtime. I don't need it for MS .NET.
The idea behind testing it in the normal environment is to pin down possible causes. If the simulation runs substantially faster in the normal environment, it strongly implies something about the unity environment is interfering. That narrows down the search space a lot. It may turn out that there's not much that can be done about environment interference, but then at least you would have an answer.
3) Ok, so how to tune BEPU in this particular case? What settings do I need to use?
Check out the BEPUphysicsDemos ConfigurationHelper. There's a couple of methods like "ApplySemiSpeedySettings" and "ApplySuperSpeedySettings". Play with the values those methods apply to see how fast you can make it while maintaining acceptable quality. You may find that 1 iteration works fine. You can also probably do similar things in PhysX.

Fiddling with the time step duration is another general tuning option.

More specific tuning depends on the simulation. A bunch of boxes in a big pile has fewer axes of tuning than a game setting where there's typically a bunch of different shapes and a complex environment.

Like I said, creating a totally 'fair' comparison is going to be quite tricky- there is no particular configuration which is guaranteed to be equal in relative performance/quality between the two engines.
4) I think it would make a sense to do that direct comparsion. It really matters)
For my purposes, it doesn't really matter. :)

I'm not really focusing on competing with other physics engines. Knowing the exact relative performance between libraries would rarely change my decisions regarding what changes are needed in BEPUphysics. Instead, my decisions are defined mostly by what I need in my own projects. That will often result in optimizations and improvements.

I'm glad to see that people use and like the engine- it's free and open source, after all. But it does surprise me a little bit when people use it in place of a native solution like PhysX in Unity :P
WVlad
Posts: 3
Joined: Sun Nov 10, 2013 9:43 am

Re: Performance in Unity BEPU vs PhysX

Post by WVlad »

it does surprise me a little bit when people use it in place of a native solution like PhysX in Unity
It seems to be handy to use the samy physics engine for both the server and the client side of my game.
playpassmedia
Posts: 1
Joined: Wed Jan 28, 2015 2:07 am

Re: Performance in Unity BEPU vs PhysX

Post by playpassmedia »

The .zip seems to have gone bad...any chance of posting it again? Or does anyone know of the most recommended Unity implementation of BEPU?

I found these...but figured the one from the BEPU forums would be worth a look but it is gone now hence this post. Thanks for any responses!
https://bepuphysics.codeplex.com/SourceControl/network
viewtopic.php?t=2032
Norbo
Site Admin
Posts: 4929
Joined: Tue Jul 04, 2006 4:45 am

Re: Performance in Unity BEPU vs PhysX

Post by Norbo »

Or does anyone know of the most recommended Unity implementation of BEPU?
I haven't kept track of unity implementations, but I'm guessing they are probably not up to date with the latest development version.

I would recommend starting with the the latest development version; it should be usable in unity with very few or no source changes. I suspect any changes that are required could be found in the commit history the older unity fork linked in that forum post. It looks like there was one change required due to an oddity with web player compatibility.
Post Reply