Potential severe bug in Rn.equals?

Found a bug? Post here.
Post Reply
STRESS
Posts: 141
Joined: Mon 19. Jan 2009, 12:10

Potential severe bug in Rn.equals?

Post by STRESS » Fri 30. Oct 2009, 17:00

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?

STRESS
Posts: 141
Joined: Mon 19. Jan 2009, 12:10

Re: Potential severe bug in Rn.equals?

Post by STRESS » Fri 30. Oct 2009, 19:51

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.).

User avatar
gunn
Posts: 323
Joined: Thu 14. Dec 2006, 09:56
Location: TU Berlin
Contact:

Re: Potential severe bug in Rn.equals?

Post by gunn » Sun 1. Nov 2009, 22:15

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)

Code: Select all

public static boolean isNan(double[] ds) 
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():

Code: Select all

	        if (Double.isNaN(asp)) matrix = Rn.identityMatrix(4);
	        else matrix = CameraUtility.getCameraToNDC((Camera) viewer.getCameraPath().getLastElement(), asp);
Just add the following line:

Code: Select all

  if (Rn.isNan(matrix)) matrix = Rn.identityMatrix(4); 
jReality core developer

STRESS
Posts: 141
Joined: Mon 19. Jan 2009, 12:10

Re: Potential severe bug in Rn.equals?

Post by STRESS » Mon 2. Nov 2009, 12:04

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.
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:

Code: Select all

	        if (Double.isNaN(asp)) matrix = Rn.identityMatrix(4);
	        else matrix = CameraUtility.getCameraToNDC((Camera) viewer.getCameraPath().getLastElement(), asp);
Just add the following line:

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.

Post Reply