Restore rotation_degrees or provide deg_to_rad(Vector*)

[TokisanGames]

Godot version

4.0alpha12+

System information

Win 10/64 NVIDIA GeForce GTX 1060/PCIe/SSE2

Issue description

Core Issues

• Many of us used rotation_degrees in our code and AnimationPlayers. It was removed for no good reason. Please restore it.

• The Inspector and code use different units for the same rotation variable. (?!)

The engine devs clearly understand that game devs wish to use degrees, because they provide degrees in the inspector. In fact it's the only option. Yet in code we can only work with radians, as rotation_degrees was removed.

It's crazy to use rotation in the inspector with degrees, while rotation in code works in radians. Any experienced game dev is going to be working with rotations in both the inspector and code. Virtually no one is going to use only one.

Radians and degrees are currently both implemented in the engine, so there is absolutely no savings of code or memory by neutering the API. At best, there are a few less lines on the manual page.

This choice has broken our animationplayers, forced us to rewrite our code, and manually convert degrees, and leaves the engine in a weird state where we use two different units for the same variable.

Please give us back the two variable syntactic sugar of rotation(radians) and rotation_degrees. Or if you want to drop one, drop radians. Or find another solution, such as below, but using two different units for rotation is nuts.

Alternative

Rotation, like all transform options are commonly updated frequently, every frame, on potentially thousands of objects. There is a deg_to_rad(float) function, but no Vector* variations.

This means for those of us who want to work in degrees in 3D, we must deconstruct a Vector3, convert each component, then reconstruct the Vector. This is unnecessarily slow in GDScript, every frame, on thousands of objects, when it could be done in C++ (especially since the code is already there).

As an alternative to the above:

• Please provide deg_to_rad(Vector2/3/4) variations (and rad_to_deg) so we can convert in C++ rather than GDscript.
• Convert AnimationPlayer animations by renaming rotation_degrees to rotation. The values are the same since the editor works in animations only. See 3.x to 4.0 converter does not convert rotation_degrees property of animations #65481.

Or maybe we do everything: restore rotation_degrees, make the code and inspector function the same way, and provide deg_to_rad(vector) and convert animation tracks. I haven't heard a single good reason for neutering the API. And I've experienced and heard of a lot of pain from devs as we fix things that unnecessarily broke.

Related to #58316, but that's an editor issue.

Steps to reproduce

# Unnecessarily slow:
node.rotation = Vector3( deg_to_rad(new_deg_rotation.x), deg_to_rad(new_deg_rotation.y), deg_to_rad(new_deg_rotation.z) )

# Should be:
node.rotation_degrees = new_deg_rotation
# or
node.rotation = deg_to_rad(new_deg_rotation) 

Temporary Workaround

Fine for limited use, but not optimal for updates on many objects every frame.

# Util.gd
static func d2r(vect: Vector3) -> Vector3:
	return Vector3( deg_to_rad(vect.x), deg_to_rad(vect.y), deg_to_rad(vect.z) )

# Called like:
node.rotation = Util.d2r(new_deg_rotation)

[Calinou]

Out of curiosity, why aren't you working with radians directly within your own code? The TAU constant makes this easy, as 1 tau is equal to 1 full turn (360 degrees).

[TokisanGames]

Perhaps I am projecting, but I believe the general case is that some people will be working with degrees on thousands of objects on a per-frame basis.

This is supported by Godot itself, as the editor only supports degrees and continues to train users to use it. #58316. You already have the conversion currently implemented in the engine in C++. Why not expose it again?

In my current case, I'm porting 30k lines of code and a thousand scenes to Godot 4 (far from automatic). The one class I've come across so far is not a per-frame usage. It is a weapon offset that takes degrees from a user variable and applies it upon equiping. In my player script, I'm working with Basis. In my enemy scripts I think we're mostly working with rotation_y. So I've got different usages all over and I've only just started scraping the surface. I'm mostly working in radians, but every hard-coded usage has to have a comment to translate it into degrees because radians suck. eg.
if angle >= 2.6: # 150 degrees

[logzero]

if angle >= 2.6: # 150 degrees

How many such magic numbers do you have in your code. Might be worth defining them somewhere, give them proper names. What does 150 degrees mean here?

[TokisanGames]

When the player is idling and the input direction is greater than 150, she plays a 180 degree turning animation before walking. When the input direction is less than that but greater than 70, she plays a 90 degree turning animation.

There are hardcoded thresholds all over. Slope distance, delays, focal length, etc. Most are consts or export var if multiple use. Single use may or may not get a const.

[fire]

I support creating deg2rad that works on real_t, vector 2, vector 3 and vector 4.

[TokisanGames]

I ran into another issue with this today. Because rotation_degrees was available in 3, I created an animation that uses it for at least two assets. Now those animations are broken and need to be recreated.

[Zireael07]

@tinmanjuggernaut Same issue here, no conversion it seems :(

[sketchyfun]

Old animations that use rotation_degrees (I have a lot of those in my game) are also broken and left unconverted. I'd definitely like to see rotation_degrees brought back.

[Calinou]

Old animations that use rotation_degrees (I have a lot of those in my game) are also broken and left unconverted. I'd definitely like to see rotation_degrees brought back.

Instead of readding a legacy property, I think the better solution is to make the 3to4 converter handle rotation_degrees animation tracks.

cc @qarmin

[akien-mga]

Old animations that use rotation_degrees (I have a lot of those in my game) are also broken and left unconverted. I'd definitely like to see rotation_degrees brought back.

Instead of readding a legacy property, I think the better solution is to make the 3to4 converter handle rotation_degrees animation tracks.

I agree that the property conversion could/should be done.

But there's still merit in discussing whether the current situation for using degrees in script can be improved. I was never really convinced by @reduz's strong belief that we should expose degrees in the inspector ("for artists") and radians in code ("for programmers") and that somehow handling it all automagically would be the best situation.

Adding more flexibility to deg2rad and making sure that it doesn't incur a significant performance cost would be a good option. Or readding a script-only rotation_degrees indeed, though the main issue here is that there are many other properties which take radians and adding proxies for all of them is a bit of a hassle and documentation bloat.

[Zireael07]

Animations are the most egregious case being broken currently, but I find myself using degrees in code fairly often (especially for things that are exported, since it's easier to change 50 to 60 than to remember however many radians that is...)

[TokisanGames]

rotation_degrees is literally already implemented in the engine. #58316 It only needs to be exposed. There is no code savings by not having it as you're already providing it to inspector users, but not animationplayer users or coders.

Providing both for artists and coders is a good choice. Providing only one depending on the interface, or handling things automagically is the worst choice. How many of you enjoy it when Windows or Apple products make choices for you or try to be smarter than you?

I think extending deg2rad would be worth doing, and would hardly take any code, but I understand if it isn't wanted. It's probably not necessary with rotation_degrees exposed.

Putting an animation player conversion in the conversion tool is nice in theory, but it's useless if the tool is not bulletproof. I tried to use it only to find it broke immediately and converted nothing. I'm now using a modified version of Aaron's script for renames and manually converting and testing everything a section at a time. I find that a standalone script is far superior, because it's adjustable in realtime, and I can use it to convert only certain directories or files at a time. And I can revert changes with git and reconvert as I make adjustments to the script or other testing. Working with an immature, built in compiled tool that's only updated on every alpha release doesn't help me at all. I think you guys should consider going the script route since you've made so many changes to the engine and haven't identified them all.

[TokisanGames]

I ran into another case of this today. I have meshes that I've visually adjusted rotations in the editor. I took those settings and hard coded them as defaults and clamped values in code. But in GD4 the editor uses only degrees, and the code only uses radians. So on top of copying one square at a time, I also have to manually convert degrees to radians. Doesn't that seem like a crazy process?

Also discussing with one of my experienced 3D artists today and he didn't even know what radians are. I expect many other new coders will be in the same situation. Not supporting degrees in code is a big mistake.

Out of curiosity, why aren't you working with radians directly within your own code? The TAU constant makes this easy, as 1 tau is equal to 1 full turn (360 degrees).

Tau doesn't help with this. It's a manual conversion.
e.g.

	eye_r.rotation_degrees = Vector3(-37, -25, -23)
	eye_l.rotation_degrees = Vector3(-37, 25, 23)
        ...
	eye_r.rotation_degrees.x = clamp(eye_r.rotation_degrees.x, -45, -13)
	eye_r.rotation_degrees.y = clamp(eye_r.rotation_degrees.y, -75, 7)