[Caml-list] OpenGL

[Caml-list] OpenGL

[Jon Harrop]

On Thursday 08 April 2004 3:53 pm, John Goerzen wrote:
> I'm just saying that I think that
> "Ocaml has a robust set of tools for real-world uses" is inaccurate.

Yes, I agree. Personally, I would like to see a carefully thought out 
interface to OpenGL, GLU etc. They are very stable and mature libraries which 
were superbly thought out but, unfortunately, suffer from a low-level API 
which sometimes ends up in a lot of "void *" raw data getting passed around 
and kept. I do not know of an existing, elegant interface to these libraries 
in any functional language and, IMHO, it would be a big but very worthwhile 
undertaking to create such an interface. I think this would make a good PhD 
for someone...

Cheers,
Jon.

-------------------
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

Re: [Caml-list] OpenGL

[Issac Trotts]

On Thu, Apr 08, 2004 at 04:11:25PM +0100, Jon Harrop wrote:
> 
> On Thursday 08 April 2004 3:53 pm, John Goerzen wrote:
> > I'm just saying that I think that
> > "Ocaml has a robust set of tools for real-world uses" is inaccurate.
> 
> Yes, I agree. Personally, I would like to see a carefully thought out 
> interface to OpenGL, GLU etc. They are very stable and mature libraries which 
> were superbly thought out but, unfortunately, suffer from a low-level API 
> which sometimes ends up in a lot of "void *" raw data getting passed around 
> and kept. I do not know of an existing, elegant interface to these libraries 
> in any functional language and, IMHO, it would be a big but very worthwhile 
> undertaking to create such an interface. I think this would make a good PhD 
> for someone...

Did you look at LablGL?

-- 
Issac Trotts
http://mallorn.ucdavis.edu/~ijtrotts
(w) 530-757-8789

-------------------
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

Re: [Caml-list] OpenGL

[Jon Harrop]

On Wednesday 07 April 2004 5:07 pm, Issac Trotts wrote:
> Did you look at LablGL?

Yes, it's lablGL that I'm working with. It's excellent for the basic stuff 
(plotting triangles), but things quickly get quite hairy. Specifically, my 
program needs the GLU tesselator (the reimplementation of which in ocaml is 
prohibitively complicated). The problems with the interface provided by 
lablGL (which can never be made to work in its current state, BTW) are 
actually much more deep seated, and apply to lots of other parts of the 
library.

There is another OpenGL interface library, IIRC, which is very low-level. 
However, I don't like this approach as it is then easy for ocaml programs to 
crash the OS, and stability and safety are surely two of the most important 
advantages of ocaml.

I have gone some way to reimplementing the lablGL interface to the GLU 
tesselator but it is very difficult. Not to mention the other parts of the 
libraries which will need equivalent things done to them...

Cheers,
Jon.

-------------------
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

Re: [Caml-list] OpenGL

[Issac Trotts]

On Thu, Apr 08, 2004 at 05:35:48PM +0100, Jon Harrop wrote:
> On Wednesday 07 April 2004 5:07 pm, Issac Trotts wrote:
> > Did you look at LablGL?
> 
> Yes, it's lablGL that I'm working with. It's excellent for the basic stuff 
> (plotting triangles), but things quickly get quite hairy. Specifically, my 
> program needs the GLU tesselator (the reimplementation of which in ocaml is 
> prohibitively complicated). The problems with the interface provided by 
> lablGL (which can never be made to work in its current state, BTW) are 
> actually much more deep seated, and apply to lots of other parts of the 
> library.

What it is about lablGL that means it can never be made to work?
 
> There is another OpenGL interface library, IIRC, which is very low-level. 
> However, I don't like this approach as it is then easy for ocaml programs to 
> crash the OS, and stability and safety are surely two of the most important 
> advantages of ocaml.

That one is called camlgl, which seems to have been abandoned.

> I have gone some way to reimplementing the lablGL interface to the GLU 
> tesselator but it is very difficult. Not to mention the other parts of the 
> libraries which will need equivalent things done to them...

I already wrote a binding for GLU using CamlIDL, but I don't recommend
it since GLU relies so much on callbacks.  It would probably be better to
wrap Jonathan Shewchuck's Triangle code:

    http://www-2.cs.cmu.edu/~quake/triangle.html

-- 
Issac Trotts
http://mallorn.ucdavis.edu/~ijtrotts
(w) 530-757-8789

-------------------
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

[Caml-list] Re: Triangle (was: OpenGL)

[Christophe TROESTLER]

On Thu, 8 Apr 2004, Issac Trotts <ijtrotts@ucdavis.edu> wrote:
> 
> I already wrote a binding for GLU using CamlIDL, but I don't recommend
> it since GLU relies so much on callbacks.  It would probably be better to
> wrap Jonathan Shewchuck's Triangle code:
> 
>     http://www-2.cs.cmu.edu/~quake/triangle.html

I am planning to do just that as soon as I have some time -- most
likely not before beginning of July.  In the meantime, if you have
some comments, whishes,...  just let me know.

ChriS

-------------------
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

Re: [Caml-list] OpenGL

[Jon Harrop]

On Thursday 08 April 2004 9:19 pm, Issac Trotts wrote:
> What it is about lablGL that means it can never be made to work?

I'll give some background information first. The GLU tesselator accepts a 
polygon (as a list of contours) and a winding rule. It uses this to generate 
a set of non-overlapping OpenGL primitives (triangles, triangle fans and 
triangle strips) which cover the regions in the contours which are deemed to 
be interior according to the winding rule.

When I found out that the (old) Mesa GLU tesselator implementation was broken, 
I tried to write my own. I failed miserably: this is a very difficult 
problem, and the subject of numerous maths and computer science PhDs. A few 
years ago, SGI released their implementation as open source and Mesa adopted 
it. It is now a very powerful part of the Mesa library, IMHO.

Unfortunately, the lablGL interface to the tesselator isn't complicated 
enough. Firstly, it isn't clear how tesselator objects should allocated and 
deallocated. The lablGL library currently lets you allocate a tesselator but 
it is immediately available for garbage collection (I believe this erroneous 
pattern appears in other portions of lablGL as well, outside the tesselator, 
such as NURBS). Anyway, even if you could allocate a tesselator and keep it 
around long enough to use it, lablGL has no facility for specifying 
callbacks. Without callbacks, the tesselator can have no "side effects" which 
is, unfortunately, the only purpose of the tesselator.

To make things more interesting, there is a combine callback which is required 
for tesselating all but the simplest of polygons. This callback basically 
allocates new vertices and calculates any related information for the new 
vertices (e.g. texture coordinates).

So I've written a couple of basic interfaces which do what I need. The first 
is the simplest and most efficient. It accepts a list of contours and a 
winding rule and uses the built-in OpenGL commands to render as a 
side-effect. The second uses custom C callbacks to build up lists of OpenGL 
primitives which are then returned to the ocaml caller. In both cases, the 
combine callback pushes new vertices onto a stack which gets deleted at the 
end of each tesselation.

This is nice, but there is a huge amount more which should be done. It should 
be possible to provide ocaml callbacks which use the "void *" that gets 
passed around to handle arbitrary data. Note, however, that although this 
would provide a superset of the functionality of my routines, it is likely to 
be much slower.

Oh yeah, and you want to be using one tesselator for each CPU, 
apparently... :)

> That one is called camlgl, which seems to have been abandoned.

That's the one, yes. I've never used it...

> I already wrote a binding for GLU using CamlIDL, but I don't recommend
> it since GLU relies so much on callbacks.  It would probably be better to
> wrap Jonathan Shewchuck's Triangle code:
>
>     http://www-2.cs.cmu.edu/~quake/triangle.html

That is certainly a very nice looking library, but it seems to be solving a 
related but substantially different problem (Delaunay triangulation vs 
polygon tesselation)?

Also, it would be nice if there was an elegant way to support OpenGL 
extensions. I'm not sure if this is theoretically possible in the general 
case, as it is likely that other non-trivial interfaces will need to be 
thought up.

Cheers,
Jon.

-------------------
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

Re: [Caml-list] OpenGL

[Brian Hurt]

A question with respect to this subject: is it necessary to make a 1:1 
mapping of GL into Ocaml?  I'm wondering if a different approach might not 
work better.  I'm thinking specifically of Java3D, which while it is built 
on top of GL, doesn't reflect GL in it's design.  The advantage of this 
approach is that you can replace GL with other rendering libraries 
(DirectX, for example).

-- 
"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

RE: [Caml-list] OpenGL

[Brandon J. Van Every]

Brian Hurt
>
> A question with respect to this subject: is it necessary to
> make a 1:1
> mapping of GL into Ocaml?  I'm wondering if a different
> approach might not
> work better.  I'm thinking specifically of Java3D, which
> while it is built
> on top of GL, doesn't reflect GL in it's design.  The
> advantage of this
> approach is that you can replace GL with other rendering libraries
> (DirectX, for example).

Ok ok, you finally forced me to butt in here before someone goes running
off on a disgusting wild goose chase.

I am a recent OCaml initiate, just barely learning it.  I'm mainly
interested in 3D graphics and AI and looking to OCaml as my C++
replacement.  My strategic plan is to create a binding to The Nebula
Device, an open source MIT-style licensed 3D engine.
http://nebuladevice.sourceforge.net.  TND has been used in several
commercial games, most notably Project Nomads.
http://www.project-nomads.de/.  The current version of TND hasn't been
commercially proven yet, however.  It is a "shader centric" 3D engine,
written on top of DirectX 9, but just now I believe it is being ported
to Linux and OpenGL.  I am not sure of the status on the OpenGL side of
things.

I haven't done anything about OCaml or the TND binding yet.  No time
right now.  But it is in my plans.  I'll only abandon the plan if OCaml
turns out to have some serious "deal breaking" weakness that I'm
currently unaware of.  I'm committed to TND, I just refuse to do C++ for
major development anymore.

Anyways, if you are not satisfied with straight OpenGL, ***PLEASE***,
for the love of God, don't run around making yet another 3D engine.
Contribute your efforts to an extant 3D engine.  Personally I think TND
is the most commercially viable candidate.  Of course I am biased, I'm
speaking from the standpoint of a Windows game developer.  If you have
other needs, like CAD or scientific visualization, maybe you will be led
towards other open source software systems.


Cheers,                     www.indiegamedesign.com
Brandon Van Every           Seattle, WA

"The pioneer is the one with the arrows in his back."
                          - anonymous entrepreneur

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.643 / Virus Database: 411 - Release Date: 3/25/2004

-------------------
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

Re: [Caml-list] OpenGL

[Jon Harrop]

On Friday 09 April 2004 2:45 am, Brian Hurt wrote:
> A question with respect to this subject: is it necessary to make a 1:1
> mapping of GL into Ocaml?  I'm wondering if a different approach might not
> work better.  I'm thinking specifically of Java3D, which while it is built
> on top of GL, doesn't reflect GL in it's design.  The advantage of this
> approach is that you can replace GL with other rendering libraries
> (DirectX, for example).

OpenGL is not for 3D alone, a lot of it is also 2D and some 4D. If someone 
were to create a higher level, 3D only interface from ocaml to OpenGL then I 
could not use it in my (2D) work, for example.

Also, OpenGL has a very carefully thought out design which works very well.

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?

Cheers,
Jon.

-------------------
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

Re: [Caml-list] OpenGL

[Brian Hurt]

On Fri, 9 Apr 2004, Jon Harrop wrote:

> On Friday 09 April 2004 2:45 am, Brian Hurt wrote:
> > A question with respect to this subject: is it necessary to make a 1:1
> > mapping of GL into Ocaml?  I'm wondering if a different approach might not
> > work better.  I'm thinking specifically of Java3D, which while it is built
> > on top of GL, doesn't reflect GL in it's design.  The advantage of this
> > approach is that you can replace GL with other rendering libraries
> > (DirectX, for example).
> 
> OpenGL is not for 3D alone, a lot of it is also 2D and some 4D. If someone 
> were to create a higher level, 3D only interface from ocaml to OpenGL then I 
> could not use it in my (2D) work, for example.
> 
> Also, OpenGL has a very carefully thought out design which works very well.

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.

Note that defining a new API interface has it's own problems.  First of 
all, you'd be looking at more work than a simple mapping.  Second, any new 
API has the danger of being a bad idea.  Third, you're throwing away 
people's experience with OpenGL.  Advantages include increased portability 
and being able to follow the best design practices of Ocaml and not C.

Note that I'm not saying we should reimplement Java3D (unless that's the 
best API we can come up with), I'm just saying that it's an existance 
proof that a language's 3D library doesn't have to be a simple mapping 
onto OpenGL.

I'd love to hear someone who's done real 3D work comparing and contrasting 
OpenGL and Java3D as approaches.  But I think that's mildly offtopic for 
this list.

> 
> 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, but I've never seen hard numbers.

-- 
"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

RE: [Caml-list] OpenGL

[Brandon J. Van Every]

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

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'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.

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.

> > 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.

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.

The main disadvantage of DirectX 9 is it has no support for 64-bit
floating point.  I don't know why Microsoft doesn't get on with this
feature.  It would allow DirectX to move into the CAD and scientific
visualization markets and pave the way for finally putting OpenGL under
the table.  Not that I want / need that result, I just don't understand
why MS hasn't done it already.  Maybe it's the XBox politics, not
wanting to make DirectX on the PC get too far ahead of XBox.

Minor points: OpenGL is generally regarded as a cleaner, easier to
initialize API than DirectX.  OpenGL is C, DirectX is C++.  Either of
those is an advantage or disadvantage depending on who you're talking to
and the circumstances.

> 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.


Cheers,                         www.indiegamedesign.com
Brandon Van Every               Seattle, WA

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

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.643 / Virus Database: 411 - Release Date: 3/25/2004

-------------------
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

Re: [Caml-list] OpenGL

[Kenneth Knowles]

On Fri, Apr 09, 2004 at 09:32:37PM -0700, Brandon J. Van Every wrote:
> [Lot's of good info on 3D APIs]

3D graphics are not particularly interesting to me, but there are three sounds
principles to apply here:

1.  Go with standards.
2.  Bind first, re-implement later.
3.  Guys who need to "get work done" have experience, so respect that.  But they
don't use modern, high-level languages very often, so remember they are
inexperienced in this arena (I know many many programmers who have never heard
of first-class functions, type inference, or polymorphic types).

Number 2 means, use what is there now, and build slowly from the ground up to
get nice orthogonal design in modules that make sense for your language.  Perl
is an excellent example.

Kenn

-------------------
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

Re: [Caml-list] OpenGL

[Nicolas Cannasse]

From: "Brandon J. Van Every"
Sent: Saturday, April 10, 2004 6:32 AM

> Minor points: OpenGL is generally regarded as a cleaner, easier to
> initialize API than DirectX.  OpenGL is C, DirectX is C++.  Either of
> those is an advantage or disadvantage depending on who you're talking to
> and the circumstances.

I think you're wrong here. DirectX is not C++. DirectX is COM, and then is C
compatible. However it have C++ wrappers to ease the syntax. The main
difference I can see between OpenGL and DirectX is that DirectX is directly
including all card vendors extensions and is always up-to-date (or even in
advance) with the high-end hardware, MS is doing a lot of cooperation with
NVidia and others and is putting a lot of efforts into DirectX - very good
documentation quality , very few bugs... among either - because they
understand how much it's important to keep being THE OS for playing games
(and, by reaction, developping games...). DirectX let you also play a lot
with cards capabilities, so you can tune better your code for some specific
cards. On the other hand, OpenGL is a more abstract layer, made for a
general-usage of 3D, that does implements card extensions - such as shaders,
which are main stream now - as extensions of itself. The community process
of OpenGL have not been enough reactive in order to keep up with DirectX (as
you said : where's 2.0 ?).

Regards,
Nicolas Cannasse

-------------------
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

RE: [Caml-list] OpenGL

[Brian Hurt]

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

RE: [Caml-list] OpenGL

[skaller]

On Sun, 2004-04-11 at 16:20, Brian Hurt wrote:

> 
> 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.

LOL! Not a chance.

Give someone a shadowing engine .. and they'll immediately
add 20 light sources to their game, move to a client/server
multiplayer model, and get their artists to render images
in 10 times more detail.

So what if the card can draw shadows in zero time?
I mean, there has to be some way to obsolete my 
game box as fast as possible...

-- 
John Skaller, mailto:skaller@users.sf.net
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net



-------------------
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

RE: [Caml-list] OpenGL

[Brandon J. Van Every]

Brian Hurt wrote:
> Brandon Van Every wrote:
> >
> > If you want to save time, I will tell you the obvious:
> > Java3D sucked,
>
> What about it sucked, was what I was trying to elicit. [...]
>
> Hmm.  Just found out that Sun recently laid off the last two
> programmers working on Java3D:

Given those results, I think a better question is if there's a
successful 3D API for a GC language out there somewhere.  By
'successful' I mean people have done some large stuff with it, not just
getting to the "hey guys I've got a wrapper" stage.  This I don't know.
All the 3D engines that have made real progress and are commercially
viable seem to be C++, but possibly I have restricted my attention,
having found Nebula.  In any event, 3D graphics guys are overwhelmingly
C++ performance tweakers.

> > but I've never seen hard numbers.
>
> That means you haven't looked.
>
> I follow the benchmarks, which is why I phrased things the way I
> did.  Graphics performance is primarily driven by the graphics card.

I am surprised then that you said you hadn't seen hard numbers.  Those
benchmarks are hard numbers.


Cheers,                         www.indiegamedesign.com
Brandon Van Every               Seattle, WA

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



---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.643 / Virus Database: 411 - Release Date: 3/25/2004

-------------------
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

Re: [Caml-list] OpenGL

[Jon Harrop]

On Sunday 11 April 2004 10:23 am, Brandon J. Van Every wrote:
> Given those results, I think a better question is if there's a
> successful 3D API for a GC language out there somewhere.

Personally, I would much rather see emphasis placed upon an elegant, 
functional (as opposed to imperative) interface for doing graphics than one 
designed around GC. I have been unable to find any previous work on this and, 
therefore, I think there is plenty of scope for innovation.

Cheers,
Jon.

-------------------
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

Re: [Caml-list] OpenGL

[Jon Harrop]

On Sunday 11 April 2004 7:20 am, Brian Hurt wrote:
> ...
> 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.

Well, I'm writing real-time graphical programs in ocaml and, so far, I haven't 
had any problems with the GC. At one point I thought I had a serious problem 
with it, but it turned out that increasing the number of vertices in a 
display list over an unknown (to me, at least) theshold was resulting in a 4 
orders of magnitude drop in performance in the GL, nothing to do with ocaml 
or its GC.

> ...
> 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.

Although the "vast majority of heavy computation" may be done on the graphics 
card, don't forget that the relatively easy computations done on the vastly 
slower CPU in serial are just as responsible for the overall speed.

Cheers,
Jon.

-------------------
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

Re: [Caml-list] OpenGL

[Issac Trotts]

On Thu, Apr 08, 2004 at 11:25:33PM +0100, Jon Harrop wrote:
> On Thursday 08 April 2004 9:19 pm, Issac Trotts wrote:
> > What it is about lablGL that means it can never be made to work?
> 
> I'll give some background information first. The GLU tesselator accepts a 
> polygon (as a list of contours) and a winding rule. It uses this to generate 
> a set of non-overlapping OpenGL primitives (triangles, triangle fans and 
> triangle strips) which cover the regions in the contours which are deemed to 
> be interior according to the winding rule.
[...]

My GLU binding is more general than the one in the LablGL distro.  It's
in the LablGL CVS repository.  You might ask Jacques Garrigue for
access.

> > That one is called camlgl, which seems to have been abandoned.
> 
> That's the one, yes. I've never used it...
> 
> > I already wrote a binding for GLU using CamlIDL, but I don't recommend
> > it since GLU relies so much on callbacks.  It would probably be better to
> > wrap Jonathan Shewchuck's Triangle code:
> >
> >     http://www-2.cs.cmu.edu/~quake/triangle.html
> 
> That is certainly a very nice looking library, but it seems to be solving a 
> related but substantially different problem (Delaunay triangulation vs 
> polygon tesselation)?

Shewchuck's program does constrained Delaunay triangulation, so it can
tesselate a large class of polygons.  In order to get triangle fans and
strips, you'd have to run a triangle strip generator on the output.

-- 
Issac Trotts
http://mallorn.ucdavis.edu/~ijtrotts
(w) 530-757-8789

-------------------
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

Re: [Caml-list] OpenGL

[Anil Madhavapeddy]

On Wed, Apr 07, 2004 at 09:07:39AM -0700, Issac Trotts wrote:
> On Thu, Apr 08, 2004 at 04:11:25PM +0100, Jon Harrop wrote:
> > 
> > On Thursday 08 April 2004 3:53 pm, John Goerzen wrote:
> > > I'm just saying that I think that
> > > "Ocaml has a robust set of tools for real-world uses" is inaccurate.
> > 
> > Yes, I agree. Personally, I would like to see a carefully thought out 
> > interface to OpenGL, GLU etc. They are very stable and mature libraries which 
> > were superbly thought out but, unfortunately, suffer from a low-level API 
> > which sometimes ends up in a lot of "void *" raw data getting passed around 
> > and kept. I do not know of an existing, elegant interface to these libraries 
> > in any functional language and, IMHO, it would be a big but very worthwhile 
> > undertaking to create such an interface. I think this would make a good PhD 
> > for someone...
> 
> Did you look at LablGL?

LablGL provides an almost 1-1 mapping between the C and OCaml OpenGL
calls... it works really well when working with the simpler bits of
OpenGL, but it rapidly descends into using a bunch of raw types for
things like the GLU tessellator.

Still, Ocaml/LablGL is a great combination for me so far - drawing
individual scene elements functionally, and rendering them with
'imperative glue' seems a natural fit for Ocaml.

-- 
Anil Madhavapeddy                                 http://anil.recoil.org
University of Cambridge                          http://www.cl.cam.ac.uk

-------------------
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