Stroke node input geometry force recook

[Sebastien Rousseau]

Hi, 

I'm doing a tool using the stroke node for breaking the corner of a geometry. User can isolate part of the geometry by selecting group. 

The problem appear when the user isolate a part and want to paint on the surface. It look like the stroke node don't refresh the geometry input and still use the inital geometry input as reference model for the stroke projection.

Maybe I'm wrong but I'm pretty sure the problem is coming from the stroke node that not re-cooking when the user tick the isolate toggle and select a group.

Does some one could give me a hint on how to fix that please, I'm pretty stuck right now. 

 

 

 

[Librarian]

You using Vdb Flatten From Height-field paint or some custom Brush stroke system over Vdb ?

[Sebastien Rousseau]

On 2020-11-28 at 10:56 AM, Librarian said:

You using Vdb Flatten From Height-field paint or some custom Brush stroke system over Vdb ?

Here a simplified hip file that show the network I use for acheive this result. break_corner_vdb.hip

 

 

Edited November 30, 2020 by Sebastien Rousseau

[Alain2131]

Hey Sebastian (or salut, fellow quebecer),

I'm sorry I don't have a solution, just findings, thoughts and assumptions.

It looks like the issue is with the handle of the stroke.
I think that behind the scenes, whatever does the projection onto the geometry uses the input of the current node for the projection. So what I assume (this is only speculation) is that since the handle is on your HDA, it then uses the input of the HDA, instead of the input of the stroke node.

When I go inside the HDA, and change the Isolate group toggle, drawing on the isolated part works correctly, same when not isolated.
And when changing the input of the node itself (removing a cube from there), the drawing works (which means the projection geometry is being updated, just might not be what we expect).
That's the reason I made that previous assumption, why would it work when we're inside the HDA (using the stroke's "real" handle) versus when outside the HDA (using the HDA intermediary handle).

So, erhm, yeah, don't know if that helps at all, or if this is anything close to the real issue.

EDIT:

It sounds like, from SideFX's documentation on the stroke state (what I meant by handle), that the stroke indeed uses the HDA's input instead of the actual stroke node for geometry projection.

Quote

Customization

The stroke state will look for spare parameters (usually hidden) on your node with the following names, and if they exist, use their values to customize the operation:

stroke_projgeoinput

Should contain an integer specifying which input to use as the geometry to draw on (stating at 0).

They wouldn't have an input selection option for the actual stroke node.

Sssooooo, the only solution I can come up with is to create a custom state, to handle the projection yourself, where you'll be able to project onto any geo you want.
Maybe copy the stroke stuff, and modify only the part for the projection geometry input. But I don't know how to create a custom state thingy.
I'd start from here.

Edited December 5, 2020 by Alain2131

[Alain2131]

Sorry for double-post, but you can see this as a TL;DR

The reason why you cannot isolate a part to draw on is that the stroke state (what allows you to draw on the geometry, which doesn't know about the stroke node you have in your HDA) uses the input of the HDA to gather the projection geometry.
It's easy to prove - plug a sphere in the stroke node, go back to the HDA, and draw on the geometry.

To fix that, maybe you could figure out how to call the stroke state manually from a custom state, and modify the kwargs parameter to be the node you want. But I don't know if this is easily doable, or doable at all.