Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!orca!mesa!rthomson From: rthomson@mesa.dsd.es.com (Rich Thomson) Newsgroups: comp.graphics Subject: Re: A Practical Introduction to PHIGS and PHIGS PLUS Message-ID: <1991Apr26.051232.7034@dsd.es.com> Date: 26 Apr 91 05:12:32 GMT References: Sender: usenet@dsd.es.com Reply-To: rthomson@dsd.es.com (Rich Thomson) Organization: Design Systems Division, Evans & Sutherland, SLC, UT Lines: 111 Nntp-Posting-Host: 130.187.85.21 In article toby@cs.man.ac.uk (toby) writes: >As the authors of 'A Practical Introduction to PHIGS and PHIGS PLUS', we feel >that it is only fair for us to have the opportunity to respond to two recent >reviews of our book [...] I haven't seen your book yet (we've got one on order), so I won't comment about it yet. I do have some comments about your response, though.... >Moving to POLYLINE SET WITH DATA [...] >There are several reasons for the adoption of this >primitive, of which efficiency was not the major consideration. One reason >was to cope with the effect of clipping -- if a single polyline is clipped, >it can result in multiple polylines internally. Hmm... I don't see how clipping should enter into the functional interface provided by P/P+. What I see as the best aspect of the PSWD primitive is the fact that it is the *only* line primitive allowing me to place a color at each vertex. Then I can use the line shading method attribute to have the lines color blended. I wrote a nifty program for last year's SIGGRAPH that displayed a terrain with each profile across the terrain represented as a POLYLINE SET 3 WITH DATA, with the vertex colors taken from a texture map that was generated along with the terrain data. Since we have anti-aliased lines under PEX, the result was something akin to texture mapping, except that update rates were quite high since the primitives involved were lines and not polygons (i.e. no texture map lookup for each pixel on the primitive, etc.). If POLYLINE SET 3 WITH DATA was introduced to cope with the effect of clipping, how would one draw color/vertex polyline primitives without it? >[...] SET OF FILL AREA SET WITH DATA [...] We stand behind our comment >that 'this degree of complexity is not something which an everyday >application programmer wishes to grapple with'. I'd agree here. Much more commonly used in application programs are TRIANGLE STRIP 3 WITH DATA and QUADRILATERAL MESH 3 WITH DATA. Not to mention the plain old FILL AREA 3 WITH DATA. SET OF FILL AREA SET WITH DATA (or SOFAS with data... gotta love it... when are we going to have the matching CHAIR with data primitive? ;-) are useful for arbitrary collections of polygons, each possibly having holes. Since FILL AREAs don't have edges, I can also imagine an application wanting to be use them for this purpose, but it still isn't necessary that they go whole-hog and use SOFAS. >Early on in the preparation of the book we made a conscious decision >not to cover NURBs in all their mathematical glory. Good. Sometimes I think the cult of the polygon has been replaced with the cult of the NURB. If I want to read about NURBs, I'll go and read any one of the bajillion books on NURBs. Keep this book to its focus and stick to explaining PHIGS (where there is a dearth of books!). >In fact, at one stage in the development of PHIGS, both left- and >right-handed systems were proposed! Holy shit, batman! I'm glad that didn't make it in... >Toby Howard >Terry Hewitt >Roger Hubbold I've noticed some people have a hard time saying "standards" and "performance" in the same breath -- its not an easy problem to solve (especially when the C binding is a moving target!), but it *IS* possible. Remember, seeing is believing. In general, I'd just like to mention that there is not much one can do in a book in regards to "PHIGS efficiency". The reason is that just like every graphics box that ever went to market had to have applications "tuned" to run at maximum efficiency, so will PHIGS applications have to be tuned. Moreover, what makes an application fast on one machine may not make an application fast on another. The tuning process is going to be different for every box, although there will always be "good" (i.e. efficient) ways of doing things in PHIGS and "bad" (i.e. correct but less efficient) ways of doing things. Different rendering engines have different architectures and whats good for one might not be good for another. Take our ESV (a workstation providing PHIGS/PHIGS-PLUS via PEX), for instance, it has up to 44 AT&T DSP32 chips scan-converting polygons and pre-processing lines. In the documentation that comes with ESV we talk about how to organize your structures for the most efficient rendering on our hardware. We also discuss WAIT/ASAP, etc, etc. Note that it is not always best to "glom" the primitives together into one big lump to get the most efficiency. If you take all your polygons and tie them up into one primitive, it's quite possible you might only have 1 DSP out of the 44 doing anything. Naturally, there are ways one might go about avoiding this problem without making the application worry about it. It is easy to split up a quad mesh or triangle strip, but how does one split a SOFAS without introducing unacceptable overhead? Basically the life of a PHIGS application when it is being ported from one hardware platform to another is tune, tune, tune (surprise, what else is new when moving an intensive graphics application from one platform to another?). Naturally a little good planning in the beginning can help one avoid the headaches, but as good software engineers we all knew that, didn't we? ;-} -- Rich -- ``Read my MIPS -- no new VAXes!!'' -- George Bush after sniffing freon Disclaimer: I speak for myself, except as noted. UUCP: ...!uunet!dsd.es.com!rthomson Rich Thomson ARPA: rthomson@dsd.es.com PEXt Programmer