Some patterns don't replace

[bbulkow]

There are a set of patterns which don't touch large parts of the sculpture - like shrubs - but if you use it, you expect those elements to go to 0 (opaque).

Is this correct? It's certainly unexpected.

Change this description to the patterns in question - see how bad it is

[cswales]

@bbulkow - which patterns are you referring to? It's not how the patterns are currently coded, but it should be easy enough to change if that's the behavior you're looking for. In the run loop, instead of filtering children by model.sub(), you want to loop through all the children, applying the pattern on ones where the tag matches, and blacking out pixels on the other ones.

[mcslee]

Documenting example fix here: https://github.com/squaredproject/Entwined/commit/1da45e0f74c00e83dcbf91c19a3b0b51fcb2261d

FYI just to avoid confusion, opaque is 0xff000000 which is also available as LXColor.BLACK - going to 0 will technically be full alpha transparency aka LXColor.CLEAR

Almost always best/safest to use LXColor.BLACK unless you're really sure you want alpha-transparency.

[cswales]

There is now a TSBufferedPattern class that does the frame buffering magic that Mark has in his example fix. The quickest way to fix a pattern is to have it derive from TSBufferedPattern, and change run() to bufferedRun().

I've done this with a couple of the patterns.

[cswales]

I've gone through and modified patterns that were only touching things like trees or shrubs. There may be one or two left, but things should be shippable.