Off-topic: what would you recommend for C++?

Discuss any questions about BEPUphysics or problems encountered.
Post Reply
diabloqfdb
Posts: 38
Joined: Mon Aug 20, 2012 10:33 am

Off-topic: what would you recommend for C++?

Post by diabloqfdb »

Hi Norbo,

This may be a bit of a weird question, but what would you recommend for someone switching from C# to C++. BEPU is really great and I have used it now for quite some time with success, but all the code base is being converted to C++, C# won't be used in the future, so unfortunately BEPU is out too... :(

You are obviously very knowledgeable in the domain of physics engines and your input is as valued as always. One of the greatest parts of BEPU has always been the swift reply on the forum. I doubt I will have the same experience with other engines.

Maybe you tried some engines before and know of one that you would use comfortably if being put in that situation. There are so many options. PhysX and Bullet seem to be quite good though, so I am investigating them.

Thanks you for reading!
Norbo
Site Admin
Posts: 4929
Joined: Tue Jul 04, 2006 4:45 am

Re: Off-topic: what would you recommend for C++?

Post by Norbo »

I haven't personally used other engines to the point that I could make strong recommendations, but it would be hard to go wrong with the most common three (PhysX, Havok, Bullet). I don't know enough about others (like Newton) to say much about them.

Here's a brain dump:
-Bullet is open source and has been proven in a whole bunch of games. It might not have as many credited AAA titles as PhysX and Havok, but you can be pretty confident that it can do the job.
-There seem to be some issues with the character controller provided by Bullet. I've never used it so I can't be sure, but I occasionally see posts complaining about it. I haven't heard anything similar about PhysX or Havok, but I haven't spent much time browsing places where those questions would get asked. Worst case scenario, you could probably port the relevant bits of the BEPUphysics character if you needed to :P
-Bullet 3.x is a rewrite. It's very GPU focused. I don't know if it has a traditional CPU path (Bullet 2.X might be it), though I believe it can run on CPUs by virtue of being built with OpenCL. If you want to use the GPU for simulation, Bullet 3.x or PhysX are probably what you want. (Havok has demonstrated some GPU capabilities, but I assume Intel does not feel strongly motivated to put lots of resources behind that... could be wrong!)
-If you need absolute CPU performance, you may want to evaluate Havok. I'm not aware of any benchmarks off the top of my head, but there are some pretty strong incentives in place for Havok to dominate their niche.
-PhysX sometimes gets a bad wrap for being 'unoptimized' on the CPU. These days it's quite speedy.
-The Bullet forums are pretty active. Many questions will already have been asked, or at least might receive relatively quick answers. (The more obscure and more complicated the issue, the less likely a community response is, unless it's the type of thing that would interest Erwin or another contributor.) I don't know much about the state of free support in PhysX and Havok, though I bet they'd both happily provide high quality support for a few dollars :)
-Both Unity and Unreal use PhysX. If there is the possibility of swapping to one of those engines, having familiarity with, and code designed for, PhysX might ease the transition. (Notably, Unity 4.X uses an older version of PhysX; Unity 5 uses 3.3.)
-Bullet documentation is not amazing, but there are fairly direct analogs to a lot of the constructs in BEPUphysics (or at least, there were in Bullet 2.X when I last looked). This should also hold true for the CPU side of PhysX and Havok, since the fundamental approaches are pretty darn similar. I don't know much about the documentation quality of PhysX or Havok.
-If you just need rigid bodies and constraints, all the engines should have you covered. However, if you need auxiliary features like cloth, deformables, fluid, and interaction between them all, I would definitely do tests in each engine to see how they work in practice (both from a development perspective as well as a runtime perspective). I wouldn't be surprised if there were issues.

Personally, if I were looking for an engine, I would focus on the CPU performance and behavior characteristics. My project(s) don't tend to require large amounts of cloth, deformables, or fluid, and every rigid body tends to interact a lot with gameplay logic. I also tend to use every bit of GPU horsepower available for graphics. GPU simulators don't map well to this kind of usage. (That's part of the reason why I haven't released any GPU stuff for BEPUphysics, even though I've built some of it.)

I would also have to pay attention to multithreaded scaling. This isn't incredibly important for clients, but if you want to run many thousands of objects in heavy interaction on a server, being able to use the full capacity of high-end Xeons helps a lot. I suspect this is where a lot of engines will have trouble. Until very recently (PS4 and Xbox One), there just wasn't a huge reason to scale above a few cores. Even then, physics simulations often still get run on a single thread; the games are using those resources for other stuff. Not even BEPUphysics does as well as I'd like here, which is going to have to change over the next couple of years.

Hope this rambling helps!
Post Reply