[Gridflow-dev] GridFlow/GL !

[Mathieu Bouchard]

On Mon, 9 Aug 2010, Claude Heiland-Allen wrote:

> I haven't tried it (yet), but is there already or are there plans for array 
> support?  The begin/vertex/end-style usage has been deprecated / 
> disrecommended in OpenGL for quite a while as far as I know

I can't even find "vertexArray" in my GL.h.

Have you looked at the new version of supercycloid.pd ? If you think that 
the speed of sending lots of points to [GEMglVertex3fv] was really a 
problem, it's probably better with [gf/gl]'s 'vertex' method, but I 
haven't measured.

The feature can be added anyway, though binaries will have to be compiled 
with a certain version, with certain consequences...

Nowadays I can compile such modules in several versions. Look at how there 
is
   gridflow-gem9292.pd_linux for a GEM earlier than 2010
   gridflow-gem9293.pd_linux for a GEM between january and may
   gridflow-gem9393.pd_linux for a GEM more recent than may 25 or something

and if there is that, then there can be multiple OpenGL modules. The PDP 
support also doesn't have to be detected by ./configure, because it's a 
separate pd_linux too.

> (though I doubt the interface will be removed in the foreseeable 
> future);

I don't understand the forward-compatible mode. It seems to me like there 
is no point removing those functions at all... especially if it means I 
have to compute rotation matrices myself or stuff... well, you can use 
[#rotatificator] and [#inner] and [#to_l] to do that, but it doesn't mean 
that anyone would enjoy it nor that there would be any point beyond being 
able to brag that it runs in "GL's forward compatible mode".

> It would seem a natural fit if you could draw from grids in that way, 
> and it has much less overhead.

Since grids got their own atom type, there could be things that use grids 
without needing a single-element message called 'grid', but this is still 
a latent feature. I'd need to redesign GRID_INLET and \grin somewhat. (How 
do I do that ?)

> Unchanging geometry could be stored on the GPU using buffer objects for 
> another potential speed boost, too.

what are display-lists for, then ?

  _ _ __ ___ _____ ________ _____________ _____________________ ...
| Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801