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