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

_{Feb}

_{Mar}
(11) 
_{Apr}
(46) 
_{May}
(65) 
_{Jun}
(85) 
_{Jul}
(94) 
_{Aug}
(99) 
_{Sep}
(62) 
_{Oct}
(58) 
_{Nov}
(85) 
_{Dec}
(39) 

2001 
_{Jan}
(90) 
_{Feb}
(29) 
_{Mar}
(90) 
_{Apr}
(96) 
_{May}
(78) 
_{Jun}
(58) 
_{Jul}
(44) 
_{Aug}
(65) 
_{Sep}
(40) 
_{Oct}
(38) 
_{Nov}
(79) 
_{Dec}
(63) 
2002 
_{Jan}
(53) 
_{Feb}
(61) 
_{Mar}
(43) 
_{Apr}
(53) 
_{May}
(35) 
_{Jun}
(59) 
_{Jul}
(18) 
_{Aug}
(12) 
_{Sep}
(28) 
_{Oct}
(61) 
_{Nov}
(54) 
_{Dec}
(23) 
2003 
_{Jan}
(16) 
_{Feb}
(42) 
_{Mar}
(38) 
_{Apr}
(35) 
_{May}
(20) 
_{Jun}
(9) 
_{Jul}
(10) 
_{Aug}
(30) 
_{Sep}
(22) 
_{Oct}
(32) 
_{Nov}
(25) 
_{Dec}
(21) 
2004 
_{Jan}
(39) 
_{Feb}
(36) 
_{Mar}
(59) 
_{Apr}
(32) 
_{May}
(21) 
_{Jun}
(4) 
_{Jul}
(8) 
_{Aug}
(21) 
_{Sep}
(11) 
_{Oct}
(21) 
_{Nov}
(22) 
_{Dec}
(19) 
2005 
_{Jan}
(62) 
_{Feb}
(24) 
_{Mar}
(17) 
_{Apr}
(16) 
_{May}
(16) 
_{Jun}
(17) 
_{Jul}
(26) 
_{Aug}
(14) 
_{Sep}
(13) 
_{Oct}
(8) 
_{Nov}
(23) 
_{Dec}
(20) 
2006 
_{Jan}
(41) 
_{Feb}
(18) 
_{Mar}
(21) 
_{Apr}
(47) 
_{May}
(13) 
_{Jun}
(33) 
_{Jul}
(32) 
_{Aug}
(21) 
_{Sep}
(27) 
_{Oct}
(34) 
_{Nov}
(19) 
_{Dec}
(46) 
2007 
_{Jan}
(21) 
_{Feb}
(26) 
_{Mar}
(13) 
_{Apr}
(22) 
_{May}
(5) 
_{Jun}
(19) 
_{Jul}
(56) 
_{Aug}
(43) 
_{Sep}
(37) 
_{Oct}
(31) 
_{Nov}
(53) 
_{Dec}
(22) 
2008 
_{Jan}
(74) 
_{Feb}
(31) 
_{Mar}
(15) 
_{Apr}
(35) 
_{May}
(23) 
_{Jun}
(26) 
_{Jul}
(17) 
_{Aug}
(27) 
_{Sep}
(35) 
_{Oct}
(30) 
_{Nov}
(29) 
_{Dec}
(17) 
2009 
_{Jan}
(35) 
_{Feb}
(39) 
_{Mar}
(44) 
_{Apr}
(28) 
_{May}
(20) 
_{Jun}
(28) 
_{Jul}
(49) 
_{Aug}
(53) 
_{Sep}
(23) 
_{Oct}
(13) 
_{Nov}
(12) 
_{Dec}
(11) 
2010 
_{Jan}
(45) 
_{Feb}
(28) 
_{Mar}
(41) 
_{Apr}
(11) 
_{May}

_{Jun}

_{Jul}

_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 


1
(1) 
2
(1) 
3
(5) 
4
(1) 
5
(4) 
6

7
(2) 
8

9
(2) 
10
(6) 
11
(9) 
12
(6) 
13
(2) 
14
(3) 
15
(8) 
16
(8) 
17
(1) 
18
(4) 
19
(1) 
20
(2) 
21

22
(1) 
23
(3) 
24
(6) 
25
(5) 
26
(1) 
27
(1) 
28
(3) 
29
(2) 
30
(1) 
31
(1) 



From: Stephen J Baker <sjbaker@li...>  20010125 15:46:17

On Thu, 25 Jan 2001, [iso88591] Flav Vara wrote: > I just cann't understand what have i to do. > I know c++ and i want to do some realtime animations > using LINUX. > Can someone explain me what do i need to begin? (Mesa? > OpenGL? GLUT? ) You *need* some kind of OpenGL API, the GLUtilities library, and Xwindows. Since you are just starting, you'll certainly want to use GLUT to hide all the nasty Xwindows issues until you are ready to climb *that* learning curve. Now, for an OpenGL API, what you need depends on what (if any) 3D graphics card you have. Essentially, if you have an nVidia card, you should probably head over to http://www.nvidia.com and grab a copy of their OpenGL for Linux. If you have any other 3D card then you'll need Mesa from http://www.mesa3d.org. The Mesa site is also a good place to get the GLutilities library (libGLU.so) and GLUT (libglut.a or .so). There is an alternative (OpenSource) version of GLUT called 'freeglut' that you can get from http://freeglut.sourceforge.net. If you have a reasonably recent Linux distro, you'll find that Mesa, GLU and GLUT are already installed...although Mesa probably won't be set up for your 3D card  so it'll run in software only (SLOW!). Some Linux distro's install those libraries in /usr/X11/lib  but that's **WRONG**, they should be in /usr/lib  if that happens to you, use symbolic links to make it *look* like they are in /usr/lib If you have to replace/upgrade Mesa, please try hard to be sure that you don't leave the old version lying around somewhere (like in /usr/X11/lib) because some programs that do a search for a valid OpenGL/Mesa library will inevitably find the wrong one and end up running with the wrong driver. Enjoy!  Steve Baker (817)6192657 (Vox/VoxMail) L3Com/Link Simulation & Training (817)6192466 (Fax) Work: sjbaker@... http://www.link.com Home: sjbaker1@... http://web2.airmail.net/sjbaker1 
From: <plastic_fluid@ya...>  20010125 10:21:17

I just cann't understand what have i to do. I know c++ and i want to do some realtime animations using LINUX. Can someone explain me what do i need to begin? (Mesa? OpenGL? GLUT? ) ____________________________________________________________ Do You Yahoo!? Get your free @yahoo.co.uk address at http://mail.yahoo.co.uk or your free @yahoo.ie address at http://mail.yahoo.ie 
From: Brian Paul <brianp@va...>  20010125 03:55:42

Rouben Rostamian wrote: > > Brian, re your message: > > > > When we transform the space with an arbitrary linear mapping > > > P : R^3 > R^3, i.e., y = P x, normals to surfaces transform > > > according to: > > > > > > N'(y) = P' N(x) > > > > > > where N(x) is the old normal, N'(y) is the new normal, and > > > > > > P' = inverse of transpose of P > > > > > > Does GL_NORMALIZE apply this formula correctly? > > > > Yes, that's what the OpenGL spec calls for. > > > > I believe the transpose is just a technicality of whether you > > represent normals as row or column vectors in the expression. > > That's correct. With row vectors the transpose goes away. > But then the order of multiplication reverses, that is, N > muptiplies P^1 from the left. > > > It's been a long time since I worked through the arithmetic but > > I seem to recall that transforming the normal by the transpose > > of the modelview's inverse still isn't good enough to correctly > > transform a surface normal when the modelview matrix has a non > > uniform scale. > > > > That is, the transformed normal may not be exactly perpendicular to > > the surface, as it was before the scale. > > There may be an angle (pun! hehe) within Mesa's implementation > which I am not aware of. But the formula N' = P' N given above > is easily derived  it's a matter of applying the chain rule of > differentiation  and gives the /exact/ normal to the transformed > surface for ay arbitrary linear transformation P. Yup, you're right. I did the arithmetic for myself. I don't know why I had it in my head that this didn't always work... Brian 
From: Rouben Rostamian <rostamian@um...>  20010125 01:26:03

Brian, re your message: > > When we transform the space with an arbitrary linear mapping > > P : R^3 > R^3, i.e., y = P x, normals to surfaces transform > > according to: > > > > N'(y) = P' N(x) > > > > where N(x) is the old normal, N'(y) is the new normal, and > > > > P' = inverse of transpose of P > > > > Does GL_NORMALIZE apply this formula correctly? > > Yes, that's what the OpenGL spec calls for. > > I believe the transpose is just a technicality of whether you > represent normals as row or column vectors in the expression. That's correct. With row vectors the transpose goes away. But then the order of multiplication reverses, that is, N muptiplies P^1 from the left. > It's been a long time since I worked through the arithmetic but > I seem to recall that transforming the normal by the transpose > of the modelview's inverse still isn't good enough to correctly > transform a surface normal when the modelview matrix has a non > uniform scale. > > That is, the transformed normal may not be exactly perpendicular to > the surface, as it was before the scale. There may be an angle (pun! hehe) within Mesa's implementation which I am not aware of. But the formula N' = P' N given above is easily derived  it's a matter of applying the chain rule of differentiation  and gives the /exact/ normal to the transformed surface for ay arbitrary linear transformation P.  Rouben Rostamian <rostamian@...> 
From: Brian Paul <brianp@va...>  20010125 00:13:27

Rouben Rostamian wrote: > > Brian, thanks for your comments about Mesa's scaling routines. > Re your remark: > > > Also note that the regular GL_NORMALIZE operation isn't always > > going to help with nonuniform scales either. With shapes like > > cylinders and cubes it just happens to do the job. But with other > > objects a nonuniform scale is going to transform normal vectors in > > a way which is not consistent with the underlying surface geometry. > > The correct transformation of normals under arbitrary scaling should > not be hard to implement in Mesa. I know how to do it mathematically, > but I don't know enough about Mesa's internals to write a patch for > its code. > > When we transform the space with an arbitrary linear mapping > P : R^3 > R^3, i.e., y = P x, normals to surfaces transform > according to: > > N'(y) = P' N(x) > > where N(x) is the old normal, N'(y) is the new normal, and > > P' = inverse of transpose of P > > Does GL_NORMALIZE apply this formula correctly? Yes, that's what the OpenGL spec calls for. I believe the transpose is just a technicality of whether you represent normals as row or column vectors in the expression. > Important: > 1. In general N'(y) and N(x) are not parallel! > 2. In general N'(y) is not of unit length. Normalize > by dividing it by its own length. > > > The behaviour with Mesa 3.2, 3.2.1, 3.3, 3.4, and 3.5 appears > > identical. With Mesa 3.1, however, the results are different > > but I'm not sure it can be called better or worse. It may > > actually be that Mesa 3.1 was broken. > > I don't think "better" or "worse" are the proper adjectives, > since right or wrong is not a matter of degrees :) > > Actually, the behavior of Mesa3.4 is correct and Mesa3.1 is wrong. > > For a simple demo program which I mentioned in my previous post, > I can analytically calculate the exact location of the highlight. > Mesa3.4 puts the highlight in the theoretically correct place. > Mesa3.1's is off quite a bit. > > But after the scene is scaled, both highlight are wrong :( It's been a long time since I worked through the arithmetic but I seem to recall that transforming the normal by the transpose of the modelview's inverse still isn't good enough to correctly transform a surface normal when the modelview matrix has a non uniform scale. That is, the transformed normal may not be exactly perpindicular to the surface, as it was before the scale. If I get a few minutes tonight I'll try going through the math by hand to refresh my memory on this. Maybe someone else here has an authoritive answer. Brian 