Refactoring Parametricism

Replies to This Discussion

Permalink Reply by Matthew J Flamm on February 25, 2011 at 12:18pm

@Dennis, yes, paneling tools is an outstanding tool!  I think the workflow you suggest would work as long as the solid desired was not too complex.  Using the two grid method in PT would let you control offset distances and normals.  Great suggestion.

Permalink Reply by Santiago Diaz on February 26, 2011 at 9:27pm

Matt, could you explain how your diagram is meant to be read?

For example, what does the distinction between Grasshopper_1 and Grasshopper_2 mean?

Permalink Reply by Santiago Diaz on February 24, 2011 at 7:55pm

Hi dominic,

 

Replying to the following:

Columns: Looking at your description, the vertical elements were modeled in Rhino, and referenced in GH? 5hrs to get some points on the lines? And using Excel as the design table? I think this could be 'drawn' and constrained in Inventor in a lot less time. I know the GH model would have a lot of flexibility, but in this case, what can you do with it that wasn't provided by an Inventor model?

Only the 27 lines mentioned were modeled in Rhino, the rest is modeled with GH.

The 5 hrs involved thinking about the approach, defining vertical lines, tilts, elevations, pitch of the roof, intersections.

Once I had decided what my approach would be, and tested the logic with those first lines, points and data path arrangements, it only took one more hour to get to this:

 

Which is actually quite fast, compared to MCAD workflows.

 

If you already have components (columns, beams, etc.) modeled and ready to drop into a project, of course it is lightning fast to model simple projects like this example.

I am not as much interested in those situations, because improving efficiency is straightforward and obvious.

I'm more interested in situations where there are no pre-defined families of objects, in which case you need to start from scratch.

The GH model I'm showing is modeled from scratch, except for the 27 lines in Rhino.

 

Here's one obvious advantage to modeling with GH, once the definition is set-up, it's virtually effortless to change inputs and alter the overall design. Here's an example, lets say we wanted to extend the roof 3 more units, curling away from the original direction.

Plan view before:

 

And after:

 

An MCAD app will also allow you to do this, as long as the location of additional elements follows the existing geometric method of definition. What happens if you want completely change the way you locate columns, roof slope, intersection points?

In MCAD, you'll need to re-model the underlying geometry, which will take the same effort as the first round. In GH, this process is not only much faster, it's open to algorithmic approaches, galapagos, etc. and it just takes some simple re-wiring to have all down-stream elements associate themselves to this new geoemtric definition.

 

For instance, here's the same definition applied to two curves, which are divided in GH, the resulting points are used as a starting point for lines directed at normal from curves.

 

This is not so easy to do in MCAD.

Permalink Reply by Stan Carroll on February 24, 2011 at 8:37pm

Santiago,

You have done an excellent job articulating why I love GH.  It is not the initial creation where I find GH so beneficial.  GH begins to earn its keep on the second, third, fourth and fifth schemes of a project. How many designers know exactly what they want when they first begin the model?  Maybe some do.  For them MCAD must be the most productive tool. On the other hand, the design process I prefer is centered around initial ideas that develop and morph over time into something I never conceive of at the outset of the modeling.  In this ever changing process, GH really shines.  In fact, it brings unexpected value to the process; the "happy accident".  Previously, I only experienced happy accidents during watercolor painting.  By this I mean that often I stumble onto something completely unexpected.  In watercolor painting a happy accident is when the paint spreads or bleeds or blends so much more beautifully than you could have ever imagined or manipulating with your brush.  In GH it sometimes happens if I mis-wire a component... or I just push a slider well beyond what I thought was reasonable... Or I explore a relationship variation that can quickly be tested on the way to another idea. These types of software induced opportunities have never been available to me in other software.  This is the magic of GH. 

Permalink Reply by Santiago Diaz on February 26, 2011 at 9:21pm

Stan, absolutely!

 

As I model with GH, ideas come to mind. Some by accident as you described, though most of all by experimenting.

I do think that when my definitions start getting overwhelming, I begin to spend more time looking for a certain component than I do exercising creativity.

This is why I am so interested in "visual refactoring" my definitions, which are in a sense a form of visual programming. It also helps when I am getting back into a definition I hadn't been working on for a while, if it has been organized and optimized, I find it much easier to dig into it again.

Permalink Reply by dominic on February 25, 2011 at 7:56am

 

Hi Santiago,

I am not as much interested in those situations, because improving efficiency is straightforward and obvious.

OTOH, I am quite interested in how tools like GH can be more efficient, especially in real world professional settings, where the 4hr-Revit v 16hr-GH disparity applies way too often. This is not about which tool is better at this point in time.

 

I don’t think how to improve efficiency is very ‘straight forward and obvious’. Sure, there are ways to improve efficiency in GH using families of components that can make GH more ‘MCAD’. But, equally, the reverse also applies.

 

The GH advantages you list stem from setting up and handling the design at a very detailed ‘mathematical’ level. The inputs can be changed easily because they are mainly math variables/parameters, and amenable to the processing using established comp languages.

 

You are right, the definition is very ‘pure’ in this way and can be transferred to things like Galapagos etc. In contrast, MCAD elements are packaged at a higher level, are more like 'grey-boxes', and do not have the ‘visual programming’ interface that GH’s canvas provides. This can change easily, and more ‘ergonomic’ entry points for scripting like iLogic are already starting to appear.

 

MCAD features are still relative ‘pure’, I think, compared to any equivalent BIM features/objects (even Revit ones). Even then, we seeing a lot of rules-based plugins that extend the type of ‘algorithms’ available, beyond the vector/matrix math that GH is already so good at.

 

I think Catia is interesting for GH’s future, as it has been doing ‘algorithmic’ (GH), and the traditional MCAD event-based history/features (RP), and geometric constraints modeling (RhinoDirect), and rules processing, and a few other modeling approaches all under one roof, for awhile. So, it’s not an either/or, MCAD vs GH proposition. You can have both, hopefully in a slicker and more synergistic ... maybe even open source-based way?

 

In fact, I think GH has to assimilate the MCAD way of doing things, without losing its strengths.

 

You mentioned Data Trees earlier. I don’t think there is anything in the MCAD way of doing things that would exclude this. In fact, Data Tress look like they would be easily (re)implemented as LINQ (or better yet PLINQ) expressions. GH will need to start to read (and store) attribute information if it wants to participate in the wider ‘engineering’ world of problem solving. Going out of process all the time to Excel is probably a dead end. Not sure, is Excel managed code these days?

 

I like the way iLogic seems to function like a model-based 'active spreadsheet' that maintains a set of dependencies that link variables via scripted expressions (rules). The user can compartmentalise and assign each spreadsheet to particular (i-)parts of the model/assembly. This is a lot more transparent than the way Revit handles its parameters. Its pretty much like GH's DAG, but coupled to individual models in an assembly.

 

Any chance of describing your experiences with ‘sketching’ in more detail?

Permalink Reply by Dennis Nelson on February 25, 2011 at 8:52am

My experience, which is by no means the level of models that are being generated on this forum, is that I find grasshopper very easy to generate points, lines, curves, even surfaces for structures, but when I starting trying to generate solid profiles for these elements my definition starts exploding into a spaghetti mess, and I start to wondering if I am really saving time.  Could I extrude and sweep those elements in Rhino faster, even if I had to do it a couple times.  

 

I think that having to ability to nest definitions help on this, although that gets into something more like generative components (correct me if I am wrong, because I haven't actually used it).

 

 

Permalink Reply by Santiago Diaz on February 26, 2011 at 9:14pm

Hi Dennis,

My experience, which is by no means the level of models that are being generated on this forum, is that I find grasshopper very easy to generate points, lines, curves, even surfaces for structures, but when I starting trying to generate solid profiles for these elements my definition starts exploding into a spaghetti mess, and I start to wondering if I am really saving time.

 

I think GH can improve how it informs the user on performance.

I really like the Profiler tool. I depend on it with large definitions.

Have you used clusters?

Can you show an example where your canvas has become a mess as you described?

I'd be more than happy to offer some suggestions.

Permalink Reply by Santiago Diaz on February 26, 2011 at 10:36am

Hi Dominic, thanks for your comments.

By the way what is your background and current use of GH?

 

You previously asked:

Why didn't you re-use the geometry as i-parts etc? I am probably not getting the whole design intent, but this is what Inventor is good at. The way it packages bits of 'scripted' components into 'little models' that can be stored and re-assembled is central to MCAD working.

The Inventor model shown is almost 5 years old. We don't model like that any more, however it does offer a good idea of general MCAD modeling approaches.

iParts is useful in certain situations, it could've been useful in the above model, its usefulness is often in function of the quantity of variants/configurations.

So much is scripted in GH, maybe it should also be possible to script/define/constrain/assist the placement/gluing of the results?

...

Starting point: I think we are talking across purposes. AFAIK, the solving sequence of GH's scripted components is fixed. It won't do circular dependencies... without a fight. The inter-component dependencies not 'managed' like constraints solvers do for MCAD apps.

Components and assemblies are individual files in MCAD.

Placement of these within assemblies in MCAD is a product of matrix transforms and persistent constraints. There is no bi-directional link, the link is unidirectional (downflow only), because of the use of proxies.

Consequently, scripting the placement of components is irrelevant in GH, unless you decide that each component needs to be contained in its own separate file.

This also brings up the point that generating components and assemblies in MCAD is not as straightforward. In iParts and iAssemblies, each configuration needs to be generated as a "child" (the individual file needs to be created for each child) before those children can be used elsewhere.

You notice the dilemma, if you generate 100 parts, and then you realize you only need 20, you've created 80 extra parts which you have no need for, thus generating wasteful data that may cause file management issues later on.

GH remains in a transient world, and when you decide to bake geometry (if you need to at all), you can do that in one Rhino file, and save it as the state of the design at that given moment. Very convenient for design, though unacceptable for most non-digital manufacturing methods, which greatly limits Rhino's use for manufacturing unless you combine it with an MCAD app.

 

One of the reasons why the distributed file approach makes perfect sense in MCAD, is that in industry you deal with a finite set of objects. Generative tools are usually not a requirement. Most mechanical engineers, product engineers and machinists would never have any use for that.

The other thing that MCAD apps like Inventor have, is the 'structured' interface that offers up all that setting out information like the coordinate systems, work planes, parameters etc in a concise fashion in the 'history tree'. This will translate into user speed. GH's canvas is a bit more freeform. I suppose the info is all there and linked, so a bit of re-jigging is easy. Also, see how T-Flex can even embed sliders and other parameter input boxes into the model itself. Pretty handy/fast to understand, which also means more speed.

True. As long as you keep the browser pane/specification tree organized and easy to query.

:)

Would love to understand what you did by sketching.

I'll start by showing what was done years ago in the Inventor model, and then share with you what I did in GH, but in another post.

 

Let's use one of the beams as an example:

 

We can isolate this component for clarity.

Notice that I've highlighted the sectional sketch with dimensions, and the point of reference, which is in relation to the CL of the column which the beam bears on. The orientation and location of the beam is already set by underlying geometry.

 

Here's a perspective view of the same:

 

The extent of the beam was also driven by reference geometry, 2 planes offset from the beam's XY plane, driven by parameters from another underlying file which serves as a parameter container:

 

Reference axes and points are present for all other components, here are some of them:

 

It starts getting cluttered if you see the reference planes as well:

Is I mentioned earlier, over time we've found better ways to define and associate geometry, parameters, manage design change, improving the efficiency of parametric models. But this model is a fair representation of a basic modeling approach, and since an Inventor-GH comparison is like comparing apples and oranges anyways, this model can be used to understand the differences and similarities, for those interested.

 

I haven't even gotten to your latest post yet, I will eventually.

Permalink Reply by dominic on February 26, 2011 at 12:51pm

 

Hi Santiago,

 

Thanks for the reply. Looking forward to the next instalment.

 

Placement of these within assemblies in MCAD is a product of matrix transforms and persistent constraints. There is no bi-directional link, the link is unidirectional (downflow only), because of the use of proxies.

 

Matrix transforms and persistent constraints: I don't think this is true. The parts can have mates to other parts that preserve geometric relationships like 'coincident' , 'aligned' etc. These are essentially bi-directional. GH's algorithmic approach does not do relationships in the same / flexible way. In GH, the 'relationship' has to be part of the generation method that dependent on the creation sequence. I.e. draw line 2 perpendicularly from the end of point of line 1.

If you are thinking about parts or assemblies sharing, or referencing parameters as part of the regen process, this is also possible. iLogic does this, and adds scripting. So does Catia. Inventor/iLogic can also access Excel and have all the parameter processing done centrally, if required.

 

Consequently, scripting the placement of components is irrelevant in GH, unless you decide that each component needs to be contained in its own separate file.

 

I wouldn't be too hasty here. Yes, you are right about compartmentalisation. I think this needs to happen with GH, in order to deal with scalability/everyday interoperability requirements. Confining projects to one script is not sustainable. MCAD apps have been doing this for ages with 'Relational Modeling'.

The Adaptive Components placement example illustrates that it is beneficial to be able to script some 'hints' that can be used on placement of the component. Say, if your component requires points as inputs, then its should be able to find the nearest points to the cursor as it moves around. I think Aish's D# / DesignScript demo'd this kind of behaviour a few years ago.

Similarly, Modo Toolpipe reminds me how a lot of UI based transactions can be captured as scripts (macro recorder etc). Allowing this input to be mixed in and/or extended by GH I think will yield a lot of 'modeling efficiency' around the edges. This is a (mis)using GH as an user-programmable 'jig' for placing/manipulating 'dumb' elements in Rhino. It may even give the 'dumb elements' a bit more 'intelligence' by leaving behind embedded attributes, like links to particular construction planes etc.

Even if we confine ourselves to scripting. GH is a visual or graphic programming interface. A lot of 'insert and connect' tasks can be done more easily using graphic methods. If we need to select certain vertices on a mesh as inputs for, say, a facade panel, its going to be quicker to do this 'graphically' (like the AC example), then ferreting out the relevant indices in the data tree et al. The 'facade panel' script would then have some coding to filter/prompt the user as to what inputs were acceptable, and so on.

 

This also brings up the point that generating components and assemblies in MCAD is not as straightforward. In iParts and iAssemblies, each configuration needs to be generated as a "child" (the individual file needs to be created for each child) before those children can be used elsewhere.

 

Not sure what you mean here. If the i-parts are built up using sketches /profiles or other more rudimentary features (like Revits' profile/face etc family templates) then reuse should be fairly straight forward. I suppose you could make it like GH scripting, if you cut and paste or include script snippets that generate the desired Inventor features.

 

One of the reasons why the distributed file approach makes perfect sense in MCAD, is that in industry you deal with a finite set of objects. Generative tools are usually not a requirement. Most mechanical engineers, product engineers and machinists would never have any use for that.

 

I don't think this is true. Look at the automotive body design apps, which are mostly Catia based. All of the body parts are pretty much 'generative' and generated from splines, in a procedural way, using very similar approaches to GH. Or sheet metal design. It's not always about configuration of off-the-shelf items like bolts. And, the constraints manager is available to arbitrate which bit of script fires first, and your mundane workaday associative dimensions etc can update without getting run over by the DAG(s) :-)

 

 

 

 

 

 

 

Permalink Reply by Santiago Diaz on February 26, 2011 at 9:08pm

Dominic, this has become a dialog between you and I on MCAD.

If you have more thoughts, I politely suggest that you email me:

santiago.diaz.ames@gmail.com

 

I will post further GH captures soon, maybe tonight.

Regarding MCAD, we can continue that discussion elsewhere.

Permalink Reply by Santiago Diaz on February 26, 2011 at 11:25pm

Now here's the GH version of the same beam.

First, here's the beam highligted and the same reference point on column CL.

 

From there, I use parameters and line to get the reference axis and plane. The perspective view is changed a bit and I've turned off the preview of all other solids for clarity:

 

With some parameters as inputs for domains, interval boxes are generated:

And finally the notches on the top of the beams are solid-differences from other boxes:

 

Very straightforward, this part takes only minutes to define.

The following image shows all components involved with the beams:

173 components required to model the beams.

 

As I mentioned before, I modeled this quickly, without putting much effort into achieving the same result with less components.

Having said that, I think it looks like more work because the GH canvas exposes most of the work put into modeling.

Whereas with Inventor, most of the work is embedded in the Parameter window, and within each feature's dialog. You are not able to see all the logical work involved at once.

• ‹ Previous
• 1
• 2
• Next ›
• Page