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

[Anthony Tavener <anthony.tavener@gmail.com>]

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