I’ve just upgraded to 4.13, which involved a lot of changes to code that set up constraints programmatically. It now compiles and everything seems to work, except where I was enabling drives.
Am I misunderstanding how it works, or are these lines incorrect?
Edit2: They are used, but in a very confusing way. The if(bDriveEnabled) block is being run even for drives that are fully disabled, but then setting up those drives with 0 spring/damping.
I can’t tell you why the programmer used &= or why InEnableTwistDrive is ignored in both functions but I have created a issue for it. You can follow it here:
No problem Ori. I’ve had to revert the project to 4.12 so didn’t do any further testing after encountering this issue. However first impressions were that everything else seemed to be working as expected.
Regarding my second edit above, does PhysX itself simply not make a distinction between disabled drives and drives with zero strength? My assumption was that it would be inefficient to have every single joint have a zero strength drive associated with it, but a brief look at the PhysX side suggested that this is indeed how it works.
Oh and while I’m here - UPhysicsConstraintComponent::SetContraintReferenceFrame is documented saying that changes will take effect in InitConstraint if the constraint is not yet active when called. This is what I’d expect would happen, however I’m pretty sure that the frame just gets overwritten at that point by that calculated from the transformations of the bodies with respect to the constraint component. I personally find it more intuitive to configure the reference frames manually in the same way as in PhysX, so it would be helpful if the above method did behave as suggested in the documentation.
