Upgrade to PhysX 5

[Jake-Shadle]

pxbind

This ports pxbind from C++ using libclang -> rust using clang's AST JSON output. The port includes adding snapshot testing of the output of pxbind + structgen both to validate the port as well as (hopefully) making any changes easier in the future. This initial port is mostly a 1 to 1 conversion with 3 notable exceptions.

• enums improved
• flags improved
• core types improved
• methods
• structs/classes
• templates - Unfortunately more templates have crept into the public API of PhysX, to a degree where it feels like we need to support at least some of them.

enums

In the current pxbind, enums are outputted like this.

pub mod PxShapeFlag{
pub type Enum = u32;
pub const eSIMULATION_SHAPE: Enum = 1u64 as u32;
pub const eSCENE_QUERY_SHAPE: Enum = 2u64 as u32;
pub const eTRIGGER_SHAPE: Enum = 4u64 as u32;
pub const eVISUALIZATION: Enum = 8u64 as u32;
}

This makes them cumbersome to use from Rust. In the new pxbind they are outputted like this.

/// Flags which affect the behavior of PxShapes.
#[derive(Copy, Clone)]
#[repr(u32)]
pub enum PxShapeFlag {
    /// The shape will partake in collision in the physical simulation.
    ///
    /// It is illegal to raise the eSIMULATION_SHAPE and eTRIGGER_SHAPE flags.
    /// In the event that one of these flags is already raised the sdk will reject any
    /// attempt to raise the other.  To raise the eSIMULATION_SHAPE first ensure that
    /// eTRIGGER_SHAPE is already lowered.
    ///
    /// This flag has no effect if simulation is disabled for the corresponding actor (see [`PxActorFlag::eDISABLE_SIMULATION`]).
    eSIMULATION_SHAPE = 1,
    /// The shape will partake in scene queries (ray casts, overlap tests, sweeps, ...).
    eSCENE_QUERY_SHAPE = 2,
    /// The shape is a trigger which can send reports whenever other shapes enter/leave its volume.
    ///
    /// Triangle meshes and heightfields can not be triggers. Shape creation will fail in these cases.
    ///
    /// Shapes marked as triggers do not collide with other objects. If an object should act both
    /// as a trigger shape and a collision shape then create a rigid body with two shapes, one being a
    /// trigger shape and the other a collision shape. 	It is illegal to raise the eTRIGGER_SHAPE and
    /// eSIMULATION_SHAPE flags on a single PxShape instance.  In the event that one of these flags is already
    /// raised the sdk will reject any attempt to raise the other.  To raise the eTRIGGER_SHAPE flag first
    /// ensure that eSIMULATION_SHAPE flag is already lowered.
    ///
    /// Trigger shapes will no longer send notification events for interactions with other trigger shapes.
    ///
    /// Shapes marked as triggers are allowed to participate in scene queries, provided the eSCENE_QUERY_SHAPE flag is set.
    ///
    /// This flag has no effect if simulation is disabled for the corresponding actor (see [`PxActorFlag::eDISABLE_SIMULATION`]).
    eTRIGGER_SHAPE = 4,
    /// Enable debug renderer for this shape
    eVISUALIZATION = 8,
}

This allows regular usage from Rust, and the Rust enum can be used on the FFI boundary since it is guaranteed to be the same size as the underlying integer type in C++.

flags

Many enums in PhysX also have a bitflags version using PxFlags<_enum_type_, _integer_type_>.

typedef PxFlags<PxShapeFlag::Enum,PxU8> PxShapeFlags;

In the current pxbind, they are outputted like this.

#[derive(Clone, Copy)]
#[repr(C)]
pub struct PxShapeFlags{
    pub mBits: u8,
}

In the new pxbind they are outputted like this.

bitflags::bitflags! {
    /// Flags for [`PxShapeFlag`]
    #[derive(Copy, Clone, Default)]
    #[repr(transparent)]
    pub struct PxShapeFlags: u8 {
        const eSIMULATION_SHAPE = 1 << 0;
        const eSCENE_QUERY_SHAPE = 1 << 1;
        const eTRIGGER_SHAPE = 1 << 2;
        const eVISUALIZATION = 1 << 3;
    }
}

Like the regular enums, this allows easy and typesafe usage from Rust that can be passed transparently through FFI. Since the enum that is paired with the bitflags are always emitted before the flags we elide the comments on the individual constants.

Core Types

PxVec3, PxVec4, PxVec3Padded, PxQuat, PxMat33, PxMat44, and PxTransform now use the equivalent glam types on FFI since they all already match the layout of the PhysX pod types. This means we also skip generating FFI bindings for the various math functions related to those types as that can just be done in pure Rust without needing to go back and forth. This was also done because PhysX now makes all of these types into templates, which makes everything more annoying, especially since the f64 versions are...never actually used. But future proof!

I've changed the core types back to non-templated versions, there is no reason to keep that baggage. EmbarkStudios/PhysX-5@87ee3fa

physx-sys

Since physx-sys just exposes the raw bindings generated by pxbind/structgen the breaking changes are mostly the same as those in the underlying sdk, eg things like constructors in core types like PxTransform now take defaults, removing 1 or more constructor bindings which can cause direct use to be incorrect due to how constructors are named with a number suffix to disambiguate the FFI functions. There were also types that were completely removed such as PxArticulation and so forth.

physx

In addition to the aforementioned changes in physx-sys, probably the biggest change in physx is that we no longer have to manually recreate bit flags and do the conversion to/from the FFI type since most bitfields (there are a few exceptions) are now automatically generated by pxbind.

Resolves: #175

[Jake-Shadle]

Ok, all platforms that we care about are about are compiling and working again, I'll merge this tomorrow. It's time to go and drink heavily.

[tgolsson]

@Jake-Shadle Sounds good. I'll leave you to override the merge so you don't get raced by the bot.

[iddm]

Nice work, guys!