[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

*To*: linuxgames@xxxxxxxxxx*Subject*: Re: Debugging desaster*From*: Gregor Mückl <GregorMueckl@xxxxxx>*Date*: Mon, 6 Jun 2005 02:52:49 +0200*Delivered-to*: archiver@seul.org*Delivered-to*: mailing list linuxgames@sunsite.dk*Delivery-date*: Sun, 05 Jun 2005 20:50:34 -0400*In-reply-to*: <42A387D1.1070307@airmail.net>*Mailing-list*: contact linuxgames-help@sunsite.dk; run by ezmlm*References*: <200506050332.26283.GregorMueckl@gmx.de> <42A387D1.1070307@airmail.net>*Reply-to*: linuxgames@xxxxxxxxxx*User-agent*: KMail/1.8.1

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

**Follow-Ups**:**Re: Debugging desaster***From:*Steve Baker

**References**:**Debugging desaster***From:*Gregor Mückl

**Re: Debugging desaster***From:*Steve Baker

- Prev by Author:
**Debugging desaster** - Next by Author:
**Re: Debugging desaster** - Previous by thread:
**Re: Debugging desaster** - Next by thread:
**Re: Debugging desaster** - Index(es):