toby@cs.man.ac.uk (toby) (04/25/91)
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, posted on comp.graphics, by Ron Levine. We are all
experienced authors, and are accustomed to the usual processes of peer review,
and public comment on publicly available material. Normally we would not feel
the necessity to respond to reviews which are expressed in conventionally
professional terms, but we feel that the content and tone of Mr Levine's
reviews merit a special reaction, especially his statements that we present
technical information which is inaccurate. We feel that Mr Levine's review
contains a number of unreasonable criticisms which might give his readers a
quite incorrect view of our book. While Mr Levine's and our opinions of PHIGS
and PHIGS PLUS may quite naturally differ, we cannot accept his criticisms
that the information contained in the book is inaccurate or erroneous.
Mr Levine's reviews have used somewhat emotive language not usually found in
the context of serious, professionally written articles, such as 'ludicrous',
'duped', 'mysterious', 'offended', and 'befuddled'. It is certainly not our
intention to call Mr Levine's literary style into question, but rather to try
to comment as honestly as we can on what we believe are quite unreasonable,
and misleading, criticisms. We should point out that the book has now been in
the public arena in Europe and the USA for some months, and Mr Levine's
comments are very far from typical of the professional opinions we have so far
encountered.
We would like to state at the outset that we are familiar with the protocols
and conventions of USENET, and we are posting this article purely as a
critical response. It is not our intention to exploit USENET for commercial
gain. In that spirit we shall not comment on what we believe are the merits of
the book, nor provide publication details and order information for the
benefit of those who have not been following the thread of the articles on
comp.graphics.
To begin, we agree with Mr Levine's comments that for many workstations, the
default deferral mode is not ASAP. We decided to base our examples on the
assumption that it was ASAP in order to make our description clearer. We are
attempting to present an introduction to PHIGS concepts, not implementation
details. Mr Levine takes us to task for our definition of implicit
regeneration, which he states is 'just wrong'. On the contrary, we believe it
is entirely correct. He also states that the PHIGS Standard Document does not
define the term. This is incorrect (it is definition 3.89 in the Standard).
Moving to POLYLINE SET WITH DATA, Mr Levine states that 'the explanation
ignores the primary rationale for aggregating a number of individual
polylines ito a single primitive: namely, that it may frequently result in
important performace gains, by reducing the overhead of function calls, bus
transactions, etc'. One of the authors is Issues Editor on the ISO PHIGS
PLUS committee. 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. POLYLINE SET WITH DATA was
felt by the ISO Committee to be the most appropriate primitive to enable a
uniform representation. We regard efficiency as an implementation issue,
and offering advice on this basis seems inappropriate to us, given the
degree to which different implementations vary.
Mr Levine states 'I was particularly offended by the discussion of 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'. Of course, this is a value judgement on our part, and we feel
it to be entirely justified. One of the ideas embodied in the PHIGS Standard
is that of 'application layers' which exist to shield applications from many
of the tedious nitty gritty and awkward function definitions which PHIGS
provides. In his remarks he omits the final part of the 'offending' paragraph:
'SET OF FILL AREA SET 3 WITH DATA would normally be used to write higher-level
utility functions - one to display a cube, another to display a tetrahedron,
and so on.' We believe this makes the context of the discussion clear.
Mr Levine is unhappy about our treatment of NURBs. Early on in the preparation
of the book we made a conscious decision not to cover NURBs in all their
mathematical glory. Instead, we decided to explain the ways in which NURBs
appear as primitives in PHIGS PLUS. No, we do not discuss their invariance
under affine transformations, nor convex hull properties and so on. This
would take us into an area far from PHIGS and PHIGS PLUS, and this is not our
intention. Yes, we make the distinction between rational and non-rational
B-splines, because this is precisely the distinction made in PHIGS PLUS. We
would not agree that 'the discussion peters out with a weak reference to the
books written by Farin and the Killer Bees'. Our text states 'The non-uniform
B-Spline formulation is very powerful, and space does not permit a more
detailed treatment. For thorough coverage of B-spline curves and surfaces the
reader is referred to [Bartels et al] and [Farin, 1990].'
Mr Levine states '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'. We take exception with this statement, which we find
extremely offensive. It would come as a great surprise to us if Mr Levine has
any information whatsoever about the history of our book, its development, or
market planning. If so, we would wonder how he came by such information. If
not, is he really in a position to comment accurately? We doubt it!
Mr Levine says 'in general, NO workstations have the ability to modify parts
of a displayed picture selectively, if not correctly'. To this, we would reply
not true. We have for years used displays which have precisely this
capability. We note that Spencer Thomas has commented on this point.
Mr Levine states 'The definition of "right-handed coordinate system" in Sec.
3.1 is just ludicrous and has no practical value'. It may appear trivial, but
we included it because many books and papers on computer graphics use a
left-handed coordinate system. In fact, at one stage in the development of
PHIGS, both left- and right-handed systems were proposed!
In conclusion we note that Mr Levine's final comment (in his second posting)
is as follows: 'But anyone who buys [the book] on the strength of the title's
claim that it is a "practical introduction" to PHIGS PLUS is being duped'.
This is a rather unpleasant allegation. On the first text page of the book we
make it QUITE CLEAR that the book does not cover PHIGS PLUS in anything like
the detail we cover PHIGS: 'As this book goes to press (January 1991), the
technical specification of PHIGS PLUS is not yet finalized, and it is
therefore not possible for us to give a complete description. However,
although the details are subject to change, the underlying philosophy is not,
and it is from this point of view that we approach PHIGS PLUS in Chapters 13
and 14'.
Toby Howard
Terry Hewitt
Roger Hubbold
--
--------------------------------------------------------------------------
Toby Howard Computer Science Department, University of Manchester,
Lecturer Oxford Road, Manchester, M13 9PL, U.K.
janet: toby@uk.ac.man.cs.p1
internet: toby%p1.cs.man.ac.uk@nsfnet-relay.ac.uk
earn/bitnet: toby%uk.ac.man.cs.p1@UKACRL
uucp: ...!ukc!mup1!toby voice: +44 61-275-6274
--------------------------------------------------------------------------rthomson@mesa.dsd.es.com (Rich Thomson) (04/26/91)
In article <TOBY.91Apr25172046@p1.cs.man.ac.uk> 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