Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!tut.cis.ohio-state.edu!ucbvax!hplabs!hp-pcd!hp-sdd!apollo!jch
From: jch@apollo.HP.COM (Jan Hardenbergh)
Newsgroups: comp.graphics
Subject: Re: Will PEX become popular? (In English)
Message-ID: <4914c3a0.20b6d@apollo.HP.COM>
Date: 9 Mar 90 01:43:00 GMT
Sender: root@apollo.HP.COM
Lines: 67

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