great explanation, and another useful way to understand the basis is to think of it like defining where the xyz axes point to. This is useful if you use a sum of unit vectors to define vectors like you do in math; so eg. (1,2,3) would be 1i + 2j + 3k, where ijk are the xyz axes. The basis actually defines what these ijk vectors mean, so eg. if they aren't scaled nor rotated (in sync with the global coordinate system), then i would be (1,0,0), j would be (0,1,0) and z (0,0,1).
Nice explanation. I'm going to recommend your video to some people, because they still struggle to understand the topic (matrices scare the crap out of them))) and i'm not a good teacher myself when it comes to math )
honestly best explanation i heard so far, everything is detailed and you take your time with the explanation without skipping over anything. this vid deserves more views 👍
Awesome!! :) thanks so much glad you enjoyed. My goal was to make it as clear as possible. Tried to pack a lot of detail in there so it was accessible to beginners and intermediate learners too.
Hello! I've spent two full days on how to correctly rotate a mesh inside of a node, so all this stuff about local/global transforms is really helpful. Will definitively share this guide, thanks a lot! ❤
Thank you:)! The dev console is a basic one i made. I'm planning on releasing it along with my fps controller once it is done. For now it is just a simple prototype I made for this tutorial. I just use the Expression class to run methods, and save command history in the LineEdit.
thanks, i used my own basic one i made, i might release it at some point, but it's very basic not many features. just made it for the video real quick.
No they are different. The standard Vector3*Vector3 in Godot is just a component wise multiplication, Vector3(1,1,1) * Vector3(0,1,2) = Vector3(0,1,2). Each component is multiplied. Transforms cannot be added, only multiplied. Generally you don't usually add matrices, at least for 3D game dev. It is the multiplication which is centered around this idea of a basis, and transforming it from the 'basis' of one transform space to another transform/grid's 'basis.'
Quick question. I know this is not the topic of the video, but why is the movement input in the beginning in the _physics_process? Recently did some testing in order to understand the difference between it and _process, and it seems that any input is only updated and/or handled in _process, never in _physics_process. So basically what I found was that any method on Input, like get_vector() is ignored if it happens in between frames while in either of the process functions, and anything triggered in _input() only runs on the next _process(). So just curious of the reasoning for putting it there I guess, maybe I am missing something?
@@tech6hutch Yes, I get that part, the issue is that the input is not handled in the physics. What that means is that input in _physics_process() can be missed if shorter than the frame, while _input() does not, but _input() only runs on _process before _physics_process, which results in the input being the same for all _physic_process calls within that frame. I guess move_and_slide should be in _physics_process(), but it won't really change anything as it will move on the vector set in _process for the entire frame. So the result is the same. So for input based control, it makes little sense to me to have it there, or at least in this way.
@@Rattja ah, if I’m understanding, there’s no reason in particular that it’s at the beginning of the method compared to anywhere else in it. I put it towards the middle since I handle actions before movement.
@@tech6hutch Oh, no, not in the beginning of method. I just meant in the beginning of the video. The question was why is it in the _physics_process() method.
Interesting, I just tested this myself, and you are right. It looks like in some cases, placing especially Input.is_action_just_pressed into _physics_process can result in completely missed inputs. If I set the physics frames per second to 10, much lower than the game FPS, jumping via Input.is_action_just_pressed seems to completely break. Not sure if it would matter for regular the regular get_vector functions. But looking it up, seems like most people agree _input or _process is the best place to poll for input to prevent input delays or missed inputs. Thanks for your comment, appreciate it! I didn't know this so it was good to learn.
this is probable the most clear and thorough explantations of 3D transforms I have yet encountered. Saved, keep it up!
AWESOME!!! Thank you so much for your comment. Wasn't sure how this would be received but I tried to make it as clear as possible.
@@MajikayoGames You make a great teacher!
great explanation, and another useful way to understand the basis is to think of it like defining where the xyz axes point to. This is useful if you use a sum of unit vectors to define vectors like you do in math; so eg. (1,2,3) would be 1i + 2j + 3k, where ijk are the xyz axes. The basis actually defines what these ijk vectors mean, so eg. if they aren't scaled nor rotated (in sync with the global coordinate system), then i would be (1,0,0), j would be (0,1,0) and z (0,0,1).
super clear explanation, best one I've seen so far!
Nice job... as I am not a programmer but seeing this, I sort of understand it. More importantly, it's interesting to learn.
Nice explanation. I'm going to recommend your video to some people, because they still struggle to understand the topic (matrices scare the crap out of them))) and i'm not a good teacher myself when it comes to math )
honestly best explanation i heard so far, everything is detailed and you take your time with the explanation without skipping over anything. this vid deserves more views 👍
Awesome!! :) thanks so much glad you enjoyed. My goal was to make it as clear as possible. Tried to pack a lot of detail in there so it was accessible to beginners and intermediate learners too.
Hello! I've spent two full days on how to correctly rotate a mesh inside of a node, so all this stuff about local/global transforms is really helpful.
Will definitively share this guide, thanks a lot! ❤
Awesome! So glad it helped. Let me know if you have any questions about it :)
Finally I understand some of the things ! Thank you!
Epic explanation thank you
Really great tutorial! could you let us know what addons you used for things like the debug draw / text?
Thank you:)! The dev console is a basic one i made. I'm planning on releasing it along with my fps controller once it is done. For now it is just a simple prototype I made for this tutorial. I just use the Expression class to run methods, and save command history in the LineEdit.
nice video, what do you use for your ingame console?
thanks, i used my own basic one i made, i might release it at some point, but it's very basic not many features. just made it for the video real quick.
multiplying vector and adding them are the same thing while using Transform vectors?
No they are different. The standard Vector3*Vector3 in Godot is just a component wise multiplication, Vector3(1,1,1) * Vector3(0,1,2) = Vector3(0,1,2). Each component is multiplied. Transforms cannot be added, only multiplied. Generally you don't usually add matrices, at least for 3D game dev. It is the multiplication which is centered around this idea of a basis, and transforming it from the 'basis' of one transform space to another transform/grid's 'basis.'
Quick question.
I know this is not the topic of the video, but why is the movement input in the beginning in the _physics_process?
Recently did some testing in order to understand the difference between it and _process, and it seems that any input is only updated and/or handled in _process, never in _physics_process.
So basically what I found was that any method on Input, like get_vector() is ignored if it happens in between frames while in either of the process functions, and anything triggered in _input() only runs on the next _process().
So just curious of the reasoning for putting it there I guess, maybe I am missing something?
Anything involving physics (like movement) should happen there
@@tech6hutch Yes, I get that part, the issue is that the input is not handled in the physics.
What that means is that input in _physics_process() can be missed if shorter than the frame, while _input() does not, but _input() only runs on _process before _physics_process, which results in the input being the same for all _physic_process calls within that frame.
I guess move_and_slide should be in _physics_process(), but it won't really change anything as it will move on the vector set in _process for the entire frame. So the result is the same.
So for input based control, it makes little sense to me to have it there, or at least in this way.
@@Rattja ah, if I’m understanding, there’s no reason in particular that it’s at the beginning of the method compared to anywhere else in it. I put it towards the middle since I handle actions before movement.
@@tech6hutch Oh, no, not in the beginning of method. I just meant in the beginning of the video.
The question was why is it in the _physics_process() method.
Interesting, I just tested this myself, and you are right. It looks like in some cases, placing especially Input.is_action_just_pressed into _physics_process can result in completely missed inputs. If I set the physics frames per second to 10, much lower than the game FPS, jumping via Input.is_action_just_pressed seems to completely break. Not sure if it would matter for regular the regular get_vector functions. But looking it up, seems like most people agree _input or _process is the best place to poll for input to prevent input delays or missed inputs. Thanks for your comment, appreciate it! I didn't know this so it was good to learn.
👍🏽👍🏽👍🏽