Animation

Just some doodling around with some hyper realistic textile meshes...

Posted is a working little animation using sprites, iterator and javascript. I want the animation to add the sprites (random size and color) without overlapping, and scroll as the screen fills.

1. Regarding, for ex., sprites filling screen but not overlapping, in javascript (or otherwise, i guess), how can a relationship be set up between queue indices, so current index uses values from previous index (or indices) to determine x position, y position, width and height?

2. Would it be better (faster) to have the random values sampled in js?

3. How can I generate the scrolling, say after the screen fills? Best way? Sometimes I see the "dummy" patch time patch input in js -- what is this for? Am I off the mark for thinking of this re: scrolling in js?

Any help is appreciated.

Hi,

I've been trying to develop a composition that will respond to Multicast messages, and then before an action according to what has been set.

Is there a way to start say, a timeline or interpolator when a specific value has been updated within the composition, instead of having it running with the initiation of the composition.

Regards, Charlie

Proposal: "get" objects that could get vertex/normal structure info post render/transforms/rotations, for Mesh/OpenCL based renderers, or even better, standard objects as well. In addition, other info about the state of the patches in a structure would be useful.

What could happen is that Render patches could get draped in an environment that's function is to provide a structure output with each Render patch inside of the macro being represented as a separate structure key in the output structure of the Environment patch.

The structure key names would correspond with each renderer's already existing key name (the one you see by hovering over the patch), enumerating structure by layer order of Render patches, with the post-render Vertex (and normal?) info of the Render patch enumerated nested inside of that keyed object. Again, this means the environment patch would convey the vertex and normal values post transform/rotate/scale on the renderer patch via a structure output on an environment that wraps one or more renderers.

Something like a clear, if on layer 1, would show up as index 0, with a keyname "clear", and possibly structure info that described the rest of the state. A Sprite on the next layer would be index 1, have a key of Sprite_1, info about the coordinates of each of it's corners, and perhaps all other info about the state of the patch.

By being able to easily obtain the vertex info of objects post scale/transform/rotation/render, we can create events that are dependent upon collision between objects, bar objects from touching one another, etc. In general, being able to read all info about the state of a macro via some kind of structure output on the macro just makes good sense, and it's sort of surprising that the functionality isn't there, after thinking about it - trying to do something ultra easy in another language tonight made me think of how this would allow for many different functions, and is a pretty straightforward and QC-esque way of handling it.

So, like a image broadcaster or spooky, but an environment that can hold consumers and have a struct output, that provides the scene structure with additional info provided by calcs of vertices, etc that the User gets to avoid (or have some real method of obtaining at all, really). This patch wouldn't "do anything", it would be for obtaining info.

ALSO, it would be great to be able to pass arbitrary structure data to a souped up GL Structure Environment that would work in a similar way (probably a separate patch). If wrote a keyed structure that corresponded with all of the Key names of the patches inside, as well as input key names, transmission could happen to those patches without even noodling anything up, if I plugged that structure into an input port on the Structure macro environment.

ALSO ALSO, iteration/duplication could happen inside of the environment by hooking objects that are like Iterator Variables to patch time on things, except the number of iterations would be specified on THAT patch, not the actual environment.

Perhaps one patch could perform both functions.