I should clarify somewhat for context.
Our use case is that we have a volumetric representation of our world’s solid geometry which is modified at runtime by the user’s actions, and therefore will not be known in advance in any form. This representation is stored as a three dimensional grid of signed distance values from an implicitly defined isosurface, and events which occur at runtime mutate this grid of values.
For visualization purposes, we triangulate our grid using a standard implementation of Marching Cubes, similar to what is described on http://.net/geometry/polygonise/, and this resulting triangle mesh is loaded into UnrealEngine vertex and index buffers and rendered normally using a scene proxy object.
However, our use case requires us to also have in-game objects and characters interacting with and navigating over this geometry. Given the underlying representation, an aggregation of simple primitives will not work, but a PxTriangleMesh should have no problems, and could be built from the same triangulation we are using for visualization, or perhaps a lower resolution triangulation. It looks like the only way to instantiate a PxTriangleMesh object in the PhysX SDK is to bake a binary representation using an instance of the PxCooking class, and then load the PxTriangleMesh from that binary representation. This cooking functionality seems to be packaged into a separate set of libraries (See ThirdParty/PhysX/PhysX-3.3/lib/Win**/VS2013/PhysXCooking**.lib) from the core PhysX runtime.
If PhysXCooking**.lib is linked into the UE4 runtime, then it should be possible to build a mesh at runtime. If it isn’t, I was hoping that it might be possible to manually link against PhysXCooking**.lib separately, strictly for the ultimate purpose of being able to generate new PxTriangleMesh objects at runtime. I don’t actually need to serialize or deserialize any UE4 assets or objects once these meshes are created, I just need to be able to create them and use them for collision detection at runtime.