RE: [Caml-list] OpenGL

[Brian Hurt <bhurt@spnz.org>]

On Fri, 9 Apr 2004, Brandon J. Van Every wrote:

> Sorry the following is acerbic.  I'm just trying to save you endless
> wasted time.

Other than these email messages, I'm not spending any time on this.

> 
> Brian Hurt wrote:
> >
> > I'll admit to not having a lot of experience with OpenGL (or
> > any other 3D
> > rendering library), and have not given one thought to merging it with
> > Ocaml.  But from the reports earlier in this thread, a direct
> > mapping of
> > the OpenGL interface into Ocaml runs into problems,
> > especially in the more
> > advanced functions.  Which is what lead me to question wether we were
> > thinking inside a box.
> 
> You should first understand "the box."  Then you could tell me whether
> 3D engines that wrap up multiple APIs, such as The Nebula Device, are a
> good solution to "the box."  I don't think talking to a C++ 3D engine
> will be entirely a picnic, but it sounds better than implementing an
> OCaml 3D engine from scratch.  I can count on a goon squad to keep
> adding features and fixing bugs in The Nebula Device.  It's a large and
> very well run project with a company contributing code.  What do you
> have to offer by comparison, just scratching your head wondering about
> 3D API unification for the first time?  Nothing.  3D engines are a *lot*
> of work.  You need a really really really REALLY compelling case before
> Not Invented Here sounds like a good idea.  The C++ binding would have
> to be pretty horrible before I'd say, screw it, start from scratch.

I actually have some idea of the amount of work entailed in writting my
own from-scratch 3D API.  I'm more likely to write my own OS.  Certainly,
reimplementing the guts of a 3D rendering software is silly.  I was
thinking of possibly "skinning" the OpenGL API with one more friendly to
Ocaml.

But I'm a great beleiver in they who do the work get to decide how the 
work gets done.

> 
> > I'd love to hear someone who's done real 3D work comparing
> > and contrasting OpenGL and Java3D as approaches.
> 
> Crank up Google.  It has certainly been discussed by many parties.

OK.

One of the first hits I got was this:
http://www.cs.uh.edu/Defenses/hzheng.html

Suggesting Java3D and OpenGL had about the same performance, with Java3D 
having the lead.  I find this result surprising, and somewhat suspect.

Some more interesting data, explaining what the guy above may have hit:
http://groups.google.com/groups?q=Java3D+AND+OpenGL&hl=en&lr=&ie=UTF-8&oe=UTF-8&selm=3C459382.3010208%40pg.gda.pl&rnum=1

My guess would be that most of the problems Java3D would have would be 
mainly Java problems.  Especially for games.  Games tend to be more 
realtime than people like to admit.  If you want to pump out 60 frames a 
second, or 1 frame every 16.6ms, a 20ms pause to garbage collect is bad.  
This is soft realtime, but it's still realtime programming.  And I have 
reliable reports of people seeing 500ms pauses in Java programs.

Wether this would be a problem for Ocaml or not I can't speak to.

> 
> If you want to save time, I will tell you the obvious: Java3D sucked,
> that is why nobody took it seriously.  If it is starting to "not suck"
> now, great, but I don't care.  Real 3D graphics guys have real 3D
> graphics work to do with real APIs and engines that have proven their
> commercial viability.  You point me at some major commercial app done in
> Java3D, then I will change my tune.

What about it sucked, was what I was trying to elicit.  Even were Java3D 
a complete train wreck, it could be so for reasons having nothing to do 
with the underlying architecture, and everything to do with how Java 
implemented it.

Hmm.  Just found out that Sun recently laid off the last two programmers 
working on Java3D:
http://www.javaperformancetuning.com/news/news034.shtml

> 
> > > Moreover, as OpenGL is available on a superset of the
> > > platforms for which
> > > Direct3D is available, what would be the advantage in using
> > > Direct3D as a back end rather than OpenGL?
> >
> > Supposedly performance,
> 
> Nonsense.  Same HW, and lotsa those NVIDIA guys are ex-SGI folk.  The
> drivers do not suck so bad that there's some huge difference between
> DirectX and OpenGL.

Notice how I phrased my response.  Especially since currently the vast 
majority of heavy computation is done on the graphics card, I'd expect the 
overhead of the API to be lost in the noise.

> 
> The main disadvantage is that OpenGL 1.5 only has a shading language as
> an ARB extension, not a required part of the API.  That will change with
> OpenGL 2.0, but where is 2.0?  If you want a standardized, widely
> deployed shader language, DirectX is way ahead of OpenGL.  I am not sure
> how big the gap is now, as I don't currently care about shader languages
> and haven't been keeping up.

OpenGL 2.0 is due out Real Soon Now:
http://developers.slashdot.org/article.pl?sid=04/04/09/1354247&mode=nested&tid=152&tid=185

Your milage may vary.


> > but I've never seen hard numbers.
> 
> That means you haven't looked.  Start with www.tomshardware.com for some
> common benchmarks.  If you look carefully, you will not see any evidence
> of either API being inherently faster than the other.  What you will
> see, is that some apps were developed with greater OpenGL expertise, and
> others with greater DirectX expertise.

Yep.  I follow the benchmarks, which is why I phrased things the way I 
did.  Graphics performance is primarily driven by the graphics card.

> 20% of the world is real.
> 80% is gobbledygook we make up inside our own heads.

Reality is what doesn't go away when you stop beleiving in it.  :-)

-- 
"Usenet is like a herd of performing elephants with diarrhea -- massive,
difficult to redirect, awe-inspiring, entertaining, and a source of
mind-boggling amounts of excrement when you least expect it."
                                - Gene Spafford 
Brian

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners