ructural member. It can only be used as a Veneer / Cladding. You may observe from my sketch that structural member is only a timber frame. Hence we do not need to have a valid bond as long as the brick veneer is tied together with each other and to the timber structural frame behind.
Nevertheless, though i understood the components used in the definition, i only partially understood the logic behind your definition i.e. only until 'Divide Dist' and Extracting the points. After that I did not understand the logic behind using
a) Extracting 40 random values and than using those values as input for Seed to extract another set of 40 random values.
b) Extracting list length, subtracting with random values created in (a) above and then dividing with number 3.
c) Duplicating the Datas
d) The most perplexing is using above logic (a,b,c) to to extract number of branches (number-40) by using Tree Statistics. If number 40 is the input we required for 3rd Random component Why couldn't we connect the List Lenght to Pramviewer and extract the number of branches (40) and connect the output to the Random Component?
e) Finally i did understand the logic behind creating 2 Vector to create the bricks. But i did not understand the addition following the vector.
f) Why do you use the function 'simplify'? - what does it do? I know it simplifies the data tree, but what does simplifying a a data tree do to the entire definition?
Hannes, i know this is quite comprehensive list of doubt, but your help is and will be always appreciated.
Cheers
AB
…
( http://en.wikipedia.org/wiki/Honeycomb_(geometry) )To fill a 3d space you can use structure already existing, like cubic or octahedra and tetrahedra.Starting from cubic structure then (the easiest).
1 - make few(x) random points
2 - 3dArray them
3 - make voronoi cells wih all the points
4 - extract just the (x) cells at the center
now you get x cells with a random shape, but that completely fill a 3d space with a cubic pattern
(the same thing can be done with octahedra and tetrahedra pattern, just its a bit harder to do the array)
Change seed to achieve a decent initial result.
You can then manually "fix" those cells removing small faces.
(by moving small parts of volume to one cell to another)
Those cells will just have a single orientation, the final pattern maybe will still look cubic-ish.
there are also structures with standard cells but non-repetitive patterns:
http://en.wikipedia.org/wiki/Penrose_tiling
but i have no idea to how to apply this in 3d (even in 2d! :S )…
e. What is the interesting thing with these? Well since are created by iterating trough the mesh faces (mesh face Normal * d + flip option ... etc etc) ... their enumeration (order) in the resulting wPtsList list ... is exactly the same with the enumeration (order) of the mesh Faces list.
2. So a ff connectivity Tree [Lord way or Sandbox] (where f(ace)-to-f(ace) actually means: neighbor faces(indices) that a given mesh face has) is the only thing that we need in order to achieve this type of "top" struts layout. Spot the extra crude List.Distinct().ToList() "clean" up method (but why bother? he he).
3. The other way ("top" layer struts - option: ballPivot) well ... it does the obvious.
…
ion of surfaces and/or "solids" : it's a very complex assembly of "components" either bespoke or widely available in the market. This demo combo summarizes the "common" cases (but the insulation for the opaque parts is WRONG 100%):
2. Contemporary trends (a bit of nonsense) point towards "liquid" forms. These ARE NOT made via "classic" linear systems. Very few actually can do it (I mean: do it yielding a building that doesn't leak]). Here's a totally wrong take on that matter from a very reputable Swiss facade maker:
And er ... hmm ... this :
3. Facade systems (curtain walls, that is) are classified in 4 classes: (a) the good old known humble stuff like the one shown in the first image (b) semi structural [yes], (c) structural [NO] and (d) planar frame-less systems.
4. Designing any proper facade is impossible with Rhino/GH: you'll need totally different software apps to do it - in real life - despite what most people believe/hope/wish.
5. Designing anything without a proper bottom-top approach (I.e. : first do the pistons then the engine) is the best recipe for not becoming (ever) a pro .…
) Take it apart, trim holes, connections, and other stuff needed for the fabrication > (c) Make 2d drawings out of them. (d) exporting them
I've got a few findings that might be useful in that context:
1. When using large amount of components, the show selected only is pretty much the weapon of choice to debug. In this context it would be useful if the Custom Preview components (also the custom vector preview component) would not turn green when selected in "Draw Only Selected Geometry" mode, since it turns them pretty much useless in this mode.
2a. A second step up to the same problem would be if turning objects on/off (enable/disable) (preview/disable preview) could be done at the group level. (Perhaps the ZUI-kung fu you've introduced could be the way to go?). This would make creating scripts that can have different stages that do not always have to be enabled a bit easier to manage.
2b. This would of course even be better if the groupwise-enable/disable operations are overrides. (in the sense that a component is only enabled when the group and the component are enabled).
3. Colours. Would it be possible to add a small pallette to the GH colour picker? Right now if we for example pick a convention "Let's make all the functionality that's for debugging yellow, all operating code that should not require messing about with green, and the parts that require human interaction Red", is a bit cumbersome, because picking the same yellow will require me to remember the colour values to get the same colour (The pipet tool will also give different colours)
4. Scribble: Can I please easily align text to 0,90,180 or 270 degrees rotation? :)…
yet accessible features that have been well factored.
I’m impressed with the mainline experience overall. BUT, and this is a huge but, Rhino5 has an absolutely massive bug right in the middle of the engine. I, of course, refer to the Boolean Problem. I’ve put the product down cussing 4 times already after realizing that I’d just lost 3 hours trying to figure out why something doesn’t work, only to realize that I’m up against yet another derivation of The Boolean Problem.
I’m written McNeel tech support about the issue. They’ve offered file-specific workarounds in response. But these workarounds don’t allow a solution that can be used resolve generalized characterizations of the bug in Grasshopper programs. Brian, the support tech I’ve dealt with on this problems goes on to say that I shouldn’t expect any significant fixes for this problem.
I’m shocked that major revision 5 of a seemingly mature product as Rhino is has such a gigantic, mainline bug in the very core of its engine. But even more surprising is Brian’s suggestion that perhaps I’m just not ready for a product like Rhino. He further suggests that I post, as I’m doing here, to see what other people think about this bug.
So what am I missing? Where do experienced Rhino/Grasshopper users find themselves on the continuum between this being a big hairy bug that should have been fixed long ago and my just not being ready for Rhino?
I’ll accept any input and consensus that prevails.
- Bob…
Added by neobobkrause at 2:34pm on October 3, 2016
e below).
Explanation of my intent:
The first input (crvTree) has the exact same data structure as the second input (cell_name). crvTree contains one or more Curves in each branch, while cell_name contains exactly one string per branch.
The third input (system_names) is a list of string data, and I compare the single string from each branch of cell_name and find a match, then return the index of system_name.
So, for example:
crvTree brings in:
{0} bunch of Curves
{1} bunch of other Curves
{2} another bunch of Curves
cell_name brings in:
{0} "curve type A"
{1} "curve type D"
{2} "curve type A"
system_name brings in:
{0;0} "curve type A"
{0;1} "curve type B"
{2;0} "curve type C"
{2;1} "curve type D"
{2;2} "curve type E"
{3;0} "curve type F"
output should be:
{0;0} bunch of Curves (and) another bunch of Curves
{2;1} bunch of other Curves
I'm pretty sure that I can't keep accessing cell_name as an item, but instead as a tree. I was only doing that to first get the strings to match, which I did.
protected override void SolveInstance(IGH_DataAccess DA) { //Declare a new List(Of T) to hold the input text data. string cell_name = "nothing yet"; List<string> system_names = new List<string>(); int index; Grasshopper.Kernel.Data.GH_Structure<Grasshopper.Kernel.Types.GH_Curve> crvTree = new Grasshopper.Kernel.Data.GH_Structure<Grasshopper.Kernel.Types.GH_Curve>();
//Retrieve the whole list of System Names using DA.GetDataList(). if ((!DA.GetDataTree(0, out crvTree))) { return; } if ((!DA.GetData(1, ref cell_name))) { return; } if ((!DA.GetDataList(2, system_names))) { return; }
index = system_names.IndexOf(cell_name);
int index2 = -1; for(int i = 0; i < system_names.Count; i++) { if(String.Equals(system_names[i], cell_name, StringComparison.OrdinalIgnoreCase)) { index2 = i; break; } } DA.SetData(0, index2); DA.SetDataTree(1, crvTree);
}…
ler se han seleccionado un conjunto de técnicas y estrategias para resolver problemas que hoy se presentan en el diseño y fabricación digital de formas complejas y euclidianas.
Bajo dos entornos de trabajo, entre técnicas interactivas y soluciones algorítmicas, se examinan conceptos y casos de estudio que le permitirán al participante decidir como y en que momento estas tecnologías pueden ser utilizadas como aliadas en los procesos de diseño y fabricación. Tomando como plataforma básica Rhino, se explora y optimiza el diseño y fabricación de topologías complejas bajo los entornos de Grasshopper y Paneling tools
En el mes de Julio de 2010 (26 al 29 de febrero) se realizará el Workshop de Grasshopper - Paneling tools en McNeel Argentina,
Contenidos:
1. Modelado Avanzado y sus Tecnicas. Aplanado y Desarrollo de Superficies.
2. Tecnicas de panelizado plano
3. Introducción al Diseño Paramétrico.Definiciones Avanzadas de Grasshopper,posibilidades y limitaciones. Ajustes de escala para impresión y corte.
4. Renderizado basico con Rhinoceros
El workshop tiene una duracion de 24 hrs. (4 dias x 6 horas por dia, horario 10 a 13 hrs y 14 a 17hrs)
Docentes
Facundo Miri - McNeel Argentina.
Se dictara en McNeel Argentina
Ciudad de la paz 2719 3A. - Belgrano - Capital Federal.
Costo del Curso
U$S250+IVA
www.rhinoceros.com.ar…
image with shows some simple usage of the path mapper.
The points worth noting are the following:
1. The "Source" is comrised of a single line notation which EXACTLY matches the existing path structure. This means that if your parameter viewer shows you a path strcutrure which looks like {0;0;0;1;0} (N=4), your source input should look like {A;B;C;D;E}(i). Here, all the letters A-E and i are placeholders meaning that they can be any letters and are standing by for each digit in your path structure. This also means that they could be any letters: {Q;R;S;T;U}(V) would work as well as {A;X;T;B;S}(J). The important thing is that you are identifying each digit (including the value of 'N', the total items in each path).
2. The "Target" is (obviously) your desired path structure. If you want to simply get rid of the zeros while maintaining essentially the same path structure, it is as simple as dropping out those placeholders while writing the target notation. In the above example, if your source is {Q;R;S;T;U}(V), you can use a targe like {S;T}(V) to return a structure which will be {0;1}(N=4) or {T}(V) for {1}(N=4) and so on.
3. if you want to swap the path structure, i.e. if you have 5 paths with 10 items each and you want 10 paths with 5 items each, you switch the placeholders in the source and target notations. for example, {X;Y}(n) -> {n}(Y)... and so on.
I hope that the above is of some help. Please feel free to keep asking.…
Added by Sameer Kumar at 10:29am on December 7, 2009