Passing rotation and other inputs through fx-map node?
sublime tool
Does somebody know an optimal way to do it? For example I do a rotation noise input to rotate things scattered by fx-node. How can I pass that input through fx-node itself simplest way possible? Preferably doing the fx-map scattering only ones.
To get output with every thing rotated plus another output as rotation factor fill ? . Should it always have to be two separate fx-map nodes? My substances are already slow as hell because of those fx-map nodes. And pixel processors seems not that much speedier at all and much more complicated .
Replies
If you want to output the value per pattern instance then use a color fxmap and just pack the rotation info into a channel of your output color.
Thanks poopipe , but unfortunately color one doesn't do Max blending . So it's for pretty limited usage. Ironically Max is still in the list but never worked with color one. I asked Algorithmic then Adobe but they never fixed it. I managed to do it same way shape splatter does it by doing 4 gray fx-maps in sync , but it works same slow . No anti-aliazing either.
in that case (assuming you're not deriving the rotation values from inside the fxmap node) I'd probably drive everything with texture inputs - at least that way your fxmap stays simple and you can probably get away with just using one
It's what I managed to get packing height, two UV gradients and 10 ID integers into single gray floating point channel . UV gradients are unusable unfortunately . it's like a short blanket . You draw it to cover height and gradients are bad . You make one gradient ok and the second one gets super stepped. I used same idea shape splatter does , only two things before and after comma inside same single value . Wonder perhaps some other math could do the trick or it hopeless anyway? Not enough digits in the values my guess.
ah - so you're intending to output UVs that you can sample in another node?
So, the bad news is that even if you can make this node behave the results will be unusable in engine/pixel processor due to blending where the patterns meet. You can disable filtering to reduce it but then you get aliasing
I had all these problems when trying to generate random UV splatter masks - I shifted the logic into a shader and it all worked fine
What is the larger goal here? I'm asking because it looks like you're essentially using an fxmap to recreate the behaviour of an fxmap
poopipe. The goal basically is to recreate shape splatter with advantages of fx-map node . Shape splatter has same aliasing issue but I hope to use another fx map node that can do ID and alpha masks only ad/sub blending + filtering. Also Shape splatter is inconvenient as hell IMO. I couldn't find how can I overcome size max 5 limit there to get decent density.
And eventually to do an easy to use Atlas scatter that wouldn't degrade alphas of things. For subjects like grass plants, small twigs etc.
It's a project I am trying to solve for couple years already. From time to time.
Although not sure , perhaps I should just subscribe to Zbrush with RedShift and do all the scattering there with proper sub-sampling/ anti aliazing and all necessary AOVs instead of inventing bicycles in SD. If only SD could work as 2d compositor smoothly.
I'm pretty sure Shape Splatter would be fxmap based if it were a viable option. The big limitation in fx-maps is the lack of per pixel control over patterns and you need that to do anything very interesting.
One workaround might be to encode position/other information into an array (as a lookup texture) rather than into an actual texture. that would allow you to keep all your data synchronised - leaving you able to sample an input map into a pixel at full precision with just blending/masking to worry about . You'd probably just end up with something that behaved like shape splatter though
Thanks poopipe . it's interesting idea actually
its pretty straightforward to implement and can significantly improve performance since you're cutting an awful lot of per pixel maths out of the node that handles drawing/blending when you just pass position etc. in.
the one gotcha is that designer filters everything so I always quantize my UVs when sampling from LUTs (just simple multiply/floor/divide)
Yeah, I do it same way "multiply/floor/divide" . For small objects it's perfectly ok even if the gradients gets a bit stepped. As of lookup texture you mean the way it works in shape splatter , right? Those small blue pixel processors where each shape sell is a pixel?
So far everything I try works even slower than shape splatter so maybe fx-maps are not that much an advantage at all.
lookup texture is a texture where you encode information into each pixel - functionally it's an array of vec4 values .
this one represents a sound file which is sampled at 1024 (32*32) intervals, the red channel hold the amplitude of the left stereo channel, green channel holds the right
in your fx-map you can use the $number variable passed from an iterator to work out where in the lookup texture to sample the value required for your current pattern (it's much easier to use a 1d LUT so would suggest starting there)
its a similar process in a pixel processor but you need to derive your $number equivalent from somewhere else (usually once of the UV coordinates)
Thanks poopipe. I am not sure yet how to implement it for fx-map node although. But I'v got the idea.
This will read from a 2d lut
squareInputSize is the number of samples in each axis you take (32 would mean you treat the image as 32x32 pixels)
$number comes in from the iterator and is the current sample ID - to sample the whole
This samples from the top left corner of the "pixel" so it's not safe for filtered sampling - really it should offset the UVs to the middle of each pixel but it was working so I didn't bother.
Thanks a lot for the example poopipe .