Is it possible to create an n-box massing script for GD?
It probably would require a special type of slider that would output n-number of outputs right? Where n would be an input to that slider.
Can you elaborate on what you’re after here? Are you aiming for N box massing instead of the 3Box massing example?
The ‘is it possible’ approach is generally not worth putting forward - anything is possible, but it comes down to:
- How much time you have available
- How complex of an outcome you need
- Your creative problem solving abilities
I generally encourage people to take the ‘I suspect this is possible, but am not sure where to begin’ approach.
N box massing is possible, but would require some logic to how boxes occur. Each box would lead to the placement of the next one probably, and from here you end up with something like a while loop, which will then end you up in Python to access this behaviour. You could place a box, pick a random, side then place another box from its centre outwards. If it clashes with any box, try another side. If all sides clash, pick another box and try again. This process could probably last a long time unless the algorithm literally boxes itself in.
Definitely don’t need a while loop to do solid unions, and if the goals are property configured the optimize method should return meaningful results. If a box is placed in a manor where it literally adds no volume, who cares? The net result is what you’re after, not the many pen strokes which lead to it, right? Done a few massing examples this way in the past, and find that it generally works out quite well if all you’re after is expressive form via controlled random. The real difficulty comes with the unknown quantity of cubes, which brings us back to the question at hand.
The hard part with an “N” occurrences slider is that you’ve removed one of the analysis points of the larger tooset. How do you configure the system so it knows how many to place? You could just have an additional slider which controls the number of boxes to create, with a List.TakeItems controling how many XYZ values to create for the boxes. But this means GD will be spending a LOT of cycles adjusting sliders for the XYZ values of each of the N sliders, but only the first say 1/n% have any impact.
Basically GD would find a decent value in the first run, and then something like this happens:
Generally speaking, each slider has to have a meaningful impact on the results and form a recognizable pattern as it moves along it’s domain. Otherwise you lose a lot of study cycles to the madness noted above. in smaller numbers this can work though - say exploring placing 3 or 4 cuboids; but if you’re exploring between 3 and 4000 you’re not going to get good results.
Which leads us to the question of ‘how to arrange the boxes’ based on a pattern rather than a manual control. This is doable thanks to the seed based Math.Random methods which were added to Dynamo around version 2.9. However this also relinquishes a portion of the control to that predefined pattern. The attached graph is an example of this where I’m stacking the resulting patterns. These same patterns can be manipulated in the XY plane, the along a curve (more or less what I did here, but my curve is a straight line), or even in a concentric radial form (somewhere I have a graph which does this quite nicely that I don’t think I ever published).
N Box massing.dyn (74.3 KB)
All of that said, the means of manipulating the pattern is what matters, and why we need to understand more of what you hand in mind.
If youre just stacking boxes sure. Im thinking moreso if youre trying to clump them in plan, or amalgamate them into a form, more like the autodesk sample.
I used 3Box massing to nBox massing as an example since everyone knows the 3Box massing example. but I would like to know in general how to avoid having to duplicate all the sliders (U, V, rotation, + many more) for each piece of geometry I want to add.
If you would generate n inputs using a math.random woudn’t generative design have a hard time optimizing the results? since each a change to one block would have unintended changes to another?
I want to build a graph that can populate a site with different appartment buildings with different variable values. The problem is i dont know how many buildings I would need in advance. so optimizing for the optimal number of buildings would require me to run multiple studies and somehow comparing them to eachother, manually adding the nessesary sliders each time.
the number would be between 1 and 10
Thanks
Yes. Effectively the use of ‘Random’ of any point means you get into a situation where there is no pattern to explore; however if instead of the seeded random you used your own pre-defined pattern that isn’t the case. As an example you can take XY values of (1,1), (1,2), (1,3), (1,4), (2,1), (2,2), (2,3),(2,4), (3,1)… and have a single List.GetItemAtIndex value pull that combination of variables. This can continue to whatever level you want to go, with the fidelity set at the step you define. The only drawback with this method is that GD will take longer to find that optimum.
Too many unknowns for me to help guide you here - can you provide a few sketches of what you’re after? It may be that working with a list permutation and then populate is the right method, or it could be that cellular division is the right call. Hard to say without seeing what you are after.