Refactoring Parametricism

Replies to This Discussion

Permalink Reply by Stan Carroll on February 23, 2011 at 1:45am

Interesting topic.  How long did it take in Inventor?

 

 

Permalink Reply by David Rutten on February 23, 2011 at 2:23am

It is a very interesting topic, probably the most interesting from my point of view (as a developer of the software). Whether or not you can achieve something at all with a software package is subservient to how quickly you can get there.

 

It is theoretically possible to create a 3D model in Notepad, but that doesn't mean that notepad should be considered a 3D modeler. Similarly, it is not enough to have a theoretical capability in Grasshopper to achieve a specific task, there needs to exist a practical pathway connecting where you are now and the completion of that task.

 

Having these sorts of comparisons and projects validates the effort I put into developing this program (especially if they come with constructive criticism!). It is undoubtedly true that Grasshopper is more suited for certain projects and less for others, and a comparison like this hinges on a great many subjective factors and can only be truly appreciated by someone who is proficient in both products (which is certainly not me).

 

You mentioned the definition is messier than expected? Can you give a specific example of something that you felt required an overly complicated approach?

 

--

David Rutten

david@mcneel.com

Poprad, Slovakia

Permalink Reply by Evert Amador on February 23, 2011 at 4:03am

Hi All, sorry to jump in,

 

Very interesting topic indeed. Sometimes it happens to me that my definitions get "messy" (probably because I don't arrange my components tidily enough) but also because if I want to use standard components I have to use 2 or 3 to get the result or use a scripting component, but sometimes I fell this could be avoided if we could access geometry properties and methods directly, let's say we want to use the x coordinates of a bunch of points, instead of decomposing the points to get the X input we could directly type X in the expression editor input to do so similarly to what happens with math formulas.

 

mmmm, I suppose that methods will be a bit trickier if more inputs where necessary.

 

On the other hand GH is very easy to start doing things with because the interface allows all levels of knowledge as shown on this forum where most of the questions, I'd say, have to do with solving specific geometry problems or asking for people experiences in similar problems and not always, how do I use a component if you know what I mean.

 

Overall I'm so, so happy GH is out there in the hands of creative people and in the hands of creative developers! Perhaps there is no need for GH to do any task because it certainly does quite a lot and it is so versatile, even better, that the requests of users get implemented as far as possible.

 

I think it's very difficult to compare two programs unless you are at the same level of proficiency on both, in the future I'm going to pay more attention as to if there would be a simpler way to do things in GH and if it required some implementation.

 

My two pence, 8)

 

Evert

Permalink Reply by Santiago Diaz on February 23, 2011 at 8:50am

Dave, I might have used the wrong word. Or maybe not.

I usually take the time to "refactor" the definition, making it more elegant, efficient, organized.

Here's an example, which is part of the above def:

Those two groups of components can (and probably should) be combined into one, but it would maybe take another 30 minutes or so to do, for a simple case like this.

It just so happened to be easiest to copy one in order to create the other and reset the wiring and parameter sources. Quick, yet messy (for my taste at least).

Often, if I realize that replacing that with a vb or c# component will speed-up the def computation, I will. But I did not do that in the above def either.

 

Another example would be comparing entirely different approaches within GH which accomplish the same result (maybe I should put together some examples). There is always one fastest option. When I begin to notice a slow-down in computation as I'm working, I start thinking of a better way. If the cause of the slow-down is not obvious, I use the profiler.

When there is just no way to make the computation faster, I start disabling key components which I don't need at the moment.

This would be an example of doing all of the above in order to improve efficiency:

I can't discuss the project it self, but in that def is a LOT of refactoring. And I could definitely improve it on that account. Though I find that not only do I inevitably run out of time to improve the performance of the definition, the benefits begin to decrease, compared to the effort to refactor, eventually refactoring defeats the purpose. This becomes an issue for large definitions.

 

Sivam, absolutely.

For design exploration, I don't think as much about definition efficiency.

My attitude towards conceptual modeling is different to my attitude towards detailed design development. I use GH in both, extensively.

Permalink Reply by sivam krish on February 23, 2011 at 5:23am

This is an apple vs orange comparison. There is early stage design and late stage design activity. Early stage activity like sketching is messy. It is meant to be. The mess represents creative exploration.

 

 The different between grasshopper the Inventor is that the programs are hidden behind buttons, whereas in grasshopper they are not. That is iots advantage which comes tp play when the shapes get funny.  But for the kind of design that you have explored it is possible to do it easily with history based modelling with programs hidden under buttons, because the geometry is of low complexity so with a few buttons you can do the same thing again and again.

 

But that is not the point. Design is not a one straight shot. It is about messing about. What you need to do is mess with both designs and sees which is easier to mess with. You will find that the clean rational CAD packages ain’t good for messing with the design and the messier CAD approaches make messing easier.  So it all depends if you want to do messing ( designing) or engineering where you can be very efficient – because you are not messing (and therefore not designing).

 

Permalink Reply by Stan Carroll on February 23, 2011 at 9:56am

Great points Sivam. 

GH is most certainly a design tool and not really a drafting tool although the results from GH are accurate 3d models easily used when it comes time to draft the final result.

 

 

 

Permalink Reply by taz on February 23, 2011 at 2:31pm

Interesting discussion.  I've been trying to learn me some Digital Project so I clawed my way through a tutorial, but now I'm itching to see how far I can get doing the same thing in GH...

 

Hopefully I'll have some time in the next month or two, but here's the tutorial if anyone is interested:

http://www.gtwiki.org/mwiki/index.php?title=Floral_Street_Bridge_Ca...

Permalink Reply by dominic on February 23, 2011 at 6:17pm

 

Hi Santiago,

 

Could you go into more detail as to what took longer to do in GH? I think it would be quite important for future usability, and interoperability with the more mainstream and 'dumber' BIM world.

 

I can well imagine that modeling your design would be a lot more cumbersome in GH. It does not lend itself to the kind of wall to wall 'algorithmic design' that GH is geared towards.  I suspect the approach RhinoParametrics takes will yield comparably quick results. I think GH could equal this ease of use and eventually better the MCAD-style 'feature based' approach Inventor/RP uses.

 

The design has a lot of arbitrary setting out points, and parameters that are not amenable to an overarching mathematical formulation like 'replication'.

 

It also is more fragmented, where there is no obvious 'starting point' or 'root input' for the whole design. Not sure, but changing one 'roof assembly' look like it would need to propagate to the adjacent assemblies. This would be a problem for GH's DAG?

 

The arbitrary nature of the design components/setting out, would ideally be defined 'by hand' using traditional CAD event-driven techniques. I guess Inventor's 'features' are like mirco GH scripts that are placed and manipulated as part of its 'main loop', and provides the user all the feed back, alignment and snapping aids that have been accumulating over the years.

 

The snapping would also be 'persistent', and a geometric constraints solver built into its 'history tree'. Like most MCAD modelers, defining profiles with standard geometric/dimensional/algebraic constraints, using a 'sketcher' is pretty quick, and doesn't require any scripting. The 'declarative' way that the constraints are defined, is going to be far quicker than the 'imperative' / sequential way GH's relies on parametric math. I guess, GC will regain the upper hand when the design can't be described with constraints very well.

 

Constraints between 'parts' or groups of features would also be constraints-solved using a 3d constraints manager or kinematics solver. Needless to say, all the features are compiled, and tested/error-trapped against the comparatively restricted gamut of possibilities; i.e. other vendor provided features. 

 

Inventor also has iLogic. Not sure if this was used. iLogic is interesting as it functions like an 'active spreadsheet' where the user can script 'rules, checks and reactions' that have full access to all of the parameters that drive the model's features. It uses VB, so I suppose you could get 'generative' with it via .NET. Probably not as comfortable as Catia's Knowledge Advisor workbench... still.

 

Would the best of both worlds be something like Inventor (for the mainstream stuff), but fully scriptable (for the esoteric stuff) in one app/thread? The user would weave between a DAG and MACD style history tree?

 

 

 

 

 

 

 

 

 

 

 

 

Permalink Reply by Santiago Diaz on February 24, 2011 at 12:44am

Hi dominic,

 

12 hours is already significantly faster than what it would take me to model it with Inventor, unless I already had modeling "blocks" ready to drop into the model and adjust to the overall geometry.

The difference with programs like Inventor is that they are made for production, regardless of the fabrication method. I won't go into detail about that, and instead focus on the modeling process.

 

In this little model, the starting point actually is a bit obvious, the foundation.

The only contents in the 3dm file are 27 lines. These indicate the location of each footing, and the direction of the tilt of each column. Everything else is defined in GH with the use of numbers as input parameters.

Needless to say, instead of those lines you could obviously generate lines and control the number of columns and panels, hence establish their layout, with any algorithmic or non-algorithmic criteria you please. That marks a major difference between GH and Inventor.

You can generate geometry with Inventor via scripting/customization (beyond iLogic), with transient graphics for visual feedback similar to GH's red-default previews. However Inventor's modeling functions are not set to input and output data trees. I won't go into detail on that, but suffice to say that the data tree associativity of GH was for me the first major difference I noticed. I've used other apps with node diagram interfaces like digital fusion for non-linear video editing since the late 90's, so the canvas did not call my attention when I first started using GH.

 

Anyways, here's a screen capture of the foundational lines:

In the first group of components, the centerlines of the rear columns are modeled:

And the locations in elevation for connection points are set. Those elevations were just numbers I copied from Excel, but you can obviously control that any way you please. I was just trying to model this quickly.

 

The same was done for the rear columns:

The above, believe it or not, took me the first 5 hours to get.

Here's a screen capture of what the model and definition looked like after 4 hours, not much:

If you're interested, next post I can get into the sketching part you mentioned, which is a bit cumbersome with GH, but not really.

I wouldn't say that using GH to do this little model was cumbersome, it just needed some thinking at the beginning. You do similar initial thinking when working with a feature-based modeler.

Permalink Reply by dominic on February 24, 2011 at 4:36am

Hi Santiago,

 

Thanks for taking the time.

12 hours is way too long for this kind of model? I think you are right. 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 big speed/usability advantage for the user that apps like Inventor provide is: All the defining, handling, assembling/gluing to the adjacent components is done as part of its 'main loop' with all the hooks that can cater to user interaction, ie traditional modeling.

I guess one example of this is how Revit handles the placing of Adptive Components. AC's (and GC's GFT's) is pretty much a copy of Catia PowerCopies (which are probably a copy of something else). When placed, the AC's input points are transferred one by one to the cursor for the user to interactively place them. When copied, it tries to keep the same inputs, while changing its position/parameters. This saves a lot of time/nerves.

 

Catia, OTOH, is still thinking in terms of scripting and looks for matching property names, or uses a script to match strings, that nearly match. Sure, sometimes, this is unavoidable, but I think that there is a lot of room for incorporating a more traditional 'event-based' interface or 'wrapper' around the scripted components.

So much is scripted in GH, maybe it should also be possible to script/define/constrain/assist the placement/gluing of the results? An example of this is how Modo's Toolpipe works. The Toolpipe is a simple tool to record the active selection, snap/alignment/working plane, tool settings for re-use. I could see the user benefitting if the GH component was aware of the app's 'state' when placing/assembling components.

 

Also, a lot of simple things could be 'modeled' first and translated into scripted form if GH could read the active workplane, snap settings etc. Draw first, convert to hand-scripted script later?

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?

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.

Would love to understand what you did by sketching.

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.

 

With a manager, If one of the beams is connected to the column, changes in either component would trigger changes in the other to preserve the connection, regardless of the creation history. In GH, the dependencies are fixed, and the connection points would probably need to be defined independently, and placed 'upstream' of both elements. This makes editing laborious... but DAG processing is a lot quicker than constraints solving.

Switching direction seems to be possible in the animation world. Maya etc have IK/FK switching, which seems to be able to reverse the solving direction on demand. Not sure how or whether the rig is scripted.

Permalink Reply by Matthew J Flamm on February 24, 2011 at 6:52pm

Hi guys, Steve Sanderson just pointed me to your discussion.

 

I have been exploring these same concepts in the context of the American Cement Building's X component modeled in both Revit 2011, and GH.  BIM and Parametric.

Posts and files over at Design By Many:

http://www.designbymany.com/content/model-pattern-american-cement-b...

 

I am equally comfortable on both of these platforms, and built the same parameters into each model.  My modeling experience was very similar to that of Santiago.  The Revit model took 4 hours to build, while the GH deff. took 16 hours to build.  Time invested is certainly not the only metric to be compared; however, it is a good demonstration of the immediacy with which modifications can be made to the component system if parameter adjustment is not satisfactory.

 

With credit to Andrew Kudless for his process work on Manifold, I have adapted a similar workflow tracing diagram to the two models:

My general observation is that both tool sets approach the same problem, namely providing a structured relationship between components and wholes, but from opposing directions.  BIM excels at compartmentalizing individual components, while parametric modelers like GH excell at global system-wide manipulations.

 

In the case of the American Cement Building, modeling the cast component seems to have fit in the box of 'the whole being reducible to its parts' the best.  Although i anticipated Revit having more trouble with the surface generation, I found it to be more flexible on all accounts.  Building up the component in a Pattern Based Curtain System family, the direct interaction with the rig (specifying control point work planes, and offsets) allowed the network of interactions to be accessible and editable throughout the build process.  This family was then applied to a curtain panel grid which itself could be flexed in proportion, and cell count.

 

With the GH build I originally had the intention of utilizing data trees for parallel component construction so that changes to the base grid would affect offset normals and the like.  However, after i had spent three hours constructing one parametric rail curve, I was unable to continue keeping track of the parallel data structure, and reverted to building a singular component.  While GH certainly has the capacity to handle this task, I have found personally that the user does not.

Permalink Reply by Dennis Nelson on February 25, 2011 at 9:01am

I would be curious to know if by using a combination of grasshopper and the paneling tools plug-in if you could generate your facade faster.  Since you can't nest solid model definitions in grasshopper, which you can in a sense with the paneling tools, could you set up your grid pattern in grasshopper but use the paneling tool to generate the solid?  Just a thought.

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