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

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

[Nickolay Semyonov-Kolchin]

Announcement CamlGL --- OpenGL bindings for Objective Caml

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

-----------------------------------------------------------
WARNING

this release was tested under RH8, gcc3.2, NVidia GL 41.91

-----------------------------------------------------------
Details
=======
1. CamlGL loads GL library at runtime. So you can switch between Native/Mesa
without recompiling. (This is currently not supported under Windows)

Gl.set_gl_lib "libGL.so.1"

2. CamlGL uses "plain" naming conversion for functions and enums. 

glEnable cgl_lighting; (* glEnable(GL_LIGHTING); *)
glVertex3f 1.0 0.0 0.0; (* glVertex3f(1.0f,1.0f,1.0f); *)
glColor3b 255 255 255; (* glColor3b(255,255,255); *)

3. CamlGL uses Bigarray module for array representation.

let a = Hgl.ba_float_init [|1.0;0.0;3.0|] in
glVertex3fv a;
-------------------------------------------------------------
Notes
======
1. GL_ALL_ATTRIB_BITS

GL_ALL_ATTRIB_BITS declared as 0xFFFFFFFF in NVidia header.
Mesa defines it as 0xFFFF.
We are using Mesa constant.

2. GL_ALL_CLIENT_ATTRIB_BITS and GL_CLIENT_ALL_ATTRIB_BITS

Declared as 0xFFFFFFFF. We are using 0x3FFFFFFF.

3. Functions with standard type string

glGetString: int -> string
glLoadProgramNV: int -> int -> int -> string -> unit
glProgramNamedParameter4{fd}[v]NV: int -> int -> string -> ... -> unit
glGetProgramNamedParameter{fd}vNV: int -> int -> string -> 'a -> unit
glProgramStringARB: int -> int -> int -> string -> unit

4. GL_NV_vertex_array_range 

VAR depends on two window system specific functions:
- {glX,wgl}AllocateMemoryNV
- {glX,wgl}FreeMemoryNV

We provide standard bindings for them:
val _glAllocateMemoryNV: int -> float -> float -> float -> tbabyte
val _glFreeMemoryNV: tbaabstract -> unit

See example in demos/simple/vatest.

5. Unimplemented

glMultiModeDrawElementsIBM
glVertexPointerListIBM
glTexCoordPointerListIBM
glNormalPointerListIBM
glIndexPointerListIBM
glFogCoordPointerListIBM
glEdgeFlagPointerListIBM
glSecondaryColorPointerListIBM
glColorPointerListIBM
glTexCoordPointervINTEL
glColorPointervINTEL
glNormalPointervINTEL
glVertexPointervINTEL
glReplacementCodePointerSUN
glGetPointerv
glMultiDrawElements
glGetVertexAttribPointervARB
glMultiDrawElementsEXT
glGetPointervEXT
glGetVariantPointervEXT
glGetVertexAttribPointervNV
glLoadIdentityDeformationMapSGIX
glDeformSGIX

6. Extensions not supported

ARB_pbuffer 
ARB_render_texture
-------------------
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] Announce: camlgl - OpenGL bindings for OCaml

[Sven Luther]

On Fri, Dec 20, 2002 at 03:46:12PM +0500, Nickolay Semyonov-Kolchin wrote:
> Announcement CamlGL --- OpenGL bindings for Objective Caml
> 
> http://www.sf.net/projects/camlgl

This is another implementation than lablgl, right ?

So, now we have 2 (possibly 3) OpenGL implmentation for ocaml, the same
situation we had some time ago with labltk and camltk.

Would you care to comment about the difference between your bindings and
the lablgl bindings, the reason which made you implement a new
alternative and the problems there would be in unifying both
implementations ?

> 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 it also be possible to use it with lablgtk, do you think ?

Friendly,

Sven Luther
-------------------
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] Announce: camlgl - OpenGL bindings for OCaml

[Nickolay Semyonov-Kolchin]

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

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

[Jacques Garrigue]

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

[Caml-list] Summary: LablGL vs CamlGL

[Nickolay Semyonov-Kolchin]

On Wednesday 25 December 2002 07:37, Jacques Garrigue wrote:

Now we have comments from both authors.

Summary:
- LablGL is type-safe, CamlGL is not.
- LablGL support OGL 1.1, CamlGL support OGL 1.4 with extensions (most 
important: shaders [NV,ATI,ARB]).
- LablGL support GLU 1.2, CamlGL has no GLU support.
- LablGL is better for beginners, CamlGL is better for people with prior OGL 
knowledge.
- LablGL uses Raw module, CamlGL uses Bigarray.
- LablGL support all Ocaml platforms, CamlGL support only Windows (VC) and 
Linux.
- LablGL is better tested.

Everything mentioned?

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

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

[Christophe Raffalli]

[-- Attachment #1: Type: text/plain, Size: 1192 bytes --]


There is one little problem with lablGL:

The height functions provided for GlDraw.normal and GlDraw.vertex necessarely 
uses boxed float.
You should add (I will do it for myself very soon) direct access to the GL 
function to be able to benefit from the optimization of OCaml for unboxed float.

This is important for this two function and may be a few others (GlDraw.begins 
and GlDraw.ends, ...) which are used very often and where the optional 
arguments and the call to the stub code may cost too much.

But I think it is a good idea to keep a type-safe interface as much as possible 
and put the unsafe fast call in a GlUnsafe module !

I learned GL using LablGl and it is very well suited for that. Much better than 
raw C or C++.


-- 
Christophe Raffalli
Université de Savoie
Batiment Le Chablais, bureau 21
73376 Le Bourget-du-Lac Cedex

tél: (33) 4 79 75 81 03
fax: (33) 4 79 75 87 42
mail: Christophe.Raffalli@univ-savoie.fr
www: http://www.lama.univ-savoie.fr/~RAFFALLI
---------------------------------------------
IMPORTANT: this mail is signed using PGP/MIME
At least Enigmail/Mozilla, mutt or evolution
can check this signature
---------------------------------------------

[-- Attachment #2: Type: application/pgp-signature, Size: 252 bytes --]