Winding number fill rule with multiple colors

[pnutus]

I'd like a fill rule that fills each region with a different color depending on the winding number. The current fillRule Winding is binary: either the winding number is zero and it doesn't fill the region, or it's non-zero and it does. I want something like

dia = loop # fillRule (WindingColors [red, blue, green, yellow])

which would cycle the colors like this

regionColor _ 0 = none
regionColor colorList n = colorList !! (n' `mod` length colorList)
  where
    n' = if (n > 0) then (n - 1) else n -- skips 0 for the cycling

(with winding number zero having no color).

I realise this might be a tall order, since it's not a standard graphics setting (there is no such thing in the SVG spec, for example). I'm posting it here anyway, since I think the idea is neat. :)

[fryguybob]

You could probably hack something like this into the rasterific backend
easily. To do it in other backends I think you would need to be able to
extract loops from a path, which would be nice functionality to have anyway.

On Fri, Aug 8, 2014 at 6:23 AM, Pontus Granström notifications@github.com
wrote:

I'd like a fill rule that fill each region with a different color
depending on the winding number. The current fillRule Winding is binary,
either the winding number is zero and it doesn't fill the region, or it's
non-zero and it does. I'd like something like

dia = loop # fillRule (WindingColors [red, blue, green, yellow])

which would cycle the colors like this

regionColor _ 0 = noneregionColor colorList n = colorList !! (n' mod length colorList)
where
n' = if (n > 0) then (n - 1) else n

(with winding number zero having no color).

I realise this might be a tall order, since it's not a standard graphics
setting (there is no such thing in the SVG spec
http://www.w3.org/TR/SVG/painting.html#FillRuleProperty, for example).
I'm posting it here anyway, since I think the idea is neat. :)

—
Reply to this email directly or view it on GitHub
#207.

[jeffreyrosenbluth]

Hmm, I'm not so sure about how easy this would be in rasterific.

[fryguybob]

I think most of the things needed would be confined to this file:

https://github.com/Twinside/Rasterific/blob/c99db7836718b7117e7ffb85b0ef79339e04fa83/src/Graphics/Rasterific/Rasterize.hs

The rasterize function would replace combineEdgeSamples with something
that combined based on the winding number directly. I'm not sure how
generally useful this would be anyway, as you would have to do a lot of
planning to get the winding numbers that you cared about except in the
situations where you just want to color something that happens to have
overlaps in interesting ways.

On Fri, Aug 8, 2014 at 10:36 AM, Jeffrey Rosenbluth <
notifications@github.com> wrote:

Hmm, I'm not so sure about how easy this would be in rasterific.

—
Reply to this email directly or view it on GitHub
#207 (comment)
.

[pnutus]

I "just want to color something that happens to have overlaps in interesting ways" :)

Maybe the best thing is to instead write a function that splits a path into regions with associated winding numbers? It's not really a generally useful thing, so it's probably not worth integrating into Style (at least not until it's working outside of Style).

[fryguybob]

Splitting a path into its loops is a very useful thing that we would like
to have. Given the loops of a path you can find the winding numbers for
each region if you can determine a point inside the loop and test the
original path for the winding number at that point.

On Fri, Aug 8, 2014 at 12:50 PM, Pontus Granström notifications@github.com
wrote:

I "just want to color something that happens to have overlaps in
interesting ways" :)

Maybe the best thing is to instead write a function that splits a path
into regions with associated winding numbers? It's not really a generally
useful thing, so it's probably not worth integrating into Style (at least
not until it's working outside of Style).

—
Reply to this email directly or view it on GitHub
#207 (comment)
.

[pnutus]

I have a feeling we'd need some way of finding intersections for that, and IIRC, there's no such thing in Diagrams. Should I create a new issue?

[byorgey]

We have path intersection testing now. See #226 . And since the intersection code gives you path parameters, not just locations, it should be possible to use it to split a path into loops. Though come to think of it I am not sure if it directly supports finding self-intersections of a path. If not I imagine that would not be hard to add.

[byorgey]

Hmm, looks like I was wrong, the high-level intersection-finding API gives you no way to get the path parameters of intersections (though the low-level API for intersecting two segments does). It also looks like there is no way currently to find self-intersection points of a single trail. It should certainly be possible to have these features, but they will require some nontrivial design & coding.

[kuribas]

I could add a windingrule to my boolean intersection code in cubicbezier to keep only a specific winding number. You could then call the overlap removal several times with different winding numbers, and color each one appropriately.