rodney@dgp.toronto.edu (Rodney Hoinkes) (05/15/91)
We have run into great problems due to the fact that we are running IRIX 3.3.2 but want to give our program to a group running 3.2 (Alias supported <- probably why they are still behind). Our code is NOT using and 3.3 specific code but unless we go back to 3.2 on our system and compile it, they cannot use it. Does anyone at SGI have a better solution? Could something be done about this in the future? Shouldn't shared libraries handle this? Note, we are also using libfm, lidbsd which are not shared. Would that be the technical reason? --- END of question 1 --- Now while I'm using net bandwidth, I'll save the space of the header and ask a few other questions. Not having the source to Flight, I can only speculate how the fog is done as I am trying to replicate the effect in some of my code. If someone with the code could set me straight, this is how I think it must be done: A number (based on desired fog thickness) of fogged/alpha'd polygons are set perpendicular to the viewer at certain distances apart to get thicker fog in the distance. V -->| | | | | ^ fogged/alpha'd planes Also, Is there any way to avoid having to calculate which alpha'd objects are closest to the viewer and draw them in the order from back to front in software rather than using the z-buffer? This problem exists with anything that is alpha'd including textures and makes the rendering of 1000's of alpha'd objects in real-time difficult due to CPU-intensive caculations. Can the z-buffer not maintain and check the alpha planes? And while I'm on a roll, I am trying to draw some really warped polygons, with each x,y point on it having a different z value. Some of them fail to be rendered even with concave(TRUE) on. And to keep going, If I turn subpixel(TRUE) on my VGX, I only notice about a 10% speed increase on fairly raw gl drawing (little CPU-intensive work), but I have seen much greater benefits of code with this in it? Is there something I might be missing that would lower the benefits of this routine? And speaking of speed, what sort of degredation does concave(TRUE) impose? And one more to people out there, Why is Feedback so machine dependant? Not the fact that it is different for each machine, but the fact that the headers are different on each type of machine (PI, GTX, VGX) so you MUST compile a separate version for each machine, rather than determining machine type at runtime and having all options in code. I have had to make my own defines for FB_POLYGON etc. for each machine type and call the appropriate handler based on machine determined at runtime. I have been lucky in that I have access to PI's, GT's, and VGX's to do this. Why couldn't SGI have done this? Ok, I've spoken my piece. I hope people out there have answers as I have been trying to get the optimum performance out of my new VGX and I don't think I yet understand the true implications of various gl routines on graphics performance. The manuals only state vague "this will slow down the system" or "this will speed up the system" statements. I am using a 310VGX, 5-span, 3.3.2. Any comparisons of various GL routines around versus GTX, GT, or PI machines? I also use a 70GT, 20TG, and 25TG. -- --- Rodney Hoinkes Centre for Landscape Research University of Toronto
dwallach@soda.berkeley.edu (Dan Wallach) (05/15/91)
In article <1991May14.193934.6923@jarvis.csri.toronto.edu> rodney@dgp.toronto.edu (Rodney Hoinkes) writes: > >Not having the source to Flight, I can only speculate how the fog is >done as I am trying to replicate the effect in some of my code. Well, I haven't seen flight source, but I can tell you how we did it for our final CS project (soon to be posted to the net, or made available via anonymous ftp as soon as we fix some more bugs...). We're drawing a fractal mountain landscape which you "drive" through. As a cheap way of deciding when to stop drawing distant polygons, we set an arbitrary distance as the end of the universe. For every vertex, we linearly interpolate between the vertex's color, and the background color, based on how far away the vertex is from the viewer. Voila! Instant fog (or murk, under water...). A second method we came up with uses the Iris lighting. Stick a light source on top of your head with some attenuation, and a constant ambient light. Polygons that are far away will just be the ambient (background...) color, while closer polygons will be lit nicely. A third method would use the Iris depthcue() call, but depthcue() didn't seem to get along nicely with the hardware lighting (any polygons which were clipped came out flat shaded). This may only be a PI weirdism. We haven't yet figured out a nice way to be half above water and half below water with correct fogging in both places. Doing it right would probably require something like BSP trees, and a lot of ugly hacking. Our Personal Irises don't have alpha buffers, or we'd probably come up with some stranger ways of doing things. Actually, the biggest headache was going from a view-up-vector and view-plane- normal to a nice out-the-window view. lookat() is difficult to get the twist right, and no amount of mucking with translate() and rotate() seemed to do the right thing, if you were looking straight down or up (y-axis). We ended up generating the matrix by hand and using multmatrix() with the system perspective matrix. Hope this helps, Dan Wallach dwallach@soda.berkeley.edu (thanks go to SGI for donating the 8 PI's which our graphics class lives on. Before that were Tek 4125 terminals...)
kurt@cashew.asd.sgi.com (Kurt Akeley) (05/15/91)
In article <1991May14.193934.6923@jarvis.csri.toronto.edu>, rodney@dgp.toronto.edu (Rodney Hoinkes) writes: |> We have run into great problems due to the fact that we are |> running IRIX 3.3.2 but want to give our program to a group |> running 3.2 (Alias supported <- probably why they are still |> behind). Our code is NOT using and 3.3 specific code but |> unless we go back to 3.2 on our system and compile it, they |> cannot use it. |> |> Does anyone at SGI have a better solution? Could something be |> done about this in the future? Shouldn't shared libraries handle |> this? |> |> Note, we are also using libfm, lidbsd which are not shared. Would |> that be the technical reason? I don't think that there is a better solution. Anyone else? |> Now while I'm using net bandwidth, I'll save the space of the header |> and ask a few other questions. |> |> Not having the source to Flight, I can only speculate how the fog is |> done as I am trying to replicate the effect in some of my code. If |> someone with the code could set me straight, this is how I think it |> must be done: |> |> A number (based on desired fog thickness) of fogged/alpha'd polygons |> are set perpendicular to the viewer at certain distances apart to |> get thicker fog in the distance. |> |> V -->| | | | | |> ^ |> fogged/alpha'd planes VGX models use the fogvertex() GL capability. In the general case image quality is improved by also using scrsubdivide GL capability, which subdivides polygons at planes perpendicular to the view direction. Flight avoids the performance loss of scrsubdivide by pretesselating its terrain. |> Also, |> |> Is there any way to avoid having to calculate which alpha'd objects |> are closest to the viewer and draw them in the order from back to |> front in software rather than using the z-buffer? This problem |> exists with anything that is alpha'd including textures and makes |> the rendering of 1000's of alpha'd objects in real-time difficult |> due to CPU-intensive caculations. To get the right answer you must sort the polygons back to front. There are, however, may tricks that result in acceptable images with less sorting overhead. |> Can the z-buffer not maintain and check the alpha planes? It can "check the alpha planes", but then what? It would need to maintain a sorted list of polygons at each pixel to produce the correct result. The VGX hardware does not have this capability. |> And while I'm on a roll, |> |> I am trying to draw some really warped polygons, with each x,y point |> on it having a different z value. Some of them fail to be rendered |> even with concave(TRUE) on. Warped polygons become self-intersecting polygons when viewed at bad angles. The GL makes NO promise about how self-intersecting polygons with more than 4 vertexes are drawn. To achieve maximum performance, subdivide ALL of your polygons into triangles, and assemble these triangles into meshes. |> And to keep going, |> |> If I turn subpixel(TRUE) on my VGX, I only notice about a 10% speed |> increase on fairly raw gl drawing (little CPU-intensive work), but |> I have seen much greater benefits of code with this in it? Is there |> something I might be missing that would lower the benefits of this |> routine? And speaking of speed, what sort of degredation does |> concave(TRUE) impose? Your application is probably pixel fill limited, rather than transformation limited. Hence subpixel, which affects transformation rate, has little effect on the overall performance. |> And one more to people out there, |> |> Why is Feedback so machine dependant? Not the fact that it is |> different for each machine, but the fact that the headers are different |> on each type of machine (PI, GTX, VGX) so you MUST compile |> a separate version for each machine, rather than determining |> machine type at runtime and having all options in code. I have had |> to make my own defines for FB_POLYGON etc. for each machine type |> and call the appropriate handler based on machine determined at |> runtime. I have been lucky in that I have access to PI's, GT's, and |> VGX's to do this. Why couldn't SGI have done this? Feedback has not been a priority, so it has received minimal attention. As partial justification, note that pipeline hardware systems with long latencies (i.e. high performance GL machines) perform poorly when run in feedback mode. Thus, if you are striving for "the optimum performance", as you mention below, you won't be using feedback anyway. |> Ok, I've spoken my piece. I hope people out there have answers as I |> have been trying to get the optimum performance out of my new VGX and |> I don't think I yet understand the true implications of various |> gl routines on graphics performance. The manuals only state vague |> "this will slow down the system" or "this will speed up the system" |> statements. |> |> I am using a 310VGX, 5-span, 3.3.2. Any comparisons of various GL |> routines around versus GTX, GT, or PI machines? I also use a 70GT, |> 20TG, and 25TG. |> |> -- |> --- |> Rodney Hoinkes |> Centre for Landscape Research |> University of Toronto
ktureski@alias.com (Kevin Tureski) (05/27/91)
In article <1991May14.193934.6923@jarvis.csri.toronto.edu>, rodney@dgp.toronto.edu (Rodney Hoinkes) writes: |> We have run into great problems due to the fact that we are |> running IRIX 3.3.2 but want to give our program to a group |> running 3.2 (Alias supported <- probably why they are still |> behind). As the guy at Alias that makes darn sure our s/w packages run properly on the latest SGI o/s, I'll take a little of the net bandwidth to quell a rumour that may start from the above statement. It's actually part of our agreement with SGI that we are responsible for updating our support customers to the latest release. Once we've verified that our own release is behaving as expected under the version of IRIX we choose to qualify the product under, we generally ship that version of IRIX in the same box that the Alias s/w is shipped in to customers who have SGI maintenance contracts through Alias and are in good standing (ie paid up). And those customers as described above received IRIX 3.3.2 quite some time ago; early Feb as I recall. This is true of most or all of the major VARs out there: it's just too much of a hassle to keep the field on an old IRIX; demos fail because the code expected different behaviour, confusion arises during support calls, etc. You will however note that I said "the version of IRIX we choose to qualify the product under". This is to safeguard ourselves and our customers: we and the other large VARs spend a lot of time testing our products to ensure stability. If I know for a fact that IRIX 3.3.3 has a problem in it when used with Alias s/w, then we won't condone or support that o/s. SGI is very responsive to these situations and works very closely with us when we discover a problem. I think all who attended the Developer's Forum got a chance to see first hand the efforts that they have made and are making in this and related areas: "It's strategic, we're committed ..." Really, SGI does an exemplary job, certainly orders of magnitude better than other large 3-letter companies that favour the colour blue, although I'll admit to seeing a significant improvement from "them" lately. And just for the record, IRIX 3.3.1 is not qualified for Alias s/w; there's a situation that can cause the window server to crash. So that's why we insist upon 3.3.2 (which, by the way, was delayed to include a fix for the above). As 3.3.3 is "fix on fail" and we haven't seen any problems with 3.3.2 serious enough to warrant a full-scale retest of our s/w under 3.3.3, we can't make any promises, and cannot recommend its use by our customers. Feel free to send me direct email on this subject if you're a site that is having any difficulty because of the version of IRIX that Alias has chosen to qualify (and hence support) our s/w under. -- Kevin Tureski Director, Systems Integration Alias Research Inc. 110 Richmond St E. Toronto Canada M5C 1P1 416 362-9181 ktureski@alias.com