[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: Debugging desaster
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.