[Caml-list] Pros and cons of different GL bindings ?

[Caml-list] Pros and cons of different GL bindings ?

[Thomas Braibant]

Hi list,

There exists at least 3 different bindings for openGL in OCaml (and maybe more):

- LablGL http://www.math.nagoya-u.ac.jp/~garrigue/soft/olabl/lablgl.html
- glMLite http://www.linux-nantes.org/~fmonnier/ocaml/GL/
- glcaml http://glcaml.sourceforge.net/

For the untrained eye, it is difficult to pick one. Could someone sum
up the pros and cons of each of these libs ?

With best regards,
Thomas Braibant

Re: [Caml-list] Pros and cons of different GL bindings ?

[Ethan Burns]

On Wednesday, April 27, 2011 6:30:25 AM UTC-4, Thomas Braibant wrote:

I have only really tried glMLite (and even then I only used it to draw simple rectangles using vertex buffers) but I did also look into the others a tiny bit.  Here is what I found:

> - LablGL http://www.math.nagoya-u.ac.jp/~garrigue/soft/olabl/lablgl.html

This appears to be the 'default' OpenGL for OCaml.  It is suppose to work with lablgtk (I don't know if the others do) but it does not seem to have support for shaders and some later OpenGL funtionality.

> - glMLite http://www.linux-nantes.org/~fmonnier/ocaml/GL/

Supports the newer OpenGL functionality (GLSL shaders and vertex buffers).  My friend had a difficult time getting it to compile/work on OSX but with some minor changes I believe that he eventually got it working. 

> - glcaml http://glcaml.sourceforge.net/

glcaml seems to be a set of automatically generated stubs.  It seems to support some of the latest OpenGL but the interface is automatically generated so it doesn't have a very OCaml-ish feel to it.

Best,
Ethan

Re: [Caml-list] Pros and cons of different GL bindings ?

[Alan Schmitt]

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

On 27 avr. 2011, at 15:17, Ethan Burns wrote:

> Supports the newer OpenGL functionality (GLSL shaders and vertex buffers).  My friend had a difficult time getting it to compile/work on OSX but with some minor changes I believe that he eventually got it working.

I also managed to get it working on OS X (thanks to help from this list). I sent a patch to Florent but as far as I know it has not been integrated yet. If anyone needs this patch to the Makefile, I can send it.

Alan

PS: your message has a "Reply-To" set to the google groups. Does it mean that replies which don't change the "To" address won't make it to the list?

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 495 bytes --]

Re: [Caml-list] Pros and cons of different GL bindings ?

[Andrei Formiga]

I worked a bit on this too, the newest version of glMLite from the SVN
repository should compile on OSX without trouble. It still does not
put the generated libraries in the right places if you use
GODI/findlib though.

My plan is to adapt glMLite to use OASIS with ocamlbuild and simplify
the process, but I haven't had the time lately to finish the work on a
OASIS build system for it.

-- 
[]s, Andrei Formiga


On Wed, Apr 27, 2011 at 10:27 AM, Alan Schmitt
<alan.schmitt@polytechnique.org> wrote:
> On 27 avr. 2011, at 15:17, Ethan Burns wrote:
>
>> Supports the newer OpenGL functionality (GLSL shaders and vertex buffers).  My friend had a difficult time getting it to compile/work on OSX but with some minor changes I believe that he eventually got it working.
>
> I also managed to get it working on OS X (thanks to help from this list). I sent a patch to Florent but as far as I know it has not been integrated yet. If anyone needs this patch to the Makefile, I can send it.
>
> Alan
>
> PS: your message has a "Reply-To" set to the google groups. Does it mean that replies which don't change the "To" address won't make it to the list?

Re: [Caml-list] Pros and cons of different GL bindings ?

[Anthony Tavener]

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

Ethan's summary is good. I'll elaborate a bit on glcaml...

I use glcaml, but don't recommend it in general. There are two reasons I
chose it: 1. It looks like OpenGL, so my familiarity with it directly
translates... the only differences are lowecase GL constants and no
parentheses around arguments. 2. It (kind-of) supports features like
shaders.

What I mean by "kind-of" is that the bindings are broken for a lot of
lesser-used features. I've been maintaining my own modifications to support
features I need (same with sdlcaml)... though I recently decided I should
follow OpenGL 4 (basically the same as OpenGL ES 2), which strips the
interface down to a minimal set heavily reliant on shaders. This is turning
into "yet another set of bindings".

I know I tried glMLite... but can't remember what problems I encountered,
and I did encounter problems which led me to settle on glcaml.

Also, there is one other binding I know, by Jeffrey Scofield, for OpenGL ES
1, and he uses this for iPhone development:
http://psellos.com/ocaml/lablgles-build.html


Summary:

If you don't need shaders: LablGL

If you want to do OpenGL ES 1.x (mobile device, for example): LablGLES

If you need shaders: glcaml or glMLite


Oh, if anyone knows of someone making OpenGL 4 / OpenGL ES 2 bindings...
please speak up! :)

 -Tony


On Wed, Apr 27, 2011 at 7:17 AM, Ethan Burns <burns.ethan@gmail.com> wrote:

> On Wednesday, April 27, 2011 6:30:25 AM UTC-4, Thomas Braibant wrote:
>
> I have only really tried glMLite (and even then I only used it to draw
> simple rectangles using vertex buffers) but I did also look into the others
> a tiny bit.  Here is what I found:
>
> > - LablGL http://www.math.nagoya-u.ac.jp/~garrigue/soft/olabl/lablgl.html
>
> This appears to be the 'default' OpenGL for OCaml.  It is suppose to work
> with lablgtk (I don't know if the others do) but it does not seem to have
> support for shaders and some later OpenGL funtionality.
>
> > - glMLite http://www.linux-nantes.org/~fmonnier/ocaml/GL/
>
> Supports the newer OpenGL functionality (GLSL shaders and vertex buffers).
>  My friend had a difficult time getting it to compile/work on OSX but with
> some minor changes I believe that he eventually got it working.
>
> > - glcaml http://glcaml.sourceforge.net/
>
> glcaml seems to be a set of automatically generated stubs.  It seems to
> support some of the latest OpenGL but the interface is automatically
> generated so it doesn't have a very OCaml-ish feel to it.
>
> Best,
> Ethan
>
> --
> Caml-list mailing list.  Subscription management and archives:
> https://sympa-roc.inria.fr/wws/info/caml-list
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs
>
>

[-- Attachment #2: Type: text/html, Size: 3856 bytes --]

Re: [Caml-list] Pros and cons of different GL bindings ?

[rixed]

There is also my own pet binding (glop project on gitorious) if you
need an abstraction layer above both OpenGL or GLES, but I don't
recommend it since you would be the only user :-)

> Oh, if anyone knows of someone making OpenGL 4 / OpenGL ES 2 bindings...
> please speak up! :)

The problem with shaders is that it seams a very unpleasant(*) language
is imposed on us. If good old OpenGL was a brilliant abstraction
between a program and an hypothetical hardware, recent OpenGL versions are
more like an API to access proprietary hardware, thus it is much less
exciting to bind ocaml with this thing.

(*): at least from the point of view of an ocaml programmer

Re: [Caml-list] Pros and cons of different GL bindings ?

[David Sheets]

You could also compile your OCaml to Javascript and use WebGL. We've
not yet written the ocamljs bindings to mimic lablgles but the
javascript shim is fairly small, "native" (not autogen'ed bindings)
and simple. The business logic stays in OCaml. We will soon be
tightening the ocamljs/closure-compiler toolchain to get even smaller
and faster js files.

You can see some early results from this design at http://ashimagames.com/

We are actively investigating compiling a strict OCaml subset
(directly semantically translatable to recursion-less GLSL) to
GLSL/Javascript for numeric library portability and algebraic
simplification of shaders.

If you are interested in this architecture, let me know and I can
clean up and send you the closure-compiler externs files we use to
escape the minification of the WebGL interface. If you require ocamljs
assistance, I would also be happy to help with that.

Best,

David Sheets
Ashima Arts

On Wed, Apr 27, 2011 at 10:16 AM,  <rixed@happyleptic.org> wrote:
> There is also my own pet binding (glop project on gitorious) if you
> need an abstraction layer above both OpenGL or GLES, but I don't
> recommend it since you would be the only user :-)
>
>> Oh, if anyone knows of someone making OpenGL 4 / OpenGL ES 2 bindings...
>> please speak up! :)
>
> The problem with shaders is that it seams a very unpleasant(*) language
> is imposed on us. If good old OpenGL was a brilliant abstraction
> between a program and an hypothetical hardware, recent OpenGL versions are
> more like an API to access proprietary hardware, thus it is much less
> exciting to bind ocaml with this thing.
>
> (*): at least from the point of view of an ocaml programmer
>
> --
> Caml-list mailing list.  Subscription management and archives:
> https://sympa-roc.inria.fr/wws/info/caml-list
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs
>
>

Re: [Caml-list] Pros and cons of different GL bindings ?

[rixed]

-[ Wed, Apr 27, 2011 at 10:46:21AM -0700, David Sheets ]----
> We are actively investigating compiling a strict OCaml subset
> (directly semantically translatable to recursion-less GLSL) to
> GLSL/Javascript for numeric library portability and algebraic
> simplification of shaders.

I really like the idea of compiling an ocaml subset into GLSL but I
don't see why the very same compiler should be limited to webgl. Isn't
webgl using the same shading language than stock opengl ?

Re: [Caml-list] Pros and cons of different GL bindings ?

[David Sheets]

On Wed, Apr 27, 2011 at 1:55 PM,  <rixed@happyleptic.org> wrote:
> I really like the idea of compiling an ocaml subset into GLSL but I
> don't see why the very same compiler should be limited to webgl. Isn't
> webgl using the same shading language than stock opengl ?

Sorry if I was unclear in my earlier message. The compiler will not be
limited to webgl; one could use the same shaders (perhaps after
stripping comments) in any OpenGL ES 2 or later implementation. Our
current interests are for typed tagless interpreters/emitters
targeting ESSL and Javascript. An emitter for desktop GL shaders (or
DirectX shaders) should not be difficult after this is done.

Re: [Caml-list] Pros and cons of different GL bindings ?

[Jacques Garrigue]

On 2011/04/28, at 1:24, Anthony Tavener wrote:

> Ethan's summary is good. I'll elaborate a bit on glcaml...
> 
> I use glcaml, but don't recommend it in general. There are two reasons I chose it: 1. It looks like OpenGL, so my familiarity with it directly translates... the only differences are lowecase GL constants and no parentheses around arguments. 2. It (kind-of) supports features like shaders.
> 
> What I mean by "kind-of" is that the bindings are broken for a lot of lesser-used features. I've been maintaining my own modifications to support features I need (same with sdlcaml)... though I recently decided I should follow OpenGL 4 (basically the same as OpenGL ES 2), which strips the interface down to a minimal set heavily reliant on shaders. This is turning into "yet another set of bindings".
> 
> I know I tried glMLite... but can't remember what problems I encountered, and I did encounter problems which led me to settle on glcaml.
> 
> Also, there is one other binding I know, by Jeffrey Scofield, for OpenGL ES 1, and he uses this for iPhone development:
> http://psellos.com/ocaml/lablgles-build.html
> 
> 
> Summary:
> 
> If you don't need shaders: LablGL
> 
> If you want to do OpenGL ES 1.x (mobile device, for example): LablGLES
> 
> If you need shaders: glcaml or glMLite

Actually, LablGL has some shader support, provided by Florent Monnier.
It has been in CVS for more than a year (file src/glShader.ml), but somehow
I never came around to make a new release.
I'm really sorry for the inconvenience.

If some people could test this code, this would be most helpful, and I could
make a release in a few weeks.

Jacques Garrigue

Re: [Caml-list] Pros and cons of different GL bindings ?

[Florent Monnier]

Le jeudi 28 avril 2011 02:32:06, Jacques Garrigue a écrit :
> On 2011/04/28, at 1:24, Anthony Tavener wrote:
> > Ethan's summary is good. I'll elaborate a bit on glcaml...
> > 
> > I use glcaml, but don't recommend it in general. There are two reasons I
> > chose it: 1. It looks like OpenGL, so my familiarity with it directly
> > translates... the only differences are lowecase GL constants and no
> > parentheses around arguments. 2. It (kind-of) supports features like
> > shaders.
> > 
> > What I mean by "kind-of" is that the bindings are broken for a lot of
> > lesser-used features. I've been maintaining my own modifications to
> > support features I need (same with sdlcaml)... though I recently decided
> > I should follow OpenGL 4 (basically the same as OpenGL ES 2), which
> > strips the interface down to a minimal set heavily reliant on shaders.
> > This is turning into "yet another set of bindings".
> > 
> > I know I tried glMLite... but can't remember what problems I encountered,
> > and I did encounter problems which led me to settle on glcaml.
> > 
> > Also, there is one other binding I know, by Jeffrey Scofield, for OpenGL
> > ES 1, and he uses this for iPhone development:
> > http://psellos.com/ocaml/lablgles-build.html
> > 
> > 
> > Summary:
> > 
> > If you don't need shaders: LablGL
> > 
> > If you want to do OpenGL ES 1.x (mobile device, for example): LablGLES
> > 
> > If you need shaders: glcaml or glMLite
> 
> Actually, LablGL has some shader support, provided by Florent Monnier.
> It has been in CVS for more than a year (file src/glShader.ml), but somehow
> I never came around to make a new release.
> I'm really sorry for the inconvenience.
> 
> If some people could test this code, this would be most helpful, and I
> could make a release in a few weeks.
> 
> Jacques Garrigue

I take the opportunity of this thread to ask to the users what 
they would prefer about this module (GlShader).
This is about all the functions which has a "count" parameter in the OCaml 
interface (and which wrap a C function which ends with the letter "v" for 
vertex probably)

http://camlcvs.inria.fr/cgi-bin/cvsweb/bazar-
ocaml/lablGL/src/glShader.ml?rev=1.1;content-type=text%2Fx-cvsweb-markup

http://camlcvs.inria.fr/cgi-bin/cvsweb/bazar-
ocaml/lablGL/src/ml_shader.c?rev=1.1;content-type=text%2Fx-cvsweb-markup

The array data are currently provided to these functions in a *flatten* way,
and the question is maybe the users would prefer a more high-level interface?
A more high-level way would be an array of array or an array of tuples.

An array of tuples would be the safer but would probably not be the more easy 
to manipulate, while a tuple is immutable.

An array of array would need to check the size of every sub-array.
With these two alternatives, the "count" parameter would not be needed 
anymore.

Please tell us what you would prefer.
___

doc for glUniform* and glUniformMatrix* :
http://www.opengl.org/sdk/docs/man/xhtml/glUniform.xml
___

external uniform4fv: location:int -> count:int -> value:float array -> unit = 
"ml_gluniform4fv"

CAMLprim value ml_gluniform4fv( value location, value ml_count, value vars )
{
    int count = Int_val(ml_count);
    int i, len = Wosize_val(vars) / Double_wosize;
    GLfloat val[len];
    if (len != (4 * count)) caml_failwith("GlShader.uniform4fv: the array size 
should be a multiple of 4");
    for (i=0; i<len; i++) {
        val[i] = Double_field(vars, i);
    }
    LOAD_FUNC(glUniform4fv, PFNGLUNIFORM4FVPROC)
    glUniform4fv( Int_val(location), count, val );
    return Val_unit;
}

==============================

external uniform_matrix4x3fv: location:int -> count:int -> transpose:bool -> 
value:float array -> unit = "ml_gluniformmatrix4x3fv"

CAMLprim value ml_gluniformmatrix4x3f(
        value location,
        value transpose,
        value mat )
{
    GLfloat val[12];
    int i, len;
    len = Wosize_val(mat) / Double_wosize;
    if (len != 12) caml_failwith("GlShader.uniform_matrix4x3f: array should 
contain 12 floats");
    for (i=0; i<12; i++) {
        val[i] = Double_field(mat, i);
    }
    LOAD_FUNC(glUniformMatrix4x3fv, PFNGLUNIFORMMATRIX4X3FVPROC)
    glUniformMatrix4x3fv(
        Int_val(location),
        1,
        Bool_val(transpose),
        val );
    return Val_unit;
}

Re: [Caml-list] Pros and cons of different GL bindings ?

[Anthony Tavener]

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

This is fantastic work and I'm glad to see LablGL getting shader support!
But I've been targeting the reduced set of OpenGL4/GLES2, so my input is
more as an observer than potential client.

The premise behind the "vector" functions (ending with v), is that if the
application already has what amounts to a contiguous array of floats in
memory, it's far more efficient to pass the pointer to where it is. This can
easily be and often is the case from C code. No so from OCaml (not that this
is bad!).

First problem in my mind, is that there's going to be a remapping anyway:
from OCaml float to "float32". Since we're unable to use the data in-place,
it might as well be in any arbitrary form the application wants, but then to
avoid two remappings the interface from LablGL must be fairly "raw" (float32
array). Alternatively, the data is structured with types useful in
application code and known by the functions.

Any way I think of a higher-level construct, it just comes back as being
more straight-forward to let the OCaml-side iterate multiple uniform_matrix
calls or map to the desired array (float32). Having a somewhat structured
input (like array of arrays, or array of tuples) is more cumbersome unless
the application-data is already in that form, which I think is unlikely. I
wouldn't work with such structures, especially not if they were being
remapped anyway. I'd prefer to have, say, a tree of my own matrix type which
I then remap once (per frame!) for OpenGL. In C, I would certainly strive
for contiguous arrays of floats so the CPU has no additional burden.

So, it seems unfortunate, but the interface being as raw as possible makes
the most sense to me. If you have LablGL matrices or something, then taking
a function which extracts those from a data structure so you can pack them
into a float array... that would be nice and high level for the
uniform_matrix*v calls.

Good luck Florent! So have you moved on from glMLite? Or does it still have
a life of it's own and you're helping to modernize LablGL?


On Mon, May 2, 2011 at 10:48 AM, Florent Monnier
<monnier.florent@gmail.com>wrote:

> Le jeudi 28 avril 2011 02:32:06, Jacques Garrigue a écrit :
> > On 2011/04/28, at 1:24, Anthony Tavener wrote:
> > > Ethan's summary is good. I'll elaborate a bit on glcaml...
> > >
> > > I use glcaml, but don't recommend it in general. There are two reasons
> I
> > > chose it: 1. It looks like OpenGL, so my familiarity with it directly
> > > translates... the only differences are lowecase GL constants and no
> > > parentheses around arguments. 2. It (kind-of) supports features like
> > > shaders.
> > >
> > > What I mean by "kind-of" is that the bindings are broken for a lot of
> > > lesser-used features. I've been maintaining my own modifications to
> > > support features I need (same with sdlcaml)... though I recently
> decided
> > > I should follow OpenGL 4 (basically the same as OpenGL ES 2), which
> > > strips the interface down to a minimal set heavily reliant on shaders.
> > > This is turning into "yet another set of bindings".
> > >
> > > I know I tried glMLite... but can't remember what problems I
> encountered,
> > > and I did encounter problems which led me to settle on glcaml.
> > >
> > > Also, there is one other binding I know, by Jeffrey Scofield, for
> OpenGL
> > > ES 1, and he uses this for iPhone development:
> > > http://psellos.com/ocaml/lablgles-build.html
> > >
> > >
> > > Summary:
> > >
> > > If you don't need shaders: LablGL
> > >
> > > If you want to do OpenGL ES 1.x (mobile device, for example): LablGLES
> > >
> > > If you need shaders: glcaml or glMLite
> >
> > Actually, LablGL has some shader support, provided by Florent Monnier.
> > It has been in CVS for more than a year (file src/glShader.ml), but
> somehow
> > I never came around to make a new release.
> > I'm really sorry for the inconvenience.
> >
> > If some people could test this code, this would be most helpful, and I
> > could make a release in a few weeks.
> >
> > Jacques Garrigue
>
> I take the opportunity of this thread to ask to the users what
> they would prefer about this module (GlShader).
> This is about all the functions which has a "count" parameter in the OCaml
> interface (and which wrap a C function which ends with the letter "v" for
> vertex probably)
>
> http://camlcvs.inria.fr/cgi-bin/cvsweb/bazar-
> ocaml/lablGL/src/glShader.ml?rev=1.1;content-type=text%2Fx-cvsweb-markup
>
> http://camlcvs.inria.fr/cgi-bin/cvsweb/bazar-
> ocaml/lablGL/src/ml_shader.c?rev=1.1;content-type=text%2Fx-cvsweb-markup
>
> The array data are currently provided to these functions in a *flatten*
> way,
> and the question is maybe the users would prefer a more high-level
> interface?
> A more high-level way would be an array of array or an array of tuples.
>
> An array of tuples would be the safer but would probably not be the more
> easy
> to manipulate, while a tuple is immutable.
>
> An array of array would need to check the size of every sub-array.
> With these two alternatives, the "count" parameter would not be needed
> anymore.
>
> Please tell us what you would prefer.
> ___
>
> doc for glUniform* and glUniformMatrix* :
> http://www.opengl.org/sdk/docs/man/xhtml/glUniform.xml
> ___
>
> external uniform4fv: location:int -> count:int -> value:float array -> unit
> =
> "ml_gluniform4fv"
>
> CAMLprim value ml_gluniform4fv( value location, value ml_count, value vars
> )
> {
>    int count = Int_val(ml_count);
>    int i, len = Wosize_val(vars) / Double_wosize;
>    GLfloat val[len];
>    if (len != (4 * count)) caml_failwith("GlShader.uniform4fv: the array
> size
> should be a multiple of 4");
>    for (i=0; i<len; i++) {
>        val[i] = Double_field(vars, i);
>    }
>    LOAD_FUNC(glUniform4fv, PFNGLUNIFORM4FVPROC)
>    glUniform4fv( Int_val(location), count, val );
>    return Val_unit;
> }
>
> ==============================
>
> external uniform_matrix4x3fv: location:int -> count:int -> transpose:bool
> ->
> value:float array -> unit = "ml_gluniformmatrix4x3fv"
>
> CAMLprim value ml_gluniformmatrix4x3f(
>        value location,
>        value transpose,
>        value mat )
> {
>    GLfloat val[12];
>    int i, len;
>    len = Wosize_val(mat) / Double_wosize;
>    if (len != 12) caml_failwith("GlShader.uniform_matrix4x3f: array should
> contain 12 floats");
>    for (i=0; i<12; i++) {
>        val[i] = Double_field(mat, i);
>    }
>    LOAD_FUNC(glUniformMatrix4x3fv, PFNGLUNIFORMMATRIX4X3FVPROC)
>    glUniformMatrix4x3fv(
>        Int_val(location),
>        1,
>        Bool_val(transpose),
>        val );
>    return Val_unit;
> }
>
>
> --
> Caml-list mailing list.  Subscription management and archives:
> https://sympa-roc.inria.fr/wws/info/caml-list
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs
>
>

[-- Attachment #2: Type: text/html, Size: 8605 bytes --]

Re: [Caml-list] Pros and cons of different GL bindings ?

[David Baelde]

Hi Florent,

This is perhaps a naive remark, but it sounds like bigarrays would
make sense here, providing structure on the caml side while keeping a
flat layout on the C side.

Cheers,

David