Pink & Ain't

I have some crazy ideas knocking around my head. My art brush tool is incredibly useful but it’s far from the most user friendly. There are a few usability features that I’ve wished for it for a long time:

1. Be able to change brush art and have it be reflected in all the existing applications of that brush
2. Be able to apply a brush in either direction, so that I don’t have to have duplicate brush symbols that are flipped around versions of each other.
3. Avoid the problem of exiting a brush symbol before deselecting the art, which leads to the transform that’s been applied to it not taking hold for the purposes of the art brush tool.
4. Be able to apply an art brush to multiple lines across multiple frames.
5. Be able to apply a new brush to an existing stroke without having to deal with invisible lines or deleting the previously applied stroke
6. Somehow be able to indicate a starting point for applying the art brush.
7. Fix CS3 compatibility of the recolor version of the art brush. Unfortunately the non-recoloring one will likely never be possible in CS3 or earlier.

Here are some of my thoughts on solutions to these problems:

1. This would actually be pretty easy if I made it so that every new application of a brush stroke was inside a new symbol. It would change to use the art brush tool a little, but it would add much more potential functionality than it takes away. If I did this I would probably keep the original stroke on a guided layer inside the new brush stroke symbol. I could store some data in the symbol, which would identify how this brush stroke was created – what direction, which brush, whether it was recolored, etc. Then it would be a snap to go through the library and find all the brush stroke symbols and operate on them in turn – updating the brush art, apply a different brush, etc.
2. This would mean a new tool to apply the brush in the opposite direction than how it usually goes, but it would be a pretty simple change to the code.
3. I’m pretty sure this is a bug in the Flash code, but I might be able to work around it. If I could check the brush symbol before applying it, making sure that there’s nothing selected in it, it would I’d never have to deal with this unapplied transform problem again. Amy I in a fantasy world to think that it could be so simple?
4. This one might be solved with the symbol method I mentioned in #1. The problem so far has been that when I‘m in multi-frame editing mode and I have lines selected on multiple frames, if I run the brush tool it ends up putting all the art brush strokes on a single frame. This is one are that’s definitely worth investigating, because this is a problem that comes up frequently when, for instance, animating an animal’s tail or some waving seaweed or what have you. To have to go through and apply the art brush tool separately on each frame is a big pain in the butt.
5. This one is solved by the solution to #1 as well. With the info in the symbolize brush stroke it would be easy to delete the existing brush art and apply the new brush to the original line in the same way it was originally applied. It would just mean that the art brush tool would do its normal thing if a raw shape is selected but if a symbol instance is selected it would try to replace the existing brush art with the new. If the selected symbol instance doesn’t conform to the standard brush stroke symbol format, the tool would do nothing. Badabing!
6. If I used something like the shape hint system that I use for the autotweener when operating on raw shapes, it would mean that the starting point could be much more easily managed in a long sequence of animated brush strokes. The tool would just start from whichever end point is closest to the shape hint.
7. I had it working before so it shouldn’t be hard to get it back into shape.

Conclusion: it seems like a no-brainer, then, to change the functionality of the art brush tool to be more like I outlined in #1. #2 and #3 shouldn’t be difficult to implement, assuming everything goes as I expect (which may not be a reasonable assumption based on my past experience with JSFL). #6 will be a little more work and I may put that off a bit. At least I could reuse some code from the autotweener, though. And #7, as I said, should be pretty easy.

These changes are pretty high on my to-do list for my library of Flash commands. If you leave a message encouraging me I’ll be more likely to make it happen.