Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!harbinger.cc.monash.edu.au!news.rmit.EDU.AU!news.unimelb.EDU.AU!munnari.OZ.AU!news.mel.connect.com.au!news.mira.net.au!vic.news.telstra.net!act.news.telstra.net!psgrain!newsfeed.internetmci.com!in2.uu.net!news.bb.net!news.blarg.net!blarg.net!vanevery
From: vanevery@blarg.net (Brandon J. Van Every)
Newsgroups: comp.graphics.api.misc,comp.graphics.algorithms,comp.windows.x.i386unix,gnu.misc.discuss,comp.unix.bsd.freebsd.misc,comp.os.linux.development.apps
Subject: Re: Freeware community needs 3d library NOW
Followup-To: comp.graphics.api.misc,comp.graphics.algorithms,comp.windows.x.i386unix,gnu.misc.discuss,comp.unix.bsd.freebsd.misc,comp.os.linux.development.apps
Date: 27 Jun 1996 05:28:42 GMT
Organization: Blarg! Online Services 206/441-9109
Lines: 110
Message-ID: <4qt66a$nag@guysmiley.blarg.net>
References: <4qlf04$7pj@guysmiley.blarg.net> <4qn08b$ntl@fido.asd.sgi.com>
NNTP-Posting-Host: animal.blarg.net
X-Newsreader: TIN [version 1.2 PL2]
Xref: euryale.cc.adfa.oz.au comp.graphics.api.misc:640 comp.graphics.algorithms:29024 comp.windows.x.i386unix:20367 gnu.misc.discuss:26735 comp.unix.bsd.freebsd.misc:22255 comp.os.linux.development.apps:18105
Allen Akin (akin@tuolumne.asd.sgi.com) wrote:
: I agree with you that there are many reasons to be dissatisfied with
: Direct3D.
Actually, I don't have any opinions on Direct3d right now. As an API,
what do you see as the problems with it?
: But by dismissing OpenGL, you're throwing out the most
: viable alternative. OpenGL is widely available, in both commercial
: and freeware (Mesa) form. Optimization of software-only renderers is
: underway at several sites (and I hear from one of them that their
: version of OpenGL is already faster than Direct3D for some important
: operations).
Could you please provide URL's of these sites?
: Many PC hardware vendors already support OpenGL, because
: Microsoft provides it for both Windows NT and Windows 95. Developers
: have been using it for a couple of years, so it's known to be strong
: enough to support real-world applications. Unlike Direct3D, it runs
: under a variety of operating systems and window systems. And so on.
: | Everything I have to say about OpenGL, is on my web pages.
: As we've discussed in the past, many of your statements about OpenGL
: are incorrect, and generally I'll respond to them so that other people
: aren't misled. In this case, I'll simply ask if you're really serious
: about building an alternative to Direct3D. If so, you ought to
: reconsider OpenGL.
: Allen
Allen, admittedly you are probably right, that some of my statements
in the past about OpenGL have been incorrect. However, here is my
current list of what I think is wrong with OpenGL. Or at
any rate, what I propose to do better in Free3d:
1) OpenGL guarantees the order of rendering. There should be an
option to control whether there's a guarantee or not. This has
enormous implications for large background Phong-shaded triangles,
etc.
2) OpenGL allows the user to switch cotexts at any time, even though
those context switches are typically enormously disruptive to system
throughput. The API user should be made very conscious of the fact
that context switching is expensive, and should not be allowed to just
do it whenever. We'd like to think that users have enough
intelligence not to write bad apps, but in practice, a lot of people
don't have the intelligence to know that. Others would argue that
even if they did know, they shouldn't have to. So we should guard
against it in the API design itself.
3) OpenGL implements way too many features that BOTH impede efficency
AND are not important to support in a large number of applications. I
haven't yet finished my "laundry list" of the features I want to throw
away. But let's start with stenciling and user clipping. You might
say, "well, just turn them off." But in practice, when you require
these things as part of the API, people end up implementing them "the
lazy way" because it's too much recombinatorial work to do otherwise.
The code becomes peppered with if..then's, which is a performance
drag. I think a 3d API should specify less things to include than
OpenGL.
4) The enormous number of OpenGL states also encorages "state driven"
code design, where you have an enormous "GL context" that is
constantly being used as both information and a scratch computation
area. This happens because it simplifies the design complexity.
However, it's probably one of the worst design decisions one could
make, because data motion is a huge bottleneck. On RISC
architectures, it's the principle bottleneck. The API should be
designed in such a way, that the "simplest" implementation of the
architecture is not condusive to "state record" designs. That may
simple mean providing a Sample Implementation that breaks out all the
possible recombinations of cases, at the highest possible level.
5) OpenGL makes no guarantee that the lighting normal is the same as
the surface normal. It should be possible to guarantee this, and it
should also be the default behavior. In many kinds of rendering, it
would allow the geometry pipe and the rasterization pipe to re-use
surface normal values.
6) OpenGL has no provisions for pre-cached global diffuse shaded
vertices. A clever game could compute these once in a static scene.
Then, as long as the static geometry and lighting doesn't change, and
you have sufficient memory, you don't have to do illumination ever
again.
7) OpenGL has no pathways for "pre-accepted" geometry. A user's 3d
spatial database could potentially feed a large number of primitives
to the library, that do not require clipping or even accept/reject
testing.
8) OpenGL has no facilities for tracking the delta's of a user's
motion, so as to determine things like "we've only changed the X
position," "we're only moving in the XZ plane," etc. Or, to specify
only XY, XZ, or YZ motion. These could potentially save a lot of ops.
Cheers,
--
Brandon J. Van Every | Check out Free3d, my 100% efficient, 100% portable
| 3d lib, at <http://www.blarg.net/~vanevery>.
3d Computer Graphics |
C++ UNIX X11 WinNT | E-mail: vanevery@blarg.net