Dan Karron@UCBVAX.BERKELEY.EDU (04/28/91)
I am trying to use the bgnqstrip and endqstrip commands to draw filled squares. I keep getting a figure that looks like it is starting at the local origin, then drawing my square, then returns to the origin. I have worked around it by using the polygon functions, but I was wondering if this was a known problem. My data is good because I get the expected results from the poly calls. Cheers! dan. | karron@nyu.edu (e-mail alias ) Dan Karron, Research Associate | | Phone: 212 263 5210 Fax: 212 263 7190 New York University Medical Center | | 560 First Avenue Digital Pager <1> (212) 397 9330 | | New York, New York 10016 <2> 10896 <3> <your-number-here> |
dprmjc@prism.ARCO.COM (M. J. Cole) (04/29/91)
In article <9104280445.AA10669@karron.med.nyu.edu>, Dan Karron@UCBVAX.BERKELEY.EDU writes: > > I am trying to use the bgnqstrip and endqstrip commands to draw > filled squares. > > I keep getting a figure that looks like it is starting at the > local origin, then drawing my square, then returns to the origin. > > I have worked around it by using the polygon functions, but > I was wondering if this was a known problem. My data is good because > I get the expected results from the poly calls. > Two possible problems: 1) qstrips require a different vertex ordering than polygons. For polygon: 1--2 For quadrilateral: 1--3 | | | | 0--3 0--2 Quoting from page 2-27 of the Graphics Library Programming Guide: "Note that the vertex order required by quad strips matches the order required for `equivalent' triangle meshes." 2) If you are using lighting on a Personal Iris DO NOT USE triangle meshes or quadrilateral strips (weird things will happen). This has been a "known bug" for so long, I wonder why they don't put a notice in the manuals. :-) ............................................................................... Mary J. Cole ARCO Oil & Gas Company mjcole@arco.com 2300 W. Plano Parkway; PRC-D3239; (214)754-6857 Plano, TX 75075 ............................................................................... I'm continually AMAZED at th'breathtaking effects of WIND EROSION!! -ZIPPY ...............................................................................
ciemo@bananapc.wpd.sgi.com (Dave Ciemiewicz) (04/29/91)
In article <9104280445.AA10669@karron.med.nyu.edu>, Dan Karron@UCBVAX.BERKELEY.EDU writes: |> |> I am trying to use the bgnqstrip and endqstrip commands to draw |> filled squares. |> |> I keep getting a figure that looks like it is starting at the |> local origin, then drawing my square, then returns to the origin. |> |> I have worked around it by using the polygon functions, but |> I was wondering if this was a known problem. My data is good because |> I get the expected results from the poly calls. |> |> Cheers! |> Quad-strips are a bit tricky for the uninitiated. The following example may clarify things enough for you to be successful. EXAMPLE To create a quad strip for the following diagram: v0 v2 v4 (0,1,0) (1,1,0) (2,1,0) o-----o-----o | | | | | | | | | o-----o-----o (0,0,0) (1,0,0) (2,0,0) v1 v3 v5 thus drawing the quadrilaterals (v0, v1, v3, v2) and (v2, v3, v5, v4), you should specify the vertices in the order: bgnqstrip(); v3f(v0); v3f(v1); v3f(v2); v3f(v3); v3f(v4); v3f(v5); endqstrip(); Notice that this zigzag traversal is special: v0 v2 v4 (0,1,0) (1,1,0) (2,1,0) o _ o _ o | / | / | | / | / | v / v / v o o o (0,0,0) (1,0,0) (2,0,0) v1 v3 v5 v0, v1, and v2 (in this example) specify a normal for backface removal which is pointing out of the screen or page toward you. Hope this helps. -- __ * __ _ __ ___ / \ / / / / \/ \/ \ "Me brain hurts!" / / \/ / /\ / / --- P.T. Gumby \___/\__/\_/ /_/ / \__/ *
tjh@ouzo.bu.edu (Tim Hall) (04/30/91)
In article <1991Apr29.141450.4737@Arco.COM> dprmjc@prism.ARCO.COM (M. J. Cole) writes: > > 2) If you are using lighting on a Personal Iris DO NOT USE triangle meshes > or quadrilateral strips (weird things will happen). This has been > a "known bug" for so long, I wonder why they don't put a notice in > the manuals. :-) > Huh? Whats the problem? I use t-meshes on P.I.'s quite often and never noticed a problem. (running 3.3.2) -Tim Hall tjh@bu-pub.bu.edu The night is filled with the cries of dispossessed children in search of paradise. -Dead Can Dance
andreess@mrlaxs.mrl.uiuc.edu (Marc Andreessen) (04/30/91)
In article <80495@bu.edu.bu.edu> tjh@ouzo.bu.edu (Tim Hall) writes: >In article <1991Apr29.141450.4737@Arco.COM> dprmjc@prism.ARCO.COM (M. J. Cole) writes: >> 2) If you are using lighting on a Personal Iris DO NOT USE triangle meshes >> or quadrilateral strips (weird things will happen). This has been >> a "known bug" for so long, I wonder why they don't put a notice in >> the manuals. :-) > Huh? Whats the problem? I use t-meshes on P.I.'s quite often >and never noticed a problem. (running 3.3.2) Indeed... what is the problem? (I know a number of people who are going to be very surprised if there really is one...) Marc -- Marc Andreessen___________University of Illinois Materials Research Laboratory Internet: andreessen@uimrl7.mrl.uiuc.edu____________Bitnet: andreessen@uiucmrl
dprmjc@prism.ARCO.COM (M. J. Cole) (05/02/91)
> >In article <1991Apr29.141450.4737@Arco.COM> I wrote: > >> 2) If you are using lighting on a Personal Iris DO NOT USE triangle meshes ^^^^^^^^^^^^^^ > >> or quadrilateral strips (weird things will happen). This has been > >> a "known bug" for so long, I wonder why they don't put a notice in > >> the manuals. :-) > In article <80495@bu.edu.bu.edu> tjh@ouzo.bu.edu (Tim Hall) wrote: > > Huh? Whats the problem? I use t-meshes on P.I.'s quite often > >and never noticed a problem. (running 3.3.2) In article <1991Apr30.012309.22200@ux1.cso.uiuc.edu>, andreess@mrlaxs.mrl.uiuc.edu (Marc Andreessen) wrote: > Indeed... what is the problem? (I know a number of people who are going > to be very surprised if there really is one...) Perhaps I should have said "SOMETIMES weird things will happen". The example at the end of the Lighting Chapter in the Graphics Library Programming Guide works. I'm not sure what invokes this behavior. A code example follows. Try compiling it with and without LIGHT #defined. To compile-n-link: cc $(CFLAGS) tmesh_test.c -lgl_s -lm -o tmesh_test If I'm doing something hopelessly stupid, please tell me. Note that this is ONLY a problem on the Personal Iris. This code works fine (with and without lighting) on GTX's and VGX's. I have personally experienced this problem on 3.2, 3.3.1 and 3.3.2. I asked the cool (and extremely helpful) guys in the Dallas SGI office about this behavior some time ago and they said, "That's a known bug on the PI. Use polygons with lighting". So, no... I didn't report it to the hotline. Oh, I'm using a 4D/25TG running 3.3.2. ............................................................................... Mary J. Cole ARCO Oil & Gas Company mjcole@arco.com 2300 W. Plano Parkway; PRC-D3239; (214)754-6857 Plano, TX 75075 ............................................................................... I'm continually AMAZED at th'breathtaking effects of WIND EROSION!! -ZIPPY ............................................................................... BEGIN Test code. ............................................................................... #include <stdio.h> #include <math.h> #include <gl/gl.h> #include <gl/device.h> #define LIGHT Matrix Identity = {1, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1}; float plane_normal[3] = {0.0, 0.0, 1.0}; float plane_polydata[4][3] = { {450, 450, 500}, {450, 550, 500}, {550, 450, 500}, {550, 550, 500} }; float plane_tmeshdata[4][3] = { {350, 350, 500}, {350, 450, 500}, {450, 350, 500}, {450, 450, 500} }; float plane_quaddata[4][3] = { {550, 550, 500}, {550, 650, 500}, {650, 550, 500}, {650, 650, 500} }; float Material[] = { AMBIENT, .0, .7, 1.1, DIFFUSE, .05, .18, .26, SPECULAR, .54, .60, .73, EMISSION, 0.0, 0.0, 0.0, ALPHA, 1.0, SHININESS, 44.6, LMNULL }; static float lm[] = { AMBIENT, .1, .1, .1, LOCALVIEWER, 1, LMNULL }; static float lt[] = { LCOLOR, 1, 1, 1, POSITION, 0, 0, 2500.0, 1, LMNULL }; main() { long xorig, yorig, xsize, ysize; float rx, ry; short val; winopen("Test tmesh/qstrip"); getorigin(&xorig, &yorig); getsize(&xsize, &ysize); doublebuffer(); RGBmode(); gconfig(); lsetdepth(0, 0x7fffff); mmode(MVIEWING); perspective(300, xsize/(float)ysize, 1.0, 1001.0); loadmatrix(Identity); translate(0.0, 0.0, -750.0); #ifdef LIGHT lmdef(DEFMATERIAL, 1, 0, Material); lmdef(DEFLIGHT, 1, 0, lt); lmdef(DEFLMODEL, 1, 0, lm); lmbind(MATERIAL, 1); lmbind(LMODEL, 1); lmbind(LIGHT0, 1); lmcolor(LMC_DIFFUSE); #endif LIGHT while (!getbutton(ESCKEY)) { ry=300*(2.0*(getvaluator(MOUSEX)-xorig)/xsize-1.0); rx= -300*(2.0*(getvaluator(MOUSEY)-yorig)/ysize-1.0); zbuffer(1); czclear(0x404040, 0x7fffff); pushmatrix(); rot(ry, 'y'); /* Simulate rotations about (500, 500, 500) */ rot(rx, 'x'); /* rather than (0, 0, 0) */ translate(-500.0, -500.0, -500.0); drawplane(); popmatrix(); swapbuffers(); } } drawplane() { bgnqstrip(); cpack(0x00ffff00); n3f(plane_normal); v3f(plane_quaddata[0]); v3f(plane_quaddata[1]); v3f(plane_quaddata[2]); v3f(plane_quaddata[3]); endqstrip(); bgntmesh(); cpack(0x00ff00ff); n3f(plane_normal); v3f(plane_tmeshdata[0]); v3f(plane_tmeshdata[1]); v3f(plane_tmeshdata[2]); v3f(plane_tmeshdata[3]); endtmesh(); bgnpolygon(); cpack(0x0000ffff); n3f(plane_normal); v3f(plane_polydata[0]); v3f(plane_polydata[1]); v3f(plane_polydata[3]); v3f(plane_polydata[2]); endpolygon(); } ............................................................................... End Test code. ...............................................................................