How do I mix my SkiaPaint before a user's passed paint in a Process Node?

Essentially I have my own default Paint and I’m allowing user to pass their own Paint from input as well. Because you can stack paints one below another and the one below may override the ones above, I want to leverage this feature.

But Input Pins can’t take an input so I can’t do this:

How do I achieve this then?

Not sure I fully understand but I think you want the precompose node.

Thanks for the response. I’m trying to avoid Precompose node in this case. More importantly, one cannot override Stroke with Precompose which I want to do.

Essentially I want to emulate how shapes work in Skia. When I don’t provide a fill/stroke to Rectangle node a white fill is used but if I pass in a Fill/Stroke to its Paint input pin that one is used.

I have the same case but I have my own default which is not white fill.

Hmm. Try HackRenderPaint (experimental)

AFAIK HackRenderPaint completely overrides the previous paint which I don’t want. Rather I want:

[myDefaultPaint, ...restOfThePaintsSuppliedByUser]

I don’t think I can sequence this in HackRenderPaint.

Right, I think to make something general purpose would be pretty steep because decomposing the input paint isn’t exposed in an intuitive way. If you can unroll the stack, maybe you can restack them with the input paint applied. If you have that unroller, you can probably place the user effect anywhere in the stack

1 Like

Did you try to make use of this input?
Stackability yes, but again region involved, which you don’t want as mentioned in the other thread. Ability to concatenate SkiaPaints - #11 by ajitid

I don’t mind regions unless they are exposed to the user. If my node definition contains regions internally then it is fine by me.

I don’t think I can achieve stackability with HackRenderPaint. If you look at Hadasi’s screenshot, Paint input pin there is directly passed to HackRenderPaint’s output, and because it is an ‘input pin’, I cannot pass my default paint to this input pin. Which again means I cannot stack them.

Just wanted to note that the way the HackRenderPaint region was crafted was with the idea in mind that the upstream layer shall be painted with a hacked paint, based on some other paint that gets handed via that input inside the region. Whether or not you can make use of that region is a different question I didn’t take the time to think through. Just wanted to point out that that’s what this input is for: to be able to use it in a paint stack.

Got it!

And sorry if I came out as defensive with my previous reply. I didn’t mean to do that.

all good. Over and out. Hoping that the one or other idea in those two threads is satisfactory for you. Don’t be shy and tell us what you wnet for in the end and why

1 Like

I went with keeping the default paint in my custom nodes simple.

Why?

The benefit of having a simple default paint is that you don’t have to deal with merge problems with paints later. As an example, I never had to deal merge issues with vvvv’s default paint (white fill). That is why I have decided that my nodes would either have unmodified Fill or unmodified Stroke as the default paint.

Another benefit is the user would be already aware of what the output of unmodified Fill or unmodified Stroke looks like.

If the user encounters an issue like this one where only having a stroke make sense, I’d put this in my node definition, in between Paint input pin and the shape I want to pass the paint to:

This would ensure the shape always appears with a stroke.

cool!
ah: EnsureStroke alternatively could be implemented like this:

This way, you’d keep all other properties like path effects coming from upstream.

1 Like