Paint normalized influence values (alike capture weights)?

[probiner]

I would like to have something like CaptureLayerPaint SOP but without having a actual bones or capture. Just set a number of channels and paint on a channels having them all being normalized as I do it, i.e. per point, the sum of all channels is 1.0. 

I've done something like this before setting an array attribute, but I can't paint it in this way.

(contains sound)
https://streamable.com/jl6ag 
https://streamable.com/665k6
So instead of just using those nulls to define those areas of influence for deformation/instancing/etc... I'm looking for to directly paint them.

So is there a way to pain such type of maps arbitrarily? 

Thanks!

Edited September 21, 2017 by probiner

[probiner]

Ended up using Capture Attribute Unpack SOP to access the Capture Layer Paint SOP values. Would be cool if was a bit more arbitrary and wouldn't require placeholder bones. But hey... it's delivering good results atm.
https://streamable.com/2riat

Edited September 21, 2017 by probiner

[probiner]

Another example where multiple sources of @P and @Cd are interpolated.
https://streamable.com/sbzod

Cheers

[probiner]

Last one I spam, RFE filled.
https://streamable.com/gat8c

[probiner]

Scene Example: 

PRB_PaintWeightsLERP_01.hipnc

Edited September 22, 2017 by probiner

[trzanko]

Great thread, the unpacking method is viable though a bit weird to work with because of the bones and capturing. I recently wrote my own wrangle for normalizing, coloring for visualization, and creating densities per a set of different attributes of an incremental name(basically paint capture weights for a set of attribs). So for example you can display the hda and up stream you can paint in multiple paint nodes overriding the color paint attrib to your own attrib but make sure the names goes like attrib0, attrib1, attrib2, ... attribn. Of course you can make the name anything you want, for my purposes I named it fgroup, simply replace fgroup to your desired prefix, display the wrangle and paint upstream attribs! Happy painting!

The multi-parm allows you to vary a density attrib by the amount specified in the channel per painted region, so fgroup0 corresponds to density0 and so on. Just make sure you have as many multiparms as you do painted attribs.

Play around with it a bit and let me know if you have any questions,  

Link to HDA -> https://gum.co/TKCTM

 

Edited January 27, 2018 by trzanko

[probiner]

Hi @trzanko

Thanks for sharing your method and files. Always nice to see different takes on similar endeavors. 
I'll point out some negative aspects that I think you could improve to make the exchange more interesting:
- You show my post in the video, but you refer to me as "someone" and "they".
- You characterize the method I present as "tedious" and a "not a great workflow" without supporting arguments. ¹
- You present an alternative method which has its benefits but misses the point of the initial inquiry. ²
- In the end you ask for a donation, which is a fine practice, since people are to be awarded for what they put out, but given the previous items it adds to the awkwardness.

What I find useful in what you present is that: since you're always painting "Solo" you don't mess other "channels" by mistake and you can easily swap channels, unlike with CaptureLayerPaint where I can't have channels swapping values. Overall though I think I would use a chain of PaintSOP more for something like BlendShape influence painting, which just adds up the values of all the channels, than to something I want normalized on interaction.

¹⁾ There can be management issues if you want to swap channels or lock them, but overall the operation is quite solid as they are stored on the SOPs, so the number of channels is updated and the painting is well preserved. I don't see anything tedious about recapture or why the workflow is not great, but feel free to explain.
²⁾ For me, the important aspects were that: normalization happens on interaction time; I don't have to manage layers due to their priority to control the final output which can be cumbersome with more layers; smoothing is done across all channels not just a single one; the ability to lock some channels so they are not affected (which I filed in the feature request, since I saw how useful it was in XSI).

The normalization aspect is not just so that everything sums up to one, but so that priority is given to what you're painting. There's a quick explanation, in the beginning, about why layers are not what I was looking for.

Cheers

Edited October 21, 2017 by probiner