rit@killdeer.Stanford.EDU (Jean-Francois Rit) (03/16/91)
The Dec solution for 3D graphics on their Risc Decstation5000 is PHIGS. Yet, their graphics demo directory (3d_demo) contain numerous examples, none of them using PHIGS, but, I guess PEX. The reason why I think they do not use PHIGS is that any PHIGS binary contains huge libraries and is at least 7M big. Incidentally, the linking of these programs is very slow and you can use this time to sift through the large, painful and Fortran oriented DECPHIGS documentation My question is: is there such a thing as a PEX implementation for the DEC5000, which would be more lightweight than PHIGS? Is it used internally by DEC? What people should I contact to have more info about this? I will forward a copy of this message to our DEC representative at Stanford, but maybe a post in the news will cut through to the right people more rapidly. J-F Rit
rthomson@mesa.dsd.es.com (Rich Thomson) (03/18/91)
In article <1991Mar15.190013.7415@neon.Stanford.EDU> rit@killdeer.Stanford.EDU (Jean-Francois Rit) writes: >The Dec solution for 3D graphics on their Risc Decstation5000 is >PHIGS. Yet, their graphics demo directory (3d_demo) contain numerous >examples, none of them using PHIGS, but, I guess PEX. PEX is PHIGS/PHIGS-PLUS Extensions to X, so if they are using PEX they are using PHIGS (at least for output -- PEX doesn't attempt to cover PHIGS style input on the server side; input happens through a beast called the "PHIGS Monitor" which runs as a separate process that interacts with a PHIGS client program). So, if you are using PEX you are using PHIGS. -- 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
garry@ithaca.uucp (Garry Wiegand) (03/20/91)
rthomson@dsd.es.com (Rich Thomson) writes: >PEX is PHIGS/PHIGS-PLUS Extensions to X, so if they are using PEX they >are using PHIGS ... 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. 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. 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. PEX might have been better-named as "3-D Extensions to X". I am aware that there are people on the committee who wanted to bind things more tightly to Phigs but, in looking at the spec, I see that the generalists seem to have won out for the most part. Garry Wiegand --- Ithaca Software, Alameda, California ...!uunet!ithaca!garry, garry%ithaca.uucp@uunet.uu.net
pmartz@undies.dsd.es.com (Paul Martz) (03/21/91)
In article <1991Mar20.044028.16631@ithaca.uucp>, garry@ithaca.uucp (Garry Wiegand) writes: > rthomson@dsd.es.com (Rich Thomson) writes: > >PEX is PHIGS/PHIGS-PLUS Extensions to X, so if they are using PEX they > >are using PHIGS ... > > 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. > > [...] > > Garry Wiegand --- Ithaca Software, Alameda, California > ...!uunet!ithaca!garry, garry%ithaca.uucp@uunet.uu.net [Of course I can't help but jump into this discussion!] It seems to me Rich is saying when you use PEX you are using PHIGS because PEX protocol requests are interpreted using PHIGS semantics on the server side. The obvious counter-argument is presented by Garry, who says you don't have to use PHIGS to use PEX, just write some other API that spits out PEX protocol. This is just quibbling: Obviously, both viewpoints are correct, depending on how you wish to view the issue. However I think it's most interesting to look at this from the application's view of things, and let's see if some of this confusion can't be cut through... If the application creates its own X window and then proceeds to call popen_xphigs, is it still using PHIGS? Well, yes, it makes many PHIGS calls after that. But it's not pure PHIGS -- it uses XCreateWindow (or some variety thereof), and popen_xphigs, which is a PEX-SI specific call to let X-cognizant applications use PHIGS. I think this is the type of program the original poster referred to when he said he came across some "PEX" programs. I have always thought of a PEX application as one which *must* run under a PEX implementation of PHIGS because it uses some X or X-related calls. The situation is similar if an application uses the proposed PEXIM API, which gives the application direct access to PEX's immediate mode functionality. The application still uses PHIGS calls, but becomes unpure, and can only port to a PEXIM implementation of PHIGS. You can no longer refer to that application as a PHIGS application because that is misleading. I wouldn't want to call it a PEX application either, since that implies it would be portable to all PEX-SI based API libraries. Let's call it a PEXIM application. So what happens when an application uses the proposed PEXtk API from ShoGraphics? It's not a PHIGS application -- there's not a single PHIGS call in there. Nor is it a GL application, even though the port would be trivial. PEX protocol is used, but the PEX-SI API is no where in sight. I guess you'd have to call it a PEXtk application. A programmer who writes a PEXtk application can be completely PHIGS ignorant, even though PEX is being used. Saying the application uses PHIGS because it uses PEX may make sense to those of us who have implemented PEX, but it just confuses the issue to the application programmer -- and aren't we implementing PEX for them, anyway? -- -paul pmartz@dsd.es.com Evans & Sutherland
gds@atticus (Greg Schechter) (03/21/91)
In article <1991Mar20.170615.11253@dsd.es.com>, pmartz@undies (Paul Martz) writes: >I think this is the >type of program the original poster referred to when he said he came >across some "PEX" programs. I have always thought of a PEX application >as one which *must* run under a PEX implementation of PHIGS because it >uses some X or X-related calls. One fairly minor quibble... PHIGS running on top of an X window system does not necessarily imply PEX. It's quite feasible to have an application which uses both PHIGS and X, and have that PHIGS implementation, when run locally, not make use of PEX at all, but, rather, talk directly to the graphics hardware. -- Greg ============================================================================= = Greg Schechter Graphics Technology Group = = Sun Microsystems, Inc Mailstop MTV21-04 = = 2550 Garcia Avenue Mountain View, CA = = gschechter@Eng.Sun.COM (415) 336-6950 = =============================================================================
rthomson@mesa.dsd.es.com (Rich Thomson) (03/21/91)
[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