Just Launched: You can now import projects and releases from Google Code onto SourceForge
We are excited to release new functionality to enable a 1-click import from Google Code onto the Allura platform on SourceForge. You can import tickets, wikis, source, releases, and more with a few simple steps. Read More
> I think the idea of separating dynamics from tiled clones is very
> interesting, but it does sound like it might become a bit complicated.
> Essentially with tiling you already have a well-defined structure that
> you can leverage.
I have been playing with the grid idea and I think it was the wrong
approach. A much simpler way is to just use the (x,y) coordinates of the
point at the center (center of balance) of the object. I haven't looked at
the code but I think this may be what the Trace tab in the Clone Tile dialog
There is a difference between using the (x,y) spatial position versus the
(row, column) position. In the following image I have explored this a bit:
Apart from the "randomized shift", the difference between the two approaches
is very subtle. For example, the (x,y) approach gives more fully saturated
squares than the (row, column) approach in the Changing Size and Changing
Shift columns. However, I would argue that the user could tweak the
gradient to get the desired effect with the (x,y) position.
The exception may be someone building a data visualization in which exact
values (rather than depending on the interpolated values) are important.
Since this is a fringe case, and one in which it might be better to generate
the SVG using a script, I think the general use case should be given
Regarding the randomized shift effect (see first column in diagram), I think
that any property should have a randomized value selector. This way, I can
select a number of objects then open the dialog for the property and select
"random" - nice to be able to give a range for the values - and have the
properties set accordingly. I think this is a more direct way to get the
desired effect than randomly shifting the tiles.
I think the gradient approach makes for a very interface. A gray scale
image of a colour gradient could be used to visualize the effect. As the
gradient tool evolves, so can the ability in the other properties. For
example, one day the user may be able to define the type of interpolation
use in the gradient tool - not just linear. (BTW - the Maya tool has a very
nice UI for manipulating the interpolation function, for reference). This
can be directly applied to the other properties.
And finally, if a gradient isn't rich enough, the user can always provide an
image. The algorithm would work in the same way - just using the values in