Re: Debugging desaster

[Gregor Mückl <GregorMueckl@xxxxxx>]

On Monday 06 June 2005 01:16, Steve Baker wrote:
> Gregor Mückl wrote:
> > The
> > getCameraRay function should produce a starting point and a ray direction
> > for a ray emerging at the camera position in 3d coordinates and going
> > through the point that the user selected in the 2d projection n screen.
> > This function fails as soon as the view gets rotated.
>
> When you say 'fails' - does it core-dump or just produce bad results?
>

It produces bad results - a crash would be far more trivial to debug :-)

> Assuming it just produces bad results - then in all likelyhood, it is
> one of two things:
>
> * You are concatenating matrices in the wrong order (this works just
>    fine when all you have are translations - but screws up badly when
>    you rotate).
>

I'm sure that this is not an issue (I did have a couple of bugs related to 
that, but once I found one I did a complete review).

> * You are somehow creating your matrix from Euler rotation angles
>    and you are concatenating those rotations in the wrong order.
>    Once again, things would only go wrong when you rotated...but this
>    error tends to be more subtle because rotating around any ONE axis
>    would work - and rotation about two or more axes would produce
>    subtle errors for small angles of rotation that grow rapidly as
>    the angles get larger.
>

Hm... I only see the deviation when I start to rotate the camera around the 
local x- and y-axes. rotations around the local z-axis are fine as are 
translations along all three axes.

This is quite close to what I actually see here. But I'm not usin Euler angles 
to construct the full modelview matrix. I'm converting mouse movements to 
angles in camera-local coordinates and construct rotational matrices from 
them, which I then multiply with existing modelview matrix to get the new 
one. Even after a couple of rotations and translations the result is 
remarkably stable and deviates little from a perfectly orthogonal matrix.

But you will probably tell me now that this doesn't do the trick.

> Have you looked at the source code for gluUnproject from (say) the
> Mesa sources.  It does something very close to what you describe and
> might serve you better than writing your own code.
>

Actually, I did look at gluUnproject from the beginning and my implementation 
is functionally almost identical. Only the matrix inversion uses a different 
algorithm. The algorithm I use passed all tests I did with it so far. But I 
begin to doubt it's correctness again, although results seem to vary only by 
about 1% at the moment (which indicates a numerical stablilty issue somewhere 
in the algorithm I use). 

Anyway, the bug still shows when using gluUnproject, which doesn't help me at 
all for a change. I'm really running out of ideas about what to check next.

Yesterday I didn't properly point out the position of the Moonlight sourcecode 
in my repository which has grown quite a bit over time already. The correct 
URL is http://www2.futureware.at/svn/gregor/Moonlight. Well, I shouldn't 
write emails at 4 o'clock in the morning when I'm about to fall asleep in 
front of the keyboard.

Regards,
Gregor