Node.collideWith Returning NaN

Not entirely sure if I’m doing something wrong here or not, but I’m running into a problem where Node.collideWith() is returning NaN.

Vector3f destination = new Vector3f()
Vector3f destNorm = new Vector3f();
Vector3f tempDest = new Vector3f();
mesh.getRandomPointAndNorm(tempDest, destNorm);
enemy.localToWorld(tempDest, destination);

tempDest.y += 50;
Vector3f direction =  destination.subtract(tempDest).normalizeLocal();
Ray ray = new Ray(tempDest, direction);
CollisionResults cr = new CollisionResults();
enemy.collideWith(ray, cr);
if (cr.size() > 0) {
    CollisionResult hit = cr.getCollision();

direction = destination.subtact(origin).normalizeLocal();
ray = new Ray(origin, direction);
cr = new CollisionResults();
enemy.collideWith(ray, cr);
if (cr.size() > 0) {
    CollisionResult hit = cr.getCollision();


9 times out of 10 this works fine, but sometimes the output is:

For the time being I resolved this by putting it in a loop that checks for Float.isNaN() and Float.isInfinity(), but I though I should post this.

I did check and destination is coming up with actual non-infinite numbers before running through the collision checks.

Output of what?

If you put printlns in here showing origin, direction, destination, etc. what do they say?

Seems like you go through a lot of trouble there to get what will amount to Vector3f(0, -1, 0) every time… since the only difference between tempDest and destination is that y += 50.

There’s no output in the actual game, but while trying to track down this bug I added in some printlns, at the bottom of the code I posted you can see what is printed.

Origin is a hard coded vector that is translated from local to world coordinates, there’s nothing wrong with the values there. Destination has appropriate values when printed after translating to world coordinates, but before going through hit detection. After going through the raycasts and hit detection it occasionally comes back with Vector3f(NaN, -Infinity, NaN), but only about 1% of the time, most of the time it comes back with appropriate values.

Origin and destination are never equal values. What I’m doing here is firing a series of six animated lasers at a random point on the target. First I get a random point then, using rays, ensure the point is on top of the target mesh then I cast another ray from the laser origin to see if there’s any part of the mesh between the two points and if so set the destination to the new point.

When I encounter the NaN bug it generally only effects one out of the six shots.

Try checking all of the hits and not just the first one. Also, print values about the hits like which geometry, it’s location, etc… might help track down what is happening.

Also, are you using JME 3.0 or 3.1? I fixed some collision bugs in 3.1 but they were mostly related to flat quads, I think.

I added in the following code for both of the collision checks:

if (Float.isNaN(destination.x) || Float.isNaN(destination.y) || Float.isNaN(destination.z)) {
    int numErr = 0;
    for (CollisionResult h : cr) {
        if (Float.isNaN(h.getContactPoint().x) || Float.isNaN(h.getContactPoint().y) || Float.isNaN(h.getContactPoint().z)) {
    System.out.println("First collision check failed:\n"
            + "Destination.x:  " + destination.x
            + "\nDestination.y:  " + destination.y
            + "\nDestination.z:  " + destination.z
            + "\nOrigin.x:  " + tempDest.x
            + "\nOrigin.y:  " + tempDest.y
            + "\nOrigin.z:  " + tempDest.z
            + "\nDirection.x:  " + direction.x
            + "\nDirection.y:  " + direction.y
            + "\nDirection.z:  " + direction.z
            + "\nCollisions:  " + cr.size()
            + "\nCollision Errors:  " + numErr);

The code on the second collision check is slightly different in that it prints out the information from the origin variable rather than tempDest.

This bug has been in my game for quite a while now, been putting it off because it was a tough one to track down, it’s a silent fail as no errors are printed when this happens, my laser just doesn’t shoot and the attack animation never finishes because it’s waiting forever for one of the lasers to reach its destination plus sometimes I can test for a good hour or more without running in to it while other times I might run into it after just a few minutes of testing. Luckily this time it cropped up right away :slight_smile:

this is the output:

First collision check failed:
Destination.x: NaN
Destination.y: -Infinity
Destination.z: NaN
Origin.x: 269.84305
Origin.y: 49.99059
Origin.z: 105.48227
Direction.x: 0.0
Direction.y: -1.0
Direction.z: 0.0
Collisions: 2
Collision Errors: 2

Interestingly there were two hits and both of them had the same NaN issue. Two of my craft make use of this code, one of them fires six times and the other fires nine times. This was the nine shot craft and out of the nine shots only one of them failed. This particular craft has three laser cannons that shoot so each cannon shoots three times.

I’ve encountered this problem with the other craft as well and it doesn’t appear as though it matters which craft is the target. The Node used for the collideWith check has only one Geometry attached to it in all cases.

I’d be happy to send you one or more of the models I’m using, I used the Blender Ogre exporter and then converted the Ogre XML file to J3o and I am loading the J3o file not the Ogre file.

Currently I am using jME 3.0, I didn’t think it would be such a great idea to upgrade in the middle of this project.

I might add that although this problem has been encountered with all of my spaceship models, one does seem to produce the problem more often than the others, of course that could just be my imagination.

That particular craft is the only one with an armature. The armature has no animations, it is controlled via code and is always in the default pose when being fired upon. I do have hardware skinning enabled, but my video card does not support it so hardware skinning is auto disabled when I run the game. At least I assume my video card doesn’t support it, just says test hardware skinning failed.