precise) that unfortunately has more than one staff. This means that I pay the bills (unfortunate to the max). Practice is vertical meaning no Structural/HVAC etc services.
2. AEC Projects are made by teams. Period.
3. Teams are organized with some sort of hierarchy. Period.
4. On each team there's always one leader. Teams can being sampled in group teams - call them clusters (kinda like a List of List of ...)
5. All cluster leaders report to the supreme human being (yours truly). Leader heads are always on my disposal (it's fun to decapitate someone: I do this every Monday).
6. AEC projects are made with 1% idea(s) and 99% of what we call "sludge" (this is not my job: I'm the One , he he).
7. You can't steer any boat if you don't know each @@$#@ nut and bold. In the past there was a naive approach on that matter (ruined automotive companies, potato chip makers, software vendors, political systems, secret service agencies ... etc etc).
8. Efficiency is above all (even above tax-free cash).
9, You can't do ANY AEC real-life thing with what GH has to offer (nor Rhino is an AEC BIM app - it would never be). You simply use GH as a supplement to Generative Components (and/or as stand alone because it's good fun). There's nothing that GH does (I'm speaking solely for AEC as always) that can't being done with Generative Components.
10. I've done so fat 257 projects (a "bit" bigger than a house, he he). Let's say about 51427 drawings (master, master details, details) and 78956 lines of text (specs, cost estimations, space schedules, supplier lists, contracts, cats and 1 dog).
If you combine all the above you'll have the answer (i.e. why I use solely - if possible - code and not GH components). If you can't combine them I'm sorry.
PS: C# is the absolute standard (never judge a language as a "stand-alone" thingy).
best, Peter (Prince of Cynics)
…
he past Architecture was the art of sketching: some "idea" with pencils/crayons + vellum paper (or with some computer) > then "others" trying to make this happen. This in general is known as top-to-bottom approach. Naive and dangerous (for the reputation/reception/acceptance of Architects/Architecture) to the max.
2. These days we work both ways: whilst some work on some "idea" (called it: "assembly") others (in sync mode) resolve the bits and nuts of that "idea" - up to 1:1 level of detail (called it "components"). This is the bottom-to-top approach. Make this your way: NEVER proceed in something whist's not EVERY bit of that something is well addressed (with at least 3-5 ways).
3. The emergence of parametric (GH, Generative Components, Dynamo) in AEC (an approach well known in MCAD word many years ago, mind) made things ... worst: the tremendous topology exploitation capabilities blinded people's mind and they are completely sucked up by the forest forgetting/by passing the critical fact that there's no forest without trees.
4. That's expected: is in the human nature to follow/admire the blink/glam and omit/skip the humble. It's the easy way you know, he he.
5. The tremendous growth of countries the likes of UAE/China/Russia made AEC things ... even worst: lot's of cash available > make us some encomium to Vanity, forget Modesty. You can replace "Vanity" with "New Frontiers" ... if you like fooling yourself.
Some Academics are not capable to understand all that: if they could they would potentially operate in the field (where the pink color is rarely used) and not in fishbowl(s). Some Academics believe that an "idea" is the 99% of the whole whilst actually is less than 1%. But on the other hand anyone can do Architecture (even Architects, he he).
That said (Vanity crisis) you want some other "component" options for this case of yours? (starting with "some" dollars more and ending with the mortgage the house/sell wife+kids option).
take care (and kill them all)…
s (and God knows how many in the next case) that's why (other than the colossal amount of time (for no reason) required for creating them ... try to bake them and measure the file size).
3 .Most non pros believe that the thing that matters the most in engineering is the geometry. Nothing could be further from the truth. Is about the 5% (complex real-life cases etc etc - but this one is very simple geometry wise and not that simple with regard the whole "ideal" AND effective strategy required).
4. So I've included in this Rhino file attached a small portion of your frames as input for the second C#: CAREFULLY study what it does and most importantly why: it gives you the clear indication about why you should attack this on an assembly/component basis by using instance definitions INSTEAD of recreating 14++ K "solids". The difference in performance is COLOSSAL, not to mention the baked Rhino file size.
5. Using instances is IMPOSSIBLE whiteout code (as is the case in 99% or real-life engineering tasks).
6. Geometry was never an issue on that one (is the 5% max of the whole puzzle no matter requirements you may have).
Bad news:
1. Zoom extends doesn't work after importing your data (maybe a NVidia Quadro K4200 driver issue - who knows?): use saved views stored.
So ...the choice is yours, best, Lord of Darkness…
ponents, among other functionalities, is significantly widening the relevance of the toolset.
Meanwhile having used the tools for some time now and have gone through the forum, in my opinion a few critical system controls is still missing - unless I'm missing some understanding.
In order to really make the hourly energy analysis valuable in early massing studies etc. the consideration of indoor climate can be more detailed. The HVAC capacities, max. airrate and min. inlet temperature should be within comfortable ranges and hardsized by user input to reduce internal draft problems. If not considered I find that the analysis could possibly demonstrate good energy behavior and reasonable operative temperature but in reality could cause a bad indoor environment - and when "rectified" at a later stage the energy consumption will increase.
I would like to know how it is possible in HB to set-up a HVAC system with these ventilation controls and a "unlimited" convective/radiant heating system, and how to deal with the issues mentioned below. The inputs parameters exists in the components, but I can't seem to get the right system behaviour.
In the attached file I have gone through 4 scenaries, each with seperate issues in setting up the system (As no template appearantly supports the combined setup the heating system is simulated using an inlet temperature of 99 degrees).
HVACSystem: "ideal air loads" - Issue: no hardsized airrate, no cooling supply air temperature
HVACSystem: "VAV w. reheat" - Issue: no regulation of airrate, no use of input heat supply temperature in heating mode
HVACSystem: "idealairloadsystem" using "additionstrings" -> issue with duplicate zone names
HVACSystem: "idealairloadsystem" using "additionstrings" on multiple zones -> issue with duplicate zone names
Thanks a lot!
Jon…
onents (radiation, sunlight-hours and view analysis) which let you study the effect of the orientation of your building and the analysis result. When you come to a question similar to "what is the orientation that the building receives the most/least amount of radiation?" is probably the right time to use this component.
HOW?
I'll try to explain the steps using a simple example. Here is my design geometries. The building in the center is the building to be designed and the rest of the buildings are context. I want to see the effect of orientation on the amount of the radiation on the test building surfaces from the start of Oct. to the end of Feb. for Chicago.
First I need to set up the normal radiation analysis and run it for the building as it is right now. [I'm not going to explain how you can set up this since you can find it in the sample file (Download the sample file from here)]
Now I need to set up the parameters for orientation study using orientationStudyPar component. You can find it under the Extra tab:
At minimum I need to input the divisionAngle, and the totalAngle and set runTheStudy to True. In this case I put 45 for divisionAngle and 180 for the totalAngle which means I want the study to be run for angles 0, 45, 90, 135 and 180.
[Note1: The divisionAngle should be divisible by totalAngle.]
[Note 2: If you don't provide any point for the basePoint, the component will use the center of the geometry as the center of the rotation.]
[Note 3: You can also rotate the context with the geometry! Normally you don't have the chance to change the context to make your design work but if you got lucky the rotateContext input is for you! Set it to True. The default is set to False.]
You're all set for the orientation study, just connect the orientationStudyPar output to OrientationStudyP input in the component and wait for the result!
The component will run the study for all the orientations and preview the latest geometry. To see the result just grab a quick graph and connect it to totalRadiation. As you can see in the graph 135 is the orientation that I receive the maximum radiation. Dang!
If you want to see all the result geometries set bakeIt to True, and the result will be baked under LadyBug> RadaitionStudy>[projectname]> . The layer name starts with a number which is the totalRadiation.
Mostapha…
her people) a tremendous amount of time creating them by hand. Dog Treat was far from perfect, however it was good enough to use almost daily.
Three years is a long time. Since 2016 my Gh knowledge has expanded and I’ve seen how dodgy some of the scripting is. With this in mind I started work on a new build. Many things have been tweaked and some things have been rebuilt from the ground up.
Everything has been designed to be leaner and be a general solution to the problem of creating dog bone corners on geometry for quick, efficient and safe CNC fabrication.
Some of these things are:
Adding prompts about user geometry to make them aware about open curves, varying curve heights and if their geometry had been altered (mostly removing unnecessary points on curves).
Smooth Transfers. If you’re in a rush and need to speed through cutting, smooth transfers mean that a lead in geometry is now created alongside the actual dog bone arc. This means the router bit doesn’t have to come to a minute stop at every corner. This is turned on by default.
Acute Angle Condition If the angle between the two curves adjacent to a dog bone point is acute, previously the dog bone corner was useless. This was because the distance between the end points of the dog bone arc were less than the diameter of the router bit. There are many ways this condition could be addressed. I chose to circumscribe a larger arc based on the original angle between the adjacent curves. While it removes more material from the corner, it minimises tool wear and any potential for material to burn.
Single Curve A single curve can now be input into Dog Treat. It will be output with both internal and external treatments.
I’ll continue to update Dog Treat as the need arises, it’s become somewhat of a hobby now. Maybe one day it will become part of a Plug-in… once I learn to code it though!
Happy Treating!
Hi Everyone,
Here's a tool I've been working on for the past 4 months or so in my free time. It's a dog bone corner generator, however it's a little different to some of the existing ones. It's designed to be used for large amounts of geometry and as such, it avoids using any curve boolean operations that are computationally taxing. You don't have to split your curves up into internal and external lots either, it works it all out so you can be lazy. I've also incorporated Lunch Box's Object Bake Component for a one click operation that bakes geometry back out to Internal and External profile layers.
Let me know how it goes, will update where necessary.
Best,
Darcy
Change Log
06/11/19 - Version 2.0 SECOND DINNER - Rebuild
29/09/17 - Version 1.3 - Now with smooth corners option, True for smooth default/False for original
18/05/17 - Version 1.2 - Now includes variable angle domain input (defaults at 90°) for angled corners
13/11/16 - slight change to enable acceptance of very large interior curves
…
Added by Darcy Zelenko at 8:44pm on November 9, 2016
string may contain any number of curly bracket pairs with non-negative integers in them:
"When {0} brings back {1} days and {2}"
The number inside the brackets refers to the data to insert in that location. In effect, {x} is a placeholder for actual data. The data inserted into a specific bracket pair is the data supplied in the latter part of the function. {0} refers to the first item, {1} to the second, {2} to the third and so on ad infinitum.
If I supply some data the entire expression may look like this:
Format("When {0} brings back {1} days and {2}", "Spring", "blue", "fair")
which will result in the string "When Spring brings back blue days and fair".
If the data you're inserting is a number (or a date) then you have additional formatting flags that you can use. These additional flags appear behind the placeholder index integer separated by a colon.
Format("Pi = {0:0.00} ({0:0.000000})", Pi)
The :0.00 means the number will be formatted using two digits. The other flag will enforce six digits, resulting in: "Pi = 3.14 (3.141593)"
--
David Rutten
david@mcneel.com
Poprad, Slovakia…
Added by David Rutten at 3:00pm on February 3, 2013
n the inability to be a real-life member within a parametric workflow (same kind of issue with Evolute Tools Pro).
As regards strictly AEC matters the main problem with GH is Rhino itself (not feature/constrain driven, not a solid modeler, not AEC oriented by any means and not biased towards assembly/component modeling). Other than that and due to the known GH inability to handle/manage blocks/nested blocks at bake time ... well... I hardly can see how "to set up work flows between different tools such as ..."
I'll post soon 5 - rather "trivial" - AEC cases that are totally undoable (shop drawing level) with anything other than CATIA (or NX).
BTW: since international practices grow and grow in numbers these days (and individuals are dead) I can't see any realistic limitation for creating dedicated teams (kinda like Frank Gerhy did) that can easily deal with the "extremely heavy" nature of the beast.
BTW: this is a job ad (Project Architect role) from one of the biggest US AEC practices (rather a corporation, he he)
How things change these days ... don't you agree?
best, Peter
…
nette for years.. but without the nice GUI. It also allows combining constraints solving to be part of the DAG.
What is parameterics? Or parametric associative as GC has been described. Can't remember. History or procedural modeling? Even constraints solving or rules based solving all use parameters. Is it generative or merely parametric? I guess the difference is a parametric door doe not generate other parameteric doors?
BIM has opened the door to a more data centric view and manipulation of the design model. To old skoolers a wall is a linear construct that can be abstracted into parameters... beginning and end points of wall in plan + height and thickness. But start adding other stuff and need to ineteroperate with others and things get problematic.
Pretty soon, all those abstractions (parametric or otherwise) need to be structured and you end up talking about schemas etc to control the format of the parameters using rules as checks or constraints..so that your parameters can interface with parameters from others without causing data quality issues. It all gets very database thinking like.
So, I would say parametrics as GH does it is more free form and ad hoc and at some point if it goes BIM, the parametrics will be need to be (re)structured..
BIM is dependent on IFC development which is not very fast. IFC4 is only beginning to think about parametrics and 'Design Transfer'.
…