HDTenEightyP/NetNews huggingface dataset:
From: bglazier@buffalo.asd.sgi.com (Bill Glazier)
Subject: Re: (FAQ?) Where to get opengl spec/conformance test
Organization: Silicon Graphics, Inc.
Date: Fri, 16 Oct 1992 22:09:17 GMT

In article <1bn18dINNs74@agate.berkeley.edu>, faustus@ygdrasil.CS.Berkeley.EDU (Wayne A. Christopher) writes:
|> In article <1bmv15INN9il@fido.asd.sgi.com> akin@sgi.com (Allen Akin) writes:
|> > The specification is intended for OpenGL implementors.  Currently it
|> > must be licensed from SGI.
|> 
|> Does this mean that if I want to implement a library that conforms to
|> the OpenGL specification, I have to pay SGI a license fee?  This
|> sounds a lot like Apple's attempts to enforce "look and feel"
|> restrictions.  What if I want to spend a few years of my life writing
|> a public-domain OpenGL implementation that is not based on the SGI
|> implementation, but conforms exactly to the interface and
|> functionality specification?  Will SGI sue me?

A standard is only of value to the extent it is implemented consistently
across all platforms.  Licensing mechanisms allow for the degree of control
necesssary to enforce/assure consistency.  That is the main reason SGI has
chosen to license OpenGL, rather than 'give it away' and let the world do with
it as they wish.  

We also are incurring significant development costs in preparing the spec and the sample implementation, so we do charge a nominal amount to help defray
these expenses.  We charge an incremental $75K for the SI, which is over
100K lines of code.  That's 75 cents per line of code - a pretty good deal.  

We have a Level 1 license so people who want to create a 'home grown'
OpenGL implementation, not based on the SI, can do so.  It's $25K. We provide source code for the OpenGL Conformance Test - which a licensee must pass to 
prove they have implemented to the spec.  And we also supply a 
bunch of other source (C and Fortran bindings, OpenGL Utility Code source, the 
Client side library, the GL/X protocol extension, and associated documentation).
Much of this is not optimizable, so there is no sense in separate companies
reinventing the wheel.  For universities, we charge $500.  

If there were no OpenGL Conformance Test, hackers around the world
would create competing incompatible versions, all for what seem to be
legitimate reasons.  The software community and the 3D industry would suffer,
as confusion over which version to use, or which subset to use became common
place.  

SGI and the OpenGL ARB are very interested in ensuring the integrity
of the technology and its associated trademarks.  Apple's enforcement
of it's look and feel guidelines helped make the Mac an easy to use
computer.  We hope the licensing process and the OpenGL conformance test
will make the OpenGL an easy to use 3D and successful API.

So my answer to your question can be summarized thusly;

1) OpenGL is not public domain because it would degrade its usefulness
2) SGI is spending a lot of money to help people implement OpenGL
and to administer a conformance process, and wants to recoup some portion
of this investment.
 

thanks,


bill
From: hjb@otter.hpl.hp.com (Harry Barman)
Newsgroups: comp.graphics.opengl
Subject: Re: OpenGL Printers?
Date: 16 Oct 92 15:32:50 GMT
Organization: Hewlett-Packard Laboratories, Bristol, UK.

If it doesn't seem possible to implement OpenGL on a printer for sensible cost,
then how about providing a lower level set of primitives that are implementable
with sensible hardware/memory configurations, and provide something better
than bitmaps?

If anyone has any suggestions I'd be interested to see them posted.  What
would be *your* favourite set of low level 3D primitives?

Cheers,

Harry
Newsgroups: comp.graphics.opengl
From: mcsavaney_d@apollo.hp.com (#David McSavaney)
Subject: Re: HP and OpenGL
Date: Tue, 13 Oct 1992 19:25:48 GMT
Organization: Hewlett-Packard Corporation, Chelmsford, MA

In article <1992Oct7.232543.16695@odin.corp.sgi.com> bglazier@buffalo.asd.sgi.com (Bill Glazier) writes:
>In article <Bvpxw8.K4x@apollo.hp.com>, mcsavaney_d@apollo.hp.com (#David McSavaney) writes:
>|> I _am_ able to talk to people about PEXlib and OpenGL and why
>|> HP supports PEX. Just give me a call.
>
>Seems they want to make darn sure that
>the current GL and OpenGL run *very well* on HP workstations.  

Bill, I am pleased to say that the GL 4.0 port from Nth Graphics does 
indeed run *very well* on HP kit.

>
>If they are 100% committed to PHIGS and PEX and PEXlib (notice how
>their previously 'strategic' Starbase API has seemingly disappeared
>from their marketing literature), why would they do this? 8*>

HP's position is clear to all who work here - we take open standards and 
make them perform very fast. We think it is in the best interest of our 
customers that we do that. Sometimes open systems development lags
what has previously been available, in which case a proprietary approach
may be the best solution in that timeframe.

> 
>HP's public position on OpenGL is clear.  Their private position is also
>clear (they want to support both API's well on HP systems).  Gosh, if I 
>weren't so biased, I'd think they were just plain playin' politics.  I wonder if Dave,
>or anybody else from HP is willing to publicly state why they are 
>NOT publicly supporting OpenGL.  I think a public forum like this is an excellent place.

Interesting and provocative. I hope I did not mention anywhere HP's _private_
position (I'd like to know what that is!) Bill, I'm sure you will agree that direct
communication would be the most effective means to continue this discussion.
HP's strategic graphics direction and the one that we will supply and support 
is the PEX, PEXlib and PHIGS triumverate.

PEX is the only way to provide truly portable, network distributable 3D 
applications based on industry standards - OpenGL does not. That Bill, is
why HP supports PEX. 
                                            
Bill, I'd very much like to have an up to date copy of the OpenGL license
agreement and any associated terms and condtions. Can you fax a copy
to me please? (508) 436 5116. Thanks.

>
>BTW, it's good to know HP folks subscribe to this newsgroup.  I was surprised
>none of them voted on the establishment of the newsgroup. Also, I hope Jerry
>Norman and his team at Nth become wildly succesful (and wealthy) selling 
>OpenGL on HP (and other) workstations!  HP apparently hopes the same thing!       
>

I'm sure Jerry will become very successful, Nth Graphics has 
a very useful GL 4.0 product.                                

>Bill Glazier
>SGI
>
Dave McSavaney
Workstation Product Marketing
Hewlett-Packard Company
                       
Not an official statement of Hewlett-Packard Company



Newsgroups: comp.graphics.opengl
From: akin@sgi.com (Allen Akin)
Newsgroups: comp.graphics.opengl,comp.sys.sgi
Subject: Re: University source license to OpenGL
Date: 7 Oct 92 16:30:59 GMT
Article-I.D.: fido.1av3c3INN9p5
Organization: Silicon Graphics, Inc.
NNTP-Posting-Host: tuolumne.asd.sgi.com


Apologies; for some reason this reply wasn't posted correctly.


In article <mark.718412958@bruce.cs.monash.edu.au> mark@cs.monash.edu.au (Mark Goodwin) writes:
| 
| Could someone from SGI please clarify SGI's policy with regard
| to University licenses for OpenGL ?
| 
| 
| In particular, we'd like to know:
| 
|   *  are the licenses available outside USA

Don't know, I'll check.

|   *  terms of the license (non-disclosure of source, etc)

It's my understanding that you're allowed to use OpenGL for
noncommercial purposes on as many systems as you choose, but not to
redistribute the source.

I'll ask Bill Glazier to post a more informative (and official) reply.

|   *  how much $$ and what do you actually get

US$500.  The package includes:

	OpenGL Specification.
		This specifies the API and all semantics for the
		core of OpenGL.
	GLX Specification.
		GLX is the set of routines used to integrate OpenGL
		and the X Window System.
	OpenGL Utilities (GLU) Specification.  
		The GLU includes matrix utility routines, polygon
		tessellation, quadrics, and NURBS curves and surfaces.
	OpenGL API Source Code (C Bindings).
	GL/X Source Code.
	GLU Source Code.
	Manual Pages.
		In troff source form.  If you'd like to preview these,
		they're available by anonymous ftp from sgi.com, in
		the directory sgi/OpenGL, in the files
		{gl,glu,glx}.shar.Z.  These are compressed Shell
		archives of PostScript for the manual pages.
	Conformance Test Suite Source Code.
		The conformance tests can be used to determine if
		an implementation of OpenGL supports the semantics
		required by the specification.
	FORTRAN and Ada Bindings for OpenGL, GLX, and GLU.
	Demonstration Programs.
	OpenGL Reference Implementation Source Code.
		This is a rewriting of the Specification in ANSI C
		to help explain the more difficult semantics.  Executable,
		but quite slow.
	OpenGL Sample Implementation Source Code.
		This is an ANSI C implementation intended for use as
		a porting base.  It runs inside the X11 Sample Server,
		using DDX routines for output.  It's designed to be
		optimized for a wide range of graphics adapters.
	OpenGL Porting and Optimization Guide.
		Notes on how to use the Sample Implementation.

|   *  who to contact to get one

I'll forward your question to Bill, but for reference here's his address
and phone number:

	Bill Glazier
	Silicon Graphics, Inc.
	2011 N. Shoreline Blvd.
	Mountain View, CA  94039-7311

	415-390-1617

Allen
Newsgroups: comp.graphics.opengl
From: hari@robios.me.wisc.edu (Kambainathan Hari)
Subject: Info wanted about Open_GL on DEC.
Organization: U. Wisconsin-Madison, Robotics Laboratory
Distribution: comp
Date: 7 Oct 92 09:59:51


Hi,

I have done programming on an IRIS using GL. Now I have to do a
graphics oriented project on a DEC 5000. Some of the questions I'd
like to know are:


* Is Open_GL available on the DEC ?

* If so, what are the minimal Hardware capabilities required to run
  Open_GL on a DEC 5000. 

* Whom should I contact and how much is it likely to cost ?

Thanks in advanance ....

- Hari

K.R.Harinarayan
Robotics Lab., Dept. of Mech. Engg.
Univ. of Wisconsin, Madison

Fone  : (608) 262-7463, (608) 262 - 9056
e-mail: hari@robios.me.wisc.edu
From: bglazier@buffalo.asd.sgi.com (Bill Glazier)
Newsgroups: comp.graphics.opengl
Subject: HP and OpenGL
Date: 7 Oct 92 23:25:43 GMT
Organization: Silicon Graphics, Inc.

In article <Bvpxw8.K4x@apollo.hp.com>, mcsavaney_d@apollo.hp.com (#David McSavaney) writes:
|> 
|> 
|> Wait a minute, wait a minute!
|> 
|> (What follows is a prejudiced view of OpenGL written by an HP marketeer who
|> supports HP's firm endorsement of PEX, PEXlib and PHIGS as the open,
|> standard graphics 3D development system to choose for the 1990's. Please
|> excuse the interruption and I promise not to do it again. Flames directly
|> to me please).
|> 
|> I _am_ able to talk to people about PEXlib and OpenGL and why
|> HP supports PEX. Just give me a call.


Gee, it seems that HP's public statements differ somewhat from reality.  Just
ask any of the numerous HP engineers that regularly hop on a plane to
Austin, Texas to visit Nth Graphics.  Nth Graphics is doing a 
third party software product allowing GL4 and OpenGL applications to run
on HP workstations.  Seems they want to make darn sure that
the current GL and OpenGL run *very well* on HP workstations.  I bet the amount
of money they are spending to travel to Texas, support Nth,
lend workstations to Nth, and show them off at tradeshows (like SIGGRAPH '92)
exceeds the 100K they would have to pay to license OpenGL directly.    

If they are 100% committed to PHIGS and PEX and PEXlib (notice how
their previously 'strategic' Starbase API has seemingly disappeared
from their marketing literature), why would they do this? 8*>

SGI (and others) have tried on numerous occasions to approach HP to ask them to
consider endorsing OpenGL.  It's been made clear they would undoubtedly
be offered a spot on the ARB (the governing body of the OpenGL), and
have as much say in the evolution of the technology as SGI or any other member
of the Board. HP has consistently refused to discuss the issue.  Nobody's asked
HP to drop its support for PHIGS, or PEX, or for any possible competing API.
We just asked for their assistance in defining an open standard not linked at the hips to PHIGS and X.  
 
HP's public position on OpenGL is clear.  Their private position is also
clear (they want to support both API's well on HP systems).  Gosh, if I weren't so biased, I'd think they were just plain playin' politics.  I wonder if Dave,
or anybody else from HP is willing to publicly state why they are NOT publicly supporting OpenGL.  I think a public forum like this is an excellent place.

BTW, it's good to know HP folks subscribe to this newsgroup.  I was surprised
none of them voted on the establishment of the newsgroup. Also, I hope Jerry
Norman and his team at Nth become wildly succesful (and wealthy) selling 
OpenGL on HP (and other) workstations!  HP apparently hopes the same thing!       




Bill Glazier
Technology Licensing
SGI

(Obviously those of you who know me won't consider me completely unbiased.
That's OK - if I ask the right questions and encourage the critical
dialogue, the net will decipher reality from fiction for themselves.)
From: segal@spud.asd.sgi.com (Mark Segal)
Newsgroups: comp.graphics.opengl
Subject: Re: OpenGL vs IRIS GL matrix conventions
Date: 9 Oct 92 17:14:32 GMT
Organization: Silicon Graphics, Inc.
NNTP-Posting-Host: spud.asd.sgi.com

In article <1992Oct9.143448.25308@daffy.cs.wisc.edu>, brianp@ssec.wisc.edu (Brian Paul) writes:
|> 
|>                                                                                 
|> While reading the man pages for the modeling transformation functions,
|> I discovered OpenGL uses post-multiplication whereas the IRIS GL uses
|> pre-multiplication.  Also, modeling and viewing matrices in OpenGL are
|> the transposes of the corresponding IRIS GL matrices.  Why the change of
|> convention?
|> 
|> I thought that pre-multiplication in the IRIS GL was used because the
|> hardware used pre-multiply.  Has post-multiply been favored because it's
|> a better convention?  What about any performance penalty?
|> 
|> Just curious.
|> 
|> Brian

Actually, whether hardware uses 'pre-multiply' or 'post-multiply' is
not (in this case) a matter of implementation but only a matter of
convention.  Convention in modern treatments of matrix theory (say in
the last 15-20 years) always write a vector as a column; a matrix is
applied to a vector on the left thusly:
        ( x')              ( x )
        ( y') = u = Mv = M ( y ).
        ( z')              ( z )
The only exception in using this notation has been computer graphics,
where for some reason a vector is often written as a row and a matrix
is applied to a vector on the right.

When I wrote the OpenGL specification, I decided to do my part to bring
computer graphics into line with the rest of mathematics, so I adopted
the 'vector as column' notation (some recent computer graphics texts have
taken the same approach).  But this does not affect any actual calculations.
The reason is that the 'vector as column' notation may be converted into
the 'vector as row' notation just by taking transposes:

                      T        T    T T          T
        (x' y' z') = u  =  (Mv)  = v M = (x y z)M .

This formula should indicate why 'modeling and viewing matrices in OpenGL
are transposes of the corresponding IRIS GL matrices'.  Nothing has
actually changed; it's just that we switched to a 'vector as column'
notation from the 'vector as row' notation.  When we did this, we had to
transpose all the old matrices when we wrote our new formulas.  But the
new formulas are exactly equivalent to the old ones (under transposition),
so nothing in any implementation has changed. The matrices are the same,
the hardware to do matrix multiplication is the same, everything is the
same except the convention used to write vectors.

I hope that this explanation is clear.  If I haven't answered your
questions satisfactorily, please let me know.

	Mark
From: kipp@warp.asd.sgi.com (Kipp Hickman)
Newsgroups: comp.graphics.opengl
Subject: Re: HP and OpenGL
Date: 13 Oct 92 21:17:41 GMT
Organization: Silicon Graphics, Inc.  Mountain View, CA
NNTP-Posting-Host: warp.asd.sgi.com


In article <Bw2rB0.4Cz@apollo.hp.com>, mcsavaney_d@apollo.hp.com writes:
> PEX is the only way to provide truly portable, network distributable 3D 
> applications based on industry standards - OpenGL does not. That Bill, is
> why HP supports PEX. 
PEX by its very nature binds you to the X protocol.  OpenGL is window
system independent, and runs on both unix based systems and NT based
systems.

> Dave McSavaney
> Workstation Product Marketing
> Hewlett-Packard Company
>                        
> Not an official statement of Hewlett-Packard Company

					kipp hickman
					silicon graphics inc.
Newsgroups: comp.graphics.opengl
From: jb@sgihbtn.sierra.com
Newsgroups: comp.graphics.opengl
Subject: Re: OpenGl vs PEX
Date: 12 Oct 92 19:16:44 GMT
Organization: Sierra Geophysics, Inc.

In article <1992Oct8.034714.4500@cssc-syd.tansu.com.au>, pete@cssc-syd.tansu.com.au (Peter Alexander Merel) writes:
|> stgprao@st.unocal.COM (Richard Ottolini) writes:
|> 
|> >Currently PEX is free (MIT-X11R5-SI version) and OpenGl costs money.
|> >Does anyone remember the contest between Sun-NEWS and XWindows a few years
|> >back?  Many people thought NEWS to be technologically superior, but its
|> >costs probably kept off most machines.
|> 
|> >P.S. Then you get what you pay for with MIT PEX-SI :-)
|> 
|> There's Shographics' pextk - that seems to compare well, and it's free too.
|> 
|> -- 
|> Internet: pete@cssc-syd.tansu.com.au   UUCP: {uunet,mcvax}!munnari!cssc-syd!pete
|> Snail: 1/18-20 Orion Road, Lane Cove NSW 2066 Australia    Phone: +61 2 911 3130
|> Theftright Peter A. Merel (T) 1992. Rights to all replies, followups, originals,
|> sources and anything else I can get my hands on reserved.

 Cost wasn't the only issue on that little battle. Compare a "hello world"
in GL vs PEX. Look at the example O'reilly for PEX -- hundreds if not
thousands of lines of code to "hello world" (and here's a clue --
even that exmaple WILL NOT WORK IN ALL CASES -- due to subsetting & etc).
THAT's the true test of market acceptance. GL is MUCH, MUCH more productive
at this time -- 'cause its an API as well as a spec.

Just my opinion ...
-- 
 JB West,  Manager of Graphics Dev't          |          Halliburton
 Sierra Geophysics, Inc.                      |     ######    ######  ######
 A Halliburton Energy Services Group Company  |    ###        ####   #   ##
            jb@sierra.com                     |   #######   ####### #######
Newsgroups: comp.graphics.opengl,speed@clules.enet.dec.com
From: bglazier@buffalo.asd.sgi.com (Bill Glazier)
Subject: Re: Info wanted about Open_GL on DEC.
Organization: Silicon Graphics, Inc.
Distribution: speed@clules.enet.dec.com
Date: Wed, 7 Oct 1992 20:41:48 GMT


 
|> | * Is Open_GL available on the DEC ?
|> 
|> Digital is an OpenGL licensee, and at the OpenGL BOF at SIGGRAPH they
|> indicated that OpenGL would be available on some DEC platforms in the
|> first half of 1993.
|> 
|> | * Whom should I contact and how much is it likely to cost ?
|> 
|> Check with your local DEC sales representative.  If he doesn't have
|> the information at hand, ask him to contact Derek Speed.

Derek Speed's email address is

speed@clules.enet.dec.com

He'll be able to answer your questions.

Newsgroups: comp.graphics.opengl
From: wlw@cc.gatech.edu (Wayne Wooten)
Subject: Availability of OpenGL
Keywords: release dates
Reply-To: wlw@cc.gatech.edu
Organization: Georgia Institute of Technology
Date: Sat, 10 Oct 1992 16:26:52 GMT


    I was wondering when OpenGL is expected to be release to the public. Is it
  already available for the SGI platform? I would also like any information
  on Nth Graphics' release date for the Sun platform.
    If it is not available yet, is there anyway of signing up as a test site, to
  obtain pre-release versions? There are a lot of people at our lab that want to
  start developing code with OpenGL yesterday...

--
Wayne Wooten                           Phone:  (404) 894-3172
GVU - Animation Group                          (404) 875-9650
College of Computing                   Office: 210
Georgia Tech                           Email:  wlw@cc.gatech.edu
From: segal@spud.asd.sgi.com (Mark Segal)
Newsgroups: comp.graphics.opengl
Subject: IRIS GL -> OpenGL (was Re: Availability of OpenGL)
Date: 12 Oct 1992 18:15:11 GMT
Organization: Silicon Graphics, Inc.
Distribution: world
NNTP-Posting-Host: spud.asd.sgi.com

In article <1bcaoiINNs4m@fido.asd.sgi.com>, kipp@warp.asd.sgi.com (Kipp Hickman) writes:
|> 
|> Another thing you can do to ease portability of IrisGL code to OpenGL
|> is to always use the following style of rendering commands:
|> 
|> 	beginpolygon
|> 		v3f
|> 		v3f
|> 		v3f
|> 		...
|> 	endpolygon

You can of course continue to intersperse normal and color setting
commands with vertex specifying commands.

|> Don't use the relative move,draw stuff, or any of the move draw stuff,
|> pclos, etc.  Don't use subpixel(true).
|> 
|> 					kipp hickman

I think what Kipp meant was that you should avoid using obsolete IRIS GL
commands.  OpenGL always uses subpixel positioning, so there is no 'subpixel'
call.  Because of this, you should not rely on the default IRIS GL behavior
of 'subpixel(FALSE)'; instead you should always call 'subpixel(TRUE)' in
your IRIS GL programs in preparation for OpenGL.  The call will have
to be eliminated when you switch to OpenGL, but the effect will remain
the same.

Generally, here are some rules for IRIS GL programmers wishing to ease
their transition to OpenGL:
* Use the mixed-mode (GL with X) model for your programs as Jeff has suggested.
  This means use X to set up your windows and deal with user input.  Don't
  use 'winopen', 'qread', or any of the GL commands dealing with window
  operations, user input, popup menus, etc.  If you are not ready yet to
  make the transition to X, you should at least separate out the window
  system/user input portions of your code and encapsulate them in preparation
  for the transition to X (or Windows/NT).
* Don't use any command marked obsolete in its man page or in the GL
  programmer's guide.  Most of these commands do not have simple OpenGL
  equivalents.
* Avoid the relative drawing commands (move/draw, etc.), commands that
  create 'old-style' polygons (polf, etc.), or any other commands that
  rely on or affect the 'current graphics position.'
* Avoid using the display list editing commands.  Display lists are not
  editable in OpenGL, so you should achieve this functionality either by
  managing your own database or by nesting display lists and redefining
  subordinate lists.
If you strictly follow these rules, you should have a relatively easy time
converting to OpenGL; many of the changes will amount to minor command
and constant renaming.

	Mark
From: erich@eye.com (Eric Haines)
Newsgroups: comp.graphics.opengl
Subject: Why cull after shading?
Date: Tue, 13 Oct 92 15:57:33 GMT
Summary: strange but true - what am I missing here?
Organization: 3D/EYE, Inc.  Ithaca, NY

Looking at "The OpenGL Machine" graphics system diagram (a wonderful flowchart
of the pipeline, distributed by SGI at SIGGRAPH), I was curious about one
thing.  Why is the operation "Polygon Culling" done after shading and
clipping?  Why shade and clip a polygon, and then decide whether to cull it?
On the face of it, this seems a bit bass-ackwards, but I assume there's some
good reason for culling so late in the pipeline (seems like culling is almost
the first thing you'd want to do).  Can any guru out there enlighten me?

Thanks,

Eric