Am using Jme on Android. While testing gameplay on emulator the following error was thrown. The error is not consistent and hence difficult to catch it.IAll calls are in single thread and material used is built in Lightning.j3md no custom shaders/nodes
Are you testing 3.7.0-beta1. That happened to me as well. See jMonkeyEngine v3.7.0-beta1 release - #12 by richtea
But the assertions are new in 3.7.0-beta1 so it is possible that we have both been doing something wrong this whole time and JME has only just noticed now. It is very intermittent for me as well so my attempt to find where it has been coming from hasn’t been very successful
1 Like
As mentioned in that other thread, things to look for are some spatial’s position of rotation going to NaN. Common causes are things like divide by zero, etc… (Honestly, every time I’ve had this happen it was because of a divide by zero somewhere so I’m having trouble thinking of different examples.)
In my case, divide by zero often comes up when I do something with the distance between two objects or two positions and forget to handle the zero case (ie: when the positions are equal)
Edit: I half remember there could be other cases where direction math is done on quaternions that 180 degrees from each other… like trying to nlerp two quats that are exactly opposite.
Or trying to get the cross product of two vectors that point in the same direction… like when doing lookAt() and passing UNIT_Y as the up vector by the direction to look is also straight up.
4 Likes
I think this is bug in MY code as @pspeed said its mostly divide by zero error.Though I was unable to recreate error in gameplay ,so i try to intentionally create some of above situtation as @psspeed mentioned and it seems that error is in using kotlin built in acos() function the parameter passed should lie within +/-1 so my value might have slipped above it and acos return NAN. I am using it to simulate my own custom align to dir method
Thank You all for yor quick response and sorry for late response from my side.
2 Likes
As a note: it’s very strange to have to use acos() for anything game-logic related. There may be a better way to do what you are doing with it.
As this is probably going to come up a lot is there anything wrong with me adding some assertions into the Transform classes setters? They’ll be asserts only so no production performance implications (and probably not much development performance implications compared to all the setTransformRefresh stuff that gets triggered along with it). I can’t think of a case where a NaN or infinite translation, rotation or scale would be a valid thing to set
1 Like
I’ve created a PR at #2275 Improve assertions for invalid transforms. by richardTingle · Pull Request #2276 · jMonkeyEngine/jmonkeyengine · GitHub
1 Like
Transform maybe… but the problem is usually earlier on in a quaternion or vector3f… and there it’s a little sketchy. NaNs are valid results for bad math… and some code might check for their bad math by letting the values go to NaN and checking those.
Like, there is a reason NaN and Infinity exist… so there may be good reasons that Vector3f(Nan/Infinity) exist. And possibly Quaternion.
Edit: I see your PR (snuck in right before I hit enter) only messes with transform.
1 Like
Yeah, that’s why I didn’t want to mess with Vector3f or Quaternion (even though that would give an even better view of where the problem came from).
The setter on the spatial will at least give a small area to search for problems (and clues where to add user code level asserts) rather than the GLRenderer one which just says there is a problem somewhere
2 Likes