nputs to run (please refer to the image)
Currently, here is how I set the data:
protected override void RegisterInputParams(GH_Component.GH_InputParamManager pManager) { //Create default size
double defaultBaySize = 0; pManager.AddTextParameter("LotLib", "Llib", "Lot Library", GH_ParamAccess.tree); pManager.AddCurveParameter("BoundaryCrv", "BC", "Boundary Input", GH_ParamAccess.list); pManager.AddIntegerParameter("Direction", "D", "Direction of gridLines", GH_ParamAccess.item, 0); pManager.AddNumberParameter("CCsize", "S", "Distance from column to column", GH_ParamAccess.item, defaultBaySize); pManager.AddCurveParameter("GridCrv", "GC", "Take in curves input for gridlines", GH_ParamAccess.list);
}
protected override void SolveInstance(IGH_DataAccess DA) {/* Setup */ GH_Structure<GH_String> LotLib = new GH_Structure<GH_String>(); DA.GetDataTree(0, out LotLib); List<Curve> BoundaryCrv = new List<Curve>(); if(!DA.GetDataList(1, BoundaryCrv)) { return; } int Direction = 0; DA.GetData(2, ref Direction); double CCsize = 0; DA.GetData(3, ref CCsize);
List<Curve> GridCrvs = new List<Curve>(); DA.GetDataList(4, GridCrvs); if (!DA.GetDataList(4, GridCrvs)) { return; }}
Is there a way can set data in the way if the component does not receive inputs for BoundaryCrv but only GridCrvs, the BoundaryCrv List will empty.
Thank you very much …
to panelize & planerize in Grasshopper using the Kangaroo plug-in.
I’d like the “funnels” to taper upwards from a small base circle to a larger square. The problem is very similar to the one tackled in another post:http://www.grasshopper3d.com/forum/topics/how-to-get-continuous-panels
So far I have simply attempted to apply the tutorial at the address below to my surface…which resulted in a wild simulation where no equilibrium was reached. I’ve played around with tolerances but to no avail.
Going forward I have some very broad questions:
1. Quite simply; how would you experienced types recommend I model the initial funnel? (Revolution surface? Mesh? Successive lofts?…)
2. Would you recommend paneling with a particular shape? Maybe it is my choice of working with only hexagons that is geometrically instable?
3. Would you apply a different technique than that used in the tutorial below, or simply change some elements? I’ve heard that the Weaverbird plug-in can be useful for use with Kangaroo for this sort of problem?
Tutorial followed: “How to create planar Honeycomb Shells using Kangaroo´s Planarization Forces” by ThinkParametric https://www.youtube.com/watch?v=MsbyfC2usUk
Thanks in advance for any feedback!…
uest Tutors: Olga Kovrikova (AL_TU), Alexandr Kalachev (AL_TU), Tudor Cosmatu (AL_TU)
Materialized Algorithm - Digital Tectonics workshop focuses on finding an appropriate design algorithm by implementing and embedding the material qualities into the design process.
Through the Rhino software tutorials, participants will get a short introduction to the nurbs-surface modeling techniques, which will be further used as a basis for form-finding and component development.
Grasshopper is a graphical algorithm editor tightly integrated with Rhino’s 3-D modeling tools which requires no specialized knowledge of programming or scripting. Sinceits existence it has been helping more and more professional designers to understand and use parametric modeling techniques. This workshop will start with the basic operation of Grasshopper integrating specific examples (Kangaroo, KingKong) which will help develop the concepts into built proposals.
Participants will have to start designing with physical models, creating a constant feedback loop between the physical and digital world allowing for the creation of differentiation and achievement of the desired geometric complexity. Finally a number of maximum two projects will be thoroughly developed and built.
For more information visit:
http://zhan.renren.com/damlab?gid=3674946092080649725&checked=true…
Added by Tudor Cosmatu at 12:28pm on August 28, 2013
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