Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!cs.utexas.edu!uunet!orca!mesa!rthomson
From: rthomson@mesa.dsd.es.com (Rich Thomson)
Newsgroups: comp.graphics
Subject: Re: PEX, PHIGS, DEC5000?
Message-ID: <1991Mar21.023819.18010@dsd.es.com>
Date: 21 Mar 91 02:38:19 GMT
References: <1991Mar20.044028.16631@ithaca.uucp>
Sender: usenet@dsd.es.com
Reply-To: rthomson@dsd.es.com (Rich Thomson)
Organization: Design Systems Division, Evans & Sutherland, SLC, UT
Lines: 107
Nntp-Posting-Host: 130.187.85.21

[N.B.  I will use the term "PHIGS" to refer collectively to both PHIGS
and PHIGS-PLUS]

In article <1991Mar20.044028.16631@ithaca.uucp>
	garry@ithaca.uucp (Garry Wiegand) writes:
>No, you can use PEX without getting involved with Phigs. We are
>planning on doing this, as soon as we have been given an actual
>working Pex. 

I don't agree here.  See Paul Martz's comment on the exchange for a
little more detail.  If you are using PEX, then you are going to get
PHIGS semantics on the rendering pipeline and it isn't a generic
geometry pipeline as you might think.  Yes, you have access to a
"renderer" resource.  The renderer will take output commands and
render them.  But the act of "rendering" an output command is not as
easily defined as you might think.  Consider the following example:

    How do you think the surface normal for the following two polygons
    will be determined?

    P1 := { V0, V1, V2, V3, V4}		P2 := { V1, V2, V3, V4, V0 }

    V0 := (0, 0)
    V1 := (1, 0)
    V2 := (.5, .5)
    V3 := (1, 1)
    V4 := (0, 1)

While these two polygons are equivalent in a geometric sense (I've
merely rotated the vertex list), they won't give equivalent output
because the default surface normal is computed from the first 3 non
co-linear points in the vertex list.  [PEX Introduction & Overview, pg
52]  Where does this specification come from?  It comes from PHIGS.
In fact, the definition of the computed geometric normal is lifted
directly from the PHIGS-PLUS document ISO/IEC 9592-4, pg 32.
This is what I mean when I say that you will get PHIGS semantics
on your server.  Since the internal architecture of the PEX-SI
ddpex layer abstracts 3D rendering below both the renderer resource
and the PHIGS workstation resource, the PEX-SI will inherintly push
some kinds of PHIGS semantics onto the renderer. [PEX-SI Architecture
Spec.  version beta, pg. 15]

>PEX has some constructs in it that are specific to Phigs, but the
>bulk of PEX is a geometry pipeline protocol plus various renderers
>on the receiving end. 

On the receiving end, you have the PHIGS workstation and a renderer.
The only difference between the two is that the p.w. is more
restricted in that it can only receive output commands from a list of
posted structures to the workstation [PEX I & O, pg.  10].  In
addition, p.w.'s contain extra state for support of PHIGS style
picking.  The protocol specification describes a renderer as:

    ``[...] a PEX resource that can be created for the purpose of doing
    3D rendering.  A renderer consists of resource ID's for various
    tables and name sets, the resource ID of a pipeline context from
    which the initial rendering pipeline attributes will be copied, and
    other attributes.''

I guess you can interpret this to mean that you have "various
renderers" in the sense that you can have several renderers, each with
their own IDs.  However, to interpret this to mean that you have
several renderers *each of which implements its own rendering
semantics*, would be a mistake I think.

This is all I'm getting at: you can have Y API's, each of which boils
down to the PEX protocol and possibly allocates and utilizes N
renderers, but when it trickles down to the lowest layer, they are all
implemented on top of the same rendering semantics.

I'm more than happy to call this set of semantics "PEX semantics" if
you want, but it originates from the concepts in PHIGS and you might
as well call it PHIGS.

>A geometry pipeline is a very generic concept in the computer
>graphics world: no matter where you start from in inventing your
>pipeline you always end up with just about the same thing at the bottom
>end. Because of the constraints on the problem, like the kinds of
>geometry you have available.

Yes, it is a generic concept but you don't "always end up with just
about the same thing at the bottom end."  Why do you think PHIGS
allows so many "implementation dependant" and "workstation dependant"
portions?  The concept of a rendering pipeline didn't originate with
either PEX or PHIGS.  It is a useful abstraction when discussing the
process of rendering.  It is not, however, a formal mechanism that can
be used to discuss these kinds of things.  Without this formalism, you
can't be sure of getting "just about the same thing" out of the
pipeline.  This is also true of PEX.  [Work on formalism in rendering
has been done: see Mallgren, W.R. _Formal Specification of Interactive
Graphics Programming Language_, MIT Press, Cambridge, MA, 1983;
Onodera & Kawai, _A Formal Model of Visualization in Computer
Graphics Systems_, Lecture Notes in Computer Science #421,
Springer-Verlag, 1990; E. L. Fiume, _The Mathematical Structure of
Raster Graphics_, Academic Press, 1989]

I think we've pretty much beat this into the ground.  There are two
directions further discussion could take place: formal methods for
computer graphics and discussions of the details of the semantics
implemented by PEX.

						-- 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