Got it: intersect assumes that the direction of the Ray is normalized. Which is not the case in HelloMousePick (and e.g. my application). I checked in a hotfix which does a normalize() in intersect, but that's not very nice (as it creates a Vector3f). What should we do to assure the direction is normalized? Or should it be up to the application? I would suggest adding a normalizeLocal() to the setDirection method and demand in the JavaDoc that the direction should be normalized as apps could do getDirection().set( something ).

I would definitely agree that the picking javadoc should say that the given ray must have a normalized direction.  As for enforcing that in setDirection though, I don't really agree because it is enforcing behavior on something that is meant as a general purpose math object.

agree, don't wanna force something that costly on people…

So you mean the apps should care for it themselfes - meaning HelloMousePick (and all possible other tests) shoud be altered not the intersects method and it should work with boxes but not with spheres?!?

i would like it that way since in many cases you can use a vector that only needs to be rotated and get away with never having to normalize…

Yeah, lets change it back and make it clear in javadoc that the incoming ray should be normalized.  This is also better anyhow because when a ray is tested against lots of boundings, it can be normalized once by the app and not once per bounding

ok, that's true - I will change it back and go through methods using it and adapt the doc tomorrow.

grrrreat, nice work finding the bug!

committed :slight_smile: