jch@Stardent.COM (Jan Hardenbergh) (04/16/91)
I just got a copy of "A Practical Introduction to PHIGS and PHIGS PLUS" by Toby Howard, Terry Hewitt, R.J. Hubbold and K.M. Wyrwas. ISBN 0-201-41641-7. I've been looking at it off and on all day now and am more and more impressed each time I pick it up. It would be hard for any new book on PHIGS to NOT be the best book on PHIGS. But this book goes way beyond being an improvement. It is, as it claims, a practical (and thorough) introduction to PHIGS. The best thing is that it is not intimidating. It starts with a "Whirlwind tour" to get your feet wet and then with a totally trivial example - draw a line. Only then does it start to systematically introduce primitives, structures, etc. It has many, many examples in C!!! The C binding matches the standard of last year - before underscores. This matches the current PHIGS products, but those of us on the cutting edge need to add our own underscores. Not a big deal. The examples are well thought out and developed along the way. Appendix A & B are non-trivial examples of how to do something useful in PHIGS. The first is a viewing example and the second shows what you can do with lighting. It has 34 color plates showing variations lighting and shading options. Diagrams are a strong point of this book. It has all of the good diagrams that you expect to see - viewing frustum, deferral update flow chart, reflectance angles, a bicycle structure hierarchy chart, etc. It also has many new ones, ASF decision chart, good structure edit diagrams and even archive conflict resolution diagrams ( that's going too far! :-). Here's the table of contents: 1. Whirlwind tour 2. Getting started 3. Graphical output 4. Creating the model 5. Editing the model 6. 3D Viewing 7. Graphical input 8. Workstations 9. Styles of output [ attributes ] 10. Archiving 11. More about the CSS [ name sets, filters... ] 12. Dealing with errors 13. PHIGS PLUS graphical output 14. The PHIGS PLUS rendering pipeline Appendix A - Viewing example program Appendix B - PHIGS PLUS example program Appendix C - Coordinate transforms [ great ] Appendix D - Using PHIGS with Fortran [sic] Appendix E - Summary of functions, elements and errors Appendix F - Colour models Appendix G - Toby's annotated PHIGS bibliography Bibliography Glossary [O.K. needs more] Index 339 pages, less than an inch thick. This is not a reference book on all of the details and issues of PHIGS. Nor is this a read once and toss tutorial. This is a book to give on a good idea about how to use any particular aspect of PHIGS. It has enough detail to get you started but keeps it simple enough so you can find what you want easily. The combination of this book and a good "call reference" manual, like the one provided with the PEX Sample Implementation should be all most people need. But, as much as I like this book, we can always hope for a better one. It could have both pieces of PHIGS (PHIGS89 & PHIGS-PLUS) integrated. It could have an newer cut at the "C" binding - although the decision to use the one that was out in the field was a good one, it won't be out in the field for too long. Those are really nits. Still hoping for two more at SIGGRAPH, Prentice Hall (Valerie Clark) and Wiley & Sons (Hopgood & Duce). If they are as good as this book, acquiring PHIGS knowledge will become much, much easier. This book is not the standard warmed over or a breezy tour of PHIGS as was "Understanding PHIGS" and the chapter in Foley, van Dam, Feiner and Hughes. It is PHIGS explained as you need it by people who have - obviously - explained it before, many times. Disclaimer, I did review this book last June. I thought from the state it was in then (Pascal examples? and almost no PHIGS-PLUS) that it was destined to be a little better than mediocre book. The explanations that were there were good, but...scarce. This book is radically better than the draft. It is great. -- -Jan "YON" Hardenbergh jch@stardent.com (508)-371-9810x261 Stardent Computer, 6 N.E. Tech Center, 521 Virginia Rd,Concord, MA 01742
levine@well.sf.ca.us (Ron Levine) (04/18/91)
Jan Hardenbergh reviews the new book on PHIGS and PHIGS PLUS on the basis of an all too cursory inspection: >I just got a copy of "A Practical Introduction to PHIGS and PHIGS PLUS" >by Toby Howard, Terry Hewitt, R.J. Hubbold and K.M. Wyrwas. ISBN >0-201-41641-7. I've been looking at it off and on all day now and am >more and more impressed each time I pick it up. Then he concludes by calling it a "great book". I have had a copy of this book for about a month. Like Jan, I was at first very impressed because the book is indeed very attractive. But on a careful examination I find that it has many faults and falls far short of "greatness". To be sure, as the first matter to appear in an important vacuum, it will be helpful to many who are struggling to get started with PHIGS in the face of inadequate vendor documentation. But some of its inaccuracies and oversights are sure to obfuscate and to hinder the progress of some readers, some of the time. Therefore, I feel compelled to counterbalance Jan's excessively enthusiastic endorsement with some negative comments and caveats that this book is not all that it claims to be. The material on PHIGS PLUS, in particular, is inadequate and sometimes even erroneous. But even the more elementary material suffers from poor explanations which frequently miss the point. One of the first objectionable things I noticed is that from the beginning there is an implicit assumption that the default display update deferral mode is ASAP, which may be true in some implementations, but not in some important ones such as DEC PHIGS and Domain/PHIGS. The PHIGS standard does not specify a default deferral mode, but it is certainly true that on most interactive systems, for pictures with any complexity at all, deferral mode ASAP is a bad choice, except perhaps for debugging purposes. Thus, a number of implementations use WAIT for the default deferral mode. As a consequence of this implicit assumption, many important unqualified statements in the first half of the book (e.g. "posting causes the structure to be traversed", and "traversal may be thought of as a continuous process") are false for implementations in which the default deferral mode is other than ASAP. Moreover, all of the example programs will fail to produce the expected picture on such implementations. Since display update deferral mode is not discussed until Chapter 8 (except for a mysterious hint on page 9), the beginning student using such an implementation is sure to be frustrated. Then, when deferral mode is finally discussed in Chapter 8 (and in the hint on page 9), the explanation largely misses the point. It seems to imply that you would want to use a deferral mode other than ASAP only on a hard copy device such as a pen plotter or laser printer, which is just not true. In fact, interactive applications on devices such as CRTs are EXACTLY where you would want to use deferral mode WAIT, together with modification mode NIVE or UQUM. Further, I think it is confusing and very bad to place the discussion of "dynamic modification accepted" in Sec. 8.3, before the discussion of deferral mode and quick update. And, in my opinion, the definition of "implicit regeneration" in this section is just wrong. (The PHIGS standard uses the term but never precisely defines it). The whole discussion fails to mention the all-important point that traversal, or regeneration, is generally needed to be sure that the picture is correct, no matter what the output device is. This observation of the difficulties with the book's treatment of display update caused me to examine many of the explanations closely, and in many cases I have found them wanting, especially in the PHIGS PLUS chapter. For example, consider the description of POLYLINE SET WITH DATA: "...it allows us to define a set of unconnected polylines as a single primitive. This can be useful for displaying a variety of composite shapes constructed from individual polylines". Of course, EXACTLY the same "variety of composite shapes" may be drawn using individual POLYLINE primitives. The explanation ignores the primary rationale for aggregating a number of individual polylines into a single primitive: namely, that it may frequently result in important performance gains, by reducing the overhead of function calls, bus transactions, etc. I am particularly offended by the discussion of SET OF FILL AREA SETS WITH DATA: "We will not go into more detail here; suffice it to say that this degree of complexity is not something which the everyday application programmer wishes to grapple with." I strongly demur. While this primitive might not be the first that a PHIGS beginner would want to attempt to use, I certainly think that it is an extremely important tool in the box of the "everyday application programmer", and no book on PHIGS PLUS can be complete without a good discussion to help the reader with its complexity, as well as examples to demonstrate its power and its benefits. The discussion of the Phong reflectance model, in particular the significance of specular versus diffuse reflection, is far too terse in relation to what is needed by people who are not already experts on rendering--at least for the students I have had when teaching PHIGS in an industrial setting. The presentation of NURBS curves and surfaces is very bad indeed. It is non-illuminating, and contains erroneous statements as well. For example: "There are two types of B-spline: rational and non- rational. Only rational B-splines have the property of being closed under a perspective transformation, which is why they are used in PHIGS PLUS". First, this ignores the important fact that "non-rational" B- splines ARE rational B-splines in which all the weights are 1. ("Non-rational" is a very unfortunate choice of nomenclature, evidently made by computer scientists. Mathematicians would never use such illogical terminology. Here we have a very clear example of the confusion that illogical terminology can cause.) Now, one of the most important properties of B-splines, rational or non-rational, is that they are invariant under affine transformations; this is important because it means that the curve you get from a set of control points and weights does not depend on the choice of coordinate system. The book ignores this property as well as several others--local control, convex hull, variation diminishing, etc.--which are all very important for explaining why B-splines, rational or non-rational, are used for the free-form curve and surface capability in PHIGS, IGES, and other systems. On the other hand, the one cited property, closure under perspective transformation, is not very important at all. In practice, it really does not matter that the perspective projection of a non-rational B-spline may be a rational B-spline. Indeed, many authors on NURBS recommend that application developers use non-rational NURBS except when non-constant weights are absolutely required. When is this? The answer is that rational B-splines are needed for exactly representing conic sections (circles, ellipses, parabolas, hyperbolas), and quadric surfaces (including spheres, cylinders, cones, etc.) as splines. This is, I think, the REAL reason that the complexity of weights and rational B-splines has come into computer graphics. Further serious faults with the NURBS discussion: absence of any clue as to the geometric significance of the weights, and lack of any guidance on appropriate choice for the order. Finally the discussion peters out with a weak reference to the books by Farin and the Killer Bees, which both are much too mathematically difficult for the supposed average reader of this book on PHIGS PLUS. It is not at all easy to write a good book on PHIGS PLUS. I know because I have written one, in the form of a tutorial manual for internal use by a large corporation. I spent an inordinate amount of time per finished page on the discussion of NURBS, trying to explain it clearly at about the right level for the non-mathematician reader. So I hope it is understandable that my hackles are raised when I see such an incomplete job rushed into print to take advantage of a market opportunity, and then receive accolades based on an all too cursory reading from an expert like Jan Hardenbergh. The book is not without value. Many of the nice features cited by Jan are indeed laudable. But it is certainly not a great book, it has serious flaws, and it is not at all adequate as an introduction to PHIGS PLUS. The authors may plead that PHIGS PLUS has been a moving target during the period of writing. But then it is misleading to claim that this alleged "introduction" to it is at all "practical". I don't know anything about the other forthcoming books that Jan mentions, but I rather suspect that a truly valid and helpful book on PHIGS PLUS is still about a year away. Ron Levine Dorian Research, Inc. (415)-535-1350
eanv20@castle.ed.ac.uk (John Woods) (04/19/91)
levine@well.sf.ca.us (Ron Levine) writes: >It is not at all easy to write a good book on PHIGS PLUS. I know >because I have written one, in the form of a tutorial manual for >internal use by a large corporation. Is this available commercially, or do the corporation hold the copyright? I'm sure many of the readers of this board, including myself, would be quite interested to read it... -- /******* cut here ******* John Woods ******* cut here ******** * Philosophy: Forsan et haec olim meminisse iuvabit (Virgil) * * Disclaimer: Every statement in this file is possibly !true * ******** cut here ******* John Woods ******* cut here *******/
jch@Stardent.COM (Jan Hardenbergh) (04/20/91)
> From: levine@well.sf.ca.us (Ron Levine) > Jan Hardenbergh reviews the new book on PHIGS and PHIGS PLUS on > the basis of an all too cursory inspection: I stand by my characterization that this book is great. I've had another few days to look at it, too. I do concur with Ron Levine in that the does not go into lots of detail in many places. But it is a 339 page book - including lots of appendices and examples. I too was disappointed with the failure to call out UQUM (Yookum?) as an important interactive feature. As for the NURBS stuff, I'm still wading through the Piegl article in January's IEEE CG&A. That is the first one that I've felt like all I have to do is reread it a few times and I will get it. So, I can't cast stones - But the one example Ron cites is broken according to my humble understanding. While Ron brings up some good points, he is too is human. > Further, I think it is confusing and very bad to > place the discussion of "dynamic modification accepted" in Sec. > 8.3, before the discussion of deferral mode and quick update. > And, in my opinion, the definition of "implicit regeneration" in > this section is just wrong. (The PHIGS standard uses the term > but never precisely defines it). The whole discussion fails to > mention the all-important point that traversal, or regeneration, > is generally needed to be sure that the picture is correct, no > matter what the output device is. While the definition of "implicit regeneration" is a little clumsy in its English, it is true. And the PHIGS spec does indeed explicity define implicit regeneration. ANSI X3.144-1988 page 10. <minus a few sentences> 3.89 implicit regeneration: The complete recreation of the contents of a display surface such that <more stuff>. Such a regeneration is not explicitly requested by the application program. While this is not a good explanation and people tend to think this can happen at any time (which it cannot) it is defined. The book does include the flow chart from the spec which is much better than any words. As for the weak treatment of PHIGS-PLUS, well, seeing as 10 new primitives were added at about the same time the book was going to press, I'd say the authors are excused for not going into detail on everything. It does have enough to get started - which is more than anything else. I thought the sections on lighting and shading were good. If you have trouble remembering lighting and shading, this of shading as applying different shades of color to an object.(shading==interpolation) It is hard for me to believe that a book could have as much detail as Ron Levine wants and still be an introductory book. I made it quite plain in my first posting that it was not "a reference book on all of the details and issues". I suspect such a book would be at least twice the size. > From: levine@well.sf.ca.us (Ron Levine) > Jan Hardenbergh reviews the new book on PHIGS and PHIGS PLUS on > the basis of an all too cursory inspection: I stand by my characterization that this book is great. I do concur with Ron Levine in that the does not go into lots of detail in many places. But it is a 339 page book - including lots of appendices and examples. I too was disappointed with the failure to call out UQUM (Yookum?) as an important interactive feature. As for the NURBS stuff, I'm still wading through the Piegl article in January's IEEE CG&A. That is the first one that I've felt like all I have to do is reread it a few times and I will get it. While Ron brings up some good points, he is too is human. > Further, I think it is confusing and very bad to > place the discussion of "dynamic modification accepted" in Sec. > 8.3, before the discussion of deferral mode and quick update. > And, in my opinion, the definition of "implicit regeneration" in > this section is just wrong. (The PHIGS standard uses the term > but never precisely defines it). The whole discussion fails to > mention the all-important point that traversal, or regeneration, > is generally needed to be sure that the picture is correct, no > matter what the output device is. While the definition of "implicit regeneration" is a little clumsy in its English, it is true. And the PHIGS spec does indeed explicity define implicit regeneration. ANSI X3.144-1988 page 10. <minus a few sentences> 3.89 implicit regeneration: The complete recreation of the contents of a display surface such that <more stuff>. Such a regeneration is not explicitly requested by the application program. While this is not a good explanation and people tend to think this can happen at any time (which it cannot) it is defined. The book does include the flow chart from the spec which is much better than any words. As for the weak treatment of PHIGS-PLUS, well, seeing as 10 new primitives were added at about the same time the book was going to press, I'd say the authors are excused for not going into detail on everything. It does have enough to get started - which is more than anything else. The charge that this was rushed to market is spurious. It sets a very high standard for PHIGS books. I'd like nothing better than to see all of the PHIGS books be better, but I'm not going to hold my breath. I thought the sections on lighting and shading were good. If you have trouble remembering lighting and shading, this of shading as applying different shades of color to an object.(shading==interpolation) It is hard for me to believe that a book could have as much detail as Ron Levine wants and still be an introductory book. I made it quite plain in my first posting that it was not "a reference book on all of the details and issues". I suspect such a book would be at least twice the size. -- -Jan "YON" Hardenbergh jch@stardent.com (508)-371-9810x261 Stardent Computer, 6 N.E. Tech Center, 521 Virginia Rd,Concord, MA 01742
levine@well.sf.ca.us (Ron Levine) (04/23/91)
I am befuddled by Jan Hardenbergh's insistence on calling this book "great", even though he recognizes many of its shortcomings. I am also befuddled by his refusal to acknowledge many other of its flaws. >I stand by my characterization that this book is great. I've had >another few days to look at it, too. I do concur with Ron Levine in >that the does not go into lots of detail in many places. But it is a >339 page book - including lots of appendices and examples. I did not complain about lack of detail so much as the fact that the quality of explanation is frequently poor. Since Jan focusses on my complaint about the definition of "implicit regeneration", let us look at the complete paragraph. "Many applications build and modify models incrementally and iteratively. Not all workstations, however, have the ability to modify parts of a displayed picture _selectively_. On some workstations, such as a laser printer, the only way to bring the picture up to date is to redraw it completely. Redrawing the entire picture in this way is known as _implicit regeneration_. It is implicit because the redrawing is not explicitly requested by the application, which specifies only the incremental changes required to the picture. Implicit regenerations occur under the control of PHIGS." Now the first sentence creates the wrong impression, because, in fact ALL applications build and modify models incrementally, in the sense that they can call only one PHIGS function at a time. The question is whether the picture should be regenerated after each PHIGS function call which redefines the picture, or only after a batch of such calls. The second sentence overlooks the fact, that in general, NO workstations have the ability to modify parts of a displayed picture selectively, at least not correctly. On a CRT, you can delete a primitive by painting it out in the background color, but in general you will not produce a correct picture because you will damage whatever primitives lie under the deleted one. Thus, the "laser printer" in the third sentence is a confounding red herring. The main clause of this sentence is essentially true of ALL workstations. The key is understanding that "redraw completely" = "regenerate" = "traverse posted structures". It means traversing all the posted structures, respecting the relative priority of the root structures, the order of primitives within a structure, and whatever hidden line or hidden surface methods are in effect. That is the only way to get a guaranteed correct picture, no matter what the output device. Now we see that the fourth sentence, which purports to define "implicit regeneration", is meaningless because of the fuzziness of "in this way", which seems to have something to do with laser printers. The fifth sentence would be true if we had a valid definition of "implicit regeneration" in the fourth, but we don't. The last sentence is sort of true, but inadequate because here is where the important concept of deferral mode should be introduced. The last sentence should rather say something like: "Implicit regeneration is regeneration automatically instigated by PHIGS in response to any picture changing function call if the deferral mode is ASAP, or if the deferral mode is BNIG or BNIL and an input interaction is underway. If deferral mode is WAIT, then regeneration occurs only when the application explicity requests it by calling UPDATE WORKSTATION or REDRAW ALL STRUCTURES." Again, nowhere does the text mention the fact that on most workstations, most of the time, the only sensible deferral mode to use is WAIT. If you want approximately correct incremental drawing on a CRT, then you might also use modification mode UQUM (quick update methods), which might or might not be supported on your workstation type in the implementation you're using. It wouldn't make sense to use UQUM on a laser printer, but it wouldn't hurt either, provided that you remember to explicitly update the display at the end of the set of incremental changes. Now this is just one example. There are many other cases of poor explanation, or explanations that miss the essential point. I previously pointed out the lack of justification of the primitive aggregating feature of POLYLINE SET WITH DATA. The definition of "right-handed coordinate system" in Sec. 3.1 is just ludicrous and has no practical value. I concur with Jan that this is the best PHIGS book out, because it is the only one. As an introduction to pre-PHIGS PLUS PHIGS it is a lot better than some of the vendor documentation, but probably no better than some others. But anyone who buys it on the strength of the title's claim that it is a "practical introduction" to PHIGS PLUS is being duped. Ron
levine@well.sf.ca.us (Ron Levine) (04/24/91)
eanv20@castle.ed.ac.uk (John Woods) asks, about the tutorial of which I dropped a hint: > Is this available commercially, or do the corporation hold the >copyright? I'm sure many of the readers of this board, including myself, >would be quite interested to read it... First, it is a little broader than PHIGS PLUS, covering also some more general topics in 3D graphics. Then, with respect to the PHIGS PLUS treatment, it is restricted to a particular implementation, and does not always try to point out the differences between that implementation and the standard or other implementations. I recently used it in teaching an internal course with some success and much positive feedback. The work certainly belongs to the company in question, because they paid me an hourly rate to produce it. The question of making it available to a wider public is under consideration. I will advertise it here if and when it becomes available. Ron Levine Dorian Research, Inc. (415)-535-1350
levine@well.sf.ca.us (Ron Levine) (04/24/91)
In two previous postings on this topic, I averred that the most
useful display update deferral mode in PHIGS is WAIT, or at
least that ASAP is the least useful deferral mode. Let me here
make clearer the basis for this assertion.
Here are the relevant facts:
1. In general, in order to be sure that the displayed picture is
the correct rendering of the picture defined by the current state
of the PHIGS data bases, including the centralized structure
store and the workstation state list, it requires regeneration,
i.e. traversal of all the posted structures, respecting their
relative display priorities, the order of primitives within the
structures, and whatever hidden line/hidden surface methods may
be in effect.
2. Depending on the complexity of the picture and the rendering
speed of the workstation, regeneration may well require a non-
negligible amount of time, perhaps a long time in relation to
what is needed for good interactive response. Even on the
fastest workstations, applications will tend to want to push
picture complexity to the practical limit.
3. Generally, an single iterative change in the picture which the
application wishes to present to the user will involve a number
of calls to PHIGS functions which modify structure contents
and/or workstation state, i.e. the data which define the correct
picture--sometimes only a few such calls, sometimes a large
number.
4. If the deferral mode is ASAP, then every individual function
call changing workstation state will implicitly cause a
regeneration, and every individual function call changing the
contents of a posted structure will implicitly cause a
regeneration. This is certainly undesirable under facts 2 and 3.
Part of the problem could be avoided by unposting a structure
before editing and reposting after editing, but if there were
several posted structures needing editing (generally true), then
there still would be several needless unwanted regenerations. A
better solution is to use deferral mode WAIT.
5. If the deferral mode is WAIT, then there is no regeneration
until the application explicitly calls for it, after having made
an entire batch of incremental changes to the data base. The
application, not PHIGS, is in control of the costly regeneration
process. Clearly the best solution under the stated facts.
Now the Howard et al book does not give the slightest clue as to
these important practical considerations. On the contrary, it
proceeds on the unstated assumption that the default deferral
mode is ASAP, usually a bad choice (although the default in some
implementations). As I mentioned, it contains many important
unqualified statements which are false in those implementations
using WAIT for the default, and almost none of its example
programs would produce the expected picture in such
implementations.
Now here is a question about PHIGS deferral mode for which I
don't have an answer. What possible use could there be for
deferral mode ASTI (At Some Time)? The standard spec seems to
imply that this deferral mode allows implicit regeneration to
occur, but at completely undetermined times. The standard also
allows an implementation to make ASTI equivalent to ASAP, which
indeed seems to be the case in the implementation with which I am
most familiar (although you couldn't tell it from their
documentation). I cannot imagine that an application programmer
would be indifferent as to if and when implicit regeneration
might occur. Can any of the Phounding Phathers of PHIGS tell me
what they had in mind when they created this deferral mode?
Ron Levine
Dorian Research, Inc.
(415)-535-1350spencer@eecs.umich.edu (Spencer W. Thomas) (04/25/91)
In article <24373@well.sf.ca.us> levine@well.sf.ca.us (Ron Levine) writes: > The second sentence overlooks the fact, that in general, NO > workstations have the ability to modify parts of a displayed > picture selectively, at least not correctly. On a CRT, you can > delete a primitive by painting it out in the background color, > but in general you will not produce a correct picture because you > will damage whatever primitives lie under the deleted one. Not true. Many high-end workstations have a "built-in" display list. Thus, as far as PHIGS is concerned, the image can be correctly modified selectively. An old example is the E&S PS300 series (not sure about their new workstation, as I don't have one.) Even on a "bit-mapped" workstation, it may be possible to selectively update an image, under certain conditions - for example, when adding a new primitive to the end of a structure (depending on structure priority). -- =Spencer W. Thomas EECS Dept, U of Michigan, Ann Arbor, MI 48109 spencer@eecs.umich.edu 313-936-2616 (8-6 E[SD]T M-F)
jch@Stardent.COM (Jan Hardenbergh) (04/25/91)
levine@well.sf.ca.us (Ron Levine) writes: > In two previous postings on this topic, I averred that the most > useful display update deferral mode in PHIGS is WAIT, or at > least that ASAP is the least useful deferral mode. Let me here > make clearer the basis for this assertion. > > Here are the relevant facts: <excellent - though still not nearly complete discussion of WAIT/UQUM deleted.> Still it should be noted that WAIT/UQUM will great for wireframe editing of models. That is not the whole constituency of PHIGS. > Now the Howard et al book does not give the slightest clue as to > these important practical considerations. This statement is just plain not true. The book does about as well at explaining them as the spec (PHIGS88/PHIGS89) does. That is not a full discussion on when to use which ones. More on this later. I did not give complete info before (missed the publisher) and have received some inquiries, let me give the complete info. A Practical Introduction to PHIGS and PHIGS PLUS TLJ Howard, WT Hewitt, RJ Hubbold, KM Wyrwas Addison-Wesley 1991 ISBN 0-201-41641-7 Price 24 Pounds (that's all I got :-) > On the contrary, it > proceeds on the unstated assumption that the default deferral > mode is ASAP, usually a bad choice (although the default in some > implementations). As I mentioned, it contains many important > unqualified statements which are false in those implementations > using WAIT for the default, and almost none of its example > programs would produce the expected picture in such > implementations. Yes, this was a mistake on the authors part. And, yes, I believe that the examples will not run with out a call to update workstation added. However, I haven't finished typing in the SEVEN page viewing example or the EIGHTEEN page PHIGS-PLUS example showing how to use lighting and shading (well, only flat shading in the example, but astute readers can figure out how to change the argument to psetintshadmethod()). The examples alone make this book great. > Now here is a question about PHIGS deferral mode for which I > don't have an answer. What possible use could there be for > deferral mode ASTI (At Some Time)? The standard spec seems to > imply that this deferral mode allows implicit regeneration to > occur, but at completely undetermined times. The standard also > allows an implementation to make ASTI equivalent to ASAP, which > indeed seems to be the case in the implementation with which I am > most familiar (although you couldn't tell it from their > documentation). I cannot imagine that an application programmer > would be indifferent as to if and when implicit regeneration > might occur. Can any of the Phounding Phathers of PHIGS tell me > what they had in mind when they created this deferral mode? I am a long ways from a "PHIGS Architect", as Eileen refers to herself, but I was at the Palm Bay meeting in 1985 when that stuff got laid out. I think the rational was that some devices would suffer severe performance penalties if they had to buffer everything up. It was not lobbied for strongly by anyone, but rather thought to be a good middle ground between ASAP and WAIT. I also remember it being quite a hot issue and when the total deferral/modifiaction package was put together - solving the main needs of those who cared about UQUM, BNIL, etc everyone was quite relieved to have a solution. I do agree with you that there are too many options. I question the usefulness of BNIL and BNIG, anyone ever used them? Theoretically, they seem nice, but that implies alot of correct cooperation between PHIGS input and output. Of course, I always question the usefulness of PHIGS input in the light of "modern UIs", but that's another story. I can only see the usefulness of three of them. WAIT/NIVE as useful for applications that want display a frame at time. WAIT/UQUM is useful for editing wireframe geometry. UQUM in Z buffer is still a research issue to my knowledge. ASAP is useful for debugging your PHIGS application. The same way calling XSynchonize to force flushes is useful. Deferral and Modification modes are not the penultimate to understanding PHIGS. They are important to developing a tuned application, granted. So are things like how many structures you use and how big they are, how you navigate in structures, the edit mode you use, where in the structure you edit ( at the end? ). And, ASAP should probably be the default - let those that know better change it. We knew when we changed it back at Apollo that niave users would have to learn another thing - but a large customer said jump... PHIGS is suffering because there is a tremendous leap in comprehension one needs to make before one feels comfortable with it. This book has exactly the right approach help people make that leap. The example they give on page 18 of the simple PHIGS program that actaully draw something is great. That is exactly the answer to the graPHIGS question last week. Considering the state of many who want to know about PHIGS is "Give me any example program that draws anything", I'd say the Practical Intro book is better than great. It is unfortunate that the examples will not work out of the box on all PHIGSs - but if they did it would be #ifdef CITY! No two PHIGSs are alike in thier arguments to popen_ws. I hope the wide spread adoption of the PEX-SI PHIGS C binding & API help fix that. (and by the way the PEX-SI does have ASAP as the default). Ron Levine states in another article that he does have a tutorial that is being considered for publication. Hopefully, that does not affect his objectivity more than being listed in the acknowledgements affects mine. Obviously, Ron has lots of insights that are not in the Practical Intro book. Do those insights make this book any less useful to those who cannot cite chapter and verse out of the spec? No. This book is good for anyone who is using PHIGS now. If you can wait, you might hope that one of the two other books scheduled to be out at SIGGRAPH will be better. (Prentice Hall (Valerie Clark) and Wiley & Sons (Hopgood & Duce) They might be. Or you might want to wait longer. Ron suspects "a truly valid and helpful book on PHIGS PLUS is still about a year away." But the Practical Intro book sets a pretty high standard. I'm currently negotiating the movie rights for my script of "The Battle of the PHIGS Books" - with complete comparisons :-) The first crop of books will contain information on how to use the various pieces of PHIGS. It's a fair amount like the Oliver Jones Intro to X book. Tells you enough to get something going, but not enough to overwhelm you. I think there is great value in that. If Ron Levine can put all of his insights into a book aimed at someone who is familiar with PHIGS but wants to design an application to maximize the performance of PHIGS for thier applications MORE POWER to him. I'd love to see a book about that, but to me that is second generation knowledge. There are a zillion things that can affect PHIGS and PHIGS implementors optimize certain paths for thier favorite customers - things leave the intuitive. For example, 3D lines are faster than 2D lines, Gouraud shaded polygons are fast than hollow polygons - that is true on at least one PHIGS library on at least one machine. Heck, a good discussion of the optimum structure size vs. the cost of instancing would be worth a paper. The bottom line for me is that the Practical Intro book has great examples, great diagrams and for most things great descriptions. It's not perfect - I did not say it was. Of course the really interesting PHIGS issues are the things that are missing form the spec all together. Immediate mode springs to mind. PHIGS really needs immediate mode - write your congressman this week or next if you think immediate mode should be added to PHIGS. It's a little late to add it to PHIGS88 or PHIGS-PLUS but if everyone agreed on how to do it that would be a BIG first step. Of course there are other things like texture mapping, transparency and antialaising, too. -- -Jan "YON" Hardenbergh jch@stardent.com (508)-371-9810x261 Stardent Computer, 6 N.E. Tech Center, 521 Virginia Rd,Concord, MA 01742
jch@Stardent.COM (Jan Hardenbergh) (04/25/91)
> I am befuddled by Jan Hardenbergh's insistence on calling this > book "great", even though he recognizes many of its shortcomings. > I am also befuddled by his refusal to acknowledge many other of > its flaws. Yes, I acknowledged that some of the details you mentioned should have been done better. I'll admit I'm wrong, when I am. But some of the things you say are poorly described are IMHO quite well described. O.K. I'm getting bored with this discussion. Here is what I have to say. If you have any inkling of the scope of PHIGS and you understand the nature of Ron Levine's complaints then you will conclude that the book must be great. PHIGS is huge - it makes X look simple! To have a book like this come out - into a vacuum - and be arguing about details speaks highly of the book. I'm not alone in liking the book. Another PHIGS knowledgable person and a tech writer have both looked at the book and had favorable opinions. It would be nice to hear some other voices on this. -- -Jan "YON" Hardenbergh jch@stardent.com (508)-371-9810x261 Stardent Computer, 6 N.E. Tech Center, 521 Virginia Rd,Concord, MA 01742
tgross@dopey.prime.com (Tom Gross) (04/26/91)
In article <1991Apr25.034649.3579@Stardent.COM> jch@Stardent.COM (Jan Hardenbergh) writes: > >Deferral and Modification modes are not the penultimate to understanding >PHIGS. They are important to developing a tuned application, granted. >So are things like how many structures you use and how big they are, how >you navigate in structures, the edit mode you use, where in the >structure you edit ( at the end? ). And, ASAP should probably be the >default - let those that know better change it. We knew when we changed >it back at Apollo that niave users would have to learn another thing - >but a large customer said jump... > Speaking as one who actually worked on the Apollo PHIGS product and was actually an employee of the company at the time this particular decision was made, just for the record, when I was trying to figure out what the default deferral mode should be I initially thought "ASAP" because it came first alphabetically and I really didn't understand what BNIG, BNIL, and ASTI were anyway. Jim Michener however suggested we make the default WAIT/NIVE on the grounds that it was better to let the application control when it wanted changes to the picture to occur. Then I saw that Graphigs had made the same choice and I felt pretty confident it was okay. There was no "large customer" involved in the decision and in fact there was no "large" domain/PHIGS customer at that time. -Tom Gross
levine@well.sf.ca.us (Ron Levine) (04/29/91)
I offer my sincere apologies to Messrs. Howard, Hewitt, and Hubbold, and Ms. Wyrwas for the excessively emotive language of my two postings critiquing their book. It's all due to excessive haste, beginning with Jan Hardenbergh's hasty uncritical rave review, through my impulse to respond to his unjustified use of the superlative emotive "great book", and ending with my haste to post my response, trying to clear the issue from my agenda, without letting it simmer at all. This haste is characteristic of the USENET medium. To be sure, you would never find such language in any of my writings prepared for print. Especially, in my second posting, I would take back "is being duped" and replace it with "would be disappointed", which would make the sentence correctly express my belief. I am very sorry that I did not and still do not, have the time to fashion a thorough, orderly, and dispassionate critique. But it was a great mistake to let myself substitute strong language, because it diverts attention from the validity of the critical points that I made. Not to prolong the flame, I will communicate directly to the authors the rebuttals I have to points of their rejoinder. (I cannot reference this rejoinder, from toby@cs.man.ac.uk with subject line "A Practical Introduction to PHIGS and PHIGS PLUS", because it has not yet appeared on the system where I read comp.graphics. It was fowarded to me by a reader of another system.) It seems to me that the fundamental issue here is that my minimum standard for well crafted explanation in expository technical writing is somewhat more stringent than what satisfies many folk in this computer graphics community. If I dare risk one more emotive, I find this state of affairs discouraging. Ron Levine
levine@well.sf.ca.us (Ron Levine) (04/29/91)
In his long article, <1991Apr25.034649.3579@Stardent.COM> Jan Hardenberg states >Ron Levine states in another article that he does have a tutorial that >is being considered for publication. Hopefully, that does not affect >his objectivity more than being listed in the acknowledgements >affect smine. Let me re-iterate: The tutorial does not belong to me, but to the company which paid me an hourly rate to write it. It is not "being considered for publication", and its form and content are not suitable for publication as a book. But, as I stated, the possibility of making it more widely available is under discussion within that company. I would receive no material benefit from its wider distribution. It does not carry my by-line. This is fine with me, because even though some people have found it beneficial and I have been commended for it, it is still short of my highest standards of expository writing. Ron Levine Dorian Research, Inc. 415-535-1350
levine@well.sf.ca.us (Ron Levine) (04/29/91)
In article <SPENCER.91Apr24142319@spline.eecs.umich.edu>, Spencer Thomas takes issue with my paraphrase of a sentence in the book: >> In article <24373@well.sf.ca.us> levine@well.sf.ca.us (Ron Levine) writes: >> The second sentence overlooks the fact, that in general, NO >> workstations have the ability to modify parts of a displayed >> picture selectively, at least not correctly. On a CRT, you can ................ > >Not true. Many high-end workstations have a "built-in" display list. >Thus, as far as PHIGS is concerned, the image can be correctly >modified selectively. An old example is the E&S PS300 series (not >sure about their new workstation, as I don't have one.) Even on a >"bit-mapped" workstation, it may be possible to selectively update an >image, under certain conditions - for example, when adding a new >primitive to the end of a structure (depending on structure priority). Yes, on a calligraphic display, such as the PS300, you can selectively modify the display list and get a picture which is correct according to the display list. Now, I have no direct experience with PHIGS implementations for such devices, and so am not very certain about the relation between the device display list and the PHIGS posted structure network, but for several reasons it is hard for me to imagine that they would be identical. And if they are not, then to be sure that the device display list correctly represents the picture defined by the PHIGS posted structure network and workstation state list would require traversing the PHIGS structure network, i.e. "regeneration". (Because of the qualifier "in general" this sentence does not exclude the possibility that for some special picture changes or in some special situations, the display can be made current without traversal, as you point out). Now, this kind of traversal would not be so expensive as regeneration for a raster display because it does not involve scan conversion. Therefore, it may well be more acceptable to use deferral mode ASAP for such devices. Perhaps that is what the authors had in mind in their assumption of ASAP, to which I have objected. Of course, the calligraphic display would be not be a very good typical workstation model for a PHIGS/PHIGS PLUS discussion because it does not support the bulk of the features of the PHIGS and especially PHIGS PLUS system which are more oriented to raster. Do you, by the way, use PHIGS to drive your PS300? Even if I allowed that my sentence may be not completely true, it has not much bearing on my complaint about the paragraph in the book from which it is paraphrased, the paragraph which purports to define "implicit regeneration". This paragraph seems to create the impression that implicit regeneration is something to be used with devices such as laser printers (which would be a bad idea). And it fails to bring out the important fact that, under the book's unstated assumption of deferral mode ASAP, every incremental picture change will produce implicit regeneration, not selective modification, at least on all the most common interactive raster workstations. Ron Levine
jch@Stardent.COM (Jan Hardenbergh) (04/30/91)
From: <1442@cvbnetPrime.COM> > In article <1991Apr25.034649.3579@Stardent.COM> > jch@Stardent.COM (Jan Hardenbergh) writes: > > > >Deferral and Modification modes are not the penultimate to understanding > >PHIGS. They are important to developing a tuned application, granted. > >So are things like how many structures you use and how big they are, how > >you navigate in structures, the edit mode you use, where in the > >structure you edit ( at the end? ). And, ASAP should probably be the > >default - let those that know better change it. We knew when we changed > >it back at Apollo that niave users would have to learn another thing - > >but a large customer said jump... > > Speaking as one who actually worked on the Apollo PHIGS product > and was actually an employee of the company at the time this > particular decision was made, just for the record, when I was > trying to figure out what the default deferral mode should be I > initially thought "ASAP" because it came first alphabetically > and I really didn't understand what BNIG, BNIL, and ASTI were > anyway. Jim Michener however suggested we make the default > WAIT/NIVE on the grounds that it was better to let the application > control when it wanted changes to the picture to occur. Then > I saw that Graphigs had made the same choice and I felt pretty > confident it was okay. There was no "large customer" involved > in the decision and in fact there was no "large" domain/PHIGS > customer at that time. > > -Tom Gross As my father always said, never ruin a good story with facts. I do remember a conversation with the manager of the PHIGS project at Apollo, not some measly employee :-). This conversation was in regards to the suitability of WAIT as the default deferral mode. I must admit I was probably construing too much into the conversation - so I will not contradict Mr Gross, himself a noted PHIGS lecturer. However, I do want to know why he insists upon refering to Jim Michener, one of the "PHIGS Architects" and long time graphics standards guru as if they were good buddies. Next, Mr. Gross will be telling us that he has lunch with and knows all of the PHIGS Architects from HP, Sun and DEC. As long as he does not claim to be one of the original PEX Architects, I can over look a little shameless name dropping :-) -- -Jan "YON" Hardenbergh jch@stardent.com (508)-371-9810x261 Stardent Computer, 6 N.E. Tech Center, 521 Virginia Rd,Concord, MA 01742
rick@pangea.Stanford.EDU (Rick Ottolini) (04/30/91)
It sounds like a lot of people want a PHIGS book, particularly with PEX coming down the line. This is a good opportunity for some author-entrepenaur out there to write something.
levine@well.sf.ca.us (Ron Levine) (05/01/91)
Sorry to break up the continuity of this discussion, but I
have canceled the posting of my two original testy intemperate
contributions. It is time to be more constructive, not purely
critical. So, as time permits, I will post a few short essays on
PHIGS topics, to show what I mean.
Ron Levine
Dorian Research, Inc.
(415)-535-1350jch@Stardent.COM (Jan Hardenbergh) (05/01/91)
From: rick@pangea.Stanford.EDU (Rick Ottolini) > It sounds like a lot of people want a PHIGS book, particularly with PEX > coming down the line. This is a good opportunity for some > author-entrepenaur out there to write something. I would advise anyone who is not well into such a project to think carefully about this. You should definitely read this book and form your own opinion about how good it is and how long it would take to do better than it. There has been some difference of opinion on how good this book is. I think it sets a high standard. A Practical Introduction to PHIGS and PHIGS PLUS TLJ Howard, WT Hewitt, RJ Hubbold, KM Wyrwas Addison-Wesley 1991 ISBN 0-201-41641-7 At SIGGRAPH there should be at least two more books. Prentice Hall will actually be publishing a book on PHIG's very soon. It is by Valerie Clark, (formerly?) of Sun Microsystems. John Wiley and Sons, Inc. is also planning to have a book available at SIGGRAPH91. "A Primer for PHIGS" by Hopgood & Duce. After SIGGRAPH there is rumored to be another book on PHIGS. This is being written by the person who wrote the old Domain/PHIGS book, which I also used to recommend. Also, Ron Levine says of his tutorial "But, as I stated, the possibility of making it more widely available is under discussion within that company." It is evident that if such a book did come out and lived up to Ron's expectations it would be an indepth exploration of the theory and practice of PHIGS. I also claimed previously that there was a rumor at the X conference the O'Reilley was going to publish the PEX-SI Library Manual Pages. These are quite good man pages on the PHIGS "C" binding on a call by call basis. That rumor may be a little stale, but it makes so much sense, heck, may be they will do a tutorial type thing, too. I'm sure there are other efforts that I do not know about... The point is this: Unless you have a decent manuscript in progress, or some special angle - OR you wanted to write a book about how to use PHIGS accross platforms, or you wanted to write a book about PHIGS & X you should not start another PHIGS book until you know you can do better. - As always, unless specifically stated otherwise, I am posting on my own behalf, expressing my own opinions and facts gathered by myself, as an individual. -- -Jan "YON" Hardenbergh jch@stardent.com (508)-371-9810x261 Stardent Computer, 6 N.E. Tech Center, 521 Virginia Rd,Concord, MA 01742
tgross@dopey.prime.com (Tom Gross) (05/02/91)
Jan Hardenbergh writes: >As my father always said, never ruin a good story with facts. I do >remember a conversation with the manager of the PHIGS project at Apollo, >not some measly employee :-). This conversation was in regards to the >suitability of WAIT as the default deferral mode. I must admit I was >probably construing too much into the conversation - so I will not >contradict Mr Gross, himself a noted PHIGS lecturer. > >However, I do want to know why he insists upon refering to Jim Michener, >one of the "PHIGS Architects" and long time graphics standards guru as >if they were good buddies. Next, Mr. Gross will be telling us that he >has lunch with and knows all of the PHIGS Architects from HP, Sun and >DEC. As long as he does not claim to be one of the original PEX >Architects, I can over look a little shameless name dropping :-) Jan, I'm beginning to regret that the last time I spoke to Andy You-Know-Who I went out of my way to assure him that you are not completely full of shit. No one who knows anything about graphics would ever admit to having been a "phigs manager". No one who really knows phigs would want to be called a "phigs expert". I certainly wouldn't call myself one of the "original PEX architects", out of respect for the people at DEC and SUN who actually did all the work. Nor do I think you should pretend to be a "phigs expert" based on your experience of sharing an office with the "phigs manager" at Apollo. No need for smiley faces here as this is obviously just good fun between friends. /tom
thomson@cs.utah.edu (Rich Thomson) (05/02/91)
In article <1462@cvbnetPrime.COM> tgross@cvbnet.prime.com (Tom Gross) writes: > No one who really knows phigs would want to be called a "phigs > expert". Why not? Here's what the webster server says about expert: > Cross references: > 1. proficient > > 1. ex.pert \'ek-.sp*rt, ik-'\ aj [ME, fr. MF & L; MF, fr. L expertus, fr. > pp. of experiri] obs 1: EXPERIENCED 2: having, involving, or displaying > special skill or knowledge derived from training or experience - ex.pert.ly > av > 2. ex.pert \'ek-.sp*rt\ n [F, fr. expert, adj] : one who has acquired > special skill in or knowledge of a particular subject : AUTHORITY > 3. ex.pert \'ek-.sp*rt\ vt : to serve as an expert for : to serve as an > expert Sounds like someone who really knows PHIGS is exactly the expert as defined above. It seems like there are lots of people out there on the net that are interested in PHIGS and are curious about salient points. Also, questions come up from people using PHIGS about how to do this or that. Given the (until recent) dearth of good information sources on PHIGS (I consider the standard something akin to a legal document instead of the kind of thing we expect from "documentation"), I would think that the more PHIGS experts we have reading and participating in comp.graphics, the better. There are lots of things that can be gleaned from "traning and experience" that aren't obvious from the standards documents. Things like: o POLYLINE SET 3 WiTH DATA is the structure element to use if you want color-per-vertex polylines o FILL AREA (and variants) don't have edges -- if you want edges, you have to use FILL AREA SET (and variants). -- Rich Rich Thomson thomson@cs.utah.edu {bellcore,hplabs,uunet}!utah-cs!thomson ``Read my MIPs -- no new VAXes!!'' --George Bush after sniffing freon