Self-Oscillation in TotK

[gamalot]

I've been playing "Legend of Zelda - Tears of the Kingdoms" recently, and it's been a great game for me, so much fun!

I found an interesting thing yesterday and I made a video of it. I'm not sure if anyone else has discovered it earlier or something like that, I haven't watched too many TotK videos.

I found that when Link stand on the "bridge" stacked by the portable pot, stabilizer, and steering stick, the mechanical system will self-oscillate if the battery died. The strong shaking sometimes threw Link out, and other times Link managed to hold on until the battery power came back and continued his voyage. It's not just the stopping of moving parts such as wheels or fans that can cause this oscillation, actually any device that drains the battery can trigger it, such as the flame emitter in the video. This will not happen if the player presses the "B" button to stop the system, my guess is that Link isn't trying to control the system in this situation.

[T3sl4co1l]

Saw someone the other day making a quite long object, and trying to hold it vertical with a stabilizer; one wasn't enough, but there were clearly some... interesting forces at work along the stack.  I'm not entirely sure that torque and shear are being computed!

There may be some simplifications with parsing a composite (glued) object as a multiple-DoF flexible object, with some eventual force limits (which might not be any particular force so much as displacement of the flex joint itself).  That might actually be a rather helpful simulation, if it means basically applying a fabric model to the structure (which they probably already have in the engine), just with different angles and rigidity for the bones.

I think they generally dialed up the damping factors quite high, which gives behavior that is rather unrealistic if you know what you're looking at, but is quite suitable for easy gameplay.  The forces available from the Ultrahand are tremendous, but it seems you have some difficulty actually slapping or crushing yourself -- despite velocity and crushing being sources of damage.

Clearly, your example shows one perhaps poorly considered counter-example of this.  Perhaps the propagation of the water waves contributes to that -- the interaction of two systems, which might well be separate systems glued together by physics.  That could easily happen, and likely they can't dial up the water damping without making waves look obviously flat.  I don't think I've seen assemblies of similar size/count misbehave on land or in the air; but perhaps one merely needs enough phase shift along a much larger assembly to find the "dry" edge case.

Even truly unstoppable forces are handled impressively well -- there's a "golf" shrine somewhere with a constrained pendulum (single axis of rotation; or was it two (both swing axes, no axial rotation)?), and a "gate" that rises from the floor -- to prevent you from taking a swing as the mechanism resets the "golf club" you're supposed to set up.  Well, it can happen that the "club" pitches forward above the gate, and you can hit the switch, triggering the gate.  Which dutifully penetrates into the "club" you've attached to the pendulum, breaking the "glue", but also..... not even exploding the "club", it just, kind of... smooshes out of the way and falls gently to the side.

They must've worked very hard to avoid the "super physics deform" (SPD) effect, characteristic of the Source engine (Havok physics) for example.  Most physics systems, really, when driven with conflicting constraints, or just a little too much energy, tend to have divergent results, so they did a good job avoiding that, at least in most cases it seems.

Meanwhile, speedrunners have discovered item duplication and wall clipping mechanics (which are variously being patched out already), partly through abuses of the menu sorting and item crafting mechanics.  Nothing, it seems, so critical yet as to be able to summon arbitrary items or effects (compare: Ocarina of Time's "[Reverse] Bottle Adventure" inventory manipulation glitches), let alone memory manipulation or code execution (ACE).

Tim

[PA0PBZ]

What happens if you turn the stabilizer 90 degrees?

[Infraviolet]

The joys of physics engines. It looks to me like the water is defined as a plane geometry and of the geometric representation of the raft comes close the physics engine misinterprts it as being on the opposite side of the water surface plane, which causes the increasing vibrations. The game here obviously interprets the increasing oscillation as a real motion of the kind you'd get if the raft were banking in a tight turn and triggers the wave breaking animations as it intensifies. This sort of thing applies particularly when there is a >10 fold different in mass/moment of inertia between objects on contact with each other, I've seen simulation engines based on game physics engines (Bullet, Newton, ODE...) where a sufficiently light weight object left sitting on a surface will start doing this over time and wobble its way along with brownian motion. All comes down to the way that computed numbers have a limited precision and rounding errors over enough time steps lead to integrated errors, similar to why inertial measurement systems for double integrating acceleration to give displacement for navigating ships/aircraft always drifted over time (and people were so happy to dump them when GPS became available).

[T3sl4co1l]

Heh, most systems (most better quality ones, I guess; the ones I'm familiar with) join objects whose collision and relative motion has been resolved below an acceptable threshold.  Or truncate motion, or etc.  The classic case in Source being, when you stack say three or more objects up, it becomes VERY difficult to put another one on top, as any vertical velocity is likely to just bounce off, and any horizontal velocity is likely to slide around (and that's if the touching faces are already parallel, ideally no torque to resolve).  When successfully placed, it tends to give a decaying oscillation, and then it stops abruptly.  Being able to ignore stationary objects saves a lot of CPU cycles of course, while also avoiding the scourge of rounding errors.

Oh yeah hm, I wonder... I never tried stacking things in Doom 3 -- which coincided with the release of Half-Life 2 and sort-of competed with it.  By coincidence, both have well developed physics engines; in Doom 3, it's not used much as a gameplay mechanic (as it is in HL2); but a not-"Gravity Gun" was used by the developers to place objects more organically, which made an appearance in the Resurrection of Evil expansion pack.  Guess I should go take a look at that some time and probe the engine, see how many and what kinds of objects can be stacked before they fall over.  Don't recall I ever tried...

Heh, or if you go really far back (or, really basic, anyway), there's the physics systems that are well enough behaved on a large scale, but which are incessantly fidgety, like... I think a lot of pinball games were of this sort, probably with pixel-based motion, so what should intuitively be a perfectly stationary resting state might've been impossible, the ball keeps jittering around a pixel or two here or there.  Well, for something where it's in motion most of the time, that can still be fine!

Tim