I am tracking down a really weird bug in that why sometimes tools that use picking functionality are not working after hours of tracking where the problem is relating from I managed to track it down that there are at some stage NANs in the CamToNDC matrix. Probably at the stage when the whole scenegraph gets set up and then they stay in there. I tried to find out where the matrix actually gets generated and I noticed that in updateImplicitDevices in DeviceManager.java the CamToNDC matrix gets build. Now it seems to me that for a few intervals there are actually NANs in matrix element 0 and 3 I guess because the camera or the components are not fully there yet but then they get replaced with real numbers but the CamToNDC matrix still does not get updated!
It looks to me that Rn.equals doesn't notice a difference, could that be?
Potential severe bug in Rn.equals?
Re: Potential severe bug in Rn.equals?
Okay I had a look at Rn.equals and I definitely must say it isn't robust enough it will fail through if any of the matrices that get compared have an element that has one of the special IEEE numbers (Inf, -Inf, NaN, etc.).
Re: Potential severe bug in Rn.equals?
Hmmm... it could indeed be that equals doesn't handle those special values correctly.
Until now there has not been any problems with not-yet-initialized values in CamToNDC matrix causing this failure.
One method you could try to help debug the problem is the method (in Rn)
which returns true if any entry is NaN (i.e., Double.isNaN(x) returns true). You could use this
to tell when you're working with a bad camToNDC matrix.
You could also combine it with the
existing code in DeviceManager.java to just skip over bad matrices. Here's the code there now in updateImplicitDevices():
Just add the following line:
Until now there has not been any problems with not-yet-initialized values in CamToNDC matrix causing this failure.
One method you could try to help debug the problem is the method (in Rn)
Code: Select all
public static boolean isNan(double[] ds)
to tell when you're working with a bad camToNDC matrix.
You could also combine it with the
existing code in DeviceManager.java to just skip over bad matrices. Here's the code there now in updateImplicitDevices():
Code: Select all
if (Double.isNaN(asp)) matrix = Rn.identityMatrix(4);
else matrix = CameraUtility.getCameraToNDC((Camera) viewer.getCameraPath().getLastElement(), asp);
Code: Select all
if (Rn.isNan(matrix)) matrix = Rn.identityMatrix(4);
jReality core developer
Re: Potential severe bug in Rn.equals?
I imagine that, the problem is mostly down to how the Eclipse RCP framework works. It is all lazy initialization which sometimes can cause bizarre side effects if you are not careful. My guess is that the NDC coordinates are screwed because the underlying component's size hasn't been set yet.gunn wrote:Hmmm... it could indeed be that equals doesn't handle those special values correctly.
Until now there has not been any problems with not-yet-initialized values in CamToNDC matrix causing this failure.
gunn wrote:Just add the following line:Code: Select all
if (Double.isNaN(asp)) matrix = Rn.identityMatrix(4); else matrix = CameraUtility.getCameraToNDC((Camera) viewer.getCameraPath().getLastElement(), asp);
Code: Select all
if (Rn.isNan(matrix)) matrix = Rn.identityMatrix(4);
Hmm that's a not a bad idea I did upgrade Rn.equals to make it more robust.