 | | | | | | |
| |
|
Hey, does anybody out there know the origin of the "Oblique",
"UpsideDown", and "Natural" viewing matrices in LDRAW.INI. I'm not
sure whether these came from LDAO, LDLITE, or perhaps even LDRAW?
Wherever they came from, they don't seem to be pure rotation matrices
fit for a viewing transformation. When I multiply one of these with
another rotation matrix the model starts to look sheared. Is there a
projection transform in there or are they just plain wrong? I believe
someone previously mentioned that there was something unusual about
these matrices but I can't remember what.
Anyways, the point is I finally got that pesky mouse-drag model
spinning trick to work in ldglite but I had to replace these three
view matrices to do it.
Also I noticed at one point that L3LAB seemed to shear the model
sometimes during spinning. Does/Did it perhaps use the view matrices
from LDRAW.INI as well?
Here are the original matrices.
Oblique=1,0,1,0.5,1,-0.5,-1,0,1
UpsideDown=-1,0,1,-0.5,-1,-0.5,1,0,0
Natural=0.625,0,1.075,0.5375,1.25,-0.3125,-1.25,0,2.5
Here are the replacement matrices.
Oblique=0.707104,0,0.707104,0.353553,0.866025,-0.353553,-0.612372,0.5,0.612372
UpsideDown=0.707104,0,0.707104,-0.353553,-0.866025,0.353553,0.612372,-0.5,-
0.612372
Natural=0.5,0,0.866025,0.433013,0.866025,-0.25,-0.75,0.5,0.433013
My Oblique matrix is a 45 degree rotation about y followed by 30 about x.
My UpsideDown matrix is a 45 degree rotation about y followed by 210 about x.
My Natural matrix is a 60 degree rotation about y followed by 30 about x.
Don
| | | | | | | | | | | | | | | | |
| |
|
Don Heyse <dheyse@hotmail.spam.go.away.com> wrote:
> Wherever they came from, they don't seem to be pure rotation matrices
> fit for a viewing transformation. When I multiply one of these with
> another rotation matrix the model starts to look sheared.
I don't know their origin, but you're right, there's a shear component in
them. Here's what a matrix decomposition shows:
> Oblique=1,0,1,0.5,1,-0.5,-1,0,1
Scale : (1.5, 0.942809, 1.41421, 0)
Rotate : (0.321751, 0.729728, 0.463648, 0)
Translate : (0, 0, 0, 0)
Shear : (0.353553, -0.117851, -0.333333, 0)
> UpsideDown=-1,0,1,-0.5,-1,-0.5,1,0,0
Scale : (1.5, 0.942809, 0.707107, 0)
Rotate : (-0.321751, -0.729728, -2.67795, 0)
Translate : (0, 0, 0, 0)
Shear : (0.353553, -0.707107, 1, 0)
> Natural=0.625,0,1.075,0.5375,1.25,-0.3125,-1.25,0,2.5
Scale : (1.49734, 1.16669, 2.07954, 0)
Rotate : (0.622665, 0.987793, 0.710271, 0)
Translate : (0, 0, 0, 0)
Shear : (0.384604, -0.841771, 0.162744, 0)
(Note for purists: I'm not even sure I used the right matrix orientation to
get the above results, but there's a shear component in there either way.)
I look forward to the next update of ldglite - very useful program!
Steve
--
Barb & Steve Demlow | demlow@visi.com | www.visi.com/~demlow/
| | | | | | | | | | | | | | | | | | | | | |
| |
|
I knew there was a way to decompose the matrices! But I couldn't find it.
Where is that written down? I also thought there was a way to remove the
cumulative round off errors in a transformation matrix after many matrix
multiplications. Do you happen to know how to do that as well?
It's been such a long time, I've forgotten way too much of this stuff.
Don
PS. I might do a new ldglite release this weekend. Lots of bug fixes
and I tried to add some more of the missing ldlite features.
In lugnet.cad.dev, Steve Demlow writes:
> Don Heyse <dheyse@hotmail.spam.go.away.com> wrote:
>
> > Wherever they came from, they don't seem to be pure rotation matrices
> > fit for a viewing transformation. When I multiply one of these with
> > another rotation matrix the model starts to look sheared.
>
> I don't know their origin, but you're right, there's a shear component in
> them. Here's what a matrix decomposition shows:
>
> > Oblique=1,0,1,0.5,1,-0.5,-1,0,1
>
> Scale : (1.5, 0.942809, 1.41421, 0)
> Rotate : (0.321751, 0.729728, 0.463648, 0)
> Translate : (0, 0, 0, 0)
> Shear : (0.353553, -0.117851, -0.333333, 0)
>
> > UpsideDown=-1,0,1,-0.5,-1,-0.5,1,0,0
>
> Scale : (1.5, 0.942809, 0.707107, 0)
> Rotate : (-0.321751, -0.729728, -2.67795, 0)
> Translate : (0, 0, 0, 0)
> Shear : (0.353553, -0.707107, 1, 0)
>
> > Natural=0.625,0,1.075,0.5375,1.25,-0.3125,-1.25,0,2.5
>
> Scale : (1.49734, 1.16669, 2.07954, 0)
> Rotate : (0.622665, 0.987793, 0.710271, 0)
> Translate : (0, 0, 0, 0)
> Shear : (0.384604, -0.841771, 0.162744, 0)
>
> (Note for purists: I'm not even sure I used the right matrix orientation to
> get the above results, but there's a shear component in there either way.)
>
> I look forward to the next update of ldglite - very useful program!
>
> Steve
| | | | | | | | | | | | | | | | | | | | | | | |
| |
|
Don Heyse <dheyse@hotmail.spam.go.away.com> wrote:
> I knew there was a way to decompose the matrices! But I couldn't find it.
> Where is that written down?
It's from Graphics Gems II, the code for which is available online (linked
from http://www.acm.org/tog/Software.html ).
> I also thought there was a way to remove the
> cumulative round off errors in a transformation matrix after many matrix
> multiplications. Do you happen to know how to do that as well?
That's called (re-)orthogonalization. Graphics Gems I has code to do it.
You might also reconsider whatever it is that's causing the matrix to become
nonorthogonal. In the case of arcball-type rotation you can:
1. Store the current transform matrix M when the rotation begins
2. Store the initial arcball conditions (cursor location, etc.)
3. For each mouse movement, compute the transform M' from the original
location to the current one - that is, don't use incremental updates
4. Multiply M and M' to get the rotated transform, and apply it to the object
5. When done, update M to M * M'
I've been using the Gems arcball code in this manner for years and have
never had to deal with orthogonalization.
> PS. I might do a new ldglite release this weekend. Lots of bug fixes
> and I tried to add some more of the missing ldlite features.
Cool!
Steve
--
Barb & Steve Demlow | demlow@visi.com | www.visi.com/~demlow/
| | | | | | | | | | | | | | | | | | | |
| |
|
I believe the matrix happens to produce a standard isometric view, but
doesn't do so in the traditional 3D graphics way of rotation. This means
that in addition to not looking right after rotation, it also doens't
produce correct results when you apply a perspective projection to it
(AFAIK). The others most likely also produce "standard" projections
visually, but don't necessarily represent something that is possible in the
real world.
The default matrix I use in LDView is equivalent to your oblique one (but
for some odd reason, with rows/columns swapped, assuming you wrote your
matrices in the same order that LDRAW expects, ie column major). I actually
had a difficult time getting the model rotated around to this angle.
If anyone cares about maximum accuracy, the irrational numbers in the matrix
are:
.707104 = sqrt(2) / 2
.353553 = sqrt(2) / 4
.866025 = sin(pi / 3)
.612372 = sqrt(1.5) / 2
--Travis Cobbs (tcobbs@san.REMOVE.rr.com)
"Don Heyse" <dheyse@hotmail.spam.go.away.com> wrote in message
news:G1ws1M.1ty@lugnet.com...
> Hey, does anybody out there know the origin of the "Oblique",
> "UpsideDown", and "Natural" viewing matrices in LDRAW.INI. I'm not
> sure whether these came from LDAO, LDLITE, or perhaps even LDRAW?
> Wherever they came from, they don't seem to be pure rotation matrices
> fit for a viewing transformation. When I multiply one of these with
> another rotation matrix the model starts to look sheared. Is there a
> projection transform in there or are they just plain wrong? I believe
> someone previously mentioned that there was something unusual about
> these matrices but I can't remember what.
>
> Anyways, the point is I finally got that pesky mouse-drag model
> spinning trick to work in ldglite but I had to replace these three
> view matrices to do it.
>
> Also I noticed at one point that L3LAB seemed to shear the model
> sometimes during spinning. Does/Did it perhaps use the view matrices
> from LDRAW.INI as well?
>
> Here are the original matrices.
> Oblique=1,0,1,0.5,1,-0.5,-1,0,1
> UpsideDown=-1,0,1,-0.5,-1,-0.5,1,0,0
> Natural=0.625,0,1.075,0.5375,1.25,-0.3125,-1.25,0,2.5
>
> Here are the replacement matrices.
Oblique=0.707104,0,0.707104,0.353553,0.866025,-0.353553,-0.612372,0.5,0.6123
72
UpsideDown=0.707104,0,0.707104,-0.353553,-0.866025,0.353553,0.612372,-0.5,-
> 0.612372
> Natural=0.5,0,0.866025,0.433013,0.866025,-0.25,-0.75,0.5,0.433013
>
> My Oblique matrix is a 45 degree rotation about y followed by 30 about x.
> My UpsideDown matrix is a 45 degree rotation about y followed by 210 about • x.
> My Natural matrix is a 60 degree rotation about y followed by 30 about x.
>
> Don
| | | | | | | | | | | | | | | | | | | | | |
| |
|
OK now we're getting somewhere. Thanks for providing the exact mathematical
representations of those numbers. Now I'm gonna have to figure out how you
calculated them. :-) (I just had the computer do the work and print out the
decimal representations)
But we still don't know where those "oblique" numbers came from and what
they're supposed to represent. Should I even bother with them for
compatibility?
By the way, the row-column order for the matrix came straight out of ldraw.ini
and is the way ldlite (and I suppose ldao) represent them. I haven't even
bothered to check if they're the same as ldraw. I'm far too lazy.
Don
In lugnet.cad.dev, Travis Cobbs writes:
> I believe the matrix happens to produce a standard isometric view, but
> doesn't do so in the traditional 3D graphics way of rotation. This means
> that in addition to not looking right after rotation, it also doens't
> produce correct results when you apply a perspective projection to it
> (AFAIK). The others most likely also produce "standard" projections
> visually, but don't necessarily represent something that is possible in the
> real world.
>
> The default matrix I use in LDView is equivalent to your oblique one (but
> for some odd reason, with rows/columns swapped, assuming you wrote your
> matrices in the same order that LDRAW expects, ie column major). I actually
> had a difficult time getting the model rotated around to this angle.
>
> If anyone cares about maximum accuracy, the irrational numbers in the matrix
> are:
>
> .707104 = sqrt(2) / 2
> .353553 = sqrt(2) / 4
> .866025 = sin(pi / 3)
> .612372 = sqrt(1.5) / 2
>
> --Travis Cobbs (tcobbs@san.REMOVE.rr.com)
>
> "Don Heyse" <dheyse@hotmail.spam.go.away.com> wrote in message
> news:G1ws1M.1ty@lugnet.com...
> > Hey, does anybody out there know the origin of the "Oblique",
> > "UpsideDown", and "Natural" viewing matrices in LDRAW.INI. I'm not
> > sure whether these came from LDAO, LDLITE, or perhaps even LDRAW?
> > Wherever they came from, they don't seem to be pure rotation matrices
> > fit for a viewing transformation. When I multiply one of these with
> > another rotation matrix the model starts to look sheared. Is there a
> > projection transform in there or are they just plain wrong? I believe
> > someone previously mentioned that there was something unusual about
> > these matrices but I can't remember what.
> >
> > Anyways, the point is I finally got that pesky mouse-drag model
> > spinning trick to work in ldglite but I had to replace these three
> > view matrices to do it.
> >
> > Also I noticed at one point that L3LAB seemed to shear the model
> > sometimes during spinning. Does/Did it perhaps use the view matrices
> > from LDRAW.INI as well?
> >
> > Here are the original matrices.
> > Oblique=1,0,1,0.5,1,-0.5,-1,0,1
> > UpsideDown=-1,0,1,-0.5,-1,-0.5,1,0,0
> > Natural=0.625,0,1.075,0.5375,1.25,-0.3125,-1.25,0,2.5
> >
> > Here are the replacement matrices.
>
> Oblique=0.707104,0,0.707104,0.353553,0.866025,-0.353553,-0.612372,0.5,0.6123
> 72
>
> UpsideDown=0.707104,0,0.707104,-0.353553,-0.866025,0.353553,0.612372,-0.5,-
> > 0.612372
> > Natural=0.5,0,0.866025,0.433013,0.866025,-0.25,-0.75,0.5,0.433013
> >
> > My Oblique matrix is a 45 degree rotation about y followed by 30 about x.
> > My UpsideDown matrix is a 45 degree rotation about y followed by 210 about • x.
> > My Natural matrix is a 60 degree rotation about y followed by 30 about x.
> >
> > Don
| | | | | | | | | | | | | | | | | | | | | | | |
| |
|
"Don Heyse" <dheyse@hotmail.spam.go.away.com> wrote in message
news:G1xC6x.7nK@lugnet.com...
> OK now we're getting somewhere. Thanks for providing the exact • mathematical
> representations of those numbers. Now I'm gonna have to figure out how • you
> calculated them. :-) (I just had the computer do the work and print out • the
> decimal representations)
To be perfectly honest, I can't really remember how I came up with them. I
think I actually started with the numeric values and--going on the
assumption that they had more mathematically precise definitions--just
figured out what those definitions were. I had some clues to work with;
namely the fact that I expected all the numbers to involve either square
root or a sine/cosine of some even fraction of pi.
> But we still don't know where those "oblique" numbers came from and what
> they're supposed to represent. Should I even bother with them for
> compatibility?
Well, they obviously represent a skew (obvious when you rotate them,
anyway). It may well be that they were just stumbled upon, and don't have
any higher meaning. They produce pleasing results, and they only start to
produce weirdness when you start assuming they are a set of rotations (which
they of course aren't).
> By the way, the row-column order for the matrix came straight out of • ldraw.ini
> and is the way ldlite (and I suppose ldao) represent them. I haven't even
> bothered to check if they're the same as ldraw. I'm far too lazy.
I looked at my code again, and it's even worse. I actually rotate 180
degrees aroung Z, then 180 degrees around Y, and only THEN apply the
rotation matrix (with rows and columns swapped from yours). If I don't
perform the two 180 degree rotations, it ends up looking at a different side
of the model. Since you are using OpenGL, we SHOULD have the same starting
point, I've obviously gone through hoops that you didn't have to. What
exactly do you apply these matrices to?
In LDView, I first translate back along the Z axis a certain distance, then
multiply by my rotation matrix (which is computed as mentioned above with
the two 180 degree rotations), then draw the model. This works fine, but
has the disadvantage that my starting point matrix is different from what
LDraw and the other tools expect, not to mention having the odd 180 degree
rotations. I'm assuming that you are doing something different.
--Travis Cobbs (tcobbs@san.REMOVE.rr.com)
| | | | | | | | | | | | | | | | | | |
| |
|
In lugnet.cad.dev, Don Heyse writes:
> Hey, does anybody out there know the origin of the "Oblique",
> "UpsideDown", and "Natural" viewing matrices in LDRAW.INI. I'm not
> sure whether these came from LDAO, LDLITE, or perhaps even LDRAW?
LDAO writes those entries to ldraw.ini. I'm not sure if any other programs
update that section or not.
The "Oblique" view is the default view for LDraw, and was also used for LDLite
(I think) and L3Lab.
"UpsideDown" is derived from "Oblique".
"Natural" was my attempt at a "pure rotation". I guess I blew it.
> Anyways, the point is I finally got that pesky mouse-drag model
> spinning trick to work in ldglite but I had to replace these three
> view matrices to do it.
>
> Also I noticed at one point that L3LAB seemed to shear the model
> sometimes during spinning. Does/Did it perhaps use the view matrices
> from LDRAW.INI as well?
L3Lab defaults to the standard Oblique view (not the one currently stored in
ldraw.ini, but the standard value). When you start to drag the model with the
mouse, L3Lab switches to a non-sheared view. You might ask Lars what that
view is, and use the same in LDGLite -- just to be consistent.
Steve
| | | | | | | | | | | | | | | | |
"Steve Bliss" <blisses@worldnet.att.net> writes:
> L3Lab defaults to the standard Oblique view (not the one currently
> stored in ldraw.ini, but the standard value). When you start to
> drag the model with the mouse, L3Lab switches to a non-sheared
> view. You might ask Lars what that view is, and use the same in
> LDGLite -- just to be consistent.
In L3Lab, you can find the current view matrix in the statistics menu
item. It is useful for usage with, e.g., LDLITE and LDraw.
Fredrik
| | | | | | |
