Physics Based Door With Closing Mechanism (5.0)

How should I go about creating a dynamic / physics based interactive door (Physics Constraints?) that also animates a self-closing mechanism relative to the doors open angle?

Questions:

  1. How would you try and implement this? My first thought was Physics Constraint on the door, then a separate mechanism with a 90 frame sequence that I could play relative to the 90deg angle of the physics constraint based door? But I feel like there must be one smart way to keep this fully physics based?

  2. Am I right in thinking that I can’t export the IK chain from 3D Studio Max but instead have to create this functionality specifically within UE (2 bone IK)? The IK chain I have in Max currently works perfectly, would be nice to be able to just import this…

  3. Should the door, door frame and mechanism all be one single mesh? Currently I have them all separate. How would you manage the assets?

In general, just don’t use physics. Its too unreliable. And a PITA…

A slerp or motor on the constraint could just push back the door.
The motor would have to be tuned to where it won’t push back objects. But when there isn’t anything it between it would return in position.

No. A door is solid there’s no need for solid or mechanical objects that won’t bend to waste the resources needed with a skeletal mesh.
Ever.
There’s engine components to do exactly what you need without having to use skeletal meshes.

Using skeletal also generates a slur of Light issues

Separate is best. Up to a point.
You wouldn’t need to separate the door knob, for instance. Or the lock mechanism if you had one.

Anything that moves individually needs to be separate.
Door frame. 2 arms. Door. Possibly locking bolt.

Then you just build out the hierarchy into the BP by parenting the door to the frame, and the 2 arms to the respective frame and door counterparts.
Couple of constraints, and they should automatically react dynamically…

Thank you!

Wanted to share an example of WHY physics are always a bad idea: (video is unusually bright, but decent enough to illustrate the issues at hand).

Doing the same exact thing with a BP driven LookAt node would by nature prevent any and all sorts of glitches and stuttering.

Thank you! That’s extremely helpful.

As I was re-redoing this properly, I figure I’d share some intel for the next sucker, so they wont have to start from Meccano like pieces to realize the math.

First of. Simplify the ever living s*it out of it.
2 sticks.
They meet up “somwhwre”.
One is tied to the door. One is tied to the frame.

Second of. The sticks are of a fixed lenght.

This in fact leads to 3:
Each stick is the radius of a circle.

Which leads to 4:
The “somewhere” up there, is actually the “intersection” of 2 circles.

As a result, you write an overly complicated mathematical blueprint noodle thing, where you take only the X / Y of both origins and the 2 radius into account.
Within it, you play will play around with the Radius,
And the ever old fact that the sum of the area of 2 squares built on the Rec-t-riangle is equal to the area of the square built on the hypotenuse. Ya know whater the engine veraion of a Phytagorean theorem goes.
If this is Greek to you, theres a good reason. Look it up.

AFTER some noodle puke, you then get an X and Y coordinates to combine with a standard Z.

Given this point, you literally “find look at rotation” from the beginning of the stick to the point you found, and apply said rotation to the stick(s).

Takes you about an hour.
Solves instabilityy and most importantly, never stutters or breaks. Unless the door does…

Thank you a lot, very informative!