Re: [Caml-list] Announce: camlgl - OpenGL bindings for OCaml

[Jacques Garrigue <garrigue@kurims.kyoto-u.ac.jp>]

Hello,

If I may be allowed some comment, as LablGL author I don't think that
LablGL is a high-level library.
And your example shows it: the codes in C, LablGL and CamlGL are
identical (up to identifier renaming)!

The main difference is that LablGL is type-safe, and that OpenGL and
CamlGL do not seem to provide any such security. My feeling is that
OpenGL was designed by Lisp programmers: it is very high level (for an
hardware interface), but there is no notion of static typing. Half of
the functions take symbolic parameters, with a handful of valid
values (explained in the manpages), but the typing allows you to pass
anything. It becomes even more interesting when there are dependencies
between parameters: according to the synmbolic value of the first
parameter, the number (and type) of required values in the array
passed as second parameter changes.  LablGL provides safe typing for
all these cases.

On the other hand, the main weakness of LablGL is that I am no 3D
programmer, and that it was done 5 years ago: almost all of openGL and
GLU 1.2 is supported, but openGL seems to have improved since.
Similarly, the legacy Raw module predates Bigarray. Since it is not
completely subsumed by Bigarray, I never went around to replace it by
Bigarray. LablGTK provides higher-level wrappers, which let you see
any memory chunk (be it a biggaray, a Raw.t or a string) in a uniform
way.

Concerning function names, there is a one-to-one mapping in the README
file: the only intent was to to split GL in a number of more
understandable modules, grouping functions by categories. I hoped it
would help beginners,but it seems to distub hardcore 3D programmers.

Also, since levels are similar, it would not be easy to move
LablGL on top of your library: all the marshalling is already done on
the C side, doing it on the ML side would mean a full rewrite.
But having GL 1.4 and extensions would certainly be nice.

Cheers,

Jacques Garrigue

From: Nickolay Semyonov-Kolchin <snob@snob.spb.ru>
> On Friday 20 December 2002 20:28, Sven Luther wrote:
> > >
> > > http://www.sf.net/projects/camlgl
> > >
> > > Key Features:
> > > - Full OpenGL 1.4 support
> > > - All window system independent ARB extensions supported
> > > - All published NVidia extensions supported (including NV30)
> > > - All ATI extensions supported
> > > - Windows and Linux version
> > > - GLFW bindings
> > > - unsupported Glut and SDL bindings
> >
> > Would you care to comment about the difference between your bindings and
> > the lablgl bindings, 
> 
> Unsorted comparison:
> - LablGL is a high level library build on top of the GL. 
> - CamlGL provides direct GL bindings.
> ---------------------------------------------
> /* C code */
> glMatrixMode(GL_MODELVIEW);
> glPushMatrix();
> glRotatef(1.0f,0.0f,2.0f,0.0f);
> glVertex3f(1.0f,1.0f,1.0f);
> 
> (* LablGL version *)
> GlMat.mode `modelview;
> GlMat.push ();
> GlMat.rotate ~angle:1.0 ~y:2.0 ();
> GlDraw.vertex ~x:1.0 ~y:1.0 ~z:1.0 ();
> 
> (* CamlGL version *)
> open Gl
> glMatrixMode cgl_modelview;
> glPushMatrix ();
> glRotatef 1.0 0.0 2.0 0.0;
> glVertex3f 1.0 1.0 1.0;
> ---------------------------------------------
> - LablGL (afaik) support all Ocaml enironments
> - CamlGL (at present time) support only Linux and Windows (VC version)
> 
> - LablGL implements only a subset of OGL functions.
> - CamlGL has full OGL support (with two exceptions)
> glGetPointerv and glMultiDrawElements are not supported.
> 
> - LablGL has partitial GLU support
> - CamlGL has no GLU support (and will never have)
> 
> - LablGL is a safe library
> - CamlGL may produce "unstable" behaviour
> I.e. if glGenLists or glGenTextures return value bigger than Caml max_int --- 
> you are doomed. (Not possible with current NVidia & ATI drivers). You can get 
> a segfault by giving incorrect array bounds for GL data, and so on. 
> 
> - CamlGL uses dynamic function loading which can cause trouble under Windows 
> enironment. (This is poor theory)
> 
> - CamlGL produces very big executable files: ~700K under Linux, ~400K under 
> Windows. (I don't care about that)
> 
> - CamlGL programs can be much faster than LablGL (VA, VAR, VAO, VP, etc)
> 
> - CamlGL can be integrated with existing C libraries without any trouble. 
> (Bigarrays)
> 
> - CamlGL can be used for modern 3d graphics. (Vertex shaders, Pixel shaders, 
> Multitexturing, VAR/VAO)
> 
> > the reason which made you implement a new
> > alternative 
> 
> LablGL has no support for GL extensions and uses syntax very different from 
> normal GL. 
> 
> >and the problems there would be in unifying both
> > implementations ?
> 
> LablGL can be implemented on top of my library. 
> 
> > Would it also be possible to use it with lablgtk, do you think ?
> >
> 
> Yes, I'am using it with lablgtk. I can send you description (cryptic) how this 
> can be done. 
> 
> Comments, suggestions are always welcome.
> 
> Nickolay
-------------------
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