stroke of one circle overlaps the fill of another circle

[loboere]

The red circle is behind the green one but its stroke is seen above the green circle, how do I avoid this? I tried "move to front" to the green circle but it doesn't work I use a vector layer

[shun-iwasawa]

Please try the following:

• Select one of the circles with Selection tool
• Right click and select Group

It will put one circle to a group which will be separately drawn from the other one.

[RodneyBaker]

Will plan to transfer this report to Opentoonz-docs so that others can benefit from the information.

[Bracket-H]

Kind of a bad interface move, though. Grouping a single item to itself...

[RodneyBaker]

Not so much relating to the interface @Bracket-H but rather rules for color fill. This isn't to suggest the process cannot yet be further improved and certainly the UI can play an important role in that. For instance, once there is a way to see a listing of what groups are available and to be able to change what is inside any given (vector) group... and preferrably via drag/drop... groups will be better understood.

But...

The key takeaway here is the importance of how groups of vector strokes define how color fill works.

Reference: https://opentoonz.readthedocs.io/en/latest/drawing_animation_levels.html?h#grouping-and-ungrouping-vectors-1

Once we understand the general rules we can do some very interesting things with vectors and vector fills:

[Bracket-H]

Mmm, I still think that requiring a vector shape to behave as OP wants it to be to be in a single group is a bit awkward.

There is nothing outlandish, edge case or exotic, in my opinion, to want the green outlined circle in front of the red one. I would go as far as call that the basic assumption of operation. So, having to workaround that by making a group out of the single item is ...weird.

Especially if not being in a group by default (or changing the underlying handling of it accordingly) has no special effect, other than the behavior OP does not want to happen.

[RodneyBaker]

Yes, the rules for vector fill are certainly weird and awkward. Most drawings likely won't consist of just two circles so that is a little awkward as well.

A key component of the underlying problem is how Opentoonz needs to determine what is 'inside' versus what is 'outside' of a shape or... group of shapes... especially when multiple shapes are involved. This problem is compounded a bit by the fact that most shapes, such as those created by the geometry tool are only one stroke... made in some cases to look like they are multiple strokes.

There are a number of fill issues associated with drawings that consist of one stroke areas that refuse to fill and (in my estimation) a core reason is that OT has no way of determining what is 'inside' vs 'outside' and will fill one side but not the other of the stroke. If it did fill both sides we'd see a different problem in that users would certainly find it strange that when trying to fill a simple shape like a circle the fill colored both the inside and the outside of the shape. And correctly so, as that would be inappropriate.

At any rate, the grouping of a stroke or set of strokes helps Opentoonz determine what is inside vs outside. This probably relates to even vs odd pairings... where any odd remaineder will be problematic... but I'm not privy enough with understanding of the code to suggest much more. In PIXAR's subsivision surfaces this is handled by the very first operation being to double the number of vertexes. This allows calculations to always be divisible by two; i.e. always even and never odd.

In Opentoonz we could probably solve several problems by never allowing strokes to be 'unequally yoked'; in other words they would always be paired with at least one hidden back side in cases where only one stroke was drawn... even for geometryic shapes. In this way it would be easier to determine inside from outside for all shaping combinations.