HDTenEightyP/NetNews huggingface dataset:
From: rthomson@mesa.dsd.es.com (Rich Thomson)
Subject: Re: 3D Scanner -> Phigs diagram
Reply-To: rthomson@dsd.es.com (Rich Thomson)
Organization: Design Systems Division, Evans & Sutherland, SLC, UT
Date: Tue, 18 Aug 92 20:31:42 GMT

>rthomson@mesa.dsd.es.com (Rich Thomson) writes:
>>I guess that depends on what you mean by "3D scanner".  CyberWare has
>>a 3D scanner that outputs (x,y,z) vertices with (r,g,b) values at each
>>vertex.

In article <marrou.714162297@eola.cs.ucf.edu>
	marrou@cs.ucf.edu (Lance R. Marrou) writes:
>Are you sure that the CyberWare scanner maintains the rgb values as well
>as the 3D data?

Yes, they were demonstrating this at SIGGRAPH in Chicago.  I got some
literature from them, but its on loan right now, so I can't quote the
specifics.

>Also, to add, I believe the maximum scan lines
>obtainable is 512x512 (horizontal x vertical, wrapped).

I wasn't aware of such a limitation.  I'm not sure what you mean by
"scan lines", since the output of the scanner depends on how it moves
in 3-space.  Their literature describes two motion paths: linearly along
a motion table, or circularly around a model platform; the latter was
what they showed at SIGGRAPH.  I'm sure there is some range of
scanning resolution supported by the device, but how that corresponds
to physical space on your 3D source depends on geometry, etc.

>This is the only 3D "scanner" that I know about, are there any others?

Most of the other scanner technology that I've seen consists of 3D
point digitizers, usually based on ultrasound technology.  Some of
these vendors are "little guys" in the computer industry; one of them
at SIGGRAPH had never heard of SCSI!

						-- RIch
-- 
	Repeal the personal income tax; vote Libertarian in 1992.
Disclaimer: I speak for myself, except as noted; Copyright 1992 Rich Thomson
UUCP: ...!uunet!dsd.es.com!rthomson			Rich Thomson
Internet: rthomson@dsd.es.com	IRC: _Rich_		PEXt Programmer
Newsgroups: comp.windows.x.pex
From: rthomson@mesa.dsd.es.com (Rich Thomson)
Subject: Re: Future development of PEX/PHIGS
Reply-To: rthomson@dsd.es.com (Rich Thomson)
Organization: Design Systems Division, Evans & Sutherland, SLC, UT
Date: Sun, 16 Aug 92 17:21:24 GMT

In article <5759@m1.cs.man.ac.uk>
	lilleyc@cs.man.ac.uk (Chris Lilley) writes:
[on anti-aliasing]
>The Evans&Sutherland implementation has had antialiasing for a while.
>The DEC implementation supports it only on harware that supports it.
>Both do it as escapes. There is no support for antialiasing in the ISO
>standard.

There is no explicit support, but that doesn't mean that the
renderings are guaranteed to be aliased, either.  A PHIGS
implementation could render all of its primitives anti-aliased and it
wouldn't be in violation of the standard.  What is missing are
controls for changing the amount of anti-aliasing performed.  We
provide full anti-aliasing on all line-based primitives (polymarkers,
polylines, stroke text) by default.  You can turn this off if it is
desired via a GSE that we provide.  Escapes are a different mechanism
used to modify global behavior of a workstation; using a GSE allows
hierarchical control of the "aliasing" attribute in a structure.
Some line-based primitives in a structure may be aliased while others
are anti-aliased, depending on where the GSE is placed in the
structure (or issued in immediate-mode).

Full support for anti-aliasing could be quickly introduced into PHIGS
if all the vendors agreed on a particular format for a GSE data record
and registered this record with ISO.  Registration is a fairly quick
process and doesn't need any voting to take place in order to be
accepted.  Portability can be maintained if the vendors work
cooperatively to support and register such a GSE.  If you, as an
application programmer or user, desire such support from your vendor,
please ask them to support such a cooperative registration.

PHIGS can be extended in many ways via registration without having to
go to the standards committee and get a full-vote for approval.  In
this way, vendors can improve and extend upon the basic
PHIGS/PHIGS-PLUS definition.  The temptation is for each vendor to "go
their own way" and provide features only in their implementation not
available in other implementations so that they can define themselves
as having a competitive edge.  This, of course, leads to portability
problems.  The best way to alleviate those portability concerns is for
vendors to register their extensions (thus allowing other vendors to
simulate/emulate them if possible) and for users to impress upon
vendors how much they care about portability.  Companies generally
listen to their customers (and if they don't, they deserve what they
get I suppose).

						-- Rich
-- 
	Repeal the personal income tax; vote Libertarian in 1992.
Disclaimer: I speak for myself, except as noted; Copyright 1992 Rich Thomson
UUCP: ...!uunet!dsd.es.com!rthomson			Rich Thomson
Internet: rthomson@dsd.es.com	IRC: _Rich_		PEXt Programmer
From: akin@sgi.com (Allen Akin)
Newsgroups: comp.windows.x.pex
Subject: Re: Future development of PEX/PHIGS
Date: 21 Aug 92 17:03:29 GMT
Organization: Silicon Graphics, Inc.

In article <1992Aug20.155104.15645@dsd.es.com> smitty@dsd.es.com writes:
| 
| OK, lets say I buy all this.  What happens when someone implements this
| (OpenGL) on something other than a high-end SGI graphics pipe?
| 
| IMHO, unless this non-SGI pipe has all of the features of the SGI pipe,
| then you immediately get into data reformating, feature subseting, software
| emulation of features, all the stuff that is supposedly "not a problem" in
| OpenGL.

I'd argue that:

   1)   The data reformatting issues I've been discussing are different
	from the data type conversion that Rich mentioned, and that Kurt
	addressed in his message.  See my recent posting in response to
	Chris Lilley's questions for an example.

   2)   I've seen other manufacturers' machines with
	data-type-conversion capability at the head of the pipeline.
	As Rich pointed out, many pipelines require some kind of
	conversion from an external data type to the internal data type
	used by the pipe. In short, this is not a feature exclusive to
	SGI machines, nor is it restricted to the high end.

   3)   Feature subsetting is completely independent of data
	reformatting or type conversion.

   4)   Software emulation is usually independent of data reformatting
	and type conversion.  The connection is rare, and involves some
	design extremes (e.g. complete absence of floating-point
	support, or insufficient memory to reformat a complete
	primitive).  I don't think this is an issue in practice.

There's a widespread belief that OpenGL can't be implemented
efficiently on machines other than SGI's.  Having spent some time
working on graphics architectures other than SGI's, I don't believe
this is true.  SGI has no monopoly on computer graphics design talent,
and there are a lot of people out there who understand all the
fundamental issues.  I think other manufacturers will be able to
implement OpenGL quite successfully when they choose to do so.

Allen
From: bruce@neuro-dev.neuro (Bruce Kall)
Subject: Transparency in SunPhigs?
Reply-To: bruce@neuro-dev.neuro
Organization: Sun Microsystems
Date: Wed, 12 Aug 92 13:14:55 GMT

Is there anyway of providing transparency in SunPhigs2.0?

---



\------------------------------------------------------------\
 \   Bruce Kall                \  Internet:   Kall@Mayo.edu   \
  \   Mayo Clinic (Foundation)  \  Phone: (507)-255-4768       \
   \   Rochester, MN 55905       \                              \
    \------------------------------------------------------------\
From: luj@ecn.purdue.edu (John Lu)
Newsgroups: comp.windows.x.pex
Subject: Re: Future development of PEX/PHIGS
Date: 13 Aug 92 22:15:34 GMT
Reply-To: luj@ecn.purdue.edu
Organization: Purdue University Engineering Computing Network

In article <1992Aug13.170434.18221@hsr.no>, jarl@hsr.no (Jarl Haugland) writes:

|> Interesting questions are:
|>   * When (if ever) will the official PHIGS version have support for
|>     immediate mode?
|>   * Will PEX/PHIGS support additional advanced graphical techniques like:
|>     - double buffering
|>     - texture mapping
|>     - antialiasing
|>     - etc....
|>     My understanding is that OpenGL will support many of these when it's
|>     available, so PEX/PHIGS will have to speed up to be into the race...
|> 
I guess that PHIGS/PHIGS PLUS can never speed up to support 
what you're demanding. By the time it did, another much better API would
have probably widely accepted.  Maybe PEX can catch up in supporting those
functionalities.  

I seem to have been convinced by Alan Akin that OpenGL superior to PEX in that
there is little need in reformatting the application's data structure for graphics.
Correct me(or him :-)) if I am wrong.

|> Finally, a different question. Is PEXIM publicly available (ftp'able)?
|> And if it is, then where?
|> 


PEXIM is available as contrib software in X11R5.

|> -- 
|> =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=
|> / Jarl Haugland                  | E-mail: jarl@hsr.no   | The cost of living \
|> / Rogaland University Center     | Tlf:    +47-4-874432  | hasn't affected    \
|> / Stavanger, NORWAY              | Fax:    +47-4-874300  | its popularity.    \
|> =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=

-- 
-- John Lu 
   luj@ecn.purdue.edu
Newsgroups: comp.windows.x.pex
From: pmartz@dsd.es.com (Paul Martz)
Subject: Re: Future development of PEX/PHIGS
Reply-To: pmartz@dsd.es.com (Paul Martz)
Organization: Evans & Sutherland Computer Corp., Salt Lake City, UT
Date: Mon, 17 Aug 92 19:50:25 GMT

In article <1992Aug13.170434.18221@hsr.no>, jarl@hsr.no (Jarl Haugland) writes:
>   * When (if ever) will the official PHIGS version have support for
>     immediate mode?

This question might be better answered in comp.graphics...
-- 

   -paul	pmartz@dsd.es.com
		Evans & Sutherland
Newsgroups: comp.windows.x.pex
From: lilleyc@cs.man.ac.uk (Chris Lilley)
Newsgroups: comp.windows.x.pex
Subject: Re: Future development of PEX/PHIGS
Date: 14 Aug 92 13:00:26 GMT
Reply-To: lilleyc@cs.man.ac.uk (Chris Lilley)
Organization: Department of Computer Science, University of Manchester UK

In article <1992Aug13.170434.18221@hsr.no> jarl@hsr.no (Jarl Haugland) writes:

>I have a couple of questions concerning what to expect from PEX and PHIGS
>in the future (whitch in this case is within a year or two). I know that some
>info is available in the PEX 6.0 specification papers, but I would appreciate
>getting some more, bouth facts and rumours.

I have no warranted crystal ball (but if you know the ftp site ... ;-)

>Interesting questions are:
>  * When (if ever) will the official PHIGS version have support for
>    immediate mode?

It is my understanding that ANSI is once more interested in this
topic. They are expected to put it to ISO in a position paper or
sugested addendum.

>  * Will PEX/PHIGS support additional advanced graphical techniques like:
>    - double buffering

Yes, it has supported double buffering for a number of years

>    - texture mapping
>    - antialiasing
>    - etc....

dunno
Applying a cell array to uv parameter space for NURBS might be one option...

The Evans&Sutherland implementation has had antialiasing for a while.
The DEC implementation supports it only on harware that supports it.
Both do it as escapes. There is no support for antialiasing in the ISO
standard.


>    My understanding is that OpenGL will support many of these when it's
>    available, so PEX/PHIGS will have to speed up to be into the race...

I will comment on OpenGL once an implementation has actually been
released. In the mean time, I will continue using PHIGS and PEX, as I
cannot program with promises.

>Finally, a different question. Is PEXIM publicly available (ftp'able)?
>And if it is, then where?

Yes I believe so. Try archie

--
Chris Lilley
---------------------------------------------------------------------------
Technical Author, ITTI Computer Graphics and Visualisation Training Project
Computer Graphics Unit, Manchester Computing Centre, Manchester, UK
Internet:   lilley@cgu.mcc.ac.uk        Janet:   lilley@uk.ac.mcc.cgu
Voice:      +44 (0)61 275 6095          Fax:     +44 (0)61 275 6040
---------------------------------------------------------------------------
From: luj@ecn.purdue.edu (John Lu)
Newsgroups: comp.windows.x.pex
Subject: Re: Future development of PEX/PHIGS
Date: 19 Aug 92 18:15:47 GMT
Reply-To: luj@ecn.purdue.edu
Organization: Purdue University Engineering Computing Network

In article <1992Aug18.182730.3478@dsd.es.com>, rthomson@mesa.dsd.es.com (Rich Thomson) writes:
|> 
|> In article <1992Aug14.210903.23864@noose.ecn.purdue.edu>
|> 	John Lu <luj@ecn.purdue.edu> writes:
|> >The biggest plus of the PHIGS(+) seems to be the fact that it is
|> >an international standard. [...] When will PHIGS/PHIGS PLUS incorporate
|> >those requirements [anti-aliasing, texture-mapping] so that one can be
|> >_guranteed_ to have portablity and uniformity ?  
|> 
|> Oh, I guess I mis-parsed your previous statement.  When you said
|> "PHIGS/PHIGS-PLUS can never speed up", were you referring to the speed
|> of an implementation (what I thought), or the speed of the standards
|> process?  

Well, if you had read the original article by jarl@hsr.no (Jarl Haugland) more
carefully, such misunderstanding would have not existed.
jarl@hsr.no (Jarl Haugland) was clearly demanding the advanced features 
from the PHIGS(+).

|> [ deteled ...]
|> >	2). It is quite evident that the PHIGS API has _much_ room to desire.
|> 
|> Quite evident to you perhaps.  Others may disagree.  Its important to
|> make the distinction between fact and opinion.  The above is clearly
|> your opinion.
|> 
But my opinions stem from the facts or experience :-).  Just introduce 
the PHIGS API to another "random" person who is familiar w/ other graphics APIs, 
see what're his "opinions".


|> 
|> Under OpenGL, the same reformatting happens; you merely get what
|> language designers call "syntactic sugar" so that you can provide the
|> data in any datatype you wish.  
|> [ .... ]
|> >In PHIGS and PEXlib, data reformating is almost essential, it is ubiquitous.
|> 
|> PEXlib is not intended to be an API, but an SPI.  If you want the
|> same syntactic sugar that is provided in OpenGL, you can write a
|> toolkit on top of PEXlib that does this reformatting for you.
|> 
Wrong. These points have been talked quite in detail by Allen Akin.
You can provid _syntax sugar_ for PHIGS API or PEXlib, but this is is 
an _extra_ layer of reformatting the application data. It is this 
appendage layer that I, as a user, want to avoid if possible.

|> >I do have some boxes running PEX-SI
|> 
|> If possible, I recommend you get a PEX server from your workstation
|> vendor instead of the PEX-SI.  

I am waiting for the PEX servers to arrive.

-- John Lu
   luj@ecn.purdue.edu
Xref: sparky comp.windows.x.pex:461 comp.windows.x:15284
From: devil@diablery.10A.com (Gil Tene)
Newsgroups: comp.windows.x.pex,comp.windows.x
Subject: Available PEX toolkits?
Date: 15 Aug 92 21:32:50 GMT
Followup-To: comp.windows.x.pex
Organization: Diablery, cloud seven, Hell. (also 10A Inc.)

Hello PEXland,

I am looking for information on available PEX toolkits/libraries.
I realize these may be novice questions, but information on this
subject seems hard to find. 

- Is there a PHIGS/PHIGS+ compatible library that interfaces to PEX 
  (One that lets you simply link with working PHIGS code).

- Any other toolkits?

- Are there any standards trends out there?

- What is the "safest, most standard" toolkit to use on a long-lasting
  project? 

- What is the difference between a PEX library and a PEX toolkit?
  (e.g. PEXlib vs. PEXtk)

- Where is the best place to get up-to-date informations and
  documentation on PEX related subjects?

Responses will be summerized and posted to the net.

AdvThanks,

-- Gil.

-- 
--------------------------------------------------------------------
-- Gil Tene			"Some days it just doesn't pay     -
-- devil@imp.HellNet.org	   to go to sleep in the morning." -
-- devil@diablery.10A.com 					   -
--------------------------------------------------------------------
Newsgroups: comp.windows.x.pex
From: akin@sgi.com (Allen Akin)
Subject: Re: Future development of PEX/PHIGS
Organization: Silicon Graphics, Inc.
Date: Wed, 19 Aug 1992 17:16:39 GMT

In article <1992Aug19.155052.21659@dsd.es.com> cannon@ziggy.es.com (Gary Cannon) writes:
| 
| Since I haven't seen the spec it is hard to know from this description
| exactly how this all works but from your description it sounds a lot like 
| the PHIGS SOFA's that are supported in PEX or the PHIGS Triangle Set that is 
| likely to be supported in PEX 6.0. Could you explain the difference?

You might want to check out the OpenGL manual pages.  They're available
as compressed Shell archives of PostScript files, by anonymous ftp from
sgi.com, in the files sgi/OpenGL/{gl,glu,glx}.shar.Z .

I used the tetrahedral mesh as an example because it's common in FEA
applications and isn't supported as a primitive by either PEX or
OpenGL.  (One reason it isn't supported directly is that it doesn't
define a "surface" in a way that's conventional for most graphics
packages.)

But the argument isn't specific to tetrahedral meshes.  As long as an
application's problem domain calls for some data structure that doesn't
correspond *precisely* to one in the PHIGS or PEX-based API, then some
reformatting or data duplication is necessary.  You could choose to
reformat tetrahedral meshes into SOFAS, Triangle Sets, Fill Areas,
Triangle Strips, or perhaps other primitives, but you would always be
paying a reformatting cost.

In contrast, the OpenGL API works with arbitrary application data
structures.  Since the relevant graphics data can always be extracted
without having to interpret the remainder of the data structure, no
reformatting or duplication is needed.  This also makes life easier for
the application developer, since he has greater freedom to tailor his
algorithms and data structures to match his problem domain, rather than
the graphics API.

Allen
Newsgroups: comp.windows.x.pex
From: stiehl@kpc.com (Gregory Stiehl)
Newsgroups: comp.windows.x.pex
Subject: Re: Future development of PEX/PHIGS
Date: 14 Aug 92 01:37:57 GMT
Reply-To: stiehl@kpc.com
Organization: Kubota Pacific Computer, Graphics Software

luj@ecn.purdue.edu (John Lu) writes:
> I seem to have been convinced by Alan Akin that OpenGL superior to PEX in that
> there is little need in reformatting the application's data structure for graphics.
> Correct me(or him :-)) if I am wrong.

I don't want to get into the dirty business of debating the plus and minuses
of PEX vs OpenGL, they both have plenty of both.  Personally (and now
professionally :-), I am very interested in seeing OpenGL.  I'm can't wait
to see how many hardware companies will be able to reach the potential of
their graphics accelerators using OpenGL.  And to see if the less open
than PEX's design process can keep all the players happy...  (History
has some pretty good examples on that...)

On the other hand, I have seen PEX running on 10 different hardware
platforms.  In fact, I first saw it a year ago at SIGGRAPH.  And a majority
of those companies had real, honest-to-goodness products (PEX servers)
at SIGGRAPH last month.  And these servers are realizing the full potential
of their hardware (even in cases of software renderers!).

I don't know why, but the saying "A bird in the hand is worth two in
the bush" comes to mind.

-greg.
From: lilleyc@cs.man.ac.uk (Chris Lilley)
Newsgroups: comp.windows.x.pex
Subject: Re: PEXtk 1.0 Test Programs
Date: 21 Aug 92 14:03:43 GMT
Organization: Dept Computer Science, University of Manchester, U.K.

In article <1992Aug20.132131.9585@uoft02.utoledo.edu> evaleros@jupiter.cse.utoledo.edu (Elsa S. Valeroso) writes:

>	I have just compiled PEXtk Version 1.0 based on DEC Contrib PEXlib 5.0
>	on one of our Sun SPARC station IPCs. I ftp'd the source code and the 
>	library from export.lcs. 

>	My question is: "When I execute any of the test programs, shouldn't the
>	workstation be clear of any previous images drawn by a previous test 
>	program? 
>	[...]
>	current one. It seems that the problem lies in the double-buffering. 
>	Test programs which do not use double buffering seem to be working 
>	fine.

Depends on the PEX server you are using. I believe that SunPHIGS2.0
only supports double buffering on graphics accelerators that have it
in hardware. ie, not IPCs, you need a SPARC2 with GS or GT
accelerator.

The SunPEX server extension is based on the PEX SI although with
optimisations for their various accelerators. I guess (we have yet to
get our hands on the Sun PEX server) that they will use the same logic
as with Sun PHIGS - support double buffering only on their better
graphics accelerators.

If you are using the PEX consortium SI, well that does not support
double buffering or HLHSR *at all*. It is a code sample; designed to
be read as much as run.

So your diagnosis seems completely correct - programs that use double
buffering will fail. You have not done anything wrong, this is the
expected behaviour.

--
Chris Lilley
---------------------------------------------------------------------------
Technical Author, ITTI Computer Graphics and Visualisation Training Project
Computer Graphics Unit, Manchester Computing Centre, Manchester, UK
Internet:   lilley@cgu.mcc.ac.uk        Janet:   lilley@uk.ac.mcc.cgu
Voice:      +44 (0)61 275 6095          Fax:     +44 (0)61 275 6040
---------------------------------------------------------------------------
Newsgroups: comp.windows.x.pex
From: hersh@expo.lcs.mit.edu (Jay Hersh)
Subject: Re: Future development of PEX/PHIGS
Organization: X Consortium, MIT Laboratory for Computer Science
Date: Mon, 17 Aug 1992 18:22:03 GMT

jarl@hsr.no (Jarl Haugland) writes:

>I have a couple of questions concerning what to expect from PEX and PHIGS
>in the future (whitch in this case is within a year or two). I know that some
>info is available in the PEX 6.0 specification papers, but I would appreciate
>getting some more, bouth facts and rumours.

>Interesting questions are:
>  * When (if ever) will the official PHIGS version have support for
>    immediate mode?

If/when the ISO group which deines PHIGS decides to add it.

>  * Will PEX/PHIGS support additional advanced graphical techniques like:
>    - double buffering
>    - texture mapping
>    - antialiasing
>    - etc....
>    My understanding is that OpenGL will support many of these when it's
>    available, so PEX/PHIGS will have to speed up to be into the race...

PEX already has hooks to support double buffering in the workstation
and there is a Mutli buffer extension to X which can be used to do it
from the client side.

PEX 6.0 plans to support texture mapping, and I believe anti-aliasing, but
I'd have to double check discussion notes.


>Finally, a different question. Is PEXIM publicly available (ftp'able)?
>And if it is, then where?

I believe it's available from export.lcs.mit.edu

>-- 
>=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=
>/ Jarl Haugland                  | E-mail: jarl@hsr.no   | The cost of living \
>/ Rogaland University Center     | Tlf:    +47-4-874432  | hasn't affected    \
>/ Stavanger, NORWAY              | Fax:    +47-4-874300  | its popularity.    \
>=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=
--
Hopfen und Malz, Gott erhalts
There is nothing open about OpenGL
Newsgroups: comp.windows.x.pex