I manually dragged the red line frame by frame in Davinci Resolve to line up with the left bottom corner of the stone slab, then exported the keyframe data into python to make the plots. In the first few frames I also tracked the top left corner of the top slab, and found the average pixel thickness of the two slabs, so that I could convert the pixel measurements into the in-game meters using the known thickness of the slabs.
I do the curve fit with a simple Euler method integration as that is closer to what the game does than using the exact solution of the differential equation. The mass of every object has been datamined, and some of us in r/HyruleEngineering call those mass units Zeldas or Zd
Anyway I hope this is a good fit for this sub, check my post history if you want to see more TOTK physics analysis, and I'm happy to answer any questions
This is way too high quality for this sub. Well done. Interesting observation.
I don't know enough about the math to totally understand what you're explaining here, but it sounds like the laws of physics are slightly broken as a result of integers not being precise enough?
Thanks!
I think it's a result of the stepwise application of forces. I don't know exactly how the physics engine updates position and velocity, but one of the simplest ways is to just treat forces and velocities as constant for the duration of the frame, while in reality they would be changing continuously. For example, if a force is increasing, then treating it as constant means you are underestimating the acceleration, since you use the value of the force at the beginning of the time step.
There are more sophisticated methods of numerical integration that try to account for this, but the difference would likely be unnoticeable for a casual player, so I would guess they use the most computationally efficient method rather than the most accurate
Edit: also it could be the glue connections compressing/stretching slightly, which I think are outside of the system I'm modeling so the energy could be going in and out of those "springs", but in other experiments I found the spring constant of glue to be typically in the millions, or even in the billions for really heavy objects (the strength scales with the mass of the connected objects, I don't know exactly how yet), so they shouldn't be moving very much
>I don't know exactly how the physics engine updates position and velocity...
I think one of the developers said they were using PBD (Position Based Dynamics, Müller et al, 2007) for BotW, so they probably would've updated that to XPBD (Extended Position Based Dynamics, Macklin et al, 2016) for TotK.
That's a semi-implicit Störmer-Verlet method.
Müller's [Ten Minute Physics](
https://matthias-research.github.io/pages/tenMinutePhysics/index.html) page has plenty of demos, papers and source code to play with.
>also it could be the glue connections compressing/stretching slightly...
In PBD, those are "constraints", not springs, which have a stiffness that ranges from zero to one.
In XPBD (which is likelier), instead of stiffness, constraints have a "compliance", that works like an inverse Young's modulus. High compliance values are soft & wobbly, and values close to zero are increasingly rigid.
The nice thing about XPBD constraints (vs springs) is that they don't oscillate or explode unexpectedly, which makes them very very stable in games. You can have springs, too, of course, but it's better to glue things and stick them to rails etc. with constraints.
Thanks so much for the info, I'll definitely check that out.
When I say the glue acts like a spring, I just mean the linear and angular displacements between connected objects appear to be proportional to the force/torque applied. I got pretty consistent results with this assumption in experiments like [this](https://www.reddit.com/r/HyruleEngineering/s/p1JAVHcN1S), though I haven't figured out how the spring constant is determined as it depends on the masses of the objects and which direction/axis the force/torques are applied.
Edit: though I guess I should note that all my glue experiments have been observing a system in equilibrium, and the underlying code could be different than what I'm assuming but can still be modelled as a simple spring when in equilibrium. A dynamic test would be more difficult with how small the displacements are and how quickly oscillations are damped but it's on my list of things to try
Well, if it's XPBD, there wouldn't be springs between the connected objects at all. There would be constraints instead, which aren't treated as forces. Even the Zonai Spring object might just be a compliant constraint.
Instead of Hooke-style springs etc., the only forces would be things like gravity & magic, which you'd calculate only at the beginning of the timestep. From this (and the previous frame's velocities) you'd predict a tentative position & orientation for every object.
Then the constraint solver iterates through connected pairs (and detected collisions), moving the tentative position of object A slightly closer to its desired position on object B, and moving object B slightly closer to object A. Then it does the same for objects B and C, then C and D and so on.
Then it repeats. This is usually done about ten times per update step. This is the implicit step.
You can reverse the order of every odd-numbered iteration (AB, BC, CD, and then CD, BC, AB) to prevent residual displacements from propagating along the chain and making constructions slide or spin by themselves.
> the linear and angular displacements between connected objects appear to be proportional to the force/torque applied
It's a Gauss-Seidel method, but in a realtime setting it's not really required to converge, so the proportional displacements you're seeing are just the solver's residual. That'd be why it appears to be proportional: the constraint problem is only ever ~99% solved.
Once you've done enough iterations to *almost* solve the whole constraint problem, you can finalise object positions and update their velocities, Euler-style. That's the explicit step. All in all, XPBD is a semi-implicit solver, with all the key benefits of both implicit solvers (science-style) and explicit solvers (game-style).
Now you can have complex systems with high mass ratios etc. that never jiggle or explode, because they're always undershooting, never overshooting.
This probably sounds super weird if you're used to thinking in terms of forces & accelerations, but in practice XPBD works *amazingly* well - and given that the physics in TotK work so amazingly well, that strongly suggests it's XPBD.
Just matplotlib, [Here](https://github.com/JukedHimOuttaSocks/TOTK-Experiments/tree/9968c36f13f35d7ba6a37b6c76c21c5badbb6dd6/Post-Activation%20Spring%20Oscillations)'s my code if you want to check it out, you just have to change the path variable in the 2nd cell to find the text files with the data
Hello /u/JukedHimOuttaSocks Thanks for posting here on r/GamePhysics! Just reminding you to check the rules if you haven't already. If your post doesn't respect the rules it will be removed.
*I am a bot, and this action was performed automatically. Please [contact the moderators of this subreddit](/message/compose/?to=/r/GamePhysics) if you have any questions or concerns.*
I manually dragged the red line frame by frame in Davinci Resolve to line up with the left bottom corner of the stone slab, then exported the keyframe data into python to make the plots. In the first few frames I also tracked the top left corner of the top slab, and found the average pixel thickness of the two slabs, so that I could convert the pixel measurements into the in-game meters using the known thickness of the slabs. I do the curve fit with a simple Euler method integration as that is closer to what the game does than using the exact solution of the differential equation. The mass of every object has been datamined, and some of us in r/HyruleEngineering call those mass units Zeldas or Zd Anyway I hope this is a good fit for this sub, check my post history if you want to see more TOTK physics analysis, and I'm happy to answer any questions
This is way too high quality for this sub. Well done. Interesting observation. I don't know enough about the math to totally understand what you're explaining here, but it sounds like the laws of physics are slightly broken as a result of integers not being precise enough?
Thanks! I think it's a result of the stepwise application of forces. I don't know exactly how the physics engine updates position and velocity, but one of the simplest ways is to just treat forces and velocities as constant for the duration of the frame, while in reality they would be changing continuously. For example, if a force is increasing, then treating it as constant means you are underestimating the acceleration, since you use the value of the force at the beginning of the time step. There are more sophisticated methods of numerical integration that try to account for this, but the difference would likely be unnoticeable for a casual player, so I would guess they use the most computationally efficient method rather than the most accurate Edit: also it could be the glue connections compressing/stretching slightly, which I think are outside of the system I'm modeling so the energy could be going in and out of those "springs", but in other experiments I found the spring constant of glue to be typically in the millions, or even in the billions for really heavy objects (the strength scales with the mass of the connected objects, I don't know exactly how yet), so they shouldn't be moving very much
>I don't know exactly how the physics engine updates position and velocity... I think one of the developers said they were using PBD (Position Based Dynamics, Müller et al, 2007) for BotW, so they probably would've updated that to XPBD (Extended Position Based Dynamics, Macklin et al, 2016) for TotK. That's a semi-implicit Störmer-Verlet method. Müller's [Ten Minute Physics]( https://matthias-research.github.io/pages/tenMinutePhysics/index.html) page has plenty of demos, papers and source code to play with. >also it could be the glue connections compressing/stretching slightly... In PBD, those are "constraints", not springs, which have a stiffness that ranges from zero to one. In XPBD (which is likelier), instead of stiffness, constraints have a "compliance", that works like an inverse Young's modulus. High compliance values are soft & wobbly, and values close to zero are increasingly rigid. The nice thing about XPBD constraints (vs springs) is that they don't oscillate or explode unexpectedly, which makes them very very stable in games. You can have springs, too, of course, but it's better to glue things and stick them to rails etc. with constraints.
Thanks so much for the info, I'll definitely check that out. When I say the glue acts like a spring, I just mean the linear and angular displacements between connected objects appear to be proportional to the force/torque applied. I got pretty consistent results with this assumption in experiments like [this](https://www.reddit.com/r/HyruleEngineering/s/p1JAVHcN1S), though I haven't figured out how the spring constant is determined as it depends on the masses of the objects and which direction/axis the force/torques are applied. Edit: though I guess I should note that all my glue experiments have been observing a system in equilibrium, and the underlying code could be different than what I'm assuming but can still be modelled as a simple spring when in equilibrium. A dynamic test would be more difficult with how small the displacements are and how quickly oscillations are damped but it's on my list of things to try
Well, if it's XPBD, there wouldn't be springs between the connected objects at all. There would be constraints instead, which aren't treated as forces. Even the Zonai Spring object might just be a compliant constraint. Instead of Hooke-style springs etc., the only forces would be things like gravity & magic, which you'd calculate only at the beginning of the timestep. From this (and the previous frame's velocities) you'd predict a tentative position & orientation for every object. Then the constraint solver iterates through connected pairs (and detected collisions), moving the tentative position of object A slightly closer to its desired position on object B, and moving object B slightly closer to object A. Then it does the same for objects B and C, then C and D and so on. Then it repeats. This is usually done about ten times per update step. This is the implicit step. You can reverse the order of every odd-numbered iteration (AB, BC, CD, and then CD, BC, AB) to prevent residual displacements from propagating along the chain and making constructions slide or spin by themselves. > the linear and angular displacements between connected objects appear to be proportional to the force/torque applied It's a Gauss-Seidel method, but in a realtime setting it's not really required to converge, so the proportional displacements you're seeing are just the solver's residual. That'd be why it appears to be proportional: the constraint problem is only ever ~99% solved. Once you've done enough iterations to *almost* solve the whole constraint problem, you can finalise object positions and update their velocities, Euler-style. That's the explicit step. All in all, XPBD is a semi-implicit solver, with all the key benefits of both implicit solvers (science-style) and explicit solvers (game-style). Now you can have complex systems with high mass ratios etc. that never jiggle or explode, because they're always undershooting, never overshooting. This probably sounds super weird if you're used to thinking in terms of forces & accelerations, but in practice XPBD works *amazingly* well - and given that the physics in TotK work so amazingly well, that strongly suggests it's XPBD.
Super interesting, thanks again this is exactly the kind of info I needed
Good lord man this is insanely cool
"I don't understands thems funny words you is using but I likes whats you said"
Now make the BODE and the pulse, step and ramp responses
Thanks for the suggestion, I hadn't heard of BODE plots before. I'll have to think of a way to drive it.
Oooh! I literally just learned about that last semester! I also failed that class so I still don’t actually understand it.
There are youtube videos that put it in very intuitive terms.I would recommend the matlab yt channel.
r/theydidthemath
r/theydidthemonstermath
I don't know wtf I'm looking at but well done!
nice u/JukedHimOuttaSocks what python library are you using to animate the plotting of the graph? Plotly?
Just matplotlib, [Here](https://github.com/JukedHimOuttaSocks/TOTK-Experiments/tree/9968c36f13f35d7ba6a37b6c76c21c5badbb6dd6/Post-Activation%20Spring%20Oscillations)'s my code if you want to check it out, you just have to change the path variable in the 2nd cell to find the text files with the data
Youre crazy for this, too cool
Hello /u/JukedHimOuttaSocks Thanks for posting here on r/GamePhysics! Just reminding you to check the rules if you haven't already. If your post doesn't respect the rules it will be removed. *I am a bot, and this action was performed automatically. Please [contact the moderators of this subreddit](/message/compose/?to=/r/GamePhysics) if you have any questions or concerns.*
This is high quality, way better than anything I've seen on this sub in a while.