[ocaml-opengl] [Caml-list] standard 3d vector library in OCaml

[Florent Monnier]

Hello Daniel,

2013/5/9, Daniel Bünzli:
>> 2013/5/8, Francois Berenger:
>> > Hello,
>> >
>> > Is there a standard library for this purpose?
>
> It's not standard, unreleased and I hate to pre-announce but in the
> following months I plan to release Gg, a module that gives you basic types
> for 2D and 3D computer graphics; vectors, matrices, quaternions,
> axis-aligned boxes, colors and raster data.

This is always christmas when you release something, thx :)

> Vectors and matrices are abstract but represented internally as records of
> floats. This allows to pass them directly to C functions that take double
> arrays and avoids bounds checking in OCaml code.

I found this trick in the ode bindings by Richard Jones.
In my opinion it's a good trick for matrices.
But I don't like it for xy or xyz triples. I prefer tuples for this
because it makes it more easy to exchange data between different ocaml
components and modules. For these I usually prefer something easy to
exchanges between different ocaml modules than something easy to
exchange with C. Because xy / xyz values are used a lot in the
high-level parts. And usually, in most parts of the code I use it
without open the tuple content, so the representation is not very
important except to make it easy to exchange without dependencies. So
this is why I prefer (float * float) and (float * float * float).

But this is only my taste. I don't know how other people manage this,
because there is not much code to read around for this kind of things.

>                                                   The memory layout of
> matrices is also the one expected by OpenGL.

It's great to have convenience like this.

> Except for the Raster module --- metadata for bigarrays to allow libraries
> to share raster data without depending on each other e.g. an OpenCV or image
> loading library and an OpenGL library ---

I've also started to play with OpenCV.
If you have things to share in OCaml I would enjoy to see it, even if
it's alpha.

>                                            the module is pretty stable now,
> it still needs a final code review though and one or two function names may
> change.

It looks quite close to a release.

> The current documentation of gg can be found here [1],

I appreciate the grey background.
With floaters in the eyes the darker is the better.
What is the license of your CSS, is it the same than your libs?
But if I build the docs from the sources it falls back to default
ocamldoc's css with plain white uncomfortable background.
Also how did you choosed this value of grey? Is it just your tastes,
or is it for a particular reason? I used very dark greys in the past
and some people sent me emails to ask me lighter background greys. Is
it compromise between people who like plain white and people who
prefer darker backgrounds?

>                                                        the code can be
> browsed here [2]. It can also be installed via the erratique-unstable opam
> repo:
>
>     opam repo add erratique-unstable
> http://erratique.ch/software/opam-unstable
>     opam update
>     opam install gg

Opam rules! [4]

> But I'd advise you not to that until the next release of opam because of
> this bug [3] which while harmless makes your `opam update` experience become
> unpleasant (you have to do a `opam remove gg`, before being able to `opam
> update`).
>
> Comments are welcome.

I noticed the mix functions for each types
mix x y t is the linear interpolation x +. t *. (y -. x)
It is not optimised for the case that we would apply it at each frame
and that (y -. x) will be the same all the time.
I have my own module for interpolation where it is not optimised too.
But I'm thinking to change it. Maybe some solution could be used to do
it in an elegant way that would not complicate the code too much.

Also you're providing only linear interpolation.
Is it that you're not using easing, or is it that you're using another
module for it?
If it's external I guess you're using the map functions to apply it.
I've started a small module for this, but I'm unsure what would be the
more convenient interface. Here are the interfaces of two different
snapshots:

http://www.linux-nantes.org/%7Efmonnier/ocaml/easing/doc-2013-04-05/Ease.html
http://www.linux-nantes.org/%7Efmonnier/ocaml/easing/doc-2013-04-05/Timed.html

http://www.linux-nantes.org/%7Efmonnier/ocaml/easing/doc-2013-05-09/Ease.html
http://www.linux-nantes.org/%7Efmonnier/ocaml/easing/doc-2013-05-09/Timed.html

Comments are wellcome.

Another thing that is only a question of taste, I would enjoy if there
would be aliases for the functions Size*.d w h with words entirely.
Sometimes the more readable is the shorter, some other times the
entire word will help understand what it is. So with aliases we can
choose what is the more pertinent for the situation.

Your new lib doesn't look promising, in fact it's already a must have!
(just like your other libs;)

> Best,
>
> Daniel
>
>
> [1] http://erratique.ch/software/gg/doc/Gg.html
> [2] https://github.com/dbuenzli/gg/
> [3] https://github.com/OCamlPro/opam/issues/552

[4] Well at least on Linux, in my Cygwin it doesn't work

--