kuba@hpfcdj.HP.COM (Kathy Kuba) (09/05/90)
I recently received my SGI 210GTX workstation (running 3.3) and began porting code from my 120GTX (3.2). All went well, except that my light sources did not illuminate my objects. Upon further investigation, I discovered that moving my POSITION from 0 0 1 0 to 0 0 -1 0 fixed the problem. Has any one else seen this?? I really don't want to do keep different versions of code for each machine. The SGI Hotline graphics expert I talked with said they "fixed" the light sources so backface lighting would work properly. All other SGI graphics workstations I've used have the positive z axis pointing out of the screen, so a light at 0 0 1 0 is shining from behind to the origin. If they believe this is really a "fix", then why didn't they make it transparent to the user? The answer I received, "change your code", is not acceptable. Comments suggestions, and alternate solutions welcome! Kathy
kurt@cashew.asd.sgi.com (Kurt Akeley) (09/07/90)
In article <17450005@hpfcdj.HP.COM>, kuba@hpfcdj.HP.COM (Kathy Kuba) writes: |> I recently received my SGI 210GTX workstation (running 3.3) and began |> porting code from my 120GTX (3.2). All went well, except that my light |> sources did not illuminate my objects. Upon further investigation, I |> discovered that moving my POSITION from 0 0 1 0 to 0 0 -1 0 fixed the |> problem. Has any one else seen this?? I really don't want to do keep |> different versions of code for each machine. The SGI Hotline graphics |> expert I talked with said they "fixed" the light sources so backface |> lighting would work properly. All other SGI graphics workstations I've |> used have the positive z axis pointing out of the screen, so a light |> at 0 0 1 0 is shining from behind to the origin. If they believe this |> is really a "fix", then why didn't they make it transparent to the user? |> The answer I received, "change your code", is not acceptable. Comments |> suggestions, and alternate solutions welcome! |> |> |> Kathy You have received some misinformation. The object coordinate system has been and remains right handed - positive Z will always extend out of the screen toward you. The default light position is and will remain 0,0,1,0. You don't need to specify this to get it. Probably the most common problem encountered with lighting is that light positions are transformed by the current ModelView matrix when the light is bound (i.e. when lmbind(LIGHTn,foo) is called). As a result you must be very careful about what ModelView matrix is present when a light is bound. In releases previous to 3.3, the ModelView matrix was undefined until it was first loaded (typically with an identity matrix). In release 3.3, the ModelView matrix is initialized to identity when mmode(MVIEWING) is first called (putting the GL into multimatrix mode, required for lighting and many other advanced GL features). It is likely that some error has been made in the matrix/lmbind sequence, and that this error is affected by the differences between the 3.2 and 3.3 software releases. Of course there really may be a bug in the GTX 3.3 lighting code, but I haven't noticed any problems with my machine (a 3.3 GTX), so it's worth going over your code carefully. -- kurt
kuba@hpfcdj.HP.COM (Kathy Kuba) (09/12/90)
> Probably the most common problem encountered with lighting is that light > positions are transformed by the current ModelView matrix when the light is > bound (i.e. when lmbind(LIGHTn,foo) is called). As a result you must be > very careful about what ModelView matrix is present when a light is bound. > In releases previous to 3.3, the ModelView matrix was undefined until it was > first loaded (typically with an identity matrix). In release 3.3, the > ModelView matrix is initialized to identity when mmode(MVIEWING) is first > called (putting the GL into multimatrix mode, required for lighting and many > other advanced GL features). It is likely that some error has been made in > the matrix/lmbind sequence, and that this error is affected by the differences > between the 3.2 and 3.3 software releases. > thanks for the pointer! it ended up being a sequence error: i was specifying my ortho before my mmode. rearranging these on 3.3 fixed the problem, and adding an additional loadmatrix(identity) solved it on 3.2. my 3.2 code also runs fine on 3.3. thanks again. kathy