I have a grid of triangles that I’d like to color each triangle using a palette. I don’t want an even dispersal of the colors, rather each color will have a weighting for how often it should appear (ex. 25%, 15%, 30%, 10%, 20%). I don’t know how I would create that pattern for the Partition List component or even if that is the right component to use in this situation.
So the question is, how do I create a system for a weighted color application that I can adjust?
triangle_grid.gh (14.0 KB)
I usually do like this, with Gene Pool and n-1 sliders (the value of the last slider is like the “remaining ones”)
triangle_grid_Re.gh (24.3 KB)
but note that you need to be careful to make values not exceed 1 
these panels tell you how many per color you get, and the final real % for each color (as the Gene pool ones are just a “guide” that doesn’t account for fractions of triangles, that you don’t want to have)
Wow, that looks great. Exactly what I needed.
I wonder if a similar system could be used to solve another aspect of the design I wanted to accomplish. Rather than having random heights within a given range (using either jitter or random), could I construct the extrude height to be one of say 5 presets? If I was coding this, I would generate a random number between 0 and 1 then by ranges, allocate a certain height (kind of what the Gene Pool is doing). The aim is to 3d print the triangles and i can more easily batch out set sizes than random heights.
yeah, because “at a certain point” we are partitioning the list of breps to give them color, then we can just move the partitioning ahead where they were just jittered curves, and extrude each partitioned branch by a different amount (amount also controlled by a new gene pool that now has n values, because each branch needs its own extrusion height)
triangle_grid_Re_Partition_ahead.gh (20.7 KB)
in alternative, if you want curves in a certain branch to be extrud by a random value that is picked from a different domain (domain which is different for each branch) you can use something like this:
triangle_grid_Re_Partition_ahead_Re.gh (25.0 KB)
you can also write the 5 Domains “by hand” in a Panel (activate multiline data first) and write literally domains like 2 to 4.32 (in case, that panel should be plugged directly to the Range input of the Random component)
last thing, you won’t suffer from this, but it’s always good to know that if you have 5 different Ranges in the Random component, you might also plug 5 different Seeds to vary the outcome
I’m playing around with it, and it looks like the color weighting partition is linked to the extrusion such that only one color is assigned to one of the set heights. How can I have these disassociated so that any triangle can be of any height and color?
oh, I think I misunderstood what you wanted then
you don’t want “pure random” heights, but want heights to be randomly picked from a list of n values?
and want each extrusion height to not be linked to a color
if you just want to get random selection among a list of predefined heights, you can use something like this:
in this case you can supply a list of available heights, but can’t choose how many per type are used, that’s a function of the seed value you enter, and the quantity per height is shown on the panel on top right
if instead you want to be able to choose how many extrusion per given height, you can either partition the list of triangles the very same way that was done for giving them colors, or you can populate a list of extrusions that is as long as the list of triangles, where each extrusion height appears a given number of times
I prefere the first one, which might result in something like this:
as per the color parts, the list of triangles is Jittered before being partitioned
I prefer the first one as well. I’m not too concerned about having an even mix between heights. The uneven distribution is appealing.
There is a difference in the color portion of the algo that I want to ask about. There are a few added components (highlighted in the image below) that I’m curious about what they are doing and why you added them? It worked as expected in the previous version without them, so what are these solving for? Just trying to learn.
oh yes, I forgot about those
they solve a situation that can be originated if the amount of items to be partitioned is bigger than the sum of Sizes
to better explain, partition Size “S” can be considered like a Pattern… it will be -even partially- repeated if you have enough items to partition
for instance, these produce the very same result:
in the earlier definition, when those grouped components you found were not present, if you wanted n partitions you could specify n-1 percentages using Gene Pool, and the last one was not even calculated because I assumed all that was left was thrown in the n_th container, which it does, but only if the remaining items are less than the amount of the very first partition
if they are more, then the Size list restarts
for instance, on 100 elements I use partition [10,20,15,25] assuming the 30 remaining ones will be thrown in a last branch with 30 elements, but because 30 is bigger than the first amount in Size list, then the Size list just restarts like a pattern and I get 10 and 20 instead of 30
the group you refer to just inserts as last value of Size list the total amount of remaining items, in such a way the sum of all the Partition Sizes is always equal to the total number of items to be partitioned
in A we have the n-1 partition sizes, which are summed together in B, then we find how many should be in the n_th container by difference from the total item count and B, then we insert that value at the end of the Size list with D
Tanks for the explanation, really thorough. I think I understand. Wouldn’t it be solved by just adding another branch in the Gene Pool for the remaining 30% and thus totalling 100% ingoing? Isuppose there would be leftovers if we weren’t careful to ensure the gene pool branches didn’t total 100.
yes, that’s exactly the point
if you add a new branch to the gene pool and don’t apply that group of components, then you need to make sure the final sum gets to 100% sharp each time you tweak something
but look what happens if you manage to make a perfect 100% using the n-1 gene pool (in such a way you don’t need the additional branch)
the newly generated last-size-count is a zero 
as if it doesn’t exist for the partitioning (there wouldn’t be enough items to partition anyway…)
on a side note, there’s nothing that prevents % to be set higher than 100%
in that case you can see the partition list turning red because the added branch is negative
I mean… it’s not safe-fail, it’s just a helper if you are supposed to set sliders in such a way they sum to 100% or less, the thing of having n-1 sliders to set, and that the value of the last slider is always set for you as “100% minus sum of all other sliders” is just less work to do
It all makes sense now. Thanks @inno for explaining and thanks for helping me solve this. I learned a lot.
