Octodemy
patreon
Balistic AI Aiming - next video - drag damping woes
🕑 Added 2024-06-03 03:27:52 +0000 UTCUpdate: I think I fixed it. I messed up the rotations. Two days of reviewing physics calculus formulas thinking they were wrong and turns out I messed up the rotations in Godot.
The next video is going to be about aiming a balistic projectile at a target point.
I meant to do this video for a while now but eventually forgot about it.
Aiming involves quite a bit of high school physics, but using some derivated formulas you can get it done fairly simple.
But that does not take into account the linear damping that game engines use.
Even though it is usually fairly small, you still can get small imprecisions.
So.... I kinda went on a tangent trying to figure this out
Linear drag - So many complications (warning: math ahead)
I'm quite rusty with math. But I thought this was going to be easy.
Or at least someone would have derived some ready to use formulas. But I was so wrong.
Apparently, getting the aiming angle while taking into account drag is not a trivial thing.
I tried to understand how to solve this but only got more confused trying to remember the little I used to know about integrals and derivatives.
In the end, I tried to use wolframalpha to get integrates I needed. But that didn't work.
Heres some of the notes I took
After a bit of research I eventually found out what I wanted was to use balistic motion using Stokes Drag. A simplified form of linear drag that is basically what game engines use.
I was quite happy when I managed to get the position in function of time working with drag, but I already managed to get that done with timesteps before, so not too exciting.
But to find the shooting angle is not so easy.
After deriving a lot of things, you still needs to use a numeric solution to try and find the result.
I eventually found an article that was exactly about this topic. But alas, I couldn't implement it.
The problems showed in the article are a bit different than my use-case and it skips some 'simple' steps at the end and instead gives an octave/matlab code.
I couldn't understand it with my limited calculus knowledge, so I tried it from scratch again.
I eventually got this
And used a numeric solver using the newton-rahpson method to solve for the angle.
But the results were strange. It kinda works at some distances, but not really.
I tried a lot of other things, but it was just shots in the dark. My math knowledge is lacking.
Also, while trying to use some math formulas in godot previously, I sometimes had to invert gravity for it to work properly.
I couldn't find any other examples to know if the above formula for T and Y are correct, so I guess that's it.
It's a solvable problem, as that article's example kind have it working, but it is too much for me and I can't understand where to go from here.
So in conclusion...
I won't be talking about aiming with linear drag for now.
You'll need to either disable the drag or have that little bit of imprecision there.
It is very little at Godot default values and should not affect gameplay in most games.
But I had hoped I could make drag work to get a perfectly physics accurate result.
I'll need a day to recover and then I'll start setting up the proper project for the tutorial video.
UPDATE:
Turns out I messed up the rotations in Godot. The formulas were probably correct.
I tried to go back to the simple calculation and found out they were also not working so reliably too. It was just that the error was smaller and was easier to miss.
So after 2 days of stressing out that the math was somehow wrong, I FINALLY found out I was doing ROTATIONS wrong.... again... its not the first time I mess up things involving rotations.
In this case, it was very simple. I was using rotation.y instead o global_rotation.y.
What I still don't understand is that the model technically doesn't have any local rotation in itself or any of its parents, its local rotation should have been equal to the global_rotation. I think I'm missing something.
I'll need to do a very in-depth review of Godots Transforms/Basis/Rotations to understand what I'm getting wrong all the time. Things gets weird when I have to directly change the rotation. I think it might be precision errors, as I saw in the docs that you should not use that and instead use the rotate methods. Even trying to orthogonalize the basis after changing the rotation didn't seem to fix as I tried that.
But anyways, now the values are correct. And maybe even the drag predictions works now.
I'll make the video using the simple predictions and if I'm not too late I'll add a note for the more complicated one. Or maybe a small post-video later.
