Hello, could UBodySetup::AddShapesToRigidActor() be exported in a future version, please? It’s not accessible since UBodySetup uses MinimalAPI.
While we’re at it, could FPhysScene::GetPhysXScene(), in PhysicsPublic.h, also be exported? I currently don’t see a way to get a reference to the synchronous PxScene from game code except from actors already present in the scene.
The reason I’m asking is because I’m trying to bring PxArticulation into UE4, and don’t want to mess with the engine’s source code.
FPhysScene is designed to hide which physics engine is being used, which is why we typically don’t return things like PxScene. I agree it would be easier in your case to get access to it, but I’d argue that adding PxArticulation should be done at the engine level.
Are you avoiding modifying engine for maintainability? Or is it because you’d rather not deal with the complexity. If you’re ok with modifying the engine code it’s possible we could take this as a pull request so that you’re not maintaining this on your own.
Hi Ori, it’s mainly for maintainability but also because the amount of work to do it right is too big for me at the moment.
My scenario is very specific, I need an articulation of static meshes. Right now a subclass of UStaticMeshComponent that takes the rigid body created by FBodyInstance in CreatePhysicsState() and converts it to a PxArticulationLink works fine and takes just a few lines of code to do it.
In the engine, PxArticulation would probably make more sense in a Skeletal Mesh, right? If you feel it’s best that these two function remain non-exported, it’s okay, they’d just make my hack a little less hacky.
Our game is built around the idea of controlling a giant humanoid robot in a more realistic way and that means a completely physical skeleton. Up until this point in development I’ve been using PxJoints (about 36 of them) with nice results.
Things start getting bad when we make the robot carry heavy stuff or walk a bit too fast. So, after finding out about PxArticulation and how it uses an iterative process in the joint drives (it seems joint projection is improved as well), I’ve decided to give it a shot and see if it improves things a bit.
I’m currently working on this and should have some results this week. I know I’m pushing the limits here using this many joints and expecting a smooth simulation, but if it helps at least a bit it’s fine by me. Our game is supposed to be funny, so glitchy physics is pretty acceptable.
Oh, and we use static meshes instead of a skeletal one because swapping out parts of the robot is a planned feature.
Makes sense. Did you try turning on sub-stepping as this can help a lot with stability? We may add proper support for this at some point, but would like to know more details about use case.