godot: Error from get_transform().basis.get_euler() after some play-time
Godot version: Godot 3.0 Stable Official Godot 3.0.1 RC1
OS/device including version: Windows 10 64 bit
Issue description:
When tying an objects rotation to a mouse axis, and calling the rotation euler from get_transform().basis.get_euler.y, the euler will after a while stop sending data and leave errors in the debug window.
Steps to reproduce: Start project linked below in Godot 3.0, F5 to start the game, use mouse to rotate cube. After 10-20 seconds errors will appear in the debugger with every frame, ie. the euler stopped working properly
Full Script failing object:
extends Spatial
var cameraAngle = 0.0
func _ready():
pass
func _input(event):
var cameraY = -event.relative.y
$"../".rotate_x(deg2rad(cameraY))
cameraAngle += cameraY
func _process(delta):
print($"../".get_global_transform().basis.get_euler().y)
This is the error reported traced to the bottom line:
0:00:35:0027 - Condition ' is_rotation() == false ' is true. returned: euler
----------
Type:Error
Description:
Time: 0:00:35:0027
C Error: Condition ' is_rotation() == false ' is true. returned: euler
C Source: core\math\matrix3.cpp:462
C Function: Basis::get_euler_yxz
Additional info: I originally found the issue while developing a character script, this is the very simplified version of the issue.
Minimal reproduction project: Project can be downloaded from here: https://drive.google.com/open?id=1B18k_mjX2-v-RhD1J-szT1q4nccwavJW
About this issue
- Original URL
- State: closed
- Created 6 years ago
- Comments: 41 (36 by maintainers)
I think this is the one. http://docs.godotengine.org/en/latest/tutorials/3d/using_transforms.html
Any updates?
Well that I think is why Godot 3 was refactored to have all floating point values be real_t which is typecast to float. Eventually it can just be typecast to double and voila. Right now there is still far to much in the engine that assumes floats are used I guess. It’ll also break GDNative which is a bit of pain. I’d love to see the switch to doubles.
That is a funny thing though, I started on an old 286 (well I started programming on a TRS-80 but never did any 3D stuff on that). It didn’t have a co-pro I think, or if it had one I didn’t know how to use it, so I could only use CPU based 32bit floating point math which was slow as can be. So a lot of math was forced to be 16bit fixed point math just to get some speed out of the thing. Precision issues galore. Luckily I got a 386 fairly quickly afterwards and learned most using 32bit fixed point math as floating point math was still costly. I never did get as crazy as some of my friends figuring out you could do a measure of parallel processing by carefully ordering your instructions so floating point and fixed point math could run side by side.
Anyways, point is, I don’t remember running into precision issues after leaving those days behind. GPUs and 64bit CPUs that don’t blink at floating point math have made life bliss. What i don’t know is if those days schooled me in naturally picking a programming style that avoids precision errors, or whether the problem isn’t as big as its made out to be 😃 What I do know is that those days taught me to value performance over convenience, something that isn’t always applicable anymore today and a little convenience can go a long way.
I tried to push for a quaternion representation of the orientation part in the Transform (which would mostly eliminate that kind of precision errors because it’s stored as 4 numbers as opposed to 9, and it’s renormalization is just a vector normalization rather than an expensive matrix orthogonolization), but it didn’t take off…