A couple of OpenGL technical/legal queries...
William C. Archibald
A couple of quick queries:
1)Quite a few modern rendering techniques and renderers support
shader function calls at arbitrary points across a surface
being rendered. Most marble textures, for example, are
rendered this way with Perlin-ish noise functions. The obvious
way to do this in OpenGL is to pre-compute a texture map and
glue it to the surface. What I would _like_ to do is call the
shader at visible (front-facing) points. Is there _any_ way
to do this kind of thing in OpenGL?
2)How does one go about perturbing surface normals via texture
maps in OpenGL?
3)If one were to create an OpenGL-like library, much the same way
that Mr. Echidna has with vogl for Iris GL, and release it to
the "Net", what would the response from SGI be?
Regards,
William C. Archibald Nippon Motorola, Ltd.
bi...@tdo.sps.mot.com Tokyo, Japan
-
John F. Spitzer
In article <1993Oct13.0...@newsgate.sps.mot.com>, bi...@entropy.sps.mot.com (William C. Archibald) writes:
> 1)Quite a few modern rendering techniques and renderers support
> shader function calls at arbitrary points across a surface
> being rendered. Most marble textures, for example, are
> rendered this way with Perlin-ish noise functions. The obvious
> way to do this in OpenGL is to pre-compute a texture map and
> glue it to the surface. What I would _like_ to do is call the
> shader at visible (front-facing) points. Is there _any_ way
> to do this kind of thing in OpenGL?
I assume you're talking about 3d textures as that's the way most (all?)
renderers do marble. OpenGL doesn't currently support 3d textures, but
there are several OpenGL vendors interested in developing an extension
to support this. I'd imagine SGI would be first since the RE has that
function already, but I'll let them talk to that...
Otherwise, you're stuck doing the surface to 3d texture intersection
and then "gluing" it to the surface, as you mentioned.
> 2)How does one go about perturbing surface normals via texture
> maps in OpenGL?
Texture mapping occurs on a fragment level while surface normals
are used much earlier for lighting and such. Thus, you can't use
texture mapping to affect the normals. You can, however, perturb
the normals yourself and have it affect the texture mapping. This
is enabled thru glTexGen with a texture generation parameter of
GL_SPHERE_MAP. Small consolation...
> 3)If one were to create an OpenGL-like library, much the same way
> that Mr. Echidna has with vogl for Iris GL, and release it to
> the "Net", what would the response from SGI be?
I'll let SGI field this one, Mason?
--
* ------------------------------------------------------------------- *
* John F. Spitzer AIX 3D Graphics Software *
* IBM Advanced Workstations and Systems OpenGL Development *
* 11400 Burnet Rd. Austin, TX 78758 (512) 838-1477 *
Kurt Akeley
|>
|>
|> 1)Quite a few modern rendering techniques and renderers support
|> shader function calls at arbitrary points across a surface
|> being rendered. Most marble textures, for example, are
|> rendered this way with Perlin-ish noise functions. The obvious
|> way to do this in OpenGL is to pre-compute a texture map and
|> glue it to the surface. What I would _like_ to do is call the
|> shader at visible (front-facing) points. Is there _any_ way
|> to do this kind of thing in OpenGL?
Not with the current API. One could extend OpenGL in this manner,
although if "the shader" is a user-specified procedure, then the
callback mechanism would be a problem in the client-server world of
X and GLX (though not in the simple world of OpenGL itself).
|> 2)How does one go about perturbing surface normals via texture
|> maps in OpenGL?
One does this by extending the API; it isn't possible in OpenGL 1.0.
|> 3)If one were to create an OpenGL-like library, much the same way
|> that Mr. Echidna has with vogl for Iris GL, and release it to
|> the "Net", what would the response from SGI be?
I don't know.
-- kurt
Michael Toy
>3)If one were to create an OpenGL-like library, much the same way
> that Mr. Echidna has with vogl for Iris GL, and release it to
> the "Net", what would the response from SGI be?
I speak for no one but myself. My guess is that it would be greeted with
enthusiasm, as long as it didn't claim to be OpenGL, merely OpenGL compatible,
as you have to pay a fee and pass the conformance test in order to be able
to claim to be OpenGL. I understand that this policy exists in order to
protect application developers by having some way of enforcing what it means
when you say you have "OpenGL".
I think SGI wants to see a zillion implementations of OpenGL, and a free one
would be great.
Don't shoot me, I'm just trying to be helpful.
-Michael
--
.signature: Insufficient memory
Allen Akin
Sorry, Michael. We have to shoot you now. :-)
In article <1993Oct13.0...@newsgate.sps.mot.com> bi...@entropy.sps.mot.com (William C. Archibald) writes:
>3)If one were to create an OpenGL-like library, much the same way
> that Mr. Echidna has with vogl for Iris GL, and release it to
> the "Net", what would the response from SGI be?
The official answer is that we would take whatever action was necessary
to protect the OpenGL specification, trademark, API, and our ability to
defend those things in the future. We have to take this position
because if we don't, we forfeit many of our legal rights to protect
OpenGL should that ever be necessary.
We don't intend to be paranoid about this. If we did, we wouldn't have
licensed OpenGL to our competitors. However, as Michael said, we are
determined that all OpenGL implementations will be complete and
consistent. That's what it takes to give applications developers a
solid porting base, and therefore create a larger market for 3D
graphics systems.
Allen
George Kyriazis
I have some trouble interpreting the above.
For example if, I, George, write something called 'gogl' (for George's OpenGL)
that I give out in the public domain, and it just happens that gogl has the
same API as OpenGL, but I make no claims that it's OpenGL compatible, what
are you going to do to me? Are you (meaning SGI) going to be severely
offended and get all angry, or are you just going to ingore me and let me be?
Notice that I am not trying to sell gogl, just give it to anyone that wishes
to use it..
If the above scenario does not work, is there any scenario where a public
domain implementation of OpenGL is going to have the "blessing" of SGI?
Thanks for the clarification...
--george
--
----------------------------------------------------------------------------
George Kyriazis | Visual Technologies Program, Rensselaer Design
kyri...@rdrc.rpi.edu | Research Center, CII 7015, RPI, Troy, NY 12180
----------------------------------------------------------------------------
Nick C. Fotis
[ Hi, George! How are you going ? ;-) ]
kyri...@nova0.rdrc.rpi.edu (George Kyriazis) writes:
>In article <29id68$r...@fido.asd.sgi.com>,
>Allen Akin <ak...@tuolumne.asd.sgi.com> wrote:
>>
>>In article <1993Oct13.0...@newsgate.sps.mot.com> bi...@entropy.sps.mot.com (William C. Archibald) writes:
>>>3)If one were to create an OpenGL-like library, much the same way
>>> that Mr. Echidna has with vogl for Iris GL, and release it to
>>> the "Net", what would the response from SGI be?
>>
>>The official answer is that we would take whatever action was necessary
>>to protect the OpenGL specification, trademark, API, and our ability to
>>defend those things in the future. We have to take this position
>>because if we don't, we forfeit many of our legal rights to protect
>>OpenGL should that ever be necessary.
>For example if, I, George, write something called 'gogl' (for George's OpenGL)
>that I give out in the public domain, and it just happens that gogl has the
>same API as OpenGL, but I make no claims that it's OpenGL compatible, what
>are you going to do to me? Are you (meaning SGI) going to be severely
>offended and get all angry, or are you just going to ingore me and let me be?
>Notice that I am not trying to sell gogl, just give it to anyone that wishes
>to use it..
>If the above scenario does not work, is there any scenario where a public
>domain implementation of OpenGL is going to have the "blessing" of SGI?
I asked some weeks ago about the possibility of an OpenGL implementation
in the Amiga (I have an A3000, and I expect to get a 24-bit card soon).
Mason Woo told to me that he finds it unlikely to see OpenGL on the Amiga
(even if I add an accelerated graphics card), and no official interest
was shown yet.
I already ordered the manuals to see what's all that about. I cannot get
an SGI (or IBM, H-P, or...) box at this moment, and I would like to
test the (programming) waters on my home machine.
So I would *love* to have a VOGL-like implementation. I would even pay for
such a library which is guaranteed OpenGL-compliant (A card like
IrisVision for the 32-bit Zorro III bus with OpenGL libraries would be
very fine - but the cost *must* be below 2,000 USD for a 24-bit version)
The Amiga is a low-end graphics machine, and I'm thinking about developing
3D-applications on it, which can be ported later on to larger machines
(like SGI boxes)
Greetings,
Nick.
--
Nick (Nikolaos) Fotis National Technical Univ. of Athens, Greece
HOME: 16 Esperidon St., InterNet : nfo...@theseas.ntua.gr
Halandri, GR - 152 32 UUCP: mcsun!pythia!theseas!nfotis
Athens, GREECE FAX: (+30 1) 77 84 578
Adam Billyard
> In article <1993Oct13.0...@newsgate.sps.mot.com>, bi...@entropy.sps.mot.com (William C. Archibald) writes:
> |>
> |> A couple of quick queries:
> |>
> |> 1)Quite a few modern rendering techniques and renderers support
> |> shader function calls at arbitrary points across a surface
> |> being rendered. Most marble textures, for example, are
> |> rendered this way with Perlin-ish noise functions. The obvious
> |> way to do this in OpenGL is to pre-compute a texture map and
> |> glue it to the surface. What I would _like_ to do is call the
> |> shader at visible (front-facing) points. Is there _any_ way
> |> to do this kind of thing in OpenGL?
>
> Not with the current API. One could extend OpenGL in this manner,
> although if "the shader" is a user-specified procedure, then the
> callback mechanism would be a problem in the client-server world of
> X and GLX (though not in the simple world of OpenGL itself).
I guess 3D hardware accelerators would have no problem providing a
general computational model with which to evaluate shader functions for
geometry samples if it wasn't for that pesky client-server mechanism.
Hell, a bunch of DDA's are practically a CPU anyway. :-)
I don't think so.
Adam.
Allen Akin
George Kyriazis <kyri...@nova0.rdrc.rpi.edu> wrote:
| ...
| For example if, I, George, write something called 'gogl' (for George's OpenGL)
| that I give out in the public domain, and it just happens that gogl has the
| same API as OpenGL, but I make no claims that it's OpenGL compatible, what
| are you going to do to me? Are you (meaning SGI) going to be severely
| offended and get all angry, or are you just going to ingore me and let me be?
Hi, George.
We won't say in advance what we would do, because it depends on the
details of each particular case. Was code from the OpenGL sample
implementation used without license? Is the API identical to OpenGL?
If not, are the differences likely to cause confusion among application
developers? Does the implementation pass the OpenGL conformance
tests? Is it a subset, and if so, which features have been dropped?
If the implementation is not conforming, is it likely to be distributed
widely enough or soon enough to interfere with the acceptance of
conforming implementations?
We can't give a simple answer, because doing so might constitute a
public declaration of intent that would prevent us from taking action
in a future case where OpenGL needs to be defended. We have to keep
our options open, and that's why I'm being noncommittal.
Our intent is not just that OpenGL will be widely used, but that there
will be general agreement about what the term "OpenGL" really means.
Without that, application developers don't have a stable porting base
and hardware developers don't have a specification they can use as a
design guide. So I guess the best summary I can offer is that SGI
would object to actions that tend to compromise those two goals.
Allen
Jon Leech
|> ku...@cashew.asd.sgi.com (Kurt Akeley) writes:
|> > Not with the current API. One could extend OpenGL in this manner,
|> > although if "the shader" is a user-specified procedure, then the
|> > callback mechanism would be a problem in the client-server world of
|> > X and GLX (though not in the simple world of OpenGL itself).
|>
|> I guess 3D hardware accelerators would have no problem providing a
|> general computational model with which to evaluate shader functions for
|> geometry samples if it wasn't for that pesky client-server mechanism.
|> Hell, a bunch of DDA's are practically a CPU anyway. :-)
|>
|> I don't think so.
You're mixing a specification - OpenGL - with an implementation. But
even so, many 3D hardware accelerators *are* a general purpose CPU (or
dozens to hundreds of thousands of CPUs), such as the Enhanced Memory Chips
used in the UNC Pixel-Planes and upcoming Pixel-Flow architectures. I
imagine the RealityEngine rasterization processors have comparable
flexibility.
We're extending OpenGL for Pixel-Flow in more or less the way mentioned
by Kurt. Shaders will be translated to code driving the EMCs and linked into
the "server" code. The API will be extended to specify shaders and shader
parameters. As Kurt mentions in passing, the mechanism by which user-defined
shaders are created and accessed by the graphics library has nothing to do
with OpenGL (which is good. Making a policy decision that (for example)
shaders are implemented as procedures in the same address space as the
application would be terribly restrictive and virtually guarantee abysmal
performance on most architectures).
The unfortunate facts that most existing graphics hardware is very
limited and (less important) that it's hard to extend the X server
dynamically may make it impractical to add user-defined shaders on current
architectures. Wait a few years and another cycle around the wheel of
reincarnation - it'll be common. Rasterization is less and less the
bottleneck, which is moving towards the transformation end of the pipeline
in recent architectures. There's increasing room to enhance the accelerators
to do something more general than scan-converting and Z-buffering convex
polygons.
Jon
__@/
Antti Miettinen
>We can't give a simple answer ..
OK - how about a simple answer to the following: as far as I know you
haven't taken any legal action against VOGL writers. Are you going to?
If not, then does this mean that you are not as paranoid about GL-like
libraries as you are about OpenGL-like libraries? :-)
Michael B. Johnson
Oh, I don't know. Why couldn't you download the shader code into the server at
the beginning of a rendering session? Think about how RenderMan solves this,
think about how NeWS dealt with similar issues. In RenderMan, you compile the
shaders and place them in the server's environment (i.e. the .slo files are in
some path known to the renderer). In NeWS, you could download Postscript code
into the server to do some particular drawing operation, and then later on
refer to it succintly in the rendering process.
The only thing that made me stick with RenderMan as the backend for my PhD as
opposed to OpenGL is the fact that OpenGL is crippled without programmable
shaders. Makes for great preview mode, though...
--
--> Michael B. Johnson
--> MIT Media Lab -- Computer Graphics & Animation Group
--> (617) 253-0663 -- wa...@media-lab.media.mit.edu
--> NeXT Mail accepted at wa...@nordine.media.mit.edu
Jason Weber
(George Kyriazis) writes:
>Hello Allen...
I'm not Allen, but I've got a comment to make.
>If the above scenario does not work, is there any scenario where a public
>domain implementation of OpenGL is going to have the "blessing" of SGI?
I wrote a reduced version of GL for my Amiga so that I could do a little
work at home in my spare time. I asked some questions on the news on
how to double buffer windows on an Amiga. In doing so, a lot of people
stated they'd want a copy of my GL to use on their Amigas. Seemed fine to me.
But when I asked SGI some questions about their headers, they got really upset
that I was infringing on their property. I wasn't using their source or
anything. I made it all from scratch. I just used their syntax.
It appears that I'll be the only one using my GL. If someone sold
GL or OpenGL for the Amiga, I'd buy it. But no one will. The market is too
small. So Amiga programmers no GL. 'cept me.
Of course, SGI's response is that if I bought an SG, I wouldn't have this
problem. I don't have $7000 laying around. I think I'd rather make
my car payments.
_ Jason Weber Phone:(703)704-1796
( \ _ \ /_ / _ _ Teletronics Inc 704-3901
\|(\/)())) \/\/(-/_)(-/( Army Research Lab Fax: 704-3196
// Modeling Simulation Branch
(/ ja...@belvoir-arl-irisgt.army.mil
kar...@vanilla.meerkat.com.asd.sgi.com
> OK - how about a simple answer to the following: as far as I know you
> haven't taken any legal action against VOGL writers. Are you going to?
> If not, then does this mean that you are not as paranoid about GL-like
> libraries as you are about OpenGL-like libraries? :-)
As someone who is neither a lawyer nor has any responsibilities in this
area, let me try and reply: I suspect you will never get a simple
answer to this simple question.
If SGI were to reply "we will not take action" then SGI would lose
standing in the courts for dealing with commercial entities
perverting the OpenGL or generally screwing over the licensing
provisions.
If SGI were to reply "we will nail poor graduate students to the
wall for building OpenGL-lite," SGI would lose standing in the
general computer community.
Any answer would be the wrong answer.
PK
Przemek Klosowski
compatible implementation of OpenGL.
In article <29k4v3$l...@fido.asd.sgi.com> ak...@tuolumne.asd.sgi.com
(Allen Akin) writes:
We won't say in advance what we would do, because it depends on the
details of each particular case. Was code from the OpenGL sample
implementation used without license? Is the API identical to OpenGL?
If not, are the differences likely to cause confusion among application
developers? Does the implementation pass the OpenGL conformance
tests? Is it a subset, and if so, which features have been dropped?
If the implementation is not conforming, is it likely to be distributed
widely enough or soon enough to interfere with the acceptance of
conforming implementations?
On the topic of compatibility of implementation---I wish SGI would
follow the model established by X Windows. The fact that you can
compile an X11 program on such wide list of OS and graphic hardware
shows clearly that compatibility is very much appreciated by software
developers; even though X11 has technical deficiencies you don't see
many people creating and using private, non-standard implementations
of X.
I don't understand why SGI does not want to emulate the
(organizational) success of X. As far as I understand, there is
already an industry consortium supervising the GL standard. Why not,
then, release the specs, sample implementation, and whatnot?
I am convinced that current policy adopted by SGI loses out in the
long term, simply because it is not agressive about the "market share"
taken by GL. Even if it is technically superior to PEX, PEX has the
distinct advantage of already being in _many_ X servers. Heck, I have
PEX in the X11R5 server running on a PC!
After all, a succeess of a software standard is well measured by the
number of programs using this standard. By this metric, GL will not
fare well unless it will be available for standard X servers.
--
przemek klosowski (prz...@rrdstrad.nist.gov)
Reactor Division (bldg. 235), E111
National Institute of Standards and Technology
Gaithersburg, MD 20899, USA
(301) 975 6249 tel
(301) 921 9847 fax
Mark Kilgard
|> On the topic of compatibility of implementation---I wish SGI would
|> follow the model established by X Windows. The fact that you can
|> compile an X11 program on such wide list of OS and graphic hardware
|> shows clearly that compatibility is very much appreciated by software
|> developers; even though X11 has technical deficiencies you don't see
|> many people creating and using private, non-standard implementations
|> of X.
There's no doubt X has been a wonderfully successful standard.
Your point about "creating and using private, non-standard
implementations" is worth considering. An advantage that X
has is that the hardware (and system software) required to
implement reasonable implementations of X *was* the common
denominator for workstations when it was developed.
If you have a dumb frame buffer, a keyboard, a mouse, a
Unix-like operating system, and a couple megs of memory,
you can do a reasonable X implementation based on MIT's
sample server. Consider that OpenGL does not benefit from
that same situation. Adequate OpenGL performance demands
either an extremely fast host processor and some level of
graphics acceleration. Back to this later.
|> I don't understand why SGI does not want to emulate the
|> (organizational) success of X.
Please understand X's success and cohesiveness was underpinned
by Project Athena's and later the X Consortium's organization
and the leadership of key individuals. But X's model isn't
the only way to make a successful standard. NFS, PostScript,
ANSI C, MS-DOS, Motif, and Unix all were developed along different
standards models but all are indisputable standards. Please
consider that the current situation, politics, and "other factors"
are important to founding a standard. One model doesn't serve
all purposes.
Note that the X model does not guarantee success. I might suggest
you consider CMU's Andrew consortium that was formed along similar
to the X Consortium. It may still be going (I don't know) but
Andrew hasn't exactly caught on like fire (I hope I haven't
offended Andrew supporters; it is cool technology).
|> As far as I understand, there is
|> already an industry consortium supervising the GL standard. Why not,
|> then, release the specs, sample implementation, and whatnot?
The spec was made available on CDs distributed at SIGgraph.
The man pages are available for ftp. Two books published by
Addison-Wesley are on the shelves of computer literate book
stores.
As for a free sample implementation, please consider that
the situation for OpenGL is not identical to X. The hardware
needed to support a reasonable implementation of OpenGL is
probably difficult for many low-end workstations and PCs
to do right.
The sample implementation of OpenGL currently available simply
does not have sufficient tuning to provide adequate performance
on most available workstations (ie, workstations with moderately
fast processors and dumb or nearly-dumb frame buffers). And
in the case of graphics accelerators, a sample implementation
will probably have to be almost totally redone if you really
want to get at the accelerator's speed.
A serious workstation vendor willing to spend the resources
to tune OpenGL to their 3D graphics hardware will have a very
capable 3D interface.
My point is I do not think swamping the market with OpenGL sample
implementations that simply don't have adequate performance
will bring 3D to the masses. Real 3D apps are interactive and
demand a certain base line of performance to be reasonable.
Creating a situation where software writers can't rely on
reasonabe OpenGL performance doesn't help. And hardware makers
will be lazy. Why push for good 3D hardware when workstation
vendors can point to a poor excuse for an OpenGL implementation
and claim they support the OpenGL standard?
|> I am convinced that current policy adopted by SGI loses out in the
|> long term, simply because it is not agressive about the "market share"
|> taken by GL. Even if it is technically superior to PEX, PEX has the
|> distinct advantage of already being in _many_ X servers. Heck, I have
|> PEX in the X11R5 server running on a PC!
Yeah, but a sample implementation of PEX hasn't made PEX a success
(based on the following standard: how many PEX apps are you
running right now?). In fact, my impression has been that people
are indeed unhappy with the PEX sample implementation. It gives
people the impression they'll be able to do 3D on their machine.
They are generally disappointed. I think people should walk away
from a 3D workstation going "Wow, man, cool" not "Is that it?"
Imagine if Adobe would have introduced PostScript for dot-matrix
printers. Yeah, they could have. But that might have stifled
the standard because people wouldn't have been impressed. Simple text
printing would have taken many times longer doing PostScript to
a dot-matrix. People would say "Who needs this? My printer worked
fast before I used PostScript." Instead Adobe was future looking
and coupled PostScript with laser printer technology.
I'd suggest that OpenGL uncoupled from graphics acceleration
technology would be similarly stifled. If you are serious about
3D, ask your vendor to be just as serious.
- Mark
These are my own thoughts, not SGI's.