Constraint drives not switching on in 4.13

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?

SwingDrive.bEnablePositionDrive &= InEnableSwingDrive;
TwistDrive.bEnablePositionDrive &= InEnableSwingDrive;

Why the &=? It is preventing me from enabling a drive in code.

Edit: Okay it looks to me like this code is rife with errors. The code above is using InEnableSwingDrive for the twist drive too and ignoring the twist argument. More than that, these booleans don’t even appear to be getting used when configuring the PhysX objects!

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.

Hey kamrann,

Thanks for the report.

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:

Hey, thanks for posting this. As you mentioned this was part of a huge refactor and it was simply a copy and paste error :frowning:

The &= should also be an = as you say. I’ve fixed it for 4.14 - please let me know if there’s any other issues with constraints.


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.