Better Fill block

Right now, Fill looks at the color of the current pixel, and floods around filling to Pen color until it finds any border pixels of any different color.

When an outline is drawn over a background that already has a lot of colors going on (so that the outline has multiple colors inside), then multiple [fill] are needed to fill each color region (and no guarantees you won't get stray pixel artifacts at the boundaries)

This makes it tough for my class' animation project, where they [clear] and redraw every single frame; moving a small object with a fill color across the background means whenever it passes a background color boundary [fill] doesn't work (or multiple fills are required, which also means computing the locations to do multiple fills, which isn't really practical)

How about this: [fill current outline starting [5] pixels in direction [90]]? The turtle has just finished closing an outline; then [set pen color to ] changed the color. The algorithm starts by detecting the color under the pixel (which is the outline color), then moves inside as instructed, and then fills everything which is not the outline color, rather than everything which is not the under-cursor color?

Or an alternative method; [fill inside color ], where the user specifies the boundary color for the fill algorithm to stop at. User still has to pen up and move inside, but then fill doesn't need to check the color under the cursor

Those are interesting compromise ideas. The official right thing is for FILL to be a C-shaped block whose included script has to draw a simple closed curve, and then FILL fills exactly the interior of that curve, regardless of previous colors. (I guess if the pen color is partly transparent, then the previous colors are partly retained.) Your proposals are like that, in the sense that they pay more attention to the border color than to the interior colors. But they're like the existing floodfill in that you don't have to plan ahead while drawing the outline.

When Things Slow Down™. Or, I dunno, maybe sooner, if Jens likes the idea. In any case we should also have the existing floodfill.

Maybe writing such a custom block would make for a good stretch task for an advanced student in your class?

I'll keep an eye out for whether an advanced student might be able to tackle a custom fill block.

bh I am intrigued by the C-block design. I guess it could 'help' by noting the position at the start, and when the inner block whose job it is to draw a closed curve returns, pen down and move to the remembered start position, just to help make sure it's closed? The C-block could also take two colors, the boundary color and the fill color, and let the inner outline-drawing block(s) assume that color and pen-down are taken care of.

I'm worried about how performant a custom block would be, looping to touch every pixel, check it for boundary color, if it's implemented with snap blocks. Maybe written in javascript is the way to go? Or does the normal [fill] block use an imported library capability?

you could have a fill on and fill off block, like pen down and pen up. (although you probably want a better name)
when fill turns on, note the current position as the first point
every time the sprite moves, fill a triangle from the first point, previous point, and the new point.
inflate the edges by a pixel so there aren't gaps between the triangles, but don't go past the corners.
don't draw degenerate triangles (triangles where two points are the same position)

Well, the trouble is, you'd really want to use the primitive JavaScript polygon fill feature.

(This is also an answer to @ruberad.)

Be careful about non-convex shapes! (E.g., the "turtle" sprite costume, which is a fancy arrowhead with part of its rear end missing.)

Is the javascript fill primitive capable only of 'fill all adjacent pixels that match the current color'? Or can it also 'fill all adjacent pixels that do not match boundary color'?

Oh, I was talking about JS polygon fill, the equivalent of my C-shaped block proposal above. I don't think they have a floodfill primitive; if you do a search you'll find a bunch of messages about various people's ideas about how to do it so it runs fast.

I first thought of that, and python's turtle library polygon fill.

whoops, didn't fully think that over. i think there should be some working method based on winding order? worst case you could still just have the fill on/fill off blocks keep track of all the relevant points. there's probably some reasonably fast method for this kind of thing already.

either way, it would be nice to have some kind of fill system where you can watch it fill before it completes, like how you don't need to finish a solid shape to draw lines. it would make debugging projects much easier.

I'm not sure that's a good idea, because you wouldn't be able to create crescent shapes.

i tested it out, i got close but it doesn't seem to be possible. i would share a project showing this but every time i try to share the project i get logged out

When logging in, have you checked the box to keep your logged in?

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.