Physics Error 3D (RigidBody): Condition "Math::is_nan(v.x)" is true/"Math::is_inf(v.x)" is true. #55458
Comments
|
Edited the original post, I said static body, but I meant rigid body.
from what I can gather from these values (from arrowProjectile.gd), it seems to me the static bodies have launched themselves away from each other so fast that their velocity/translation values could have gotten too big, causing a crash. They rotate alot, and I know other game engines don't appear to handle large rotational velocities well (e.g. Skyrim https://www.youtube.com/watch?v=8aiOR_KuRe4), so it could be the rotation that the projectiles experience. Thus catching high velocities of rigid bodies early should prevent this crash. Honestly i'm not sure how to control the linear velocity of rigid bodies, but I tested this piece of code inserted in arrowProjectile.gd shown below (horrendously inefficient I know)...
edit: above code really should have theoretically been (again needlessly inefficient): I was hoping making it static beforehand would prevent an increase in velocities to a NAN (assumes velocities increases to NAN/inf rather than starting there) Unfortunately, the problem persists, so I could be misinterpreting it. Some code that functions like below does not prevent a crash in larger projects, but will prevent console spam in the projects that don't crash (though at the expense of your rigid body, but it broke anyway). (May also need to remove the child, can't remember if free does that for you) |
Thaniel94
changed the title
|
While it won't be experienced in the minimal reproduction project the cause of the crash in the larger project appears to be caused by an access violation, though the position in the code where it breaks is not consistent. I'm unsure if this error is related to the crash at all, though I suspect it is, as they tend to appear together (though not always, the error in the title does not always cause a crash in the larger projects). Also, in the latest crash at least, an access violation is caused because an array overruns its length trying to find a set of infinite values in a float4 (or at least that's what I interpreted from below. The area in the code where the program crashes and the way it crashes has thus far varied, with the above being 1 of 2 different places (so far), though it has always been an access violation. edit: Another recent variation on the crash in visual studio is not really a crash in that no fatal errror occurs, and the program continues to run (i.e. can press the pause button in the IDE and it will stop at a piece of code), but the game window itself just freezes, as though a crash has occured. |
Godot version
3.4
System information
Windows 10, does not appear graphics related but NVIDEA GeForce GTX 1060 6GB, (GLES2, and GLES3 as far as I know)
Issue description
Note: Error appears similar to: #50450, #32611 (though the circumstances getting to the error seem to differ, so i'm unsure if it's a duplicate)
For larger projects run from the Godot editor this problem has causes me a crash of the Godot project itself (but NOT the editor). The message spams in console for a second, followed by windows problem reporting popping up (followed by windows problem reporting itself stopping working).
Appears to occur when rigid bodies are spawned already intersecting with each other (this could just be terrible practice on my part).
For smaller projects, as discovered when making the reproduction project, it never causes a crash, but still spams the console with the Math::is_nan error until the offending collision object (rigid body) is removed from the scene. I say rigid body only because thats the one I used, don't know about other physics bodies.
When running the project through the 3.4 editor, the error is a Math::is_nan(v.x) error, but when debugged via visual studio, the error is a Math::is_inf(v.x) error.
Another difference with visual studio and the Godot editor is when run via the editor, larger projects crash, while larger projects run via visual studio exhibit the same behaviour as smaller projects, spamming the error in console until the offending object is removed (but without crashing).
Here is the error in full:
ERROR: Condition "Math::is_nan(v.x)" is true.
at: instance_set_transform (servers/visual/visual_server_scene.cpp:691)
(and for visual studio with the code from https://github.com/godotengine/godot/tree/3.4-stable ):
ERROR: Condition "Math::is_inf(v.x)" is true.
at: instance_set_transform (servers/visual/visual_server_scene.cpp:690)
Not sure if it is helpful, but here is the call stack from visual studio when the error is thrown (using Godot 3.4 source code taken from
https://github.com/godotengine/godot/tree/3.4-stable
with scons vsproj):
Steps to reproduce
I have found this 22.9KB project is reliable at getting the error quickly, but ultimately I have found this error is hard to predict, showing up from a few seconds to a few minutes after starting (and this project does not crash. I'm unsure what difference causes the crash in larger projects).
The project is a simple FPS, pan the camera around with mouse movement and click and hold left click to fire projectiles. Keep doing this, with the camera preferably facing upwards (shifting the camera 180 degrees up and down can help).
within the span of a few seconds to a few minutes you should get the error.
ERROR: Condition "Math::is_nan(v.x)" is true.
or
ERROR: Condition "Math::is_inf(v.x)" is true.
if debugging via visual studio.
A visual indication of the bug in game will be the 2 or more colliding projectiles that I have to assume cause the bug floating in the air, unresponsive to collisions.
Press the 'R' key and the scene will reset, removing the offending rigid bodies.
Minimal reproduction project
NANbowminireproducedproject.zip
The text was updated successfully, but these errors were encountered: