For those who want to see the missing part about quaternions, head over to the original channel, this one has only 1 video, but if you go to the actual guy who made the whole series, you can find them all: ruclips.net/video/tzx_jHtPId4/видео.html
Came here to get information about gimbal lock for a computergraphics course I have at university. Not only do I understand it now but also got useful information for my animation journey. Thanks :)
Hah, it's interesting that you can even have a form of gimbal lock in software! I came here from my general interest in the 50th anniversary of the 1st lunar landing, and by extension, the rest of them. But then this type of lock should be easier to get out of in software than in the real world. Right? Just rotate the middle ring to turn the inner one back out of alignment.
Despite being categorized as Gaming, this is very helpful in understanding the gimbal lock which is not a gaming specific concept, I study robotics and that explanation was super helpful. But where is the Quat video?
I use axis angle primarily for all my world objects they use their orientation matrices right up forward for axis and the angle is added to the orientation. This means that a world object uses its own up when it creates its world space or view space so their is no gimble lock in any combination of all axis rotations xyz and its timed so the angle is compensated for by lost frames or high frame rates. My orbiting height camera that needs the targets orthogonal point is another story.
Definitely helps to think of Euler axes as the Yes, No, and So-So axes. If you tilt your head sideways by 90’ and do a YES motion, without the face, a YES motion looks the same as a NO motion.
I don't understand why this is an issue, at least with non-physical, logical systems in software/simulation. If the object's local axes are simply updated with each rotation, you never end up in a situation with two axes on the same plane. Why aren't local axes, about which we are performing our rotations, always kept perpendicular to each other, and in the same relative direction to one another? If that were done, the situation at 6:37 (gimbal lock) would never occur, because the blue ring would move to stay perpendicular to the red ring. I can see how this could be a problem with a physical system, like a gyroscope, but why is this an issue in the conceptual realm of software?
@Pulseczar1 THANK YOU!!! I'm surfing the web for the past week trying to find someone having the same dilemma as I do and here you are, I found you :)))))))))) I really don't understand why Euler angles are basically understood (and implemented) as a physical gimbal. There is no point in parenting the 3 axes like that, other than creating the gimbal lock problem, so that you later have to solve with quaternions. Did you manage to find out in the meantime a rational explanation about this? No matter what article I read, what webpage I visit and what YT video I watch, they keep showing the same crap over and over again, like the gimbal makes any sense in the first place. Why not just have the 3 axes stay in the same place (absolute orientation, not relative), then whatever moves around them will be able to do so without ever having any gimbal lock, because there's no gimbal to begin with... The gimbal basically switches from an orthogonal basis to a non-orthogonal one as soon as you move any of the inner rings, which again, I don't understand why we're creating this problem voluntarily so that later we can find a solution for it. The physical gimbal makes no sense in software representation of rotations. It's the physical constraints that eventually create the lock, so why not get rid of them?
@@SixStringOverdose It was so long ago that I had my head immersed in this subject that I would have to figure a lot out to answer your question. I read most of a book on learning math for 3D video games. Reading something like that might help you answer your question. It was called "3D Math Primer for Graphics and Game Development".
@@SixStringOverdose this shit is very meaningful and amazing! i have had the same dilemma with you dudes for so long times, and finally I get my own answer for this dilemma(not logically perfect, but quite satisfying, at least, for me). Let Rotation order be X->Y->Z. And you want to represent Eular rotation by combining three transformation matrices using numpy, then you r rotating Y-axis, and you want to rotate Z-axis according to Y-axis rotation(just same with Pulseczar1's idea), but rotating Z-axis(and it's rotation) according to Y-axis rotation is same with converting Z-axis rotation matrix to axis angle representation(those axis is Z-axis), then rotate axis-vector of axis-angle representation according to Y-axis rotation during maintaining it's theta, and then convert axis-angle representation(rotated along Y-axis rotation) to rotation matrix again. this scheme is not simple and hard to represent. but parenting scheme is very easy to represent just by using inner products. Idk whether there is some tools for Animators, which implement your idea(rotating parent's axis) but for Engineers, that idea is not seamless, and we have simpler solution 'quaternion'. Because no one clearly explain about this shit, I had to satisfied with my own explanation like that. But I'm not sure about such explanation. If there is another one who have some insights about that, please counter my logic, and give better explanations. Thanks.
his look up and look down plane got equated to his look left look right plane. a real monkey brain doesn't work that way because its not using euler, his planes are relative to his eyeballs, but the computer (software) brain is using euler transformations, to break the lock the inner axis needs to change first (an annoyance to an animator). If a physical gyro is used the gyro can't tell the difference between left and right from up and down anymore since they are the same gimbal position. If you had a 3d gyro on a plane and took a straight nose dive (-90 degree) your gyro wouldn't know if you changing your orientation anymore since left and right are both up, pulling up would also be up, and so would pulling down (making you fly upside down). since your left and right and up and down are locked together they never split up now
better yet, nobody is able to explain to me why Euler angles are implemented as a physical gimbal in software... I mean the lock itself appears due to the physical constraints of the gimbal, we can all see how that happens. But why not just have an orthogonal system (X, Y, Z) which stays perpendicular no matter what and also doesn't rotate? Why make the axes parented like inside of a gimbal? Why not have them independent? The gimbal only goes from an orthogonal system to a non-orthogonal one as soon as the inner rings start moving. I know I might be the stupid one here, but until I find a proper explanation, I think that the concept itself is stupid and unfortunately nobody questions it, as it became the norm...
So, basically, if you rotate a craft with an attitude gyro onto its side, and then pull up, the computer can't tell where you are pointing, because your yaw plane and your pitch plane have switched places--so the 8-ball goes crazy. Do I have this right?
You are a hero. Taught a girl that don't know where is left and right about the Gimbel Lock.
For those who want to see the missing part about quaternions, head over to the original channel, this one has only 1 video, but if you go to the actual guy who made the whole series, you can find them all: ruclips.net/video/tzx_jHtPId4/видео.html
Came here to get information about gimbal lock for a computergraphics course I have at university. Not only do I understand it now but also got useful information for my animation journey. Thanks :)
This is the best explanation of Gimbal Locks I've found on RUclips. But where is the second part of the video on Quaternions?
ruclips.net/video/tzx_jHtPId4/видео.html
Extremely useful, no other video is this clear, thanks a lot!
where's the quats yo? this is pretty awesome, but talk about a cliffhanger
Yeah!
Lol I started watching for the quaternions. It ended before that :P
ruclips.net/video/tzx_jHtPId4/видео.html
Best explanation! It's so clear! Thank you!
Now It is finally time to talk about *stroke sounds Quaternions Rota.....tio....nsss *dies
ruclips.net/video/tzx_jHtPId4/видео.html
Hah, it's interesting that you can even have a form of gimbal lock in software! I came here from my general interest in the 50th anniversary of the 1st lunar landing, and by extension, the rest of them. But then this type of lock should be easier to get out of in software than in the real world. Right? Just rotate the middle ring to turn the inner one back out of alignment.
Despite being categorized as Gaming, this is very helpful in understanding the gimbal lock which is not a gaming specific concept, I study robotics and that explanation was super helpful. But where is the Quat video?
ruclips.net/video/tzx_jHtPId4/видео.html
Great explaination
I like to think that uploader tried understanding quaternions and his brain just melted xD
ruclips.net/video/tzx_jHtPId4/видео.html
Great tutorial
where's the quaternion video?
do you find that?
I think I found it! ruclips.net/video/tzx_jHtPId4/видео.html
@@vaaal88 thank youu
ruclips.net/video/tzx_jHtPId4/видео.html
yo Nathan,you rock!!
9:50 calm down dude
3years later and we still didn't get 2nd part of the video.
ruclips.net/video/tzx_jHtPId4/видео.html
I use axis angle primarily for all my world objects they use their orientation matrices right up forward for axis and the angle is added to the orientation. This means that a world object uses its own up when it creates its world space or view space so their is no gimble lock in any combination of all axis rotations xyz and its timed so the angle is compensated for by lost frames or high frame rates. My orbiting height camera that needs the targets orthogonal point is another story.
Great video! Thanks.
Definitely helps to think of Euler axes as the Yes, No, and So-So axes. If you tilt your head sideways by 90’ and do a YES motion, without the face, a YES motion looks the same as a NO motion.
Makes me wonder if planetary systems and galaxies are in fact gimbal locked?
Mind blown!
Still waiting for the part 2: Quaternions ;)
ruclips.net/video/tzx_jHtPId4/видео.html
best video for gimbal lock
I don't understand why this is an issue, at least with non-physical, logical systems in software/simulation. If the object's local axes are simply updated with each rotation, you never end up in a situation with two axes on the same plane. Why aren't local axes, about which we are performing our rotations, always kept perpendicular to each other, and in the same relative direction to one another? If that were done, the situation at 6:37 (gimbal lock) would never occur, because the blue ring would move to stay perpendicular to the red ring. I can see how this could be a problem with a physical system, like a gyroscope, but why is this an issue in the conceptual realm of software?
@Pulseczar1 THANK YOU!!! I'm surfing the web for the past week trying to find someone having the same dilemma as I do and here you are, I found you :)))))))))) I really don't understand why Euler angles are basically understood (and implemented) as a physical gimbal. There is no point in parenting the 3 axes like that, other than creating the gimbal lock problem, so that you later have to solve with quaternions. Did you manage to find out in the meantime a rational explanation about this? No matter what article I read, what webpage I visit and what YT video I watch, they keep showing the same crap over and over again, like the gimbal makes any sense in the first place. Why not just have the 3 axes stay in the same place (absolute orientation, not relative), then whatever moves around them will be able to do so without ever having any gimbal lock, because there's no gimbal to begin with... The gimbal basically switches from an orthogonal basis to a non-orthogonal one as soon as you move any of the inner rings, which again, I don't understand why we're creating this problem voluntarily so that later we can find a solution for it. The physical gimbal makes no sense in software representation of rotations. It's the physical constraints that eventually create the lock, so why not get rid of them?
@@SixStringOverdose It was so long ago that I had my head immersed in this subject that I would have to figure a lot out to answer your question. I read most of a book on learning math for 3D video games. Reading something like that might help you answer your question. It was called "3D Math Primer for Graphics and Game Development".
@@Pulseczar1 no worries, I have that book as well :D thanks a lot anyway!!!
@@SixStringOverdose It's a good book.
@@SixStringOverdose this shit is very meaningful and amazing! i have had the same dilemma with you dudes for so long times, and finally I get my own answer for this dilemma(not logically perfect, but quite satisfying, at least, for me). Let Rotation order be X->Y->Z. And you want to represent Eular rotation by combining three transformation matrices using numpy, then you r rotating Y-axis, and you want to rotate Z-axis according to Y-axis rotation(just same with Pulseczar1's idea), but rotating Z-axis(and it's rotation) according to Y-axis rotation is same with converting Z-axis rotation matrix to axis angle representation(those axis is Z-axis), then rotate axis-vector of axis-angle representation according to Y-axis rotation during maintaining it's theta, and then convert axis-angle representation(rotated along Y-axis rotation) to rotation matrix again. this scheme is not simple and hard to represent. but parenting scheme is very easy to represent just by using inner products. Idk whether there is some tools for Animators, which implement your idea(rotating parent's axis) but for Engineers, that idea is not seamless, and we have simpler solution 'quaternion'. Because no one clearly explain about this shit, I had to satisfied with my own explanation like that. But I'm not sure about such explanation. If there is another one who have some insights about that, please counter my logic, and give better explanations. Thanks.
This series continues here: ruclips.net/video/tzx_jHtPId4/видео.html
Still didnt explain properly, no one seems to explain why gimbal lock is an issue ?
Why can't the monkey at 7:02 "break" the gimbal lock ?
his look up and look down plane got equated to his look left look right plane. a real monkey brain doesn't work that way because its not using euler, his planes are relative to his eyeballs, but the computer (software) brain is using euler transformations, to break the lock the inner axis needs to change first (an annoyance to an animator). If a physical gyro is used the gyro can't tell the difference between left and right from up and down anymore since they are the same gimbal position. If you had a 3d gyro on a plane and took a straight nose dive (-90 degree) your gyro wouldn't know if you changing your orientation anymore since left and right are both up, pulling up would also be up, and so would pulling down (making you fly upside down). since your left and right and up and down are locked together they never split up now
better yet, nobody is able to explain to me why Euler angles are implemented as a physical gimbal in software... I mean the lock itself appears due to the physical constraints of the gimbal, we can all see how that happens. But why not just have an orthogonal system (X, Y, Z) which stays perpendicular no matter what and also doesn't rotate? Why make the axes parented like inside of a gimbal? Why not have them independent? The gimbal only goes from an orthogonal system to a non-orthogonal one as soon as the inner rings start moving. I know I might be the stupid one here, but until I find a proper explanation, I think that the concept itself is stupid and unfortunately nobody questions it, as it became the norm...
So, basically, if you rotate a craft with an attitude gyro onto its side, and then pull up, the computer can't tell where you are pointing, because your yaw plane and your pitch plane have switched places--so the 8-ball goes crazy. Do I have this right?
Can you share this blender project?
This was a nice explanation when where is the last part? Oops
ruclips.net/video/tzx_jHtPId4/видео.html
Meaning or alignment of the axes *changES.*
How about trying a new throat physician ?