Yeah, that’d make more sense, fair enough …
Rejigged the logic a bit, more robust now:
Added a function that determines the direction of the mouse movement in relation to the door’s facing direction:
the inner workings
- the door mesh is attached to the hinge around which it pivots, the mesh is 100uus and offset by half:
This step can be omitted and simplified in the Modeling Mode
→ xForm
→ Edit Pivot
(or have a properly exported mesh instead, ofc) where you can set the pivot yourself:
- the Door
Static Mesh Component
simulates physics; but only when it’s awake and Chaos puts it to sleep quickly:
This can be further optimised by detecting the Wake
/ Sleep
events and disabling the motor in the Physics Constraint component.
- the Physics Constraint component:
It creates a physical dependency between 2 other components.
- even though we simulate physics, the Physics Constraint component
Locked
the mesh in place:
- it can still swing in one axis, limited and offset - play with those 2 values to see how they affect rotations - they’re relative to the aDoor actor (and yes, you can absolutely make revolving supermarket doors with this):
- the door has a motor that will try to reach
Swing
velocity of 0 (stop it) with theStrength 4.0
factor.
You get quite a bit of flexibility here. This would produce a door that is easy to operate (Strength 2.0
) but also closes after you (Strength 3.0
):
Again, massage the values as needed. Some of those settings can (should!) be parametrised and made Instance Editable
so you can configure each door separately:
Updated project link:
a Youtube or a social
No YT and antisocial , and I feel spread thinly already, mostly hang around the forums.
it works, there are no janky physics
Seems fine at the moment. Knowing life and UE physics, chances are you’ll eventually run into an undesired behaviour. Most kinks can be ironed out, though.