[PD-dev] [GEM] update

[Mathieu Bouchard]

On Sun, 11 May 2003, chris clepper wrote:

> the 'meaningful way' is what i'm talking about.  how to make it 
> simple for the user to get some element of the pixel data, like the Y 
> for example, and map it to another system like texcoords or vertices.

Well, the problem with that is that there is no standard way of doing
so.

In video you can make a set of stereotyped effects with a few user-tunable
parameters and hand that to the user. Same with each other subsystem, I
guess.

When it comes to moving data across subsystems, however, I think the
possibilities have not been explored enough yet, so there wouldn't be any
kind of agreement on what is a good way to convert from one subsystem to
another, and that is bound to evolve very much in the next years.

For my own practice I want to leave all doors open, and basically do all
of the mathematical mapping myself. What I don't want is dealing with C++
and buffer overflows and writing the minute details of everything.

It's true however that leaving all doors open means someone may get lost
figuring out his path. Then abstractions may represent certain forms of
beaten path. But to make abstractions (bottom-up design), I'd rather have
evidence that the pattern I am abstracting out is really a pattern, which
is not too obvious to me at first sight, lacking long-term experience
doing intermedia conversion.

> ok, i'm not making any sort of value judgement about GridFLow at all, 
> but i think you actually made the point for me: i don't think users 
> need to care or even know about which C data type the pixel info is 
> in and what it needs to be cast to to work in GL.

Well I expect the C datatype to become optional... I just have too many
questions left unanswered regarding that, so I'm leaving most implicit
conversions for later.

So would you please concentrate on the dimensionality aspect of data,
which is more fundamental. Like, a 3D N-sided polygon is represented by a
N-row, 3-column grid (Dim[N,3]), while a picture is represented by a
Height-by-Width-by-Channels grid (Dim[Y,X,C]).

So, is the user supposed to be aware of the grid dimensions like N*3 vs
Y*X*C ?

> there are lots of people i know and work with that really couldn't be
> bothered with the process of explicitly doing the buffer parsing to
> get at the data they want, casts and resizes - that's the sort of
> thing the programmers of the system are supposed to do for them. ;)

oh. well maybe that lots of people you know really couldn't be
bothered with the idea of making those intermedia mappings in the
first place.

Or if they really want to do it, but can't be bothered with the
dimensionality and interpretation of the data, well that begins to smell
like money. Especially because it smells like hard work. I mean reifying
the user's desires may require quite a bit of psychoanalysis (grin)
sometimes, and then a bunch of trial-and-error.

Else they may be happy with a bunch of standard intermedia effects
(whenever that comes to exist) but that's the same problem as with
anything else. Not being above the tools being used, there's the risk of
looking like anyone else. Artistically, there's definitely a PhotoShop
style, an AdobeIllustrator/CorelDraw style, and so on. Of course a bit of
that is each medium itself by its conceptual nature, but the most obvious
is the stereotyping of effects.

> a hypothetical object could be [pix_to_vertex R 64 64] which would
> take the red channel of the video and scale it to 64 by 64 array of
> vertices.

oh ok.

reminds me I have to implement [@slice] someday because right now taking a
slice (cropping) data is done using the very flexible [@for]/[@store], but
it deserves to be faster...

Of course [@slice] would work for any data type representable as grid...

________________________________________________________________
Mathieu Bouchard                       http://artengine.ca/matju