Hi Koderz,
Were you able to improve the runtime PhysX baking performance after all? This is the only thing dragging my procedural generation engine’s performance down at the moment and I would love to hear from anyone who managed to improve this process… At least knowing about the possibility of improving it would be helpful before jumping into the adventure of going through a good portion of the UE4 and PhysX code base.
Some numbers about my case: Without enabling collision on any of the generated meshes, I am able to generate a terrain of 768x768x128 blocks in volume (together with a good number of procedural trees and quite a bit of foliage that has a lot of vertices to avoid translucency) and put all of those onto screen under 1,750M CPU cycles (0.5 sec) on my I5-4590. Moreover, although the collision is not enabled, I still generate the required FTriMeshCollisionData array during this process. When I enable collision, the amount of CPU cycles required to put the exact same geometry onto screen goes up to 13,000M. That is 7 times the processing power required to generate and render the same geometry.
These numbers don’t add up in my mind. From noise generation to merging the generated voxels in order to create leaner meshes out of them and to putting those meshes onto screen, the amount of work done in a procedural generation pipeline is absolutely massive. The fact that baking PhsyX data out of ready-provided collision mesh data takes 6 times longer just doesn’t make sense. Clearly the baking process wasn’t designed to be done in real time, hence wasn’t optimized accordingly. That’s why I am hoping that there should be a good amount of room for improvement and eager to hear what others have done about it…