How Godot's Transform3D Type Works
HTML-код
- Опубликовано: 1 авг 2024
- This video gives an explanation of Godot's Transform3D and Basis types. It shows how they are actually 3x4 and 3x3 matrices under the hood, and gives an introductory explanation of matrix math.
Rotation matrix visualization web demo I used in the video: majikayogames.github.io/rotat...
Godot Transform3D documentation: docs.godotengine.org/en/stabl...
Contents of this video:
0:00 - Intro
0:15 - Using transform.basis for character movement
1:42 - What is a Transform3D?
3:18 - Using transform.inverse()
5:53 - Basis explanation & visualization
9:00 - Transform3D is a 3x4 matrix
11:05 - Refresher on Vectors
12:36 - 2D basis visualization
18:56 - 3D basis & transforms
23:29 - Outro
If this video helped you, consider supporting the channel on Patreon or Ko-fi:
/ majikayogames
ko-fi.com/majikayogames
Finally I understand some of the things ! Thank you!
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 :)
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!
Epic explanation thank you
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 )
Nice job... as I am not a programmer but seeing this, I sort of understand it. More importantly, it's interesting to learn.
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.
👍🏽👍🏽👍🏽
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.
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.
multiplying vector and adding them are the same thing while using Transform vectors?
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.