[Fluxus] getting wire-colour

[Kassen]

Hey Dave,

Colour is part of the primitive state, some of which can be accessed
> (e.g. the transform).
>
>
Yes. I'd like to try to make a case for including colour and wire-colour in
there.


> We could add functions to make everything readable, but it's also
> possible to store extra information (of anything you like) if you store
> the primitive in a structure or list along with anything else associated
> with it. This is the way I tend to do it, and I think for anything
> sufficiently complicated it's inevitable.
>

I agree. I would say though that colour is different from properties like
"material" and "velocity" in that Fluxus doesn't have build-in
"electro-magnets" that need to be aware of the material nor
"police-cruisers" looking into a primitive's velocity. We do have build-in
ways to set colour, it is stored by default and expressed by default, we
just can't get to the data by default. To me that's not very "beautiful",
particularly because in the transformation matrix we do have a structure
that would make a natural place for this information.


>
> I have experimented with storing data to do with particles in user pdata
> arrays - e.g. using elements of per-particle vectors to store state
> information, that seemed to work pretty well.
>
>
I'm not sure that would work for me here (maybe it would). What I'm after
right now is a "(decay)" function to be called every frame. "decay" would go
over all primitives, get their opacity and wire-opacity, subtract (delta)
times some factor, write those back and destroy any primitives that would
now be invisible. That would allow me to build lots of things from the seq
function, scheduled to be on the beat, and not worry about clogging it all
too much, nor get too much overhead in the seq function to set custom
properties.

Maybe something like that would need a series of custom (paint-foo)
functions, as opposed to the (draw-foo) ones, but IMHO, because the data is
already there and is merely currently unreachable, having just a "(decay)"
function that would be simple enough to potentially write in performance
would be nicer.

Does that make sense? Would extending the transformation matrix potentially
break anything? I could try myself, if I'm currently the only one who's
interested.

Yours,
Kas.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pawfal.org/pipermail/fluxus-pawfal.org/attachments/20110629/8cd1a5ca/attachment.html>