EDIT:
I made a new discovery. I can consistently make either c++/standard examples stable and the other not by switching between 2 different FPS limits or different Max Substep Delta values. and it doesn’t seem to be a simple case of making sure they are above/below certain thresholds. though higher fps/lower substep will yield better chance of hitting stability. but even when severely over-compensating. there are magic numbers that will always break stability. This is rather worrying, since I can’t ever guarantee what FPS end users will be running at. All I can do is ensure the substep is good at both 30/60 and force them into one of those. but now I’m wondering if these magic values will change depending on different hardware, and whether or not each different Physics object will depend on different magic numbers.
ORIGINAL POST:
Old Title: C++ constraint consistently less stable than prototype
Left: Prototype, Right: C++
https://www.dropbox.com/s/ja15n96w05zqmg0/ConstraintMismatch.mp4
I’ve double, triple, sextuple checked the values. they are identical. I’ve re-compiled, closed/re-opened Unreal. Always C++ is unstable. Protoype is solid.
.h
private:
UPROPERTY(VisibleAnywhere, Category = "Components")
UStaticMeshComponent* Mass = nullptr;
UPROPERTY(VisibleAnywhere, Category = "Components")
UStaticMeshComponent* Wheel = nullptr;
UPROPERTY(VisibleAnywhere, Category = "Components")
UPhysicsConstraintComponent* MassWheelConstraint = nullptr;
.cpp
Mass = CreateDefaultSubobject<UStaticMeshComponent>(FName("Mass"));
SetRootComponent(Mass);
Wheel = CreateDefaultSubobject<UStaticMeshComponent>(FName("Wheel"));
Wheel->SetupAttachment(Mass);
MassWheelConstraint = CreateDefaultSubobject<UPhysicsConstraintComponent>(FName("Mass Wheel Constraint"));
MassWheelConstraint->SetupAttachment(Mass);
They are perfectly aligned:
Spot the difference. Again, Left is Prototype, Right is C++. Top is Mass, Middle is Constraint, Bottom is Wheel.
Click to expand ^^