jdchrist@watcgl.waterloo.edu (Dan Christensen) (05/17/89)
I have a couple of questions regarding the drawing of filled polygons on an Iris 4D/120GTX. 1) Using the fastest settings of the lighting model (single light source at infinity, viewer at infinity), how many shaded polygons can be drawn per second? (I know that this is a difficult question, but a rough figure would be useful). 2) I am trying to draw a large mesh of shaded triangles. The GT Library has routines for drawing triangular meshes. These routines look like they would speed up drawing significantly because only one third of the lighting calculations need to be done and one third of the data needs to be put into the pipeline, compared to drawing each triangle separately. The problem I found with these routines is that you have no control over the order in which the vertices are drawn so that backface removal becomes useless. Turning off backface removal results in an overall slowing in the drawing. Is there any way to specify the order in which the vertices are drawn? It would be a shame if there isn't because these routines look like they could speed things up greatly. Is there a way to do the same thing manually? Could the program draw each vertex and save the colours calculated by the hardware and then draw the polygons with the lighting model turned off, using the precalculated colours? Thanks for any help. ---- Dan Christensen, Computer Graphics Lab, jdchrist@watcgl.uwaterloo.ca University of Waterloo, Waterloo, Ont. jdchrist@watcgl.waterloo.edu
thant@horus.SGI.COM (Thant Tessman) (05/18/89)
In article <9753@watcgl.waterloo.edu>, jdchrist@watcgl.waterloo.edu (Dan Christensen) writes: > I have a couple of questions regarding the drawing of filled polygons > on an Iris 4D/120GTX. > > 1) Using the fastest settings of the lighting model (single light source > at infinity, viewer at infinity), how many shaded polygons can be > drawn per second? (I know that this is a difficult question, but a > rough figure would be useful). > Check the sales literature. SGI quotes lit polygons. (I'm no good with numbers.) Realize that the number doesn't include clearing the screen. Also, since on the GTX the graphics are CPU limited, indexing into data will be slower than running a pointer through the data. Indexing requires a multiply and an add. Incrementing a pointer is just an add. Also, using the z-buffer for polygons under a certain size (50x50 pixels?) doesn't cost you anything. > 2) I am trying to draw a large mesh of shaded triangles. The GT > Library has routines for drawing triangular meshes. These > routines look like they would speed up drawing significantly because > only one third of the lighting calculations need to be done and one ^^^^^ One half. In a single strip, each point is sent down once instead of twice (not including the end points). In a connected row of strips each point is sent down twice instead of four times. > third of the data needs to be put into the pipeline, compared to > drawing each triangle separately. The problem I found with these > routines is that you have no control over the order in which the > vertices are drawn so that backface removal becomes useless. > Turning off backface removal results in an overall slowing in the > drawing. Is there any way to specify the order in which the > vertices are drawn? It would be a shame if there isn't because > these routines look like they could speed things up greatly. Is > there a way to do the same thing manually? Could the program draw > each vertex and save the colours calculated by the hardware and then > draw the polygons with the lighting model turned off, using the > precalculated colours? > > Thanks for any help. > > ---- > Dan Christensen, Computer Graphics Lab, jdchrist@watcgl.uwaterloo.ca > University of Waterloo, Waterloo, Ont. jdchrist@watcgl.waterloo.edu Triangle-meshes can be used with backface removal. The 'front' of the tmesh is determined by the first triangle and preserved for the rest of the mesh, even if swaptmesh is used. The 'swaptmesh' command is a way of manipulating which edge of the previous triangle you want to connect the new triangle to. There is one bug that shows up when backfaced tmeshes get clipped. Sometimes the individual clipped triangles will randomly disappear or appear, but this is being fixed. thant@sgi.com "there are 336 dimples on the standard golf ball"
jdchrist@watcgl.waterloo.edu (Dan Christensen) (05/19/89)
[stuff omitted throughout] In article <33129@sgi.SGI.COM> thant@horus.SGI.COM (Thant Tessman) writes: > >Also, >since on the GTX the graphics are CPU limited, indexing into data will be >slower than running a pointer through the data. Indexing requires a multiply >and an add. Incrementing a pointer is just an add. On page 2-32 of the Iris-4D Series Compiler Guide it is described ways of making your code faster when being optimized and say "Using subscripts instead of pointers". It mentions that pointers are used in the generated code anyways but that subscripts help because the optimizer can figure things out better. I don't know if this is true when you are just doing the default optimization, but it is when you ask for extra optimization. >> 2) I am trying to draw a large mesh of shaded triangles. The GT >> Library has routines for drawing triangular meshes. These >> routines look like they would speed up drawing significantly because >> only one third of the lighting calculations need to be done and one > ^^^^^ >One half. In a single strip, each point is sent down once instead of twice >(not including the end points). In a connected row of strips each point is >sent down twice instead of four times. I think it is one third, for a long strip. To draw this using the mesh commands 2 4 6 8 /\--------/\--------/\--------/ / \ / \ / \ / / \ / \ / \ / / \ / \ / \ / /--------\/--------\/--------\/ 1 3 5 7 requires a total of 8 vertices to be specified. Each one is sent once. To draw it using non-mesh routines requires 3*6=18 vertices to be specified. The internal ones are specified *three* times each. The ratio in this case is 18/8 > 1/2 and goes to 1/3 for longer strips. In my case I am drawing long strips so it is very close to 1/3. >> third of the data needs to be put into the pipeline, compared to >> drawing each triangle separately. The problem I found with these >> routines is that you have no control over the order in which the >> vertices are drawn so that backface removal becomes useless. >Triangle-meshes can be used with backface removal. The 'front' of the tmesh >is determined by the first triangle and preserved for the rest of the mesh, >even if swaptmesh is used. This is what I was looking for! I must have missed that fact in the documentation. I just assumed that each polygon was checked individually. Thanks very much! >There is one bug that shows up when backfaced tmeshes get clipped. Sometimes >the individual clipped triangles will randomly disappear or appear, but this >is being fixed. Any idea when? >thant@sgi.com "there are 336 dimples on the standard golf ball" Thanks for the help. ---- Dan Christensen, Computer Graphics Lab, jdchrist@watcgl.uwaterloo.ca University of Waterloo, Waterloo, Ont. jdchrist@watcgl.waterloo.edu
thant@horus.sgi.com (Thant Tessman) (05/22/89)
In article <9803@watcgl.waterloo.edu>, jdchrist@watcgl.waterloo.edu (Dan Christensen) writes: > [stuff omitted throughout] > > In article <33129@sgi.SGI.COM> thant@horus.SGI.COM (Thant Tessman) writes: > > > > >> 2) I am trying to draw a large mesh of shaded triangles. The GT > >> Library has routines for drawing triangular meshes. These > >> routines look like they would speed up drawing significantly because > >> only one third of the lighting calculations need to be done and one > > ^^^^^ > >One half. In a single strip, each point is sent down once instead of twice > >(not including the end points). In a connected row of strips each point is > >sent down twice instead of four times. > > I think it is one third, for a long strip. To draw this using the You're right. I was thinking in comparison to quadrangles. thant@sgi.com