You can subscribe to this list here.
2000 
_{Jan}

_{Feb}

_{Mar}

_{Apr}

_{May}

_{Jun}

_{Jul}
(390) 
_{Aug}
(767) 
_{Sep}
(940) 
_{Oct}
(964) 
_{Nov}
(819) 
_{Dec}
(762) 

2001 
_{Jan}
(680) 
_{Feb}
(1075) 
_{Mar}
(954) 
_{Apr}
(595) 
_{May}
(725) 
_{Jun}
(868) 
_{Jul}
(678) 
_{Aug}
(785) 
_{Sep}
(410) 
_{Oct}
(395) 
_{Nov}
(374) 
_{Dec}
(419) 
2002 
_{Jan}
(699) 
_{Feb}
(501) 
_{Mar}
(311) 
_{Apr}
(334) 
_{May}
(501) 
_{Jun}
(507) 
_{Jul}
(441) 
_{Aug}
(395) 
_{Sep}
(540) 
_{Oct}
(416) 
_{Nov}
(369) 
_{Dec}
(373) 
2003 
_{Jan}
(514) 
_{Feb}
(488) 
_{Mar}
(396) 
_{Apr}
(624) 
_{May}
(590) 
_{Jun}
(562) 
_{Jul}
(546) 
_{Aug}
(463) 
_{Sep}
(389) 
_{Oct}
(399) 
_{Nov}
(333) 
_{Dec}
(449) 
2004 
_{Jan}
(317) 
_{Feb}
(395) 
_{Mar}
(136) 
_{Apr}
(338) 
_{May}
(488) 
_{Jun}
(306) 
_{Jul}
(266) 
_{Aug}
(424) 
_{Sep}
(502) 
_{Oct}
(170) 
_{Nov}
(170) 
_{Dec}
(134) 
2005 
_{Jan}
(249) 
_{Feb}
(109) 
_{Mar}
(119) 
_{Apr}
(282) 
_{May}
(82) 
_{Jun}
(113) 
_{Jul}
(56) 
_{Aug}
(160) 
_{Sep}
(89) 
_{Oct}
(98) 
_{Nov}
(237) 
_{Dec}
(297) 
2006 
_{Jan}
(151) 
_{Feb}
(250) 
_{Mar}
(222) 
_{Apr}
(147) 
_{May}
(266) 
_{Jun}
(313) 
_{Jul}
(367) 
_{Aug}
(135) 
_{Sep}
(108) 
_{Oct}
(110) 
_{Nov}
(220) 
_{Dec}
(47) 
2007 
_{Jan}
(133) 
_{Feb}
(144) 
_{Mar}
(247) 
_{Apr}
(191) 
_{May}
(191) 
_{Jun}
(171) 
_{Jul}
(160) 
_{Aug}
(51) 
_{Sep}
(125) 
_{Oct}
(115) 
_{Nov}
(78) 
_{Dec}
(67) 
2008 
_{Jan}
(165) 
_{Feb}
(37) 
_{Mar}
(130) 
_{Apr}
(111) 
_{May}
(91) 
_{Jun}
(142) 
_{Jul}
(54) 
_{Aug}
(104) 
_{Sep}
(89) 
_{Oct}
(87) 
_{Nov}
(44) 
_{Dec}
(54) 
2009 
_{Jan}
(283) 
_{Feb}
(113) 
_{Mar}
(154) 
_{Apr}
(395) 
_{May}
(62) 
_{Jun}
(48) 
_{Jul}
(52) 
_{Aug}
(54) 
_{Sep}
(131) 
_{Oct}
(29) 
_{Nov}
(32) 
_{Dec}
(37) 
2010 
_{Jan}
(34) 
_{Feb}
(36) 
_{Mar}
(40) 
_{Apr}
(23) 
_{May}
(38) 
_{Jun}
(34) 
_{Jul}
(36) 
_{Aug}
(27) 
_{Sep}
(9) 
_{Oct}
(18) 
_{Nov}
(25) 
_{Dec}

2011 
_{Jan}
(1) 
_{Feb}
(14) 
_{Mar}
(1) 
_{Apr}
(5) 
_{May}
(1) 
_{Jun}

_{Jul}

_{Aug}
(37) 
_{Sep}
(6) 
_{Oct}
(2) 
_{Nov}

_{Dec}

2012 
_{Jan}

_{Feb}
(7) 
_{Mar}

_{Apr}
(4) 
_{May}

_{Jun}
(3) 
_{Jul}

_{Aug}

_{Sep}
(1) 
_{Oct}

_{Nov}

_{Dec}
(10) 
2013 
_{Jan}

_{Feb}
(1) 
_{Mar}
(7) 
_{Apr}
(2) 
_{May}

_{Jun}

_{Jul}
(9) 
_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

2014 
_{Jan}
(14) 
_{Feb}

_{Mar}
(2) 
_{Apr}

_{May}
(10) 
_{Jun}

_{Jul}

_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 






1
(18) 
2
(3) 
3
(8) 
4
(12) 
5
(10) 
6
(6) 
7
(40) 
8
(43) 
9
(18) 
10
(7) 
11
(28) 
12
(26) 
13
(17) 
14
(29) 
15
(18) 
16
(32) 
17
(8) 
18
(31) 
19
(18) 
20
(9) 
21
(1) 
22
(24) 
23
(9) 
24

25
(3) 
26
(13) 
27
(1) 
28
(8) 
29
(16) 
30
(7) 
31







From: Tom Forsyth <tom.forsyth@bl...>  20030830 21:37:17

> I agree with the other posters who have recommended keeping a quat or > an up vector in addition to the position and direction. (That is, if > you can't clamp the pitch at less than +/ 90 degrees  if you *can* > clamp pitch and you don't need roll for a special effect, then IMO > it's good to just keep pos and dir, and enforce zero roll.) Possibly better still, lerp towards a roll of either straight up or straight down, whichever is closest to the current up or down. But only if the pich is less than something like 70 degrees, yeah. That way you can still loop over the top, and you stay upside down, and you can also look straight up and down and not have the autoroll doing wierd things. TomF. > Original Message > From: gdalgorithmslistadmin@... > [mailto:gdalgorithmslistadmin@...] On > Behalf Of Thatcher Ulrich > Sent: 29 August 2003 20:26 > To: gdalgorithmslist@... > Subject: Re: [Algorithms] Camera > > > On Sat, Aug 30, 2003 at 10:43:28AM 0400, Stephan Rose wrote: > > Anyone know a good tutorial on cameras? I've tried > different methods now > > and none of them have had quite the result I'm looking for. > > > > I either end up with a camera that suffers from gimbal > lock, *or* can't > > rotate past 90/+90 degrees pitch. > > > > Only thing I store is my position and forward vector. > Right/Up vectors > > are recreated everytime. > > > > Basically what I'd like is a camera that I can turn in any > direction, > > without suffering from gimbal lock, or having trouble > rotating past +/ > > 90 degrees pitch, and no unwanted roll!! :) > > So if I'm reading this right, nobody has really addressed what I see > as the core problem, which is avoiding the unwanted roll, but still > letting you flip over with decent control. > > I agree with the other posters who have recommended keeping a quat or > an up vector in addition to the position and direction. (That is, if > you can't clamp the pitch at less than +/ 90 degrees  if you *can* > clamp pitch and you don't need roll for a special effect, then IMO > it's good to just keep pos and dir, and enforce zero roll.) > > Anyway, back to the problem: I don't have a readymade solution, but > my suggestion is to keep roll state and use delta angles to update the > camera orientation, but aggressively damp the roll to 0 when > abs(pitch) is less than some threshold (maybe 75 or 80 degrees or so). > >  > Thatcher Ulrich > http://tulrich.com > > >  > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > GDAlgorithmslist mailing list > GDAlgorithmslist@... > https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=6188 > 
From: Stephan Rose <kermos@be...>  20030830 19:54:40

Thanks, I actually ended up thinking of the same thing and implemented it this morning. :) Great though to see that my thinking was correct. :) Works beautiful now too! Only difference is I kept the quaternions instead of using matrices as you're showing here. Allows me to still smoothly interpolate between my current orientation to the new target orientation, but the target orientation I now reconstruct everytime yaw/pitch/roll is modified. Thanks everyone for your help, highly appreciated. Stephan Original Message From: gdalgorithmslistadmin@... [mailto:gdalgorithmslistadmin@...] On Behalf Of Jon Watte Sent: Saturday, August 30, 2003 2:06 PM To: gdalgorithmslist@... Subject: RE: [Algorithms] Camera > But then how do I properly do this so that I don't end up rolling if I > yaw and pitch? If you want worldspace yaw/pitch around a worldspace up that is known separately from the camera, keep yaw/pitch in world space and regenerate the matrix each frame. In this case, you should map mouse up/down to pitch delta, and mouse left/right to roll delta, no matter what the current values are. I e, each frame: yaw += mouse_dx * scale; pitch += mouse_dy * scale; wrap( yaw, 0, 2pi ); wrap( pitch, 0, 2pi ); matrix = world_identity; matrix *= rotate_matrix( pitch, world_east ); matrix *= rotate_matrix( yaw, world_up ); (You may need to swap order depending on your matrix package/convetion) Note that, if you do this, the left/right will work reverse from normal once you go past the apex at 90 degrees. That's to be expected and the way this control function works. Note that mapping dx/dy to yaw/pitch, and reconstructing the matrix from worldspace vectors, ensures that there is no mad flip around the apex, nor any accumulation of rotation around roll. However, there are, instead, certain angles that you think you ought to be able to get at, which you can't, because you only have two degrees of freedom. Cheers, / h+  This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ GDAlgorithmslist mailing list GDAlgorithmslist@... https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist Archives: http://sourceforge.net/mailarchive/forum.php?forum_ida88 
From: Jon Watte <hplus@mi...>  20030830 18:06:52

> But then how do I properly do this so that I don't end up rolling if I > yaw and pitch? If you want worldspace yaw/pitch around a worldspace up that is known=20 separately from the camera, keep yaw/pitch in world space and = regenerate=20 the matrix each frame. In this case, you should map mouse up/down to = pitch=20 delta, and mouse left/right to roll delta, no matter what the current=20 values are. I e, each frame: yaw +=3D mouse_dx * scale; pitch +=3D mouse_dy * scale; wrap( yaw, 0, 2pi ); wrap( pitch, 0, 2pi ); matrix =3D world_identity; matrix *=3D rotate_matrix( pitch, world_east ); matrix *=3D rotate_matrix( yaw, world_up ); (You may need to swap order depending on your matrix package/convetion) Note that, if you do this, the left/right will work reverse from normal=20 once you go past the apex at 90 degrees. That's to be expected and the=20 way this control function works. Note that mapping dx/dy to yaw/pitch, and reconstructing the matrix = from=20 worldspace vectors, ensures that there is no mad flip around the apex,=20 nor any accumulation of rotation around roll. However, there are, = instead,=20 certain angles that you think you ought to be able to get at, which you=20 can't, because you only have two degrees of freedom. Cheers, / h+ 
From: Stephan Rose <kermos@be...>  20030830 05:40:22

But then how do I properly do this so that I don't end up rolling if I yaw and pitch? I'm yawing by rotating around the worlds up vector I'm pitching by rotating around the cameras right axis If I was rolling (on purpose!), which right now I'm not, it'd be around the cameras forward vector. These can basically occur in any order depending on user input... What am I still doing wrong??? There's got to be something that I'm still doing wrong because any 3d modeler can do it right...so there quite obviously is a way... Anyway...too frustrated and too tired right now :) Bed time.... Stephan Original Message From: gdalgorithmslistadmin@... [mailto:gdalgorithmslistadmin@...] On Behalf Of Jon Watte Sent: Friday, August 29, 2003 11:59 PM To: gdalgorithmslist@... Subject: RE: [Algorithms] Camera > I'm guessing at this point in time, it's just simply floating point > errors introduced over time causing this. Nope. This is how rotations work. You accumulate rotation around more than one worldspace axis when you rotate around a localspace axis, if you compare reference frames. Run this experiment: Hold an orientable item out in front of you. I'll use a knife, held handle down, edge to the left. Rotate the knife 90 degrees counterclockwise around your front vector. This puts the edge down, and the handle to the right. Rotate the knife 90 degrees counterclockwise around your up vector (translated to the knife, of course :). This puts the point of the knife towards you, with the edge down. No, rotate the knife 90 degrees counterclockwise around your right axis (again, translated to the knife). This puts the point back upwards, which is where it was in the first place, but this time the edge points towards you. If you do the same experiment with much smaller rotations, you will still accumulate rotation when going through a triangle that puts you back to the beginning. This is just inherent in how rotations work, no matter what the representation is. Cheers, / h+  This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ GDAlgorithmslist mailing list GDAlgorithmslist@... https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist Archives: http://sourceforge.net/mailarchive/forum.php?forum_ida88 
From: Jon Watte <hplus@mi...>  20030830 03:59:06

> I'm guessing at this point in time, it's just simply floating point > errors introduced over time causing this. Nope. This is how rotations work. You accumulate rotation=20 around more than one worldspace axis when you rotate around a=20 localspace axis, if you compare reference frames. Run this experiment: Hold an orientable item out in front of you. I'll use a knife,=20 held handle down, edge to the left. Rotate the knife 90 degrees counterclockwise around your front vector. This puts the edge down, and the handle to the right. Rotate the knife 90 degrees counterclockwise around your up=20 vector (translated to the knife, of course :). This puts the=20 point of the knife towards you, with the edge down. No, rotate the knife 90 degrees counterclockwise around your=20 right axis (again, translated to the knife). This puts the=20 point back upwards, which is where it was in the first place,=20 but this time the edge points towards you. If you do the same experiment with much smaller rotations, you=20 will still accumulate rotation when going through a triangle=20 that puts you back to the beginning. This is just inherent in=20 how rotations work, no matter what the representation is. Cheers, / h+ 
From: Stephan Rose <kermos@be...>  20030830 03:23:29

Almost got it now... After implementing the slerp to smoothly move the camera (which works beautifully), I noticed there still is somewhat of a roll being induced that wasn't previously visible. Thinking that maybe it's caused by the slerp, I disabled that again, and rotated my mouse 'till my hand got numb for about a few minutes to simulate those 500 times/sec slerp rotations( ~500 FPS, 1 rotation per frame). And sure enough there still is a tiny amount of roll in there. While it'd prolly never be an issue without the slerp as the rolls do seem to cancel out over time, with the slerp in there to smooth things out, the roll does become quite pronounced. Still far better than what I had at the beginning w/ no slerp, but still there though. :) I'm guessing at this point in time, it's just simply floating point errors introduced over time causing this. Question now is what do I do about them? Both quaternions (the target and the current) are being normalized after anytime they're modified. Thanks again :) Stephan 
From: Stephan Rose <kermos@be...>  20030830 01:00:43

That did it!!! Thank you! :) If anyone wants to see the finished camera class (should be finishing it tonight now finally) I'll be happy to make it available.... D3DX9 is required though. Stephan Original Message From: gdalgorithmslistadmin@... [mailto:gdalgorithmslistadmin@...] On Behalf Of Pete Brubaker Sent: Friday, August 29, 2003 7:22 PM To: gdalgorithmslist@... Subject: RE: [Algorithms] Camera Ok, so what I did to solve this is quite simple. When I first started learning 3D this was one of the first things I wanted to do. In turn it gave me a good foundation of linear algebra that I neglected in the past. First, allow me to explain how I implemented a traditional first person camera. You need to degrees of freedom, pitch and yaw. You want to yaw about the world up axis, not the local camera up axis. And you want to pitch around the cameras local right axis. So in thinking about this and what I intended to do with the camera I just decided to store a 4x4 matrix for the camera. I know this is a bit much. I could just store a Vec3 position and a 3x3 matrix for the rotation (yes or a quat, but then you pay to convert it to a matrix if you are using it for drawing. But that is another debate that I don't want to start here.) In the CCamera::Rotate function you input an angle for rotation in degrees, and a normalized vector for the axis. You generate a temporary rotation matrix then multiply that by the rotation components of the camera's matrix. The other two functions just handle the mouse input (mSensitivity is just a scalar that adjusts the sensitivity of the mouse input.) Now if you follow this general idea you can do this with a quat. You can yaw a quat via the world up axis by generating a temp rotation quat about the world up axis, then multiply it with the original quat, and then renormalize. You can also generate a quat rotation about the right axis by transforming a normal world right Vec3( 1.0f, 0.0f, 0.0f ) by the current quat to get the camera's local right axis. You would then generate a quat rotation from that axis and the input angle, multiply it with the original quat, and then renormalize. The Functions: ////////////////////// // Pitch the camera ////////////////////// void Pitch( const float& angle ) { // Rotate about the cameras right axis ( the first vec3 in this particular matrix format ) Rotate( angle * mSensitivity, &mMatrix[0] ); } /////////////////// // Yaw the camera /////////////////// void Yaw( const float& angle ) { // Rotate about the world up vector ( Y up here ) Rotate( angle * mSensitivity, Vec3( 0.0f, 1.0f, 0.0f ) ); } /////////////////////////////////////////////////////////////////// // CCamera::Rotate ( Rotate the camera's matrix about any axis. ) /////////////////////////////////////////////////////////////////// void CCamera::Rotate( const float& inAngle, const Vec3& inAxis ) { Mat44 rotateMatrix; Mat44SetIdentity( rotateMatrix ); // Generate the rotation matrix around the axis Mat33SetRotation( rotateMatrix, DegToRad( inAngle ), inAxis ); // Multiply the 3x3 component of the camera's matrix // by the 3x3 component of the rotation matrix Mat33Mul( mMatrix, rotateMatrix, mMatrix ); // Orthonormalize the 3x3 part of the cameras matrix Mat33OrthoNormalize( mMatrix ); } Then to use this matrix to draw in GL just push the matrix stack, invert this matrix and multiply it on. Mat44 temp; Mat44InvertOrtho( temp, mMatrix ); glMultMatrixf( temp ); I would also be happy to supply the matrix and vector functions if you need them. I hope this helps, P __________________________________________________________________ Pete Brubaker Associate Technical Director LucasArts, a division of Lucasfilm Entertainment Company Ltd. San Rafael, CA * Email: pbrubaker@... <mailto:pbrubaker@...> __________________________________________________________________ Original Message From: Stephan Rose [mailto:kermos@...] Sent: Saturday, August 30, 2003 2:58 PM To: gdalgorithmslist@... Subject: RE: [Algorithms] Camera Thanks Garett, I will take a look at that link. To try to elaborate a bit more on what I'm looking for. I'm looking to write a camera class that can rotate any given amount in any given axis from any given orientation. Basically similar to my 3D Solid Modeler camera's I use for my mechanical engineering at work (Autodesk Inventor). I can rotate the camera freely in any axis from any orientation without having even the slightest deviation in any axis that I don't want to rotate in. I hope this explains it a bit more. The game I'm working on in my free time, will only require yaw/pitch when played (1st person view). However in editing mode I want a complete free rotating flying camera so that my artist has complete freedom of movement when editing the world to place objects, etc. Also for future projects, I may need a camera that has complete freedom of movement. Therefore I want to write this class right the first time around to be universal and work for any application I need it to. Thanks, Stephan Original Message From: gdalgorithmslistadmin@... [mailto:gdalgorithmslistadmin@...] On Behalf Of Garett Bass Sent: Friday, August 29, 2003 4:48 PM To: gdalgorithmslist@... Subject: RE: [Algorithms] Camera Stephan, You can find some sample camera code using quaternions here: http://personal.nbnet.nb.ca/daveg/opengl/camera/index.html Note that, pitching up 90 degrees, yawing right 90 degress, then pitching down 90 degrees, is the same as simply rolling right 90 degrees. Perhaps the roll you are experiencing is due to the order in which your rotations are applied? I'm not sure I understand what you're trying to acheive. If it is your intent that yaw should always be relative to the world's vertical axis, then you may need to consider a different approach. Perhaps you could store a pitch vector and a yaw vector, and cross the two to create a roll vector per frame? This would allow you to flip over completely, but when you're looking straight up, world yaw == camera roll. It may be helpful to have a more complete explanation of the effect you are looking for. Will this camera represent the viewpoint of a person standing upright on the ground, or an astronaut floating free in space, or something else entirely? Regards, Garett Bass gtbass@... Original Message From: gdalgorithmslistadmin@... [mailto:gdalgorithmslistadmin@...]On Behalf Of Stephan Rose Sent: Saturday, August 30, 2003 1:52 PM To: gdalgorithmslist@... Subject: RE: [Algorithms] Camera Thanks for your responses everyone, but even using quaternions I just cannot get this to work right. If I take my input from my mouse to yaw and pitch the camera, the inputs are all delta angles, create my delta quaternion from that, multiply that by my existing orientation to get the new orientation, I still get the roll problem. Even if I normalize the new orientation quaternion afterwards, no difference. Where am I going wrong here? How do I properly determine the new target orientation based on my current orientation and the delta? Thanks, Stephan  This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ GDAlgorithmslist mailing list GDAlgorithmslist@... https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=6188  This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ GDAlgorithmslist mailing list GDAlgorithmslist@... https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=6188  This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ GDAlgorithmslist mailing list GDAlgorithmslist@... https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist Archives: http://sourceforge.net/mailarchive/forum.php?forum_ida88 
From: Pete Brubaker <PB<rubaker@lu...>  20030829 23:22:10

Ok, so what I did to solve this is quite simple. When I first started = learning 3D this was one of the first things I wanted to do. In turn it = gave me a good foundation of linear algebra that I neglected in the = past. First, allow me to explain how I implemented a traditional first person = camera. You need to degrees of freedom, pitch and yaw. You want to yaw = about the world up axis, not the local camera up axis. And you want to = pitch around the cameras local right axis. So in thinking about this and what I intended to do with the camera I = just decided to store a 4x4 matrix for the camera. I know this is a bit = much. I could just store a Vec3 position and a 3x3 matrix for the = rotation (yes or a quat, but then you pay to convert it to a matrix if = you are using it for drawing. But that is another debate that I don't = want to start here.) In the CCamera::Rotate function you input an angle for rotation in = degrees, and a normalized vector for the axis. You generate a temporary = rotation matrix then multiply that by the rotation components of the = camera's matrix. The other two functions just handle the mouse input = (mSensitivity is just a scalar that adjusts the sensitivity of the mouse = input.) Now if you follow this general idea you can do this with a quat. You = can yaw a quat via the world up axis by generating a temp rotation quat = about the world up axis, then multiply it with the original quat, and = then renormalize. You can also generate a quat rotation about the = right axis by transforming a normal world right Vec3( 1.0f, 0.0f, 0.0f ) = by the current quat to get the camera's local right axis. You would = then generate a quat rotation from that axis and the input angle, = multiply it with the original quat, and then renormalize. The Functions: ////////////////////// // Pitch the camera ////////////////////// void Pitch( const float& angle ) { // Rotate about the cameras right axis ( the first vec3 in this = particular matrix format ) Rotate( angle * mSensitivity, &mMatrix[0] );=20 } /////////////////// // Yaw the camera /////////////////// void Yaw( const float& angle ) { // Rotate about the world up vector ( Y up here ) Rotate( angle * mSensitivity, Vec3( 0.0f, 1.0f, 0.0f ) ); } /////////////////////////////////////////////////////////////////// // CCamera::Rotate ( Rotate the camera's matrix about any axis. ) /////////////////////////////////////////////////////////////////// void CCamera::Rotate( const float& inAngle, const Vec3& inAxis ) { Mat44 rotateMatrix; Mat44SetIdentity( rotateMatrix ); // Generate the rotation matrix around the axis Mat33SetRotation( rotateMatrix, DegToRad( inAngle ), inAxis ); // Multiply the 3x3 component of the camera's matrix // by the 3x3 component of the rotation matrix Mat33Mul( mMatrix, rotateMatrix, mMatrix ); // Orthonormalize the 3x3 part of the cameras matrix Mat33OrthoNormalize( mMatrix ); } Then to use this matrix to draw in GL just push the matrix stack, invert = this matrix and multiply it on. Mat44 temp; Mat44InvertOrtho( temp, mMatrix ); glMultMatrixf( temp ); I would also be happy to supply the matrix and vector functions if you = need them. I hope this helps, P __________________________________________________________________ Pete Brubaker Associate Technical Director=20 LucasArts, a division of Lucasfilm Entertainment Company Ltd.=20 San Rafael, CA=20 * Email: pbrubaker@... <mailto:pbrubaker@...>=20 __________________________________________________________________ =20 Original Message From: Stephan Rose [mailto:kermos@...] Sent: Saturday, August 30, 2003 2:58 PM To: gdalgorithmslist@... Subject: RE: [Algorithms] Camera Thanks Garett, I will take a look at that link. To try to elaborate a bit more on what I'm looking for. I'm looking to write a camera class that can rotate any given amount in any given axis from any given orientation. Basically similar to my 3D Solid Modeler camera's I use for my mechanical engineering at work (Autodesk Inventor). I can rotate the camera freely in any axis from any orientation without having even the slightest deviation in any axis that I don't want to rotate in. I hope this explains it a bit more. The game I'm working on in my free time, will only require yaw/pitch when played (1st person view). However in editing mode I want a complete free rotating flying camera so that my artist has complete freedom of movement when editing the world to place objects, etc. Also for future projects, I may need a camera that has complete freedom of movement. Therefore I want to write this class right the first time around to be universal and work for any application I need it to. Thanks, Stephan Original Message From: gdalgorithmslistadmin@... [mailto:gdalgorithmslistadmin@...] On Behalf Of Garett Bass Sent: Friday, August 29, 2003 4:48 PM To: gdalgorithmslist@... Subject: RE: [Algorithms] Camera Stephan, You can find some sample camera code using quaternions here: http://personal.nbnet.nb.ca/daveg/opengl/camera/index.html Note that, pitching up 90 degrees, yawing right 90 degress, then pitching down 90 degrees, is the same as simply rolling right 90 degrees. Perhaps the roll you are experiencing is due to the order in which your rotations are applied? I'm not sure I understand what you're trying to acheive. If it is your intent that yaw should always be relative to the world's vertical axis, then you may need to consider a different approach. Perhaps you could store a pitch vector and a yaw vector, and cross the two to create a roll vector per frame? This would allow you to flip over completely, but when you're looking straight up, world yaw =3D=3D camera roll. It may be helpful to have a more complete explanation of the effect you are looking for. Will this camera represent the viewpoint of a person standing upright on the ground, or an astronaut floating free in space, or something else entirely? Regards, Garett Bass gtbass@... Original Message From: gdalgorithmslistadmin@... [mailto:gdalgorithmslistadmin@...]On Behalf Of Stephan Rose Sent: Saturday, August 30, 2003 1:52 PM To: gdalgorithmslist@... Subject: RE: [Algorithms] Camera Thanks for your responses everyone, but even using quaternions I just cannot get this to work right. If I take my input from my mouse to yaw and pitch the camera, the inputs are all delta angles, create my delta quaternion from that, multiply that by my existing orientation to get the new orientation, I still get the roll problem. Even if I normalize the new orientation quaternion afterwards, no difference. Where am I going wrong here? How do I properly determine the new target orientation based on my current orientation and the delta? Thanks, Stephan  This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ GDAlgorithmslist mailing list GDAlgorithmslist@... https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=3D6188  This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ GDAlgorithmslist mailing list GDAlgorithmslist@... https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=3D6188 
From: Stephan Rose <kermos@be...>  20030829 22:08:15

Thanks Garett, I will take a look at that link. To try to elaborate a bit more on what I'm looking for. I'm looking to write a camera class that can rotate any given amount in any given axis from any given orientation. Basically similar to my 3D Solid Modeler camera's I use for my mechanical engineering at work (Autodesk Inventor). I can rotate the camera freely in any axis from any orientation without having even the slightest deviation in any axis that I don't want to rotate in. I hope this explains it a bit more. The game I'm working on in my free time, will only require yaw/pitch when played (1st person view). However in editing mode I want a complete free rotating flying camera so that my artist has complete freedom of movement when editing the world to place objects, etc. Also for future projects, I may need a camera that has complete freedom of movement. Therefore I want to write this class right the first time around to be universal and work for any application I need it to. Thanks, Stephan Original Message From: gdalgorithmslistadmin@... [mailto:gdalgorithmslistadmin@...] On Behalf Of Garett Bass Sent: Friday, August 29, 2003 4:48 PM To: gdalgorithmslist@... Subject: RE: [Algorithms] Camera Stephan, You can find some sample camera code using quaternions here: http://personal.nbnet.nb.ca/daveg/opengl/camera/index.html Note that, pitching up 90 degrees, yawing right 90 degress, then pitching down 90 degrees, is the same as simply rolling right 90 degrees. Perhaps the roll you are experiencing is due to the order in which your rotations are applied? I'm not sure I understand what you're trying to acheive. If it is your intent that yaw should always be relative to the world's vertical axis, then you may need to consider a different approach. Perhaps you could store a pitch vector and a yaw vector, and cross the two to create a roll vector per frame? This would allow you to flip over completely, but when you're looking straight up, world yaw == camera roll. It may be helpful to have a more complete explanation of the effect you are looking for. Will this camera represent the viewpoint of a person standing upright on the ground, or an astronaut floating free in space, or something else entirely? Regards, Garett Bass gtbass@... Original Message From: gdalgorithmslistadmin@... [mailto:gdalgorithmslistadmin@...]On Behalf Of Stephan Rose Sent: Saturday, August 30, 2003 1:52 PM To: gdalgorithmslist@... Subject: RE: [Algorithms] Camera Thanks for your responses everyone, but even using quaternions I just cannot get this to work right. If I take my input from my mouse to yaw and pitch the camera, the inputs are all delta angles, create my delta quaternion from that, multiply that by my existing orientation to get the new orientation, I still get the roll problem. Even if I normalize the new orientation quaternion afterwards, no difference. Where am I going wrong here? How do I properly determine the new target orientation based on my current orientation and the delta? Thanks, Stephan  This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ GDAlgorithmslist mailing list GDAlgorithmslist@... https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=6188 
From: Jonathan Blow <jon@nu...>  20030829 21:23:21

> for every n: > if (4d_dotproduct(q_n, q_{n+1}) > 2pi) > q_{n+1} = q_{n+1} > > That should ofcourse be pi, not 2pi. Except of course, it should be "< 0", not "> pi". 
From: Garett Bass <gtbass@st...>  20030829 20:58:13

Stephan, You can find some sample camera code using quaternions here: http://personal.nbnet.nb.ca/daveg/opengl/camera/index.html Note that, pitching up 90 degrees, yawing right 90 degress, then pitching down 90 degrees, is the same as simply rolling right 90 degrees. Perhaps the roll you are experiencing is due to the order in which your rotations are applied? I'm not sure I understand what you're trying to acheive. If it is your intent that yaw should always be relative to the world's vertical axis, then you may need to consider a different approach. Perhaps you could store a pitch vector and a yaw vector, and cross the two to create a roll vector per frame? This would allow you to flip over completely, but when you're looking straight up, world yaw == camera roll. It may be helpful to have a more complete explanation of the effect you are looking for. Will this camera represent the viewpoint of a person standing upright on the ground, or an astronaut floating free in space, or something else entirely? Regards, Garett Bass gtbass@... Original Message From: gdalgorithmslistadmin@... [mailto:gdalgorithmslistadmin@...]On Behalf Of Stephan Rose Sent: Saturday, August 30, 2003 1:52 PM To: gdalgorithmslist@... Subject: RE: [Algorithms] Camera Thanks for your responses everyone, but even using quaternions I just cannot get this to work right. If I take my input from my mouse to yaw and pitch the camera, the inputs are all delta angles, create my delta quaternion from that, multiply that by my existing orientation to get the new orientation, I still get the roll problem. Even if I normalize the new orientation quaternion afterwards, no difference. Where am I going wrong here? How do I properly determine the new target orientation based on my current orientation and the delta? Thanks, Stephan 
From: Thatcher Ulrich <tu@tu...>  20030829 19:26:06

On Sat, Aug 30, 2003 at 10:43:28AM 0400, Stephan Rose wrote: > Anyone know a good tutorial on cameras? I've tried different methods now > and none of them have had quite the result I'm looking for. > > I either end up with a camera that suffers from gimbal lock, *or* can't > rotate past 90/+90 degrees pitch. > > Only thing I store is my position and forward vector. Right/Up vectors > are recreated everytime. > > Basically what I'd like is a camera that I can turn in any direction, > without suffering from gimbal lock, or having trouble rotating past +/ > 90 degrees pitch, and no unwanted roll!! :) So if I'm reading this right, nobody has really addressed what I see as the core problem, which is avoiding the unwanted roll, but still letting you flip over with decent control. I agree with the other posters who have recommended keeping a quat or an up vector in addition to the position and direction. (That is, if you can't clamp the pitch at less than +/ 90 degrees  if you *can* clamp pitch and you don't need roll for a special effect, then IMO it's good to just keep pos and dir, and enforce zero roll.) Anyway, back to the problem: I don't have a readymade solution, but my suggestion is to keep roll state and use delta angles to update the camera orientation, but aggressively damp the roll to 0 when abs(pitch) is less than some threshold (maybe 75 or 80 degrees or so).  Thatcher Ulrich http://tulrich.com 
From: Jon Watte <hplus@mi...>  20030829 19:16:18

Note that the delta quaternion needs to be calculated relative to the = current quaternion, not relative to world space. Do quattomatrix and use the "up" axis of that matrix (typically Y) for = heading, and the "right" axis for roll. Cheers, / h+ Original Message From: gdalgorithmslistadmin@... = [mailto:gdalgorithmslistadmin@...]On Behalf Of = Stephan Rose Sent: Saturday, August 30, 2003 11:52 AM To: gdalgorithmslist@... Subject: RE: [Algorithms] Camera Thanks for your responses everyone, but even using quaternions I just = cannot get this to work right. =20 If I take my input from my mouse to yaw and pitch the camera, the inputs = are all delta angles, create my delta quaternion from that, multiply = that by my existing orientation to get the new orientation, I still get = the roll problem. Even if I normalize the new orientation quaternion = afterwards, no difference. =20 Where am I going wrong here? How do I properly determine the new target = orientation based on my current orientation and the delta? =20 Thanks, =20 Stephan 
From: Stephan Rose <kermos@be...>  20030829 19:01:53

Thanks for your responses everyone, but even using quaternions I just cannot get this to work right. If I take my input from my mouse to yaw and pitch the camera, the inputs are all delta angles, create my delta quaternion from that, multiply that by my existing orientation to get the new orientation, I still get the roll problem. Even if I normalize the new orientation quaternion afterwards, no difference. Where am I going wrong here? How do I properly determine the new target orientation based on my current orientation and the delta? Thanks, Stephan 
From: Alex Mohr <amohr@cs...>  20030829 16:40:40

I've always found it most useful to store position, forward, and up. (Up just has to be linearly independent from forward, not orthogonal to it..) This scheme's advantages are that it's quite intuitive and it's easy to orient the camera with respect to objects in the scene (i.e. I want to look at object X) as well as do incremental rotations like "pitch 10 degrees, yaw 30 degrees". It's also easy to generate rotation matrices and quaternions and other favorite affine transformation specifications. Some might argue that it's slow since this involves normalizing a number of vectors, but this has *never* been anywhere close to a bottleneck for me. I guess the real answer is to pick something that you like for an underlying representation and then make sure you can always convert to other reps that can support the operations you want to use. Alex >Anyone know a good tutorial on cameras? I've tried different methods now >and none of them have had quite the result I'm looking for. > >I either end up with a camera that suffers from gimbal lock, *or* can't >rotate past 90/+90 degrees pitch. > >Only thing I store is my position and forward vector. Right/Up vectors >are recreated everytime. > >Basically what I'd like is a camera that I can turn in any direction, >without suffering from gimbal lock, or having trouble rotating past +/ >90 degrees pitch, and no unwanted roll!! :) > >Any help would be greatly appreciated. > >Thanks, > >Stephan 
From: Willem H. de Boer <W<illem@mu...>  20030829 16:17:44

I absentmindedly wrote: for every n: if (4d_dotproduct(q_n, q_{n+1}) > 2pi) q_{n+1} = q_{n+1} That should ofcourse be pi, not 2pi. Willem 
From: Willem H. de Boer <W<illem@mu...>  20030829 16:14:50

Be careful with option a) though. Because one rotation can be represented by two unit norm quaternions (q, and q). So you need to make sure that your sequence of quaternions {q_n} (n=1,2,...,num_of_quats_in_path) abides to this rule: for every n: if (4d_dotproduct(q_n, q_{n+1}) > 2pi) q_{n+1} = q_{n+1} This so you always interpolate quaternions along the shortestarc. Failing to do so, will result in weird behaviour of your camera. Also, quaternion interpolation does not always yield nice enough results for camera interpolation, due to the fact that the roll may fluctuate too much. We humans are used to camera path where there is virtually no change in roll over the sequence. Have a look at the article "Fibre Bundle Twist Reduction" by Ken Shoemake. He talks about minimizing deviation roll for quaternion camera paths. Willem 
From: Jon Watte <hplus@mi...>  20030829 15:58:08

If that's what you want, then you have to store something better than = position and forward vector. I'd suggest storing the camera as a position and a quaternion (for = orientation). Then your various camera cues can act as forces on the = camera, and the camera response with some amount of inertia and damping, = and of course some special option to immediately cut to a new vantage = point/orientation for special cases. Cheers, / h+ Original Message From: gdalgorithmslistadmin@... = [mailto:gdalgorithmslistadmin@...]On Behalf Of = Stephan Rose Sent: Saturday, August 30, 2003 7:43 AM To: GD Algorithms Subject: [Algorithms] Camera Anyone know a good tutorial on cameras? I've tried different methods = now and none of them have had quite the result I'm looking for. =20 I either end up with a camera that suffers from gimbal lock, *or* = can't rotate past 90/+90 degrees pitch. =20 Only thing I store is my position and forward vector. Right/Up vectors = are recreated everytime. =20 Basically what I'd like is a camera that I can turn in any direction, = without suffering from gimbal lock, or having trouble rotating past +/ = 90 degrees pitch, and no unwanted roll!! J =20 Any help would be greatly appreciated. =20 Thanks, =20 Stephan 
From: Paul_F<irth@sc...>  20030829 15:47:59

You need either=20 a) quaternions where quat =3D your new orientation, quat0 =3D old orientation, vector =3D = delta=20 direction quat.w =3D 0.5 * (quat0.x * vector.x + quat0.y * vector.y + quat0.z *=20 vector.z); quat.x +=3D 0.5 * (quat0.w * vector.x  quat0.z * vector.y + quat0.y *=20 vector.z); quat.y +=3D 0.5 * (quat0.z * vector.x + quat0.w * vector.y  quat0.x *=20 vector.z); quat.z +=3D 0.5 * (quat0.x * vector.y  quat0.y * vector.x + quat0.w *=20 vector.z); b) store a camera matrix and rotate each axis by the others and and three= delta angles: where ROT =3D axis, angle rotate up =3D up ROT right by delta pitch right =3D right ROT up delta heading forward =3D CROSS right and up right =3D right ROT forward delta bank up =3D up ROT forward delta bank Either way you loose the concept of absolute angles, you must work instead= with delta angles. The quat is the more compact and less prone to error. Both will need=20 correcting for numerical drift the quat can simply be renormalised but the matrix will need to be=20 orthonormalised (more expensive). Cheers, Paul. "Stephan Rose" <kermos@...> Sent by: gdalgorithmslistadmin@... 30/08/2003 15:43 Please respond to gdalgorithmslist =20 To: "GD Algorithms" <gdalgorithmslist@...> cc:=20 Subject: [Algorithms] Camera Anyone know a good tutorial on cameras? I've tried different methods now=20 and none of them have had quite the result I'm looking for. =20 I either end up with a camera that suffers from gimbal lock, *or* can't rot= ate past 90/+90 degrees pitch. =20 Only thing I store is my position and forward vector. Right/Up vectors are= recreated everytime. =20 Basically what I'd like is a camera that I can turn in any direction,=20 without suffering from gimbal lock, or having trouble rotating past +/ 90= degrees pitch, and no unwanted roll!! J =20 Any help would be greatly appreciated. =20 Thanks, =20 Stephan ********************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify postmaster@... This footnote also confirms that this email message has been checked for all known viruses. ********************************************************************** SCEE 2003 
From: Stephan Rose <kermos@be...>  20030829 14:53:58

Anyone know a good tutorial on cameras? I've tried different methods now and none of them have had quite the result I'm looking for. I either end up with a camera that suffers from gimbal lock, *or* can't rotate past 90/+90 degrees pitch. Only thing I store is my position and forward vector. Right/Up vectors are recreated everytime. Basically what I'd like is a camera that I can turn in any direction, without suffering from gimbal lock, or having trouble rotating past +/ 90 degrees pitch, and no unwanted roll!! :) Any help would be greatly appreciated. Thanks, Stephan 
From: PeterPike Sloan <ppsloan@wi...>  20030829 10:28:17

I think calculating the vertex color in the shader is the most efficient = way to do things  you don't need to store the PRT coefficients as = floats though, I've used shorts and bytes effectively (you might want to = use more precision for the lower frequency bands though. You also want = to maximize the precision if you use signed integer formats...) Also if = you use compression techniques you don't need as many coefficients (and = you can defenitly quantize things  I tend to use signed shorts, but I = think the 8 bit formats work ok if you maximize there precision...) =20 Dynamic VB's have much lower performance vs. static ones (you would have = to use the former if you do the shading on the CPU), but if you are = using them anyways (ie: skinning on the CPU, etc.) it might be easiest = to do the shading on the CPU as well. =20 PeterPike Sloan ________________________________ From: gdalgorithmslistadmin@... on behalf of Chris = Haarmeijer Sent: Fri 8/29/2003 2:24 AM To: gdalgo Subject: [Algorithms] PRT and SH lighting I'm busy implementing precomputed radiance transfer but how is the = runtime lighting best implemented? Recompute the vertexcolors when lights are changed (recalculate the vertex color stream in each mesh using the = light and vertex coefficients)? If I'm using 4 bands, it would be 16 3D floats extra per vertex if I want to calculate the final vertexcolor in a vertexshader...... Chris  Keep IT Simple Software Van Alphenstraat 12 7514 DD Enschede W: http://www.keepitsimple.nl E: mailto:info@... T: +31 53 4356687  This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ GDAlgorithmslist mailing list GDAlgorithmslist@... https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=3D6188 
From: Chris Haarmeijer <c.haarmeijer@ke...>  20030829 09:22:23

I'm busy implementing precomputed radiance transfer but how is the runtime lighting best implemented? Recompute the vertexcolors when lights are changed (recalculate the vertex color stream in each mesh using the light and vertex coefficients)? If I'm using 4 bands, it would be 16 3D floats extra per vertex if I want to calculate the final vertexcolor in a vertexshader...... Chris  Keep IT Simple Software Van Alphenstraat 12 7514 DD Enschede W: http://www.keepitsimple.nl E: mailto:info@... T: +31 53 4356687 
From: Dan Baker <danbaker@wi...>  20030829 01:07:35

There was a paper in SIGGRAPH where they precomputed the radiance functions for a set of different poses and basically just lerped (it might have been fancier then that) between them. It looked pretty good but required a ton of precompute time (They were sayinng things like 90 hours... ) An interesting research project would be to compute the radiance maps for each keyframe and then keep only those that are important. I think with just a few poses you could fix the major problems like the lips not getting brighter and darker when a character speeks. I really think this would look pretty good, but I have not seen anyone do it yet. Dan Original Message From: gdalgorithmslistadmin@... [mailto:gdalgorithmslistadmin@...] On Behalf Of Tom Forsyth Sent: Thursday, August 28, 2003 2:22 PM To: gdalgorithmslist@... Subject: RE: [Algorithms] Blending Spherical harmonics with traditionnal lighting It's worth mentioning that animated objects can be made to work, but the lighting model may not change according to the animation. So in the example of a person wearing a baggy shirt, the folds and wrinkles in the shirt will still do the right thing, because locally the animation doesn't change how they react to light very much. But the more global effects  such as the arm shadowing the torso in certain poses  they're much harder to represent. Probably the most important feature from a perceptual standpoint is the face. The really good thing about the face is that although it does animate, it doesn;t animate all that much. Probably the major animation is the jaw moving up and down, and that accounts for most of the changing in lighting (how much it shadows the neck). Things like eyebrows moving, smiling, etc  none of those change the lighting values very much, and the most prominent feature as far as lighting is concerned  the nose  doesn't have any moving parts very near it, except maybe bits of the bottom lip. So in fact the lighting on the face can use really cool stuff like PRT, and you simply ignore the fact that the lighting is not perfect, because all the lowhanging fruit (the BRDF of skin, subsurface scattering effects, the "halo" caused by whiskers and hairs when the light is behind the subject, the shadowing of the nose)  all that still works fine. So when PeterPike says "PRT doesn't work for animated objects", he's being too modest. It works just fine  it doesn't produce random junk or anything scary like that. It just doesn't change it behaviour according to the animation. But in many cases it's still better than nothing at all. And of course you can happily combine it with conventional techniques like stencil volumes or stencil buffers to add those largescale selfshadowing effects back in. TomF. > Original Message > From: gdalgorithmslistadmin@...=20 > [mailto:gdalgorithmslistadmin@...] On=20 > Behalf Of Willem H. de Boer > Sent: 28 August 2003 17:14 > To: gdalgorithmslist@... > Subject: RE: [Algorithms] Blending Spherical harmonics with=20 > traditionnal lighting >=20 >=20 > If you are using SH to represent irradiance environment > maps, like Ramamoorthi et al.'s "An Efficient Representation > of Irradiance Environment Maps" then it scales very well > to deformable meshes. Just think about it, you have pre > computed the convolution of the lighting function L(s) > with the cosinetransfer A(s), and you are feeding it > normals. So the only thing that would need to be recalculated > are the normals of every vertex on the mesh. >=20 > If, however, you are using SH for precomputed radiance > transfer, as in Sloan et al.'s "Precomputed Radiance Transfer > , [...]" then it gets a bit tricky. For diffuse surfaces, > it would imply recalculating the visibility function V(s) > for every vertex of the mesh (if you are storing a coeff. > vector pervertex that is). Considering the naive approach > of calculating V(s) in the first place is stochastic > raytracing, I wouldn't recommend it ;) >=20 > I believe that there exist some papers on using PRT with > deformable meshes, but titles of papers elude me. >=20 > >My main concern is=20 > >to how well SH > >lighting blends in with traditionnal dot lighting (or I=20 > >should say how > >traditionnal lighting blends in with SH lighting). >=20 > Tom Forsyth did a talk at this year's GDCE on this > very problem. Also, there have been lots of discussions > on this list involving Tom, that talked about this. >=20 > HTH, >=20 > Willem >=20 >=20 >  > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > GDAlgorithmslist mailing list > GDAlgorithmslist@... > https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=3D6188 >=20  This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ GDAlgorithmslist mailing list GDAlgorithmslist@... https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=3D6188 
From: Tom Forsyth <tom.forsyth@bl...>  20030828 21:55:21

> One thing you can do is represent the light that hits an object  this > is doing spherical harmonic _irradiance_. Actually PeterPike pointed out today that this is technically called "radiance". If you do a convolution against the cosine kernel (the familiar max(0,N.L) Lambert lighting equation), then _that_ is "irradiance". The difference in code is that a couple of constants change value (though I've been unwittingly using the radiance values rather than the irradiance values for the last six months, and the lighting wasn't that far wrong :). TomF. > Original Message > From: gdalgorithmslistadmin@... > [mailto:gdalgorithmslistadmin@...] On > Behalf Of Tom Forsyth > Sent: 28 August 2003 22:15 > To: gdalgorithmslist@... > Subject: RE: [Algorithms] Blending Spherical harmonics with > traditionnal lighting > > > Careful there  there's no such thing as "SH lighting". SHs > are just an > image representation (but on a sphere, not a 2D rectangle), > and you can > do a lot of different things with them, in the same way that "texture > mapping" doesn't mean a great deal when there are so many > things you can > do with a texture. They're a bit like a cubemap, only not  > the data is > stored in the frequency domain (like MP3s and JPEGs) rather than the > spacial domian (like WAVs and TGAs). > > One thing you can do is represent the light that hits an object  this > is doing spherical harmonic _irradiance_. This is something that is > extremely practical for games, and indeed at Muckyfoot we're > using them > in all our lighting techniques. Dynamic and animated objects work just > fine. > > Another thing you can do with them is represent a mesh's > _response_ to a > certain pattern of light. So the most primitive form of this > is using a > normal with an N.L value. But you can usen an SH instead and represent > more complex functions such as local selfshadowing. > > At the upper end you can do PeterPike Sloan's stuff  Precomputed > Radiance Transfer. This includes a lot of very cool stuff like > subsurface scattering, caustics, glassy reflections, BRDFs  a whole > shopping list of cool graphics features. And the cool thing > is that with > his new compression work it's really cheap to do. However, > _this_ is the > algorithm that has trouble with animated objects. > > Literally eight hours ago, PeterPike and I gave our talk on > this stuff > at GDC Europe. I'll put my slides on my website in a few days or so > (http://www.tomforsyth.pwp.blueyonder.co.uk/papers.html), and I'm sure > PeterPike will add his to his website when he gets back to > the US, and > will post the details here. > > TomF. > > > > Original Message > > From: gdalgorithmslistadmin@... > > [mailto:gdalgorithmslistadmin@...] On > > Behalf Of Francis Boivin > > Sent: 28 August 2003 16:38 > > To: gdalgorithmslist@... > > Subject: [Algorithms] Blending Spherical harmonics with > > traditionnal lighting > > > > > > Like a lot of people lately, I've been going trough the > > various SH papers > > lying around the internet to learn what the fuss is all about > > when it comes > > to spherical harmonics. I've seen some pretty convincing > > demos (on PS2 and > > in the DX9 summer Beta 2) and I'm about to jump on the SH > > bandwagon but > > there's still one major thing I haven't seen covered. > > > > As it is right now, SH can't be applied to meshes that are > deformed at > > runtime (ie: morphing, skinning, etc) although I know it's > an area of > > research that is pretty active. With this in mind it means > > that SH lighting > > can only be applied to a static scene. My main concern is to > > how well SH > > lighting blends in with traditionnal dot lighting (or I > should say how > > traditionnal lighting blends in with SH lighting). All demos > > out there > > aren't typical game scenes and I still wonder if it really > > applies to games > > (I'm pretty convinced that it's the next step but what do > you think!). > > > > Furthermore, does SH applies to a scene where, for example > you have an > > object lying on the floor and the object can be picked up and > > moved around? > > Can both object be lighted using SH or does SH lighting only > > applies to > > static scenery? > > > > I would just like to hear any comments you have to make about > > SH integration > > in games; how it blends in with traditionnal lighting models, > > on what kind > > of objects SH can be used, etc. > > > > Thanks! > > > > Francis > > > > > >  > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > GDAlgorithmslist mailing list > GDAlgorithmslist@... > https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=6188 > 
From: Tom Forsyth <tom.forsyth@bl...>  20030828 21:22:29

It's worth mentioning that animated objects can be made to work, but the lighting model may not change according to the animation. So in the example of a person wearing a baggy shirt, the folds and wrinkles in the shirt will still do the right thing, because locally the animation doesn't change how they react to light very much. But the more global effects  such as the arm shadowing the torso in certain poses  they're much harder to represent. Probably the most important feature from a perceptual standpoint is the face. The really good thing about the face is that although it does animate, it doesn;t animate all that much. Probably the major animation is the jaw moving up and down, and that accounts for most of the changing in lighting (how much it shadows the neck). Things like eyebrows moving, smiling, etc  none of those change the lighting values very much, and the most prominent feature as far as lighting is concerned  the nose  doesn't have any moving parts very near it, except maybe bits of the bottom lip. So in fact the lighting on the face can use really cool stuff like PRT, and you simply ignore the fact that the lighting is not perfect, because all the lowhanging fruit (the BRDF of skin, subsurface scattering effects, the "halo" caused by whiskers and hairs when the light is behind the subject, the shadowing of the nose)  all that still works fine. So when PeterPike says "PRT doesn't work for animated objects", he's being too modest. It works just fine  it doesn't produce random junk or anything scary like that. It just doesn't change it behaviour according to the animation. But in many cases it's still better than nothing at all. And of course you can happily combine it with conventional techniques like stencil volumes or stencil buffers to add those largescale selfshadowing effects back in. TomF. > Original Message > From: gdalgorithmslistadmin@... > [mailto:gdalgorithmslistadmin@...] On > Behalf Of Willem H. de Boer > Sent: 28 August 2003 17:14 > To: gdalgorithmslist@... > Subject: RE: [Algorithms] Blending Spherical harmonics with > traditionnal lighting > > > If you are using SH to represent irradiance environment > maps, like Ramamoorthi et al.'s "An Efficient Representation > of Irradiance Environment Maps" then it scales very well > to deformable meshes. Just think about it, you have pre > computed the convolution of the lighting function L(s) > with the cosinetransfer A(s), and you are feeding it > normals. So the only thing that would need to be recalculated > are the normals of every vertex on the mesh. > > If, however, you are using SH for precomputed radiance > transfer, as in Sloan et al.'s "Precomputed Radiance Transfer > , [...]" then it gets a bit tricky. For diffuse surfaces, > it would imply recalculating the visibility function V(s) > for every vertex of the mesh (if you are storing a coeff. > vector pervertex that is). Considering the naive approach > of calculating V(s) in the first place is stochastic > raytracing, I wouldn't recommend it ;) > > I believe that there exist some papers on using PRT with > deformable meshes, but titles of papers elude me. > > >My main concern is > >to how well SH > >lighting blends in with traditionnal dot lighting (or I > >should say how > >traditionnal lighting blends in with SH lighting). > > Tom Forsyth did a talk at this year's GDCE on this > very problem. Also, there have been lots of discussions > on this list involving Tom, that talked about this. > > HTH, > > Willem > > >  > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > GDAlgorithmslist mailing list > GDAlgorithmslist@... > https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=6188 > 