cycy@isl1.ri.cmu.edu (Scum) (12/08/89)
First, I should, since I posted the question here, answer why my system wasn't working when we got our upgrade. It turns out that, unbeknownst to me, we only got the eoe and nfs upgrades; we didn't get the development package. Thanks to the SGI people who responded to me. I really appreciate the fact that you folks read this board and try to help us with the problems here. Now, my system is a happy system once again, and running fine. Or at least it was until a new feature was added. We want to use dgl (Distributed Graphics Library) and have things appear on another monitor's screen. That works; however, on the local screen there is a problem with lighting in one of the windows, and it's pretty weird. The objects appear, and they appear in the correct material colour. However, the lighting model or the lights seem to be screwed up. The objects are just coloured flat now. No shadows, no shading, no perspective, nothing. This worked in gl, but it seems there is something missing in dgl. By the way, normals are set. I tried depth cueing and z-buffering with dgl on the local, remote and both screens, and those worked. The lighting works when I link gl, but not dgl. Of course, the graphics don't get distributed in gl. I called the graphics hotline (in fact, they're the ones who suggested these tests), and they're working on the problem. However, given as I'm desparate for time, I thought I'd post on here to see if anybody had any clues on this problem. Perhaps somebody has encountered it before, for instance. Thanks for any help. -- Chris. -- -- Chris. (cycy@isl1.ri.cmu.edu) "People make me pro-nuclear." -- Margarette Smith
tarolli@riva.esd.sgi.com (Gary Tarolli) (12/08/89)
From postnews Thu Dec 7 15:18:37 1989 In article <7254@pt.cs.cmu.edu>, cycy@isl1.ri.cmu.edu (Scum) writes: > > We want to use dgl (Distributed Graphics Library) and have things appear > on another monitor's screen. That works; however, on the local screen there > is a problem with lighting in one of the windows, and it's pretty weird. The > objects appear, and they appear in the correct material colour. However, the > lighting model or the lights seem to be screwed up. The objects are just > coloured flat now. No shadows, no shading, no perspective, nothing. This worked > in gl, but it seems there is something missing in dgl. By the way, normals are > set. I tried depth cueing and z-buffering with dgl on the local, remote and > both screens, and those worked. The lighting works when I link gl, but not dgl. I think you stumbled across one of the commands that behave slightly differentlyin the GL than in the DGL. The command is lmdef, and the GL ignores the third parameter whereas the DGL requires it. People normally, by habit, put 0 as the 3rd parameter and the GL works fine. If you read the man page , the 3rd parameter is supposed to be the number of floats in the 4th argument. The DGL looks at this value to determine how many floats to send. Thus if you are like most people and set it to 0, the DGL will send 0 floats and thus lmdef wont work and the result will be just like what you are experiencing - total weirdness. There is also a slight difference in behavior if you use NULL for the 4th parameter and dont specify 0 for the 3rd. I dont suspect this is your problem, however. Check the 3rd parameter and make sure it is set correctly, that should fix your problem. -- Gary Tarolli
cycy@isl1.ri.cmu.edu (Scum) (12/08/89)
In article <45948@sgi.sgi.com>, tarolli@riva.esd.sgi.com (Gary Tarolli) writes: > In article <7254@pt.cs.cmu.edu>, cycy@isl1.ri.cmu.edu (Scum) writes: > > We want to use dgl (Distributed Graphics Library) and have things appear > > on another monitor's screen. That works; however, on the local screen there > > is a problem with lighting in one of the windows, and it's pretty weird. The > > objects appear, and they appear in the correct material colour. However, the > > lighting model or the lights seem to be screwed up. The objects are just > > coloured flat now. No shadows, no shading, no perspective, nothing. This worked > > in gl, but it seems there is something missing in dgl. By the way, normals are > > I think you stumbled across one of the commands that behave slightly differentlyin the GL than in the DGL. The command is lmdef, and the GL ignores the third > parameter whereas the DGL requires it. People normally, by habit, put 0 as > the 3rd parameter and the GL works fine. If you read the man page , the 3rd > parameter is supposed to be the number of floats in the 4th argument. The > DGL looks at this value to determine how many floats to send. Thus if you > are like most people and set it to 0, the DGL will send 0 floats and thus > Check the 3rd parameter and make sure it is set correctly, that should fix > your problem. > Gary Tarolli That was it! Actually, I had miscounted the parameters (I skipped a line in when I was counting the elements in the array) and had used 10 instead of 14 for the third parameter. Thanks a million!!!!!!!!! -- Chris. -- -- Chris. (cycy@isl1.ri.cmu.edu) "People make me pro-nuclear." -- Margarette Smith