PhysX Read/Write capability in libPlasma

[Aloys]

If we switched to a different physics engine what kind of impact would it have on the existing gameplay and puzzles? (if any).

[Robert The Rebuilder]

It would be good to find some decent replacement for PhysX; it's not clear whether there's been any benefit to using it versus ODE or Havok. Has anyone with a graphics card that supports the PhysX acceleration noticed any performance boost in MOUL (especially with many people/objects running around)?

I decided to follow NxOgre's example, and I'm releasing the PhysicsIO library under LGPL v3. According to the GPL compatibility matrix, a GPL v3 project (such as libPlasma) may use a LGPL v3 library.

[Note that it is actually better to maintain your GPL status, since that allows you to include LGPL libraries as well as GPL libs. If you did change to LGPL, then you could not include GPL libs without reverting the project back to GPL. Go figure.]

Anyway, if you're interested, here are the links:

• PhysicsIO.zip: the LGPL library. Unzip this into the 3rdPartyLibs directory. Note the new name, since PhysX is a registered trademark of NVIDIA Corporation.
• PhysXPlasma2.zip: the modified ResManager, GeneralPhysical and Plasma.vcproj files. Replace the ones in your libPlasma checkout with these.
• PhysX System Software: Install this before running your libPlasma executables.

Let me know if you experience any problems. I've found that I needed to completely clean and build (as opposed to selecting Rebuild) the Plasma solution for it to work correctly. As long as I can remember, Visual Studio's Rebuild option has been problematic.

[Chacal]

Having a storage sytem for phyisical objects that isn't physics-implementation dependent would be a great help in keeping different versions compatible.

Agreed. If we keep using 3rd-party physics engines (proprietary or not), an abstraction layer is desirable.


Sorry if I sound like Ric Romero, but this is the only part of the thread I understand!

[D'Lanor]

Having a storage sytem for phyisical objects that isn't physics-implementation dependent would be a great help in keeping different versions compatible.

Agreed. If we keep using 3rd-party physics engines (proprietary or not), an abstraction layer is desirable.

Also agreed. Actually for a long time I was under the impression that Cyan had already set it up like that, since they switched physics engines more often than underwear.

Sorry if I sound like Ric Romero, but this is the only part of the thread I understand!

You are not alone. My knowledge is limited to age building and vault mangling. About game engines I know nothing.

[Deledrius]

Having a storage sytem for phyisical objects that isn't physics-implementation dependent would be a great help in keeping different versions compatible.

Agreed. If we keep using 3rd-party physics engines (proprietary or not), an abstraction layer is desirable.

Indeed. Since none of the available options are stand-out as being optimal for these purposes, an abstraction layer making it easier to switch to something else would be best.

[ddb174]

Here's another vote for that cross-engine abstract physics class.

[Paradox]

Having a storage sytem for phyisical objects that isn't physics-implementation dependent would be a great help in keeping different versions compatible.

Agreed. If we keep using 3rd-party physics engines (proprietary or not), an abstraction layer is desirable.

Also agreed. Actually for a long time I was under the impression that Cyan had already set it up like that, since they switched physics engines more often than underwear.

Havok and ODE didn't have any "engine-specific" data, rather they just stored the vertices and faces of the collider mesh (using two different formats of course, but it was still a bit of abstraction).
PhysX allows you to "cook" collider meshes so that calculations are faster, so Cyan opted to store this cooked data in the plPXPhysical class. In theory, we might be able to get by without it, but it could have adverse effects on the engine speeds.

libPlasma tries to abstract all three engines with a plGenericPhysical object, which allows conversion between the three engines (aside from the PhysX cooked data).

[Deledrius]

So that's pretty much taken care of already. The question here is just how to utilize/create the cooked data as long as we're still using Plasma+PhysX, I guess.

[Trylon]

I'd say stick with the wrapper until we can hack in a custom implementation.

[ddb174]

Unfortunately, the meshes are the easy part. There's lots of flags, and the physics engines do have their own peculiarities, which make it very difficult to do. It is a little like converting between Uru and SL: possible, but ugly and buggy and imperfect ;)