Please use PhysX 3 :)

Nvidia recently released PhysX 3, that support CPU multithreading. If UE4 will include it, it will use more than one core. :slight_smile: and physics simulations will run faster :slight_smile:

Hi Sabino,

PhysX 3.3.1 is already integrated into the engine. There are typically plans to upgrade the PhysX to the latest versions when they are released. However, this requires testing and making sure things integrate properly though.

Keep any eye on the release notes for each engine version as the update would be listed there.

Thank you!

Tim

Thank you :slight_smile:
What about multi-threading?

Multithreading is already there

So itā€™s confirmed then that Physx v3 and up is optimized for multi-threading? Does that mean there is no ā€œharmā€ to users with non-Nvidia systems? (Donā€™t get me wrong, I have an Nvidia card and love their products, I just donā€™t want to be the one making a game that runs like dirt on intel/amd systems)

PhysX Destruction are is handled on the CPU and is card agnostic. The performance will depend on the users system. The best solution with targeting multiple systems is to build and test often.

The goal with anything in the engine is that it will run with both AMD and NV cards. Epic does not want to split the community and appear biased towards a single GPU. Just as a recap because it has been mentioned a number of times, and even in some previous posts you have made about destruction meshes, there is no benefit with the out-of-the-box integrationā€™s with those who have a NV card over an AMD Card.

Gotcha, thanks for that.

Correct. PhysX is multi-threaded on the CPU regardless of the GPU hardware used.

It is poorly multi-threaded. I never get it to use more than 1ā€¦1 1/2 cores. Even when the frame rate turns into a slide show because of physics going on.

Even with the latest version? Honestly, I trust Epic and the Unreal Engine team so I feel like it canā€™t be performing terribly, but if it was, then I feel like Epic would be aware of the problem and would probably switch to another solution in the future. Tim Hobson has a really good point, Epic wouldnā€™t make a decision based on personal bias. My point is, are you sure it was the latest version of PhysX that was running on 1 core?

Either way, Iā€™d love to see some kind of complete analysis with benchmarks or even thread usage visuals (something like this but for the latest version of PhysX, as that one is from back in 2009), mainly to see how much better it performs now than it used to, and also to see how it performs against other physics solutions like Havok and Bullet if possible. Unfortunately Iā€™m not really experienced enough to really be able to do this analysis myself. Iā€™m not really a technical guy (Iā€™m a 3D Artist, and still somewhat of a beginner at that) and Iā€™ve only just begun seriously learning UE4. It would be really cool if Epic would be able to do the analysis officially, but Iā€™m sure they have a lot on their plate so I doubt theyā€™ll have the time for something like that.

Hey Tgirgis,

If youā€™re comparing the state of PhysX now to what it was in UE3/UDk there probably will be some differences. UE3 had been in development for a very long time. UE4 has only been publicly available for just shy of a year. There are in-fact some improvements that can be made.

I really donā€™t think a test comparing Havok, Bullet, and PhysX is possible since PhysX is so ingrained with UE4. Thereā€™s not a way Iā€™m aware of that you can just drop in a new physics engine and have it work without doing some heavy lifting in code.

Iā€™ll investigate the multi-threaded issues and see if there is a way to see whatā€™s going on and share that information when I have time. With some other things going on right now it may be a little bit, but Iā€™ll get back to you all as soon as I can. :slight_smile:

If we had the PhysX source code at our disposal, we would be able to make our own threads by using C++ :frowning:

Thanks, that was extremely helpful, itā€™s too bad they didnā€™t test Havok in that benchmark =(

Darn, I figured that would be the case. Itā€™s not really extremely necessary to test it (at least not directly in the engine) as long as PhysX is performing well on multiple cores. If you find at some point down the road that it is not performing as intended and a direct problem cannot be identified easily, then I would say some kind of benchmark would be worth the major effort.

Please, Epic developers, let me know if you are going to improve PhysX performance.
PS. If I bought UE4 and had access to the source code, would I be able to create my own threads or implement Bullet/ODE? Thank you :slight_smile:

You can, but not easily. There was some discussion about it on this thread -

Certain parts of PhysX are threaded quite well, but to get the most parallelism you need to use the ā€˜async sceneā€™ and accept that those objects will be a ā€˜frame behindā€™. Also note that lots of physics objects can often mean lots of dynamic components, which can have their own cost rendering-wise. Itā€™s worth using the stats system to work out what is going on. We are constantly talking with NVIDIA about improving performance, and there should be more improvements coming down the pipe in future versions of PhysX (3.4 and beyond).

Awesome, any more performance that can be squeezed out of it would be hugely beneficial to me. Iā€™m overall experiencing pretty good Physics Performance on my end though already, a level of 200 objects adding forces, doing line traces and smashing into each other behaves pretty nicely on my machine. (i7-3820K + GTX 980).

Itā€™s worth adding for those posting in the thread, that PhysX performance is massively improved when you do package a game, I guess because all the additional editor overhead is nout.

Is there a big list of tips anywhere for how to keep a physics-based game running as optimized as possible, like fixing the timestep or whatever? Iā€™m planning on networking the system I have right now, which just talks to the Physics engine and tells it what velocity and angular velocity a certain object should have. Might get expensive for 200+ objects. Is it more efficient to just SetWorldPosition on objects and handle collision responses yourself? I had that system in place, but it just wasnā€™t all that smooth.

My project deals about a game with a lot of physic effectsā€¦ And the mono-core execution is a problem. UE4 is such a powerful engine :frowning:
Can I use PhysX SDK and make a multithreaded game?

And, please answer sincerely, how many cores are used?

Yes! PhysX is multi-threaded and double buffered so you can interact with it from multiple threads at the same time. A big part of physics effects relies on gameplay code where you need to query information like, what objects are near me, what will I collide with if I move this way. These types of queries are all thread safe and can be done in parallel as PhysX allows for multiple readers at the same time.