ComponenteDevoto_Prototyping process (part 2: data out of geometry)

Departing from the last post, i continue explaining how it is possible to sort data out of geometry. I will talk to mr. Devoto soon departing from what i've produced, in order to understand how to make a prototype for ComponenteDevoto.

1_family modeling

Before importing geometry i've been able to model thanks to RhinoGrasshopper, I need to produce a tool which "read" geometry data and convert it in other data such as:

• fabrication data
• material amount needed 
• weight and cost
• 3d views and drawings for communication
• papers to talk on once we'll be at Devoto's

That's what a Revit family can beutifully do.

I've therefore modeled a line-based family: this gender of family is able to read a parameter (Line Length) which does not come from the family itself, rather it is an element of the outer project geomtery. What i want to do is collect this instance parameter and use it for purposes above.

This family has two types, dividers and lamelle (sheets). Each one has its own type parameters and visualization, but they could come from the same line: which mean that i make "the same move" for placing both types, while i can choose parameters coming out of type (such as thickness) with just a selection.

Family parameters are connected with instance dimensions only: Heigth (type), Thickness(type), Length (instance).

2_project modeling

Once i've modeled this family i open it in a new project. What i do now is importing Rhino geometry. I choose a .SAT (ACIS solid) format, so i export this file in rhino and import it in revit.

Placing line-based instances: just pick an imported geometry edge and create an instance. Each instance collect the edge data (length), carries his own other data (such as heigth or thickness), both can be elaborated into new parameters such as area (for cost) and Volume (for weight). 

Manually clicking on edges is preferable to populating imported geometry via scripting: thus i can check it. Otherwise, with visual script + script, some stupid mistakes can occour and farewell to good design.

Thanks to this Semi-automatic process i get soon schedulig for both data design and fabrication data. I create project parameters (unit cost and unit weight) and calculated parameters (cost and volume).

Imported geometry has tolerance measures: but these are one order of magnitude smaller, therefore it is easy to set schedule values (which WILL be exported) in order no longer to keep this information.

Furthermore, since lamelle and dividers are supposed to be cropped out of panels (which implies that thickness is a material's propriety), i can export a schedule containg how many X x Y pieces of that type i want to cut (since i know panels' dimension, i can say how many panel i need).

Together with STL file exports, i've now all fabrication data for this prototype. This is just a rough export.

Schedules are not complete yet. Thus because .SAT import does not carry own parameters, and therefore i do not know what's base volume or footprint dimension.

So what i do is importing both base and top.SAT geometry (which is "invisible to schedules") into a new family, which has two types with its own paramethers. Please note that i insert parameters manually out of rhino's file.

What i do now is importing the family, superimposing it so .SAT geometry already present in the model and group the two of them.

Why not just creating base-top families and model lamelle and dividers out of those ones? Because like this it is not possible to just pick up lines, it is necessary to draw them -i don't know why. We can say that families are associative to .sat geometry, while it is not to another family -even better: we should set contraints to other families (no thanks), while to.sat geometry these are implicit (yes please!!).

Here i can create nice sheets and go talking to mr.Devoto.