this post was submitted on 12 Jul 2023
0 points (NaN% liked)
Godot
5866 readers
12 users here now
Welcome to the programming.dev Godot community!
This is a place where you can discuss about anything relating to the Godot game engine. Feel free to ask questions, post tutorials, show off your godot game, etc.
Make sure to follow the Godot CoC while chatting
We have a matrix room that can be used for chatting with other members of the community here
Links
Other Communities
- !inat@programming.dev
- !play_my_game@programming.dev
- !destroy_my_game@programming.dev
- !voxel_dev@programming.dev
- !roguelikedev@programming.dev
- !game_design@programming.dev
- !gamedev@programming.dev
Rules
- Posts need to be in english
- Posts with explicit content must be tagged with nsfw
- We do not condone harassment inside the community as well as trolling or equivalent behaviour
- Do not post illegal materials or post things encouraging actions such as pirating games
We have a four strike system in this community where you get warned the first time you break a rule, then given a week ban, then given a year ban, then a permanent ban. Certain actions may bypass this and go straight to permanent ban if severe enough and done with malicious intent
Wormhole
Credits
- The icon is a modified version of the official godot engine logo (changing the colors to a gradient and black background)
- The banner is from Godot Design
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
Ok so it seems like they don't commute? I asked the question in part because i wanted to do something like:
and i wanted to be sure that if i do
set_base_transform(some_node, some_transform)
i'd be guaranteed to get thatget_base_transform(some_node) == some_transform
afterwards. But when i tried it the above code did not work out, at least i didnt get the result i expected. But when i flipped it so thatset_base_transform
didnode.transform = node.transform * base_transform.affine_inverse()
instead it did work out. Its still not hard proof though, maybe something else was messed up the first time, or it only looks like it works now and i'll discover the transform still isn't what i wanted it to be. Or they do commute but only under some constriction like no scale on any axis or something and i just happened to fulfill it with all the ones i used in my test.So it would still be good to know for sure whether/when
Transform3D
's commute.EDIT: I accidentally wrote the first line wrong, it said that they do commute. When actually the experience i had with it working only after both functions did their multiplications in a compatible order should indicate that they don't commute.
I'm writing this as someone who has not done much with Godot, but from the mathematical standpoint, two
Transform3D
s do not commute in general. There are situations in which they will commute, though. If they are both pure rotations, they will commute if their rotation axes are the same.Edit to add: This was based on thinking about a
Transform3D
as a transformation matrix acting on R^3^.I likewise don't really use Godot, but for graphics in general, the 4th coordinate is important, even if it is "usually" 1. It's most obvious to correctly interpolate near the poles of a sphere with a single rectangular texture, but think for a minute what "near" means.
Back to the main point though: the important things we normally rely on for matrix math are associativity (particularly, for exponentiation!) and anticommutativity (beware definitions that are sloppy about "inverse").
Who said it isn't? Transformation matrices acting on R^3^ are 4x4 (since transformation matrices acting on R^n^ are of dimension n+1 in general), whether they're full rank or not.