Change name of ' Translation ' to ' Position' in Transforms . .

[jasperbrooks79]

Describe the project you are working on:
A Tomb Raider game . .

Describe the problem or limitation you are having in your project:
I was sitting making some visual script, and I noticed that the ' place ' of, a character, or object is called ' translation ' . . However, when making the ' logic ', for instance, to make a vector, I thought it makes more sense to say, ' GET position ' of enemy MINUS ' GET position ' of player, to make a vector, from player, to enemy . . I know ' translation ' is a pretty good name, but when we do the math, what we want to do, ' when thinking ', is GET position of something, MINUS position of something else . . I think under transforms, it might make more sense to write ' Position ', also since translation of refers to movement, ie. translate something from A to B, and not ' technically ' a position, it'd make more sense to call ' Translation ' ' Position ' . .

That way, when we make boxes in visual script, the names of the boxes make more sense, or so . . ie. to make a vector from player to enemy the box, should be called Get Position ( enemy ) MINUS Get Position ( Player ), not ' get translation ' . . It's a little thing, but it'd make the engine have names, that ' match ' the words, for how we think, more . .

I was also thinking, since under Transform is says Rotation Degrees, same way some boxes have a ' Index ' setting, ie. for a rotation, one can disable ' Default Settings ', that one could have an ' index ' for a GET rotation box, that outputs either radians, or degrees . . I'm not sure, just some thoughts . . It'd make the engine a bit more, like what we ' think ', when doing math, that's all . . It'd just be a small help, especially for visual script coders, or so . .

Also, for some reason the written code, for keyboard presses is called Input(), but in visual script, it is called action . . imo, in visual script, it could be called Input also, or User_input, I think it makes more sense to make it match what is written code, since then after one has learned visual script, one is more ready, to begin learning written code, and so as much as possible, the words in visual script boxes match, what happens in written code, to help talk between written coders, and visual script game makers, or so . . These are very minor things, but they often bug me . .

Describe the feature / enhancement and how it helps to overcome the problem or limitation:
These are just really small changes, that I think would make the coding experience a bit nicer, nothing more, a bit silly . . .

Describe how your proposal will work, with code, pseudocode, mockups, and/or diagrams:
Change transform name ' Translation ', to ' Position ', so when making code, it matches more, how we think in math, that's all . . .

If this enhancement will not be used often, can it be worked around with a few lines of script?:
I can't re-change the engine, very well, as a new user, it'd take a long time . .

Is there a reason why this should be core and not an add-on in the asset library?:
Well, it would just make the engine make a bit more sense, to how we think, from math, making it a bit faster . .

[jasperbrooks79]

Other names that make more sense, to Translation, is ' Location ', ' Place ', but ' Position ' is prob. the best . . I know this is very noob, and a bit dumb, all the same, it'd make more sense, when coding, to me . . Silly, lol . . . Also, bec. translation actually refers, strictly speaking, for MOVING objects, ie. translate from place A, to place B, refers to the MOVEMENT between points, not the ' place ', or prob. most mathmatically, ' Position ' . . It's simple, but makes coding it, a bit nicer, or so . . . Thx . . .

[jonbonazza]

Translation, rotation, and scale are the standard terminologies for the 3 components of a 3d transform. It's called translation because it's how far it's translated (moved) from the origin.

[aaronfranke]

Aside from being standard, an important reason is that "Translation" explicitly does not involve rotation/scale/shearing, while "Position" can be ambiguous and phrases like "positioning an object" can include rotation.

Note that in the code for the transformation matrix, Godot uses transform.origin since it's the offset of the origin of the basis vectors relative to the parent transform.

[jasperbrooks79]

oh, thank you, I didn't know, sry . . . <3

[aaronfranke]

This has been implemented in godotengine/godot#44198 (not merged yet, awaiting review)

[bluenote10]

This is not well aligned with #1336 which I planned to implement as soon as I find some time.

If you have the time please read that essay ;)

It really should be named translation, because

• This is inconsistent with basically any other transformation library I'm aware of.
• scale and rotate can be used as a verb, position can't, which is awkward from a linguistic perspective and breaks common verb based APIs as explained in Enable transform chaining by making scaled/rotated/translated consistent #1336.
• It is about translating something. Especially when combining transformations it doesn't help to think in "set the position" -- it is much more about "translating" similar to how you scale or rotate the coordinate system.
• Renaming it to position digs deeper into the currently broken semantics of translation handling (which is right multiply, whereas scale/rotate are left multiply, see the linked proposal).

[aaronfranke]

Note that if the 3D term is kept as "translation", then we should rename the 2D one from "position" to "translation". Currently it's inconsistent between 2D and 3D.

[madmiraal]

It is about translating something. Especially when combining transformations it doesn't help to think in "set the position" -- it is much more about "translating" similar to how you scale or rotate the coordinate system.

There is a difference between the property position and the method translate(). This is about changing the name of the property not the method. The property returns the current position of the object. It can also be used to set the current position of the object, but this is different to translate() which changes the position relative to the current position. Making a clear distinction between the two by having different names would probably help reduce this confusion too. I would go so far as to suggest removing the translate(offset) method, which is just a helper method for position = position + offset.

There is no scale() method. If there was, I would expect to do the same i.e. scale the Node relative to the current scale. However, this would not be obvious and cause confusion if they had the same name. Similarly, the fact that the property rotation and the method rotate() refer to different things (one is a set of Euler rotations (YXZ to be specific) the other is a single rotation around a specified axis) remains a source of confusion.

IMHO Most users just want to control a Nodes position, rotation and scale. The fact that these three properties are being collated into a Transform is an engine detail. Therefore, the terminology, the mathematics behind transforms, and the issues discussed in #1336 are, to all intents and purposes, unrelated.

[bluenote10]

There is a difference between the property position and the method translate(). This is about changing the name of the property not the method.

Good point, thanks for clarifying! So this means that godotengine/godot#44198 doesn't really implement this proposal in the sense of "change name of ... in Transforms" but rather "change name of ... in Nodes".

IMHO Most users just want to control a Nodes position, rotation and scale. The fact that these three properties are being collated into a Transform is an engine detail. Therefore, the terminology, the mathematics behind transforms, and the issues discussed in #1336 are, to all intents and purposes, unrelated.

Partially agreed :) It is basically a decision between

1. Should Node and Transform use consistent terminology.
2. Should Node use a simplified terminology to help newcomers.

Personally I would lean towards (1). Regarding Transform it should be clear that we need the verb form translate / rotate / scale. On Node side they reappear in the form of properties. If these properties are called translation / rotation / scale (plus the derived rotation_degrees) it would be clear how they relate to the underlying Transform. Renaming them to position / rotation / scale introduces a minor mismatch, even if "position" may be easier to grasp then "translation". At some point users have to deal with the underlying Transform anyway and then it would help if the property would have been called "translation" to begin with? Personally I would still favor a consistent terminology, but I don't feel strongly about it.

[t-karcher]

If you decide to use a consistent terminology for all nodes (personally, I don't have a strong opinion on that), you should consider renaming rect_position in the Control class as well.

[jasperbrooks79]

what I meant was, a node doesn't or, a point doesn't have a ' Translation ', UNTIL you move it . .

but, it does have a position . . so, the name is less than ideal, and it'd make coding easier to understand, at least in visual script . .

NEW position = OLD position + value . . <3

[jasperbrooks79]

In many 3D programs, the terms translate, scale, and rotate are used, but they don't refer to the ' starting ' value, or current ' place ', they're used meaning, the process of moving, so if a 3D object stands ' still ', even if it's at position 2,3,5 ( x,y,z ), it has ZERO translation . .

however, the visual script node, that MOVES an object or, entity live, should be called ' change position ', or ' translate ' . . so, the name is in a sense wrong, but so often used by 3D programs, that it's a small difference . .

however, when it comes to the engine making sense, when you want to move an objects, having it be ' position ' would make the way you THINK, be same as what the engine is ' written ' like, or so . .

it's about giving the engines names, that work the same way people think, when they SEE a word, so it makes instant or, much more sense <3

translation is, about how much a box IS moving, not how much it HAS moved, so when an object doesn't move, it has zero translation . . it's like position, vs. speed . . if you only know a speed value, at some time, is zero, it's not enough to know, where you are, from the origin . . <3 however, it's a pretty good word, but not technically accurate, or so . .

makes me confused, so there . . . <3

in a word, translate is more like move, or change_position . . it refers to an active process, that changes the position or, coordinate, or ' place ' . . :O Thanks . . and, the word translation doesn't make sense, bec. it refers to an ' before ' and, ' after ' position, but ' translate ' refers to the movement or, process between those or, so <3

so, when it says ' translation 3,5,6 ' in Godot, the object should ' really ' be moving, along that vector, every 1 sec, or so . . it's a small mistake, but it's one I noticed, and might make little difference . . it'd help new coders, use the engine, that's all, and experienced users, might have to ' think ' less, and focus more, on coding the ' deep ' stuff, heavy code, etc . . <3 Thanks . . .

[jasperbrooks79]

I added some stuff to the explanation, but I'm not sure the posters here will see it, unless I make a new comment, but as I learned some people ' follow ' this channel, and get an e-mail every time some posts anything, anywhere, I'll really stop doing this, didn't know <3

Sorry . . </3 . .

ps. I have OCD, some autism, and type funny, also obsess over small details, like words, so on, sry . . .