Reassembling Segments into Texture (Layout TOP?) & Updating Problem

Beginners
, ,
1

Hello everyone,

I would still consider myself more of a beginner. At the moment, I’m working on a network which I call “gradientGrid.” So far, I’ve been able to implement the following processes functionally:

  • Generating a Table DAT based on the number of rows and columns from a Constant CHOP, to calculate the Crop Left, Crop Right, Crop Bottom, Crop Top values of individual cells/segments.
  • Within “Container1,” using a Replicator COMP based on the generated Table DAT to divide the texture into individual segments.
  • Within the replicated “segment*” Container COMPs: Analyzing the individual segments to obtain the minimum pixel color, average color, and maximum pixel color.
  • Within the replicated “segment*” Container COMPs: Creating a gradient with a Ramp TOP from the 3 obtained colors.

gradientGrid_wip6.12_render1_inputImage
input TOP

Now, I want to reassemble the individual segments into one TOP. In the end, the input TOP should be “pixelated/segmented” according to the number of rows and columns, with each segment represented as a gradient. The segments are divided as follows:
7 8 9
4 5 6
1 2 3

Starting from bottom left, moving left to right & bottom to top, ending at top right.

Problem 1:
I tried using a Layout TOP, but I couldn’t properly assemble the segments regardless of whether I set Align to “Left to Right,” “Grid Rows,” or “Grid Columns.” Unfortunately, none of the “Grid” Align options seem to fit my use case, and it also doesn’t seem possible to set the direction. I could assemble the whole thing in two steps. First, assembling the individual segments into rows with Align set to “Left to Right.” And then assembling the resulting rows with Align set to “Bottom to Top.” But isn’t there a simpler method?

gradientGrid_wip6.12_render5_layout3__gridRows_error1
gradientGrid_wip6.12_render6_layout4_gridColumns_error1

Problem 2:
Another problem seems to be that somehow the “out1” TOPs (=gradients) are not being updated correctly. Initially, in “container1/layout1,” all segments display the same “out1,” and it’s only when I manually click into those “segment*” containers (which should actually be different) that they are displayed correctly. To debug, I created another layout TOP “container1/layout2,” which taps into the “out2” (=segments before gradient). These seem to be “correctly” updated.

gradientGrid_wip6.12_render2_layout1_gradient_error2
gradientGrid_wip6.12_render3_layout1_gradient_updatet_error2
gradientGrid_wip6.12_render4_layout2_segment_error2

gradientGrid_wip6.12.toe (8.6 KB)

2

Hi @palmavilluan,

Regarding Problem 1:
As you saw, the Layout TOP is building things up top to bottom while your crops are setup in the opposite direction. The simplest solution hence is to reverse the rows in your crop order…

Regarding Problem 2:
the way you set it up is that the Script DAT in each segment is not cooked as it is disconnected from the output chain itself - nothing is referencing it so it is not seen as needed. One solution could be for the Script DAT to be the DAT holding the Ramp TOP keys and referencing it in the Ramp TOP’s “DAT” parameter. This way it is referenced and required for the final image meaning it will cook when the final image is looked at.

Comments:

image
image1920×921 67 KB

I took some liberty to simplify your network a bit.
While I would recommend using a Script DAT for creating the table with the crop values, you can also skip that completely and use expressions in each segments crop to determine the correct crop values for the segment.
First I added a “WH” type parameter to “container1” called “Resolution” which will hold the number of rows and columns. Next, to get easy access to these parameters, I’ve added a Parent OP Shortcut called Grid. With this you now have easy access to this operator from anywhere within it.
Having this and considering the reversed order of cropping, the expressions in the “Crop Left” parameter now become:

((parent().digits)%parent.Grid.par.Resolutionw)*(1/parent.Grid.par.Resolutionw)

which uses the segment’s index (the digit on it’s name) uses a modulate operator to loop it over the number of columns and multiplies it by the stepsize.
Similarly the “Crop Bottom” parameter now becomes:

1-(int(parent().digits/parent.Grid.par.Resolutionw)+1)*(1/parent.Grid.par.Resolutionh)

which uses again the segment’s index but divides it by the number of columns (then round down) giving me the current row and multiply this by the stepsize for each row.

Further I’ve added a TOP network utilizing a Lookup TOP to create the ramps from the 3 Analyze TOPs removing the need for filling a Ramp TOP’s key table.

Hope this helps
cheers
Markus
gradientGrid_wip6_MH.12.toe (6.7 KB)