What this error means and should I care? ERROR: core/math/basis.cpp:47 - Condition "det == 0" is true

Help
,
1

Godot Version

Godot 4.4 Stable

Question

This keeps printing randomly and even after closing the game, just with the editor opened. Not sure what it means or if I should even care. Also another separate issue I think, when clicking on the errors tab, if there are too many, the entire editor slows down a lot and even crashes sometimes.

godot_issue
godot_issue934Ă—659 110 KB

2

This is not normal and you shouldn’t just ignore it, because it might spiral out into other issues, potentially breaking your project.
Does the problem occur only in just one particular project or every project you open? Try creating a new project and see if the problem persists.
You can also try a newer version of Godot, e.g. recently released 4.5.beta2, to see if that helps with your issue.

1 Like
3

will try this as soon as I can, thanks for the answer. I think it’s only this porject though, worked on another game some time ago on the same godot ver and this did not happen

4

Also I should note it happens kind of randomly, so no idea where to start debugging. Is there a way to know the line that causes an error like this? Normally a script error let’s you go directly to the line, but this is just text with no extra info…

5

It’s not pointing to any of your specific script. The core/math/basis.cpp is an internal engine’s core C++ script. There is no point in you trying to debug it, unless you really know what you’re doing and know how the engine’s core works internally.

6

I see. So my only option would be to keep working normally, and whwnever this happens again, just try to remember exactly what I did on the game?

7

AFAICT this is an error in the godot engine, not your project (but it’s still concerning because e.g. I don’t ever get this error. So your project or environment is interacting badly somehow).

You can find the line at godot/core/math/basis.cpp at master · godotengine/godot · GitHub

There are instructions somewhere in the godot documentation on how to build the whole project, if you feel so inclined to jump into a deep debug session. Ofc this will be harder b/c it happens randomly, but maybe setting a simple breakpoint there would be sufficient to figure things out?

1 Like
8

Thank you! Will take a look.

9

It’s complaining that some basis (or something with a basis component, like a Transform3D) you handed Godot has a determinant that’s zero. That’s almost certainly not what you want. It means your basis isn’t invertable and definitely not orthonormal. It probably also means at least two of the vectors in your basis are parallel.

From a use point of view, it means whatever gets transformed by that basis is going to be glitchy/screwy at best, if it draws at all.

So, I think somewhere you’re handing Godot some bad data.

10

Looking at the line that’s failing (47) it is in this code:

void Basis::invert() {
	real_t co[3] = {
		cofac(1, 1, 2, 2), cofac(1, 2, 2, 0), cofac(1, 0, 2, 1)
	};
	real_t det = rows[0][0] * co[0] +
			rows[0][1] * co[1] +
			rows[0][2] * co[2];
#ifdef MATH_CHECKS
	ERR_FAIL_COND(det == 0);  ##### <-- Line 47 #####
#endif
	real_t s = 1.0f / det;

	set(co[0] * s, cofac(0, 2, 2, 1) * s, cofac(0, 1, 1, 2) * s,
			co[1] * s, cofac(0, 0, 2, 2) * s, cofac(0, 2, 1, 0) * s,
			co[2] * s, cofac(0, 1, 2, 0) * s, cofac(0, 0, 1, 1) * s);
}

So it is definitely an invert operation that is failing. Props to @Ryan_Flynn for going to look that code up for you.

Bugs are never random. If they appear random it is because you don’t have enough information. I’m working on the assumption this is a 3D game because of the invert function called that looks like it is dealing with a Vector3. With what we have, there are a few pieces of information to help us look:

  1. The fact that it’s happening in your editor “randomly” means that you have a real easy way to track this down. It’s happening in one of your scenes. Specifically, one of your scenes that does transforms, and that those transforms are setup to happen by default - which points to an idle animation. Close all your scenes. Clear your Output window. Open each 3D scene that has any kind of animation, one by one, closing each one before moving onto the next. When errors pop up, you’ve found your culprit(s). You can use the next two items to help narrow down the problem.
  2. An invert operation is being run using a basis that is equal to zero. Assuming this is a 3D game, you should start by looking for Vector3.ZERO using Ctrl+Shift+F in your entire codebase, and see if any uses of that are causing your problem. If the first step helped you narrow it down, you can just use Ctrl+F to keep it in the active script
  3. As @hexgrid pointed out, this could be a transform somewhere in your code. Again, looking for something where a Vector3 is zero, you might look to see if any of your transforms are multiplying a Vector3 by a float value that is in fact zero when you expect it to be something else.
  4. This could be in an animation player somewhere, if you are moving things around. In which case, you’re going to have to look for zeroes in it. Unfortunately, this is not so easy to do.
1 Like
11

Thanks a ton for this detailed answer. Will try this as soon as I can and report here the results. Even if I fix this, is the bazilion error spamming a normal behaviour? Maybe the fact it keeps printing when the game is not running is a hint it could be on a @tool script? Also the lag and sometimes crash that happens when opening the errors tab (when there are a lot of errors) is also normal/known? I ask this to know if I should report/let someone know on github or something.

1 Like
12

Yes. All programming languages do that. When an error happens, it is reported. Your error is happening a LOT. Once you fix it, all the errors will go away. If they don’t, that means it’s in a second place.

It could be, but it doesn’t have to be necessarily. I worked on a commercial game where every time I checked in code, the player.tscn file would have changes in it if I even opened it. Turned out, that was because whoever set it up had it the idle animations which were 2D inverse kinematics (IK) running by default. So whenever I saved the project, every part of the player was in a different place. So I always had to reset that file. This is why I think it could be an idle animation.

That’s a problem with your RAM and not Godot. Basically Godot is just reporting the errors, and there are so many that you are running out of RAM and seeing slowdowns and crashes. someone with twice the RAM you have may not even notice it with the same code.

The real issue goes back to what you said in your original post:

You should always care if there is an error. Warnings can be ignored (at your own peril), but Errors should always be dealt with. It could make your game unplayable for people with less RAM or a smaller GPU than you have.

Again, from your original post:

This isn’t a separate issue. Because if the errors aren’t happening, you won’t experience this. An error means your are virtually guaranteed of having problems in your code.

It is always best practice to address all errors and warnings as soon as they appear. Otherwise your output becomes so overrun with red and yellow that you end up with error blindness, and when new ones appear, you can’t see them. This will result in even more bugs, and more frustration in tracking them down.

1 Like
13

Okay just checked and it happens whenever I open the player scene, so practically sure it’s an animation… what i’m not sure is how exactly this error could be happening… I have a lot of bone attachment nodes, maybe related? Ans if it’s setting the scale to zero on an animation, I assume I’ll have to look all keyframes one by one? But even so it would be an engine issue and not bad practice or similar right? Thanks for the detailed answer btw, really helpful

1 Like
14

Okay I found the isse. Not only that, but it’s eassy to recreate. Just add a 3d decal and set scale to 0. outpu goes crazy. Should I create a github bug report, or maybe it’s already known?

1 Like
15

That’s not necessarily a bug. If you want something to not be visible, you should set it to visible = false. However, if you feel it’s a bug, log it and they will let you know. My guess is since you’re getting an error, it may be intended behavior. Basically you’re flooding memory with objects that don’t exist. Basically it’s a potential memory leak.

If you want the scale to be 0, just call queue_free() on it.

1 Like
16

Well imo this is clearly a bug… but I just tried and it actually happens with all the nodes I’ve tried. Is this really intended?

17

Like I said, log it, see what happens. I honestly can’t say if it’s a bug or not. Which is why I suggested you log it if you feel strongly about it.

Yes.

So here’s the thing: Error messages just don’t happen. They appear because someone programmed them to happen when a developer does something they shouldn’t.

This code was in the Godot Engine code. It’s not a bug with the C++ compiler. It’s an ifdef, which means someone very clearly put it in there to trigger in case someone does something like this. In this case, a transformation to a scale of zero can cause problems - so it’s not allowed.

It’s probably not allowed because it can lead to a divide by zero error, and that is a C++ compiler issue. Because you cannot divide things by zero. But I’m just guessing. There could be other issues.

So, I suggest if you feel that something should be given a scale of zero, you write up a the bug, or a feature request and see what happens. It is possible that this is old code, and if you were to highlight it, someone might have a solution now that wasn’t added when the code was originally made. Because I checked and that particular line of code was written 12 years ago - before the engine was even open source.

1 Like