From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@sympa.inria.fr Delivered-To: caml-list@sympa.inria.fr Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by sympa.inria.fr (Postfix) with ESMTPS id 474AD7EE51 for ; Thu, 9 May 2013 22:27:37 +0200 (CEST) Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of monnier.florent@gmail.com) identity=pra; client-ip=209.85.219.42; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="monnier.florent@gmail.com"; x-sender="monnier.florent@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of monnier.florent@gmail.com designates 209.85.219.42 as permitted sender) identity=mailfrom; client-ip=209.85.219.42; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="monnier.florent@gmail.com"; x-sender="monnier.florent@gmail.com"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of postmaster@mail-oa0-f42.google.com) identity=helo; client-ip=209.85.219.42; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="monnier.florent@gmail.com"; x-sender="postmaster@mail-oa0-f42.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArUEAAEGjFHRVdsqlGdsb2JhbABSFoMosUSOSHIIFg4BAQEBBwsLCRIqgh8BAQQBQAEbHQEDAQsGBQs7IgERAQUBHAYuh14BAwkGDKEOjD2CfoRbChknDViHRAEFDI5pMweDVQOXLIEmjioWKYQ3Og X-IPAS-Result: ArUEAAEGjFHRVdsqlGdsb2JhbABSFoMosUSOSHIIFg4BAQEBBwsLCRIqgh8BAQQBQAEbHQEDAQsGBQs7IgERAQUBHAYuh14BAwkGDKEOjD2CfoRbChknDViHRAEFDI5pMweDVQOXLIEmjioWKYQ3Og X-IronPort-AV: E=Sophos;i="4.87,642,1363129200"; d="scan'208";a="13742150" Received: from mail-oa0-f42.google.com ([209.85.219.42]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/RC4-SHA; 09 May 2013 22:27:36 +0200 Received: by mail-oa0-f42.google.com with SMTP id i10so4079101oag.29 for ; Thu, 09 May 2013 13:27:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=s7aw0nWOB6vLp/XLbWWTgMTaDiQbXIG1eKcFnzBowF4=; b=UmDGb9M/QMKl+Jts1CTOMRs5E5Se4gkFi0slNAD7hVFU/m8AQapP6MDxfDnN5dECMu TgUaFqLeBO5kKSFkpgPm2OmqcDr8FSKI4WInmKnpWzdKWmOhJfz9RqqTjNEgGjWFKa9V NW/uKVDRA/x8PAtYzgzvkuvWXEPjjzK+FRCzfHcwIMdrNGTrk/q3VnQdMXeqrn0urXdO 7epYX0l41Qc5rVuWt2cW2GJ8RKJ4U6b9mlS4xQANo1/dJ6S67Cc6yS6pRIlaTV7/mOjQ HGGnGISFK5n4d9mlozPxc/KuRBY3AHsfGKggNBcGvdwVD63U7d9axVvs7dfiUQ/fdO48 JGiw== MIME-Version: 1.0 X-Received: by 10.60.16.69 with SMTP id e5mr5207840oed.46.1368131254682; Thu, 09 May 2013 13:27:34 -0700 (PDT) Received: by 10.60.3.168 with HTTP; Thu, 9 May 2013 13:27:34 -0700 (PDT) In-Reply-To: References: <5WRK1WTA-CFLT-K2D2-HI4C-UBS0MHNSFIAY@cs.ucy.ac.cy> <5189B929.2030808@riken.jp> Date: Thu, 9 May 2013 22:27:34 +0200 Message-ID: From: Florent Monnier To: =?ISO-8859-1?Q?Daniel_B=FCnzli?= Cc: ocaml-opengl , Caml List Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Validation-by: monnier.florent@gmail.com Subject: Re: [ocaml-opengl] [Caml-list] standard 3d vector library in OCaml Hello Daniel, 2013/5/9, Daniel B=FCnzli: >> 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 im= age > 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 no= w, > it still needs a final code review though and one or two function names m= ay > 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 bec= ome > 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.ht= ml http://www.linux-nantes.org/%7Efmonnier/ocaml/easing/doc-2013-04-05/Timed.h= tml http://www.linux-nantes.org/%7Efmonnier/ocaml/easing/doc-2013-05-09/Ease.ht= ml http://www.linux-nantes.org/%7Efmonnier/ocaml/easing/doc-2013-05-09/Timed.h= tml 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 --