Here you go! Take a good look at this image above. I found this graph here. It is about the construction industry in general very much INCLUDING ARCHITECTURE. I just really felt like posting it, what a freaking shame! Why the heck do you think it is? Is it our arrogant attitude to technology? C'mon man, we are still drafting lines, redrafting, trimming, filleting (yes, not much has changed since the 18th century)...
So, negative values in family parameters. I am sure most of you know how to deal with this problem, but I still wanted to get it out there for those that don't. By the way, this is my approach to dealing with this issue and I suspect that is not the only way of doing it so if you happen to know a better one – please share in the comments!
Ok, family parameters CAN take negative values, however once they are assign to a dimensional constraint – they won't accept any negative values and will give you a “Parameter Offset has an invalid value.” error. Below I created a simple family where I nested another one that has a red cube in it. The goal is to constrain this cube to the Left/Right reference plane and make it move from “Negative” to “Positive” side with a single “Offset” user parameter that can take both : negative and positive values.
The solution comes at the cost of adding an extra Reference Plane (on the “Negative” side of the “Left/Right” ref plane) and two additional (non-user) family parameters with formulas that will drive the location of the box.
We need an additional reference plane on the “Negative” side of our “Left/Right” ref plane. This new plane needs to be constrained to the “Left/Right” one. Then the ref plane that our box is aligned to needs to be constrained to the new “Negative” ref plane (see image below).
Now, all we have left to do is to create family parameters that will drive these dimensions. User will only be allowed to tweak one of them – “Offset” parameter, which will be able to take either negative or positive values. Then we need one parameter to drive the “Negative” ref plane – I will call it “_negOffset” and another one that will drive the actual plane that drives the red box – I will call it “_posOffset”.
So, the idea is that we need to figure out whether user plugged in a positive or negative number. Depending on whether the number is positive or negative this will assign an absolute value of this number to one of “_negOffset” / “_posOffset” parameters and set another one to ZERO. Here is how you want to express this in formulas:
“_posOffset” = if(Offset > 0', abs(Offset), 0')
“_negOffset” = if(Offset < 0', abs(Offset), 0')
These two parameters drive the location of the box by checking if the value supplied by your user in the “Offset” field is below or above zero. all you need to do is to assign them to the dimensions…
In this series of posts I am going to cover a few "other" ways utilizing
masses in Revit projects. Not necessarily in the traditional sense of using
them like driving the “by-face” creation of the building elements (floors,
walls etc) or modeling geometry that is more complex than the project elements
can handle, but using masses as utilities elements or helpers for your project
development. I will cover at least two examples showing how masses helped me
out in my day-to-day Revit work to resolve certain things in Revit project
environment. I’m going to have at least one API and one non-API example. So,
hopefully based on these examples you could come up with some other creative
use for Revit masses that will save you either lots of tedious work or
additional coding time.
Ok, the first example is a non-API one. Basically the
problem that I ran into is that the apartment building that I’m working on has
funky balconies that are wave – like and thus are different on each floor. The
slab profiles are driven by 3d mass which consists of two extruded boxes that
define the “skin” boundary and a bunch of “curved” wave – like shapes that
drive the location and the profiles for the balconies. The slabs are defined
“by – face” so when we change the mass the slabs update to their host mass
floor. Take a look at the picture below to get the idea.
slab driving in-place mass
So, basically adjusting the balconies after each change in
the apartment layouts becomes a free – form exercise, however we still need to
comply with certain rules like the Min/Max depth of the balconies (we have ours
at 4-6 feet). That is exactly when utility masses will come in handy because
when you manually editing the profiles of these shapes it is hard to tell whether
you satisfied the Min/Max depth requirements.
offset parameter from the face of the shell
The graphical workaround for that is to create an in-place
mass that corresponds with the shell of the building (in my sample case it is
just two rectangular boxes) and drive the location of the ref lines that
generate profile for the extrusion with an instance offset parameter.
Left: Max offset (6ft) Right: Min offset (4ft)
Also
create an instance parameter for material of the extrusions and link the
material of the boxes to it. Then you can create an exactly same in-place mass so you have two of them in your project – one will show the Min
boundary for the balconies and another will be your Max boundary. Create 2
materials of different colors and set their transparency to 50%. Now assign one
of them to the instance parameter of your “Min” mass and another one to the “Max”
mass. Lastly set the offset instance parameter of Min mass to 4ft and Max mass
to 6 ft – and that is about it.
Now when you do your free-form editing in the
in-place mass that drives your building geometry (shape of slabs in my case)
you just need to keep these two masses visible and you will always see the
extent of your constrains projected on your building elements (mass floors or
slabs in my case) so you can do all your editing in 3d view and not have to
measure anything.
Free form mass profile editing. Notice that you can clearly see the boundaries of our 4' and 6' constrains
The great part of it is that since your utility masses are
properly constrained and parameterized you won’t have to worry about editing
them no more other than maybe changing the offset parameters’ values if your project
constrains change.
This is a very specific example and chances are that you
might not have to ever deal with this particular problem in your life. But, the
only reason why I brought it up is to show that masses in project environment
can be used not only as what their main application was intended to be like
driving project geometry etc, but also as helpers/utility objects for all kinds
of purposes due to the fact that you can parameterize the heck out of them…
It came up in the office a few days ago that we were needed to apply some random pattern on a façade somehow. I went online and tried to figure out if there was a way to somehow apply a pseudo random function in instance parameter formulas or at least to figure out some kind of hack on how to mimic the randomness with family functionality. I know that random component in Grasshopper is a very popular one but I didn’t find anything Revit related, so I decided to write my own randomizing tool for Revit. Random pattern trick is being used very often by designers so hopefully this will save a hassle of mimicking random behavior “by hand”.
The way it works – it lets you locate the instance parameter that you want to randomize among the family instances in your document by selecting the Category, then Family and then Type of your objects. That will give you list of all the Instance Parameters that you are allowed to select from. It works not on all Parameter Types but only on those that make sense such as:
-Integer
-Number
-Length
-Angle
-YesNo
So the only parameters that you will see in the Randomizer’s parameter list will be the ones of the types listed above.
Although only these parameters are accepted you can virtually make it work with any Parameter Type by hooking them up through formulas to parameters of the allowed types supported by the Randomizer.
Once you check the one of the parameters that you wish to randomize you will be allowed to set the domain range for the pseudo random value. Also, in case you need the output values of the parameters on Number, Angle or Length Types to be round numbers make sure to check the Force Round Numbers check box. Then you can click Add to List button which will add the parameter and its random value domain data in the list of parameters that will be randomized. If at some point you changed your mind and want to remove a parameter from the list – just click the delete button next to the parameter you want to remove.
Another thing to mention is that you need to have all the family instances that you want to be altered to be visible in the active view. Those instances that are hidden in view won’t be taken in consideration by the Randomizer (if they are Temporary Hidden they WILL be affected).
Oh, and one more thing – it does not work yet on instances that are sitting inside external .rfa files nor inside In-Place masses for the reason that the parameters of these instances are read-only in the project mode. But I am planning on solving this issue as soon as possible since that would probably be the most valuable use for this tool (say randomizing parameters of Curtain Panels by pattern etc).
If you are interested in “test-drivng” this tool just send me an email to request it on dchiriacov [at] gmail [dot] com and I will email you back the files and the tool. It would be interesting to see the results if you end up experimenting with it, so send back images and don’t forget to mention the author ;).
Wow, it really has been a while since I posted anything here
since the last time. It’s been almost half a year or so. I felt bad about it
the other day, but here is the thing: it’s been about three month or so that I
started taking train to work. It takes me about 105 minutes one way (!) so in
total I spend about 210 minutes in commute each day, which is not really that
bad of a thing once you get in the rhythm of it. It is definitely not as bad of
an option as driving (sitting in traffic even for a half of the commute time).
At least on the train you can get some stuff done – which is a good thing
(assuming that you are not playing ‘solitaire’ or being absorbed by ‘fb’)! So, what I usually end up doing is either
doing some office tech related research, or some personal research / coding,
often do some web work for my fife’s totally awesome project, I also spend a
good amount of time coding firm-related Revit custom API-plugins .
So, I thought that I should dedicate some of that ‘productive’
train –time to writing some posts on what I have been up to lately. We recently
made a switch / trying to transition to Revit in the office so 3 projects that
came in within past few month were all started and being progressed in Revit
which is exciting. Also starting to work with energy modeling tools, which is
even more exciting. Therefore I am hoping to post several blog-posts on Revit
API functionality, how we are trying to extend our Revit functionality, and how
it has helped/affected/enhanced our workflow. I’m by no means a Revit API
expert – I really started using it a couple months ago when we needed to
eliminate certain repetitive tasks on a project. But hopefully this will
demonstrate great potential and flexibility of (almost latest – 2011) Revit API.
I am telling you –
there is great potential in the mix of Revit API and Family functionality. When
you combine these two together plus some ‘out of the box’ thinking you can do
all kinds of thing with Revit. Another thing that I noticed that to tackle
Revit API coming from RhinoCommon/Grasshopper background is very rewarding and
odd at the same time. Odd because most of the things you end up doing with the
API is not geometry related at all and a lot of the times (of course depending
on what Revit plug-in you write) you would write a Revit tool without having to
access any rvt Element’s geometry at all.
Anyhow, stop by very soon for some Revit API and recent GH work that I
have been doing lately.
I have not had a chance to use Galapagos before but
fortunately two days ago I started to mess around with it. I decided to test it
but I wanted to set it up for something that would resemble some real-world
arch/design related problem. So here I wanted to share this experiment related
to space planning.
I have 3 rooms with “T”-like corridor configuration bound by
some rectangular zone with set dimensions. RoomRed and RoomGreen rooms have one
door each and the RoomBlue has two doors. The goal was to set a few
requirements for the plan configuration and areas and let Galapagos give me
options to choose from that fit all my requirements. I started with a few
condition but then quickly realized that I needed to supply more to narrow down
the option since the pool of solutions was too big.
So basically I ended up with 12 requirements to the optimum
floor plan configuration. Each of them I expressed as true/false output and fed
the result into the MassAddition component to give me total score of the
“success –meter”. The thing is that one
needs to supply only one number to the “fitness” parameter (as far as I
understand), meaning that in case you have a very complex / twisted set of
parameters to check for in one run you’ve got to be rather creative about how
you “squish” them all into one number. I might be very confusing from the
beginning but it actually gives you a lot of freedom in how you express your
requirements to the solution.
So, back to my definition:
Conditions that Galapagos needed to satisfy/check against
(In Each True worth 1pt and False worth 0pt):
0 - RoomBlue must not occupy more than 60% of combined roomArea
(total – circulation)
1 - RoomBlue must be at least two times larger than RoomGreen
2 - RoomBlue must be at least three times larger than RoomRed
3a - RoomRed must not be much smaller then RoomGreen (not
more than 20% difference)
3b - RoomRed must not ALSO NOT be larger than RoomGreen
4 - circulation area must not exceed 15% of combined room area
5 – corridors must not be narrower than X (slider value)
6a - redRoomDoor must be almost in front of the corresponding
blueRoomDoor1 (distance from door to door is not more than CorridorWidth*1.5)
6b - greenRoomDoor must be almost in front of the corresponding
blueRoomDoor2 (distance from door to door is not more than CorridorWidth*1.5)
6c - the doors of the BlueRoom must be at least (X*CorridorWidth)
away from each other
6d - the doors of the BlueRoom must be not be further than (X*CorridorWidth)
away from each other
So total is 12 conditions thus to satisfy all these
requirements Galapagos needed to optimize the solution up to 12 points (the max
possible fitness value would be 12).
The main sliders that I supplied for the “genome” are:
- U and V parameters that move this “T” configuration inside
the zone boundary
- rotation of the zone boundary
- parameters for door locations on the perimeter of each
room (door are free to be located anywhere on rooms’ perimeter)
- corridor width
I have done a good amount of runs and the solver would come
back to me with quite a few solutions (that completely satisfied all the
requirements, thus had fitness 12) during almost every run (except for a couple
of ones that crashed on me). As you can see from the run on the video I had to
stop the run half way because Galapagos by that time already found 3 solutions
that had maximum possible fitness value of 12 (meaning that every one of the twelve
requirements that I set up returned TRUE), so I didn’t really want to continue.
You can see that all the requirements were satisfied as far as the
relationships among the areas, door locations, corridor width etc.
This might not look like a very complex problem but it sure
shows that Galapagos can be used to solve more complex problems. Healthcare
planning for instance can be a great example – I can see how this type of
approach can have a huge potential to optimize very complex hospitals’ plans.
I have been working on some Revit API lately related to building performance tools and integration of analysis software. For now it looks like it is going to be some collection of handy Revit tools. I have a few questions that I put in the form of a survey that hopefully will take me a bit further in my work. It is no big deal (I think about 10 questions or so) and should not take much time at all in case you decide to help me out and fill it out.
Your opinion is very important to me, so if you are a BIM user I'd like to ask you to click on the link below and fill out my survey. Click here to take survey
Thank you very much for your time!!!
To produce a system that will work with input program by
computing its components’ position, orientation, size and inter-relationships
within an envelope (task domain), and thus to get the most suited/efficient combination
for existing conditions.
SOLUTION
This software (the program solver) is written based on the
Emergent Behavior Algorithms / Evolutionary Algorithms. An idea that all these
systems have in common is that they are concentrated on creating the rules for
the behavior in general rather than programming the end result. This means that
the result is unpredictable in most of the cases, but it always emerges out of
the interaction between the components of the system and their personal
properties Program Solver is a flexible class library (written in VB.NET)
written for the purpose of being able solve program arrangement in a building
based on client demands and referenced environmental data.
IN GENERAL
In a few words, this is a GH definition is useful when you
have an initial building envelope and a rather detailed program developed with
environmental/area requirements per each program component (say, you know the
area that it needs to occupy, should it be in a noisy part of a building or
not, how much solar access you need for this space, wind-wise etc). Then you run
several analyses for this envelope outside of GH (like ECOTECT, Wind/CFD
software etc) and reference these spreadsheets in the GH document. Then you set
up your requirements for each program components. Then you run the solver and
it starts computing a bunch of appropriate solutions for your requirements and
gives you the diagnostics (how much it suites in percentage your “perfect”
setting scenario) – then voila – you have a number of solutions with diagnostics
for each so you can go ahead and discuss on the one that you will proceed with…
Just wanted to mention that I updated my curtain wall project material on
MyArduino blog. So, go ahead an check it out...
http://dimak1999arduino.blogspot.com/
Exciting times! This might not look like a big deal but it is my first evolutionary system that I built myself, so it is actually a BIG deal for me! I am currently working on a building program solver for my thesis project. It will be a chunk of code based on evolutionary algorithms/principles and it is supposed to have program components as Simple Agents with their requirements as settings, a building volume/envelope as a system domain and analysis data (Solar, CFDwind velocity, Noise/Acoustic data) mapped on the envelope as a reference (target) for the “Agents’” properties. So, it will be randomly initialized and then these Components/Agents will have to iteratively adjust themselves within the building envelope.
Well, since I had never dealt with Evolutionary Systems before and they are kind of tough to digest for “mortal” folks like me I decided to start with something a bit simpler. Oh, and also apart from understanding the way the system work I’d also have to dig into the OOP and ideally build a class library (.dll) to solve that. And taking in consideration that I had never done that (I mean, I dealt with OOP only within GH RunScript()), so I figured that I’d practice and see what I can do about it with a simpler system but as well evolutionary based.
So, I build a .dll with 4 classes: SystemSettings, Zones, Cells and Agents. Basically the logic behind this thing is that there are 1X1 Cells that define a “pixel” for agent movement. There are Zones (bigger square cells) which centroids act as attractors for the Agents. Zones get their attractor value during the initialization either random within a set range or each of them get the same val. And then, depending on how many Agents are located in each Zone they either decrease their attractor value or increase. Agents are the only guys that are moving. They look for a closest Zone centroid (the distance is not only the distance but (dist*attractVal) so the closet centroid doesn’t mean that the agent will be attracted to it. Well, it is fun to see which zone wins and by tweaking the settings it’s interesting to observe how they affect the whole population.
The most important thing is that I actually feel more comfortable dealing with these kind of algorithms and their complexity because in the beginning I thought that my head would explode-it feels like you understand the way it works in theory but you have no clue how to approach it. Plus I got some library building experience (still not much, but hey.. one step at a time). I can share the DLL and GH code if someone is interested. Just let me know.
This exercise was conducted to run solar exposure analysis on my building envelope and to produce flat fenestration panels with the apertures that correspond to the exposure values. The NURBS surface of the envelope was triangulated and the solar radiation analysis was run on it. Then the values of //DIRECT
SOLAR RADIATION// were extracted to Excel file. (please, disregard that on the GH screen shots it sais /TOTAL RADIATION//-the actual model screenshots are built with direct solar radiation) I built a GH definition that takes the triangulated mesh of the envelope as an input and builds a parameterized watertight flat fenestration panels with controllable thickness and with two apertures. All of the components and parameters are adjustable.
Here I reworked the RhinoScript from the previous post into a GH definition. I follows pretty much the same logic as the rhinoscript. The problem that I had with the rhinoscript was that I'd have to set up a loop in order to be able to modify the panel parameters in the runtime and that thing worked pretty slow. Here in the GH definition you can do that and see the immediate effect on the panels. As a note, if your skin consists of multiple panels in order to play with th settings you might want to disconnect the last VB component that generates surfaces and it leaves you with wire frame so it is not too slow on regeneration of the view (in this example I have 150 quads and it is ok). Unlike with the previous RhScript here you need to have your Excel file open and if you opened it after you ran the GH deff just tweak some slider to regenerate.
I wrote a RhinoScript that generates fenestration panel components in response to solar exposure of the facade. Say you have an envelope that you want to create fenestration for. The workflow is that you mesh your NURBS surface (unless it is already a mesh) to a particular sized quads that will be driving your panels. Then you take this mesh through .3ds or some other extension to Ecotect and run Incident Solar Radiation on it. Then you extract the .csv file with radiation values per each mesh face from Ecotect and resave it in Excel as .xls. Once you've done all that you are all set to run the script. So, the script itself generates watertight panels that are based of mesh quad nodes. You set the offset up and down which ends up being the thickness of your component. The panels work of the top and bottom offset mesh nodes and each component is a loft of two rectangles and top and bottom ellipses. They are all parametrized so you get options to set the ratios. Bu the main thing is that the inside ellipse is driven by the solar radiation value - script samples the values from Excel file and scales it accordingly to wherever this value and this particular mesh face falls into the overall range. Highest exposure - smallest aperture// Lowest exposer largest aperture. Top ellipse always stays has the same ratio, though, based on mesh dimensions that it belongs to. Oh, as you might have noticed Ecotect triangulates those quads that you bring in so you end up having twice as many values as you have mesh faces. The code takes care of that in the sense that it takes two neighboring values and 'means them up' to a new array of values. IT ONLY WORKS FOR QUAD MESHES (and you can tweak that if you want). THE SCRIPT PROMPTS YOU TO LOCATE THE EXCEL FILE IN THE BEGINNING. Also, if you output your excel values make sure you delete all the junk information in the header of the file OR rewrite the script to start reading values from where they begin in the excel file.
I also want to credit Ted Ngai for using his Excel connection in my script.
I wrote this one a while ago and wanted to share, so maybe it will be useful for somebody. You don't need to keep the same component geometry and if you wish you can recode it for whatever you want. Let me know if you need anything regarding that.
Here is another tool in Grasshopper. This one outputs ribs. It only works with NURBS surfaces. I was making it with intention for others to use, so I was trying to put as much flexibility and functionality as possible. Maybe because of that it ended up not very user-friendly, but it does the job. I'd advise to put a little time in playing with it (it has a whole bunch of axis swapping so if it doesn't seem like giving you the desired result - just swap axises either the cut directions or orientation on the bed). My intention was to make it somewhat universal in the sense that it would cut:
-open surfaces
-one-way closed surfaces
-and solids (this one is not set up yet)
As you might already know - the approach to these is different so the VB components account for that. As I said I haven't set it up for solids yet, but it's coming soon and I'll post it. There are no boolean solids involved and the notches are drawn of parameter half way of the Brep intersection, so it should be pretty stable. There is a red message box there that tells you what option to set it up for (either "1" - open srf, or "2" - one way closed) and again IF IT DOESN'T SEEM TO BE BEHAVING AS IT SHOULD JUST SWAP AXES!
This is GH definition that works both with polymeshes and with NURBS surfaces. Basically, you just assign your object that you need to manufacture and then go through the settings. You can change the material thickness to control the amount of sections. Also it works of a BBox corners so I parametrized the Start and End of the axis (and you can flip axis to cut veridically or horizontally). This way you can cut only the portion of the model that you need (if you need the whole thing -set the axis to 0-1 domain). You have settings for the sheet dimensions for reference and you can output any sections by number as you want. Also you can move sections on the bed and distance between them. Just play around - it's pretty flexible.
I wrote this using 6.055GH so earlier versions probably won't work
ISSUES: This definition doesn't do anything about the intersecting surfaces - so if your surface intersects itself you will get a self intersection on the section curve.
I'm going to start posting some digital prototyping tools that I wrote in free time. Also some other generative Grasshopper definitions and RhinoScripts that might be of some use.So, I'll begin as soon as I figure where to host them By the way big thanks to Wiley G for sharing the space!
Here is some little attractor script for curves that I wrote when I just began learning RhinoScript. Hopefully it will be useful for some people as a reference to build up on it. Below there is a similar script but for points as an input. I think I modified a script that I found on Roland Snooks website
I currently work as an architectural designer in Miami, FL. There I am involved in the following things:
-Architectural Design
-Revit Implementation
-Development of custom design and project management tool (Revit API and Grasshopper, in C# / VB.NET)
-Development of Parametric Content (Revit Families)
-Advising on /Implementation of Parametric Project Development Strategies
-Environmental Analysis / Energy Modeling (Green Building Studio, Ecotect, etc)
-Technology Research
Apart from that I am trying to stay involved in academia as much as possible.
