sato@wm120_no0.rinfo.sumiden.co.jp ( Kenya SATO @ SEI ) (03/05/90)
Does anybody doubt that PEX will be popular after being released at the beginning of 1991? I expected that PEX will popular for one or two years. But when the speed of computer networks becomes much faster than they are now, a graphics server may emerge, which quickly makes graphics images and sends the image data to a low-cost bitmap display. If this becomes true, PEX will become obsolute. -- Kenya SATO ( sato%rinfo.sumiden.co.jp@uunet.uu.net ) Computer & Information Systems R&D Department Information & Electronics Technology Laboratories SUMITOMO ELECTRIC INDUSTRIES, LTD.
kyriazis@iear.arts.rpi.edu (George Kyriazis) (03/06/90)
In article <1460@wm120_no0.rinfo.sumiden.co.jp> sato@wm120_no0.rinfo.sumiden.co.jp ( Kenya SATO @ SEI ) writes: > > >Does anybody doubt that PEX will be popular after being released at >the beginning of 1991? > I think that PEX will be popular for a few years but not for too long mainly for the following two reasons: 1. Programming in PHIGS is a pain. Programming in X is also a pain. It's pretty logical to derive that programming in PEX will be a pain squared! 2. Simulations are becoming more and more popular. Those need physical interactions between geometric objects. The tree structure of PHIGS does not easily allow picturing of those interactions. Therefore some more object-oriented approaches to rendering should be developed to "replace" PHIGS. ---------------------------------------------------------------------- George Kyriazis kyriazis@turing.cs.rpi.edu kyriazis@rdrc.rpi.edu kyriazis@iear.arts.rpi.edu
jch@apollo.HP.COM (Jan Hardenbergh) (03/08/90)
From: sato@wm120_no0.rinfo.sumiden.co.jp ( Kenya SATO @ SEI ) From: kyriazis@iear.arts.rpi.edu (George Kyriazis) > Does anybody doubt that PEX will be popular after being released at > the beginning of 1991? Are you asking about PHIGS or networked 3D graphics? PHIGS will be like FORTRAN. Lots of people will complain about it but it will be the best option they have. PHIGS will change over time to adapt to customer needs. > I expected that PEX will popular for one or two years. But when the > speed of computer networks becomes much faster than they are now, a > graphics server may emerge, which quickly makes graphics images and > sends the image data to a low-cost bitmap display. If this becomes > true, PEX will become obsolute. This is possible, but think about how much data you are pushing around. How big is the window? Are you using 24 bit pixels? 600 pixels x 500 pixels x 3 bytes = 1 mega byte. The whole screen is 3 mega bytes. Do you want any animation? With a little effort one can come up with a formula to determine is a given application will do better of worse with different network compute/graphics servers. Here are some variables. primDefCalc - Calculations to define primitive primDispCalc - Calculations to display or render primitive percentChange - How much of the scene change between redisplays primExpansion - How much data does it take to render this primitive. For Example - a circle is defined by a center and a radius but takes many many lines to draw. A line does not expand at all. An application having lots of nurb surfaces will have a high PrimExpansion. percentClip - How much of the scene gets clipped usually. computeRatio - Ratio of compute horsepower between the client's box and server's box. metafileSize - if an application's metafile is too big then it is better to keep it in one place. Another question this poses, what is the graphics server running? Chances are good it will be PEX, or some derivative. > 1. Programming in PHIGS is a pain. Programming in X is also a pain. > It's pretty logical to derive that programming in PEX will > be a pain squared! PHIGS will be the interface to PEX. Only those things that would normally change from vendor to vendor will change for PEX. So, still only a pain. > 2. Simulations are becoming more and more popular. Those need > physical interactions between geometric objects. The tree structure > of PHIGS does not easily allow picturing of those interactions. > Therefore some more object-oriented approaches to rendering should > be developed to "replace" PHIGS. That depends if the objects are rigid bodies. PHIGS is ideal for rigid body animation. Just diddle a single matrix and move the object. What the display list aspect of PHIGS is not good for is deformations of a large percentage of the objects. When the number of edits between refreshes ( percentChange ) goes up a display list is bad, a display list accross the net is worse. But you still use the same basic primitives of PHIGS: viewing, modelling matrices, lighting, shading and polygons/tristrips or whatevers. I do agree that allowing some sort of object oriented interface to PHIGS would be a good idea. PHIGS is, technically, only a year old and already has quite a bit of support. It will change, sure. But get replaced? I don't think so. -Jan Hardenbergh - jch@apollo.hp.com - HP / Graphics Technology Division
david@ics.ics.COM (David B. Lewis) (03/08/90)
>Does anybody doubt that PEX will be popular after being released at >the beginning of 1991? >Kenya SATO ( sato%rinfo.sumiden.co.jp@uunet.uu.net ) Depends on how quickly multi-threaded X servers make it to the rest of the world. David B. Lewis david@ics.com david%ics.UUCP@bu.edu ...!uunet!ics.com!david "Free computerized National Police! / Everybody got identity cards? At ease! / Freedom for Big Business to eat up the sea / Freedom for Exxon to examine your pee!" -- Allen Ginsberg, "Industrial Waves"
kyriazis@iear.arts.rpi.edu (George Kyriazis) (03/08/90)
In article <490eac1b.20b6d@apollo.HP.COM> jch@apollo.HP.COM (Jan Hardenbergh) writes: > >> 2. Simulations are becoming more and more popular. Those need >> physical interactions between geometric objects. The tree structure >> of PHIGS does not easily allow picturing of those interactions. >> Therefore some more object-oriented approaches to rendering should >> be developed to "replace" PHIGS. > >That depends if the objects are rigid bodies. PHIGS is ideal for rigid >body animation. Just diddle a single matrix and move the object. > Hmm.. I can argue about that. PHIGS is good for rigid-body animations that have an obvious tree structure, eg. robot arms. I'll bring an easy conter example and how it ties into simulation: Say you have a 3-legged table that can tip over easily over some floor. You interactively apply forces at different positions of the table to see how it behaves. In this example, the tree structure of PHIGS does not help at all. Even worse, you have to do your rigid body simulation away from the graphics interface and then struggle to map your structure into some PHIGS tree. In other words, you are using the massive computational power you have in your graphics engine just for graphics and doing the simulation on your poor SPARC/R2000/68040, even if data that you need for simulation are already calculated by the graphics engine! Ouch! >What the display list aspect of PHIGS is not good for is deformations of >a large percentage of the objects. When the number of edits between >refreshes ( percentChange ) goes up a display list is bad, a display >list accross the net is worse. But you still use the same basic >primitives of PHIGS: viewing, modelling matrices, lighting, shading and >polygons/tristrips or whatevers. > I would strongly agree on that. But, is there another graphics 'standard' that does this efficiently today? >I do agree that allowing some sort of object oriented interface to >PHIGS would be a good idea. PHIGS is, technically, only a year old >and already has quite a bit of support. It will change, sure. But >get replaced? I don't think so. > My point is that a "graphics standard" will not actually be very useful in the future. Something like a "graphics simulation standard" sounds better. Graphics engines is a nice idea, but I think it's a waste to keep them just for graphics work. Maybe rename them to "accelerator engines" in the future? PHIGS will eventually be replaced several years down the road. Companies will keep on supporting existing standards as long as nothing better is in sight, and research environments will keep on trying to pursuade companies that what they are working on is better than the existing standards.. :-) > >-Jan Hardenbergh - jch@apollo.hp.com - HP / Graphics Technology Division ---------------------------------------------------------------------- George Kyriazis kyriazis@turing.cs.rpi.edu kyriazis@rdrc.rpi.edu kyriazis@iear.arts.rpi.edu
jch@apollo.HP.COM (Jan Hardenbergh) (03/09/90)
From: kyriazis@iear.arts.rpi.edu (George Kyriazis) > >That depends if the objects are rigid bodies. PHIGS is ideal for rigid > >body animation. Just diddle a single matrix and move the object. > > > Hmm.. I can argue about that. PHIGS is good for rigid-body animations that > have an obvious tree structure, eg. robot arms. I'll bring an easy > conter example and how it ties into simulation: > Say you have a 3-legged table that can tip over easily over some floor. > You interactively apply forces at different positions of the table to > see how it behaves. In this example, the tree structure of PHIGS does not > help at all. Yes, so...? I am not claiming that the hierarchiy is always appropriate. Actually, how to effectively use hierarchy in PHIGS is worthy of some study. In general there are lots of PHIGS features that will not be used by this or that application. > Even worse, you have to do your rigid body simulation away > from the graphics interface and then struggle to map your structure into > some PHIGS tree. While it is true that PHIGS will not calculate the new position of your rigid body for you, PHIGS will allow you to easily position it by just changing one matrix. > In other words, you are using the massive computational power > you have in your graphics engine just for graphics and doing the simulation > on your poor SPARC/R2000/68040, even if data that you need for simulation > are already calculated by the graphics engine! Ouch! This is an excellent point. Special purpose graphics engines are not appropriate for all graphics applications. Look at a DN10K sometime. It has a very smart frame buffer for a graphics engine. All of the geometry pipeline is done by the regular CPU, or CPUs. It can give you 78K polygons per second, but you have all of that power to run your application when you are not doing graphics. (Err... that 78k is GMR3D) > >list accross the net is worse. But you still use the same basic > >primitives of PHIGS: viewing, modelling matrices, lighting, shading and > >polygons/tristrips or whatevers. > > > I would strongly agree on that. But, is there another graphics 'standard' > that does this efficiently today? No, but one could imagine allowing access to the PHIGS pipeline with out having to use the display list. > My point is that a "graphics standard" will not actually be very useful > in the future. Something like a "graphics simulation standard" sounds > better. Graphics engines is a nice idea, but I think it's a waste to keep > them just for graphics work. Maybe rename them to "accelerator engines" in > the future? PHIGS will eventually be replaced several years down the road. > Companies will keep on supporting existing standards as long as nothing > better is in sight, and research environments will keep on trying to > pursuade companies that what they are working on is better than the existing > standards.. :-) You seem to equate PHIGS with graphics engine. No reason to do that. You also seem to think PHIGS will be replaced while still acknowledging it has the right tools. I think you will do better to get better access to the tools that PHIGS has instead of starting the standards process over. This one is definitely one my own time, and not on behalf of my employer. -Jan Hardenbergh - jch@apollo.hp.com - HP / Graphics Technology Division
sato@wm120_no0.rinfo.sumiden.co.jp ( Kenya SATO @ SEI ) (03/09/90)
In article <$*-#G+_@rpi.edu>, kyriazis@iear.arts.rpi.edu (George Kyriazis) says: > In article <1460@wm120_no0.rinfo.sumiden.co.jp> sato@wm120_no0.rinfo.sumiden.co.jp ( Kenya SATO @ SEI ) writes: >> >>Does anybody doubt that PEX will be popular after being released at >>the beginning of 1991? >> > > I think that PEX will be popular for a few years but not for too long mainly > for the following two reasons: > > 1. Programming in PHIGS is a pain. Programming in X is also a pain. > It's pretty logical to derive that programming in PEX will > be a pain squared! > > 2. Simulations are becoming more and more popular. Those need > physical interactions between geometric objects. The tree structure > of PHIGS does not easily allow picturing of those interactions. > Therefore some more object-oriented approaches to rendering should > be developed to "replace" PHIGS. I agree with you. It is painful to program in PHIGS. Of course, Programming in X is a pain if you use X lib, but it is easier to program using Toolkit than using X lib directly. I think good programming tools in graphics, like X Toolkit, would make your programming easier. Such a utility, let's call it "PEX Toolkit", would provide the basic functionality necessery to build a variety of application environments. Anyway, I wanted to know if the concept of PEX, which means the PEX protocol, would be popular. If the communication between a client process and X server process through a network becomes much faster, the client process, which may run on a graphics server computer, makes graphics images and sends the image data to the server process without using the PEX protocol. -- Kenya SATO ( sato%rinfo.sumiden.co.jp@uunet.uu.net ) Computer & Information Systems R&D Department Information & Electronics Technology Laboratories SUMITOMO ELECTRIC INDUSTRIES, LTD.
buck@drax.gsfc.nasa.gov (Loren (Buck) Buchanan) (03/09/90)
In article <490eac1b.20b6d@apollo.HP.COM> jch@apollo.HP.COM (Jan Hardenbergh) writes: >PHIGS will be like FORTRAN. Lots of people will complain about it >but it will be the best option they have. PHIGS will change over >time to adapt to customer needs. A better analogy is PHIGS is like ADA, GKS is like FORTRAN (well classic FORTRAN). Not only will PHIGS (GKS, CGI, CGM, PEX, X, etc.) change over time but so will the hardware it runs on, the support software (operating systems and other tools), but so will the mindset of the programmers and users. >PHIGS will be the interface to PEX. Only those things that would normally >change from vendor to vendor will change for PEX. So, still only a pain. But this pain is small in comparison to starting from scratch for each new system management/purchasing buys for us. >I do agree that allowing some sort of object oriented interface to >PHIGS would be a good idea. PHIGS is, technically, only a year old >and already has quite a bit of support. It will change, sure. But >get replaced? I don't think so. I agree, it will be evolution, not revolution. What ever replaces PHIGS will have to be in the GKS-CGI-CGM-PHIGS family of standards. B Cing U Buck Loren "Buck" Buchanan | internet: buck@drax.gsfc.nasa.gov | standard disclaimer CSC, 1100 West St. | uucp: ...!ames!dftsrv!drax!buck | "By the horns of a Laurel, MD 20707 | phonenet: (301) 497-2531 or 9898 | sky demon..."
kyriazis@iear.arts.rpi.edu (George Kyriazis) (03/10/90)
In article <4914c3a0.20b6d@apollo.HP.COM> jch@apollo.HP.COM (Jan Hardenbergh) writes: >This is an excellent point. Special purpose graphics engines are not >appropriate for all graphics applications. Look at a DN10K sometime. >It has a very smart frame buffer for a graphics engine. All of the >geometry pipeline is done by the regular CPU, or CPUs. It can give you >78K polygons per second, but you have all of that power to run your >application when you are not doing graphics. (Err... that 78k is GMR3D) > I will certainly look into the architecture if the DN10K. >You seem to equate PHIGS with graphics engine. No reason to do that. > So, PHIGS runs on machines with graphics accelerators and machine without graphics accelerators. There is more to talk about when dealing with machines that have accelerators. For low cost machines, there is no real hardware problem; you just srtuggle to make the software run with the existing hardware. For more expensive machines though there is the challange of how to design the custom additional hardware. >You also seem to think PHIGS will be replaced while still acknowledging >it has the right tools. I think you will do better to get better access >to the tools that PHIGS has instead of starting the standards process over. > Ok. Perhaps replaced wasn't the right word. There are many things in PHIGS that are worthwile, and many people have spent a lot of time developing algorithms to speed it up (you, working at HP can probably be one of them). By replacing, I meant the same kind of procedure when PHIGS became a standard that kinda 'replaced' GKS. Ok, then. I think that the 'evolving' new standard should deviate a bit from the tree structure and allow DAG structures to be displayed. >-Jan Hardenbergh - jch@apollo.hp.com - HP / Graphics Technology Division ---------------------------------------------------------------------- George Kyriazis kyriazis@turing.cs.rpi.edu kyriazis@rdrc.rpi.edu kyriazis@iear.arts.rpi.edu
dboyes@rice.edu (David Boyes) (03/11/90)
In article <1573@wm120_no0.rinfo.sumiden.co.jp> sato@wm120_no0.rinfo.sumiden.co.jp ( Kenya SATO @ SEI ) writes: >>>Does anybody doubt that PEX will be popular after being released at >>>the beginning of 1991? >Anyway, I wanted to know if the concept of PEX, which means the PEX >protocol, would be popular. Given these days of faster network media and more efficient network interface hardware, I can speculate a bit. PEX as a specific implementation of PHIGS in a client/server model will probably have a limited lifespan; PHIGS+ and PHIGS++ are already in the pipe as enhancements to the PHIGS standard, and implementations are even available now from your favorite Three-Lettered Vendors. The concept of dividing the computational portion of a graphics application from the actual physical rendering of the image by composing the image in an formal abstract protocol is much more interesting. Given large host A with large computational resources and a network connection and desktop workstation B with smaller resources and nifty graphics hardware, it makes a great deal of sense to allow each machine to do what it does best and communicate via a formal protocol such as the one suggested in the PEX research. Something like this protocol may also go a long way toward some of the difficulties that arise when dealing with heterogeneous environments. IBM has done (in my opinion) a very nice implementation of PHIGS over X that really makes choosing one of their machines as a computational engine a palatable option, but much of their graphics display hardware is ill-suited to high-speed raster imaging (the RX/6000 may change this). The choice of X as a least common denominator transport for the image data makes it possible to use the Sparcstation in the next room or the RT down the hall with equal facility without having to deal with compiler problems or OS dependencies. In summary, I think PEX is not the final answer, but it's a good step towards an answer. >Kenya SATO ( sato%rinfo.sumiden.co.jp@uunet.uu.net ) -- David Boyes | "Where's the ka-boom? There's supposed to be an dboyes@rice.edu | Earth-shattering ka-boom!...Heavens! Someone has | stolen the Illudium Q-38 Explosive Space Modulator! "Delays, delays!" | The Earth creature has *stolen* the Space Modulator!"