Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!swrinde!ucsd!ucsdhub!hp-sdd!apollo!jch
From: jch@apollo.HP.COM (Jan Hardenbergh)
Newsgroups: comp.graphics
Subject: Re: Will PEX become popular? (In English)
Message-ID: <490eac1b.20b6d@apollo.HP.COM>
Date: 7 Mar 90 20:38:00 GMT
Sender: root@apollo.HP.COM
Lines: 71

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