Pack and later split several grey images in and from a single 32 bit channel?
sublime tool
Namely Height, UV and index. Does anyone know how to do it properly ? Or at least on what principles? Bits masking or something maybe?
I am trying to do it for FX map in 32 bit mode. Something similar to what available for shape splatter in which pixel processors I couldn't understand a thing so it looks easier to invent your own bicycle rather than figure out how they did it.
Replies
not a thing you can do in designer - you need access to the actual data rather than the result of looking at the image.
your best bet is to channel pack if you're looking to pass data around
How do you think they did it in Shape splatter? Main principles? I mean UV gradients and index coming from scattered/splattered things . I tried to learn from it many times but still have no clue. Lots of pixel processors I couldn't even comprehend what they do.
I had a quick look and it doesn't seem to be doing anything too weird - it is complicated but most of the complexity comes from there being a lot of input maps and parameters rather than it doing anything magical.
without spending ages looking at it I think what happens is...
They generate a texture (data texture) with a size based on the number of x/y tiles and using that to store position, rotation, scale and height information for each pattern. They sample that texture and from that can generate UVs that are then used to sample the input pattern(s)
A simplified example of the UV generation would be the graph pictured below - its just scaling and clamping UVs to give you discrete patterns. To use this you index into an input image from the saturate node (the result of the if statement is just for visualisation) there's a couple of custom nodes in there (frac_f2 etc) but it should be obvious how they work
In the case of the shape splatter they're sampling the data texture at each pixel to get the starting coordinates/extent and orientation for each discrete set of pattern UVs rather than using the UVcoords themselves as I have in the example image
The pattern index can be derived from a floored version of the scaled UVs (before the frac) converted to a single float (just v+u) and stored in a third channel.
as a side note - this is a really effective way of handling things like road markings and other repeating patterns in a shader as you only need to sample the input texture once
hopefully that helps you get your head around it.
Thanks a lot poopipe. But my issue not with exactly generating UV but rather how they make UVs following the height blend . For example I have cubes intersecting each other through Max (lighter) blending . From your explanation it looks like they generate small UV pictures for cubes but how they later make them mask each other after scattering . For regular heights blend through Max math it's totally understandable but doing it for UV gradients is not exactly clear how? Are they just generate a full size mask for each new instance separately?
like this cubes . I see cubesUVs are clearly follow their height MAx blend . I wonder if I can do it in Fx map somehow.
I mean I could do it through the regular height blend node that output the mask too. The math is extremely simple . I could do it for each cube one by one , gazillion time my guess but I doubt they do it that way. Or they really do? I can't figure out it from their pixel processors.
Each cube is masked in by a tile_sample_blend_2 function that you find a big stack of in the final pixel processor. (this bit)
The above looks like a kernel filter but I think that's misleading - the offset sampling appears to be there to support multiple pattern inputs (which are compacted into an atlas) rather than being used to compare height values between patterns
It'd take quite a while to pick through and establish exactly what's happening in this function but at the end it appears it's choosing which pattern to draw based on which has a greater height value when compared to the result of the previous iteration of that function.
The UVs etc. are passed through along with the height at each iteration so you get those masked for free
The packing described in the below image is an example of how you can pack an integer and a fractional positive float into a single channel - this is as dense as you can achieve in designer
eg. a value of 3.54 in the Y component would give you pattern index of 3 and a v coordinate of 0.54
As to whether you can reproduce this behaviour in an fx-map or not - I think the answer is no.
You have no access to the pixel values within a pattern so you are unable to compare one instance of a pattern to another on a per pixel basis. This plus the fact there's no custom blending options at all is presumably why they went to the effort of making the shape splatter in the first place.
as a side note - if you do start buggering around with the fx maps i found there was a tendency for data to get corrupted when using 32f input patterns , i posted something on the official forums with a workaround and worked a bit with allegorithmic to get the bug looked at but tbh I haven't been back to check whether it got fixed or not
Thank you very much poopipe.
Although I still don't understand how they manage to blend my cubes one by one. My guess using some sort of list or indices maybe, the blending itself of all 4 RGBAs at once through if else and height boolean is perfectly clear now. Your are right , the masking kind of free that way.
Also I am actually trying kind of very same idea in fx-map to pack one image in integers and another one after comma with floor node. But for some uncertain reason it doesn't splits well after. Thus my initial question. I get sort of grate pattern on the gradients even when my integer parts are thousands . Is it that data corruption in fx-map your are talking about?
Adobe seem to have helpfully deleted the old forum completely rather than bring the last 10 years worth or knowledge over to their system so I can't find the discussion thread about it to refresh my memory.
It doesn't quite sound like what I was seeing but since the data was corrupted that doesn't mean a great deal - like I'd be seeing a stretched version of the image in primary colors.
Looking back at my graphs, I think my workaround was to force inputs to 16bit prior to feeding them into the fx-map - you won't lose any meaningful precision dropping from 32 to 16 bit unless you're doing something quite demanding