Pain Points in Grasshopper

Replies to This Discussion

Permalink Reply by Steve Lewis on July 29, 2014 at 12:47pm

I dont get the Boeing analogy. An aeroplane is essentially a prodcut that goes through 1000s of cycles of optimization over a 10 year life cycle. The design gestation period far exceeds that in AEC. A building is a one-off, every building is in escense a prototype. We dont traditionally have time to spend on optimization and have to use engineering judgment etc. to get the job done in time. There is much too learn from the aerospace industry, sure, but AEC is not the same. Constarint baased parametric modelling work flows are ideal in aerospace, it does not scale as well in AEC, espeically when the software costs at least 20k a seat. 

Permalink Reply by David Rutten on July 29, 2014 at 2:34pm

Aren't we getting a bit off-topic here?

Permalink Reply by Santiago Diaz on July 29, 2014 at 11:25pm

agreed

Permalink Reply by David Rutten on July 29, 2014 at 1:41am

Hi Peter,

I think you've put your finger on the hardest problem of all in GH ideology. Is GH a thing onto itself that it should remain 'true' to, or should it become whatever (some) architects need it to be?

The former is much easier for me, and a far less risky path. Software Cemetery is filled with programs that tried to do too much all at once. The latter is more along McNeel ideology, at least the publicly stated one we all try to adhere to.

There will be changes to GH2 that make some of the things you mentioned easier and maybe even possible. UserData on every value (be it a boolean or a brep) for example will make it much easier to interface with AEC apps, and it allows people to create not just data but also information pertaining to that data.

UserData only works well if it is properly handled at the lowest level, and there's a big hurdle to overcome with providing it to end users without burdening GHA developers.

Permalink Reply by Steve Lewis on July 29, 2014 at 1:58am

I think its a perfect medium as is as long as it continues to be able to be customizable.

Its a graphical algorithm with a blank canvas to define a bespoke work flow or solution.

I think its great to let the community extend it as needed in particular bespoke areas by having a well exposed API  and giving a medium for people to present those plug-ins. As others have said, I think as long as you concentrate on the core experience/robustness/openness/performance/experience, everyone else can help fill in the gaps and the bespoke areas needed, like in AEC, with custom components/userobjects/clusters.

As an aside:

1 a graphical way of documenting and navigating through components on a canvas such as through a hierarchal specification tree/browser would be useful.

2. please do not get rid of clusters, these are huge, especially the ability to modularize, reuse  and clean up grasshopper definitions using them. I use these a lot now.

3 I would like the ability to have a way of easily navigating through and linking grasshopper documents. I think a tab based approach to access different documents is better than the existing window approach.

4 I would concentrate on also improving the performance of GH, I still can potentially get massive bottle necks. Especially with viewing a large amount of BREPS.

5 The ability to externally reference a grasshopper document form another document  would be massive. Similar to mathCAD where I can reference a set of functions or global parameters in one work sheet and read them in a new one.

6 I also would like to be able to add a jpeg to the canvas - say I had a sketch of a structural detail with annotation as a PDF I would like to be able to drop that on the canvas for viewing. A live rhino viewport viewer that could be dropped on the canvas would be nice

7 PDF printing of the canvas/other ways of documenting a grasshopper definition for issue to a client say

8  Away to add hyperlinks to a table of contents say, so I, or a downstream user, can quickly navigate around the canvas form this table of contents - for example Section 1 Inputs Section 2 Driver geometry 2.1 Structure 2.2 façade 3 Outputs 3.1 Façade penalization study

Permalink Reply by Steve Lewis on July 29, 2014 at 2:06am

Yeah userdata is useful, I have been working on that myself for a while, and how to modify/document/handle is difficult. I think I have a solution, then again, I don't want to waste my time if you are doing it too.

Permalink Reply by peter fotiadis on July 29, 2014 at 2:59am

Hi David

Well ... choosing the "right" development path it's indeed a task not without risks.

On the other hand the 1M question is :

Can GH play a core role (*) in the contemporary AEC business? (and all things considered this is the sector where the challenge/profits/future/etc is - I mean that artists/academics/students are very important for spreading the GH ideology ... but real-life ... well ... you get the gist).

On the other hand what is (of should be) contemporary AEC these days?

Is it a frantic exploitation of "forms/shapes/topologies" for the shake of it ? (at least in most of cases).

Is it the dawn of the art of optimization? (assuming that always form should follow function).

Is it just a temporary (and quite costly) travel into the rabbit hole? (waiting for the next Mies van der Rohe - less is more etc etc).

Is it just some last spasms? (before corporations take over and shut down the whole thing).

All in all: After evaluating the +/-  (towards a potential AEC orientation) and if you decide to take some risks I would suggest to mimic the CATIA way: set up a team of people spread worldwide who you can trust (always remember what Bentley Systems suffered form that famous defection, he he) and try to pin the minimum components required for some "dedication" (one step at the time etc etc etc).

BTW: don't take the whole BIM thing too seriously: just another trip into the rabbit hole. PLM on the other hand...

(*) as it is it can't

best, Peter

Permalink Reply by Ernesto Bueno on July 31, 2014 at 3:00am

I agree with most of Peter thoughts (already echoed by others). I also consider important to address interoperability with BIM and PLM, but as he already suggested, BIM is based on industry dynamics that aren’t completely there. BIM will have to continue to evolve some more if their supporters want to get to realize the promise that still is. I can’t say much about PLM, but I would say that both BIM and PLM should be considered in future developments of GH and Rhino. David has said several times that some GH limitations regarding geometry and data structures (central to interoperability) are actually Rhino limitations. So, I wouldn’t put so much pressure on David for this, or at least I would distribute the pressure also on the core Rhino development team.

Talking about Rhino vs. GH geometry, there is one (1) wish I have: support for extrusion geometry. GH already inputs extrusion elements from Rhino, but they are converted to breps. Is not a bad thing per se. The problem is when you need to bake several breps that make the Rhino file to weight several hundred MB. When these breps are actually prismatic, extrusion-like solids, is a shame that they aren’t stored as Rhino V5’s extrusion geometry in a file of just a couple of MB (I overcame this once with an inelegant RhinoScript that wasn’t good for other people). This was one of RhinoBIM’s main arguments. We can develop a structural model made of I-beams in GH using the Extrude components. We should be able to bake them as extrusions. That would also work for urban models with thousands of prismatic massing buildings (e.g. extruded footprints). Even GH’s boxes are baked as breps! Baking boxes as extrusions could be practical for voxelated or Minecraft-like models.

(2) Collaborative network support. Maybe with worksession handling, or something that aloud project team members to work on a single definition or in external references or something alike. I know there is another Rhino limitation on this, but maybe clusters are already going in that direction?

And maybe on the plug-ins domain:

(3) Remote control panel that could be really “remote”, like from other computer or device. There is an old Android App for that, but is not only a matter of updating. I mean, it would be great to control a slider with the accelerometer of an Android phone, but to have that on an iPhone will require another development team. If GH could support networks, a remote counterpart of a RCP plug-in could be developed as a cross-platform web app. I don’t know if you can access accelerometer functionality through HTML5 already, but for now, asking a client (or an spectator or any stakeholder for that matter) to control your sliders from gestures of his/her own phone would be awesome (maybe Firefly will fill that hole?).

(4) GIS support. GH already imports .shp files. Meerkat can even access the database, but what about writing to shapefiles or generating our own with databases processed/generated in GH?

(5) SketchUp support. Not only starchitects and corporations are using GH in the AEC. There are a lot of small firms, freelancers and students interested. Most of them use SketchUp for 3D modeling (not CATIA, neither Revit). Yes, you can import/export .skp from Rhino, but if GH could support nested block at bake time (also mentioned by others), it could write .skp files with complex relations of blocks (that are called components in SketchUp) and nested groups, going beyond what Rhino can export.

(6) Read/Write other formats. There are some challenges with proprietary formats that are not completely supported by Rhino, but they’re still a lot of open formats that are relevant to the fields of GH users, like stl and ply for 3D-printing. It could be nice to write mesh colors to a ply for 3D-printing a colored prototype based on GH colors. There are others, like IGES, STEP, COLLADA, etc. and 2D, like svg, odg and pdf. Some of them could offer special formatting options like custom data that the format supports but nobody uses just because is impractical to access this from direct modeling environments (but not from visual programming).

--Ernesto

Permalink Reply by David Rutten on July 31, 2014 at 3:46am

Quick responses:

1. Extrusions. Yes. GH1 was developed before Rhino supported extrusions and it never made its way in. GH2 will be able to deal with them better, though I'd very much like to 'hide' this from the users. In my mind, extrusions are just a more memory efficient way to store certain breps and they shouldn't be 'on the surface'.
2. Collaboration. Yes. This is one of the major issues we agree needs fixin'. Not just multiple people working on a single project, but even a single person trying to split up the GH logic into manageable chunks. 
3. I'd much prefer to make it possible for plugin developers to write a remote control panel. This means making the GH SDK more easily accessible. There are simply too many potential external controllers available for me to deal with them all. Plugins like FireFly are much better at exposing this functionality that I could ever be.
4. GIS. I've put in a request to Rhino core development to make the existing file importers/exporters available as SDK methods. I think Steve Baer has a good idea on how to solve this for Rhino6. In addition to handling the file formats Rhino supports, I agree it would be a good idea to perhaps also write special import/export components for other formats. This is something that I started doing very late in the GH1 cycle and it never really took off.
5. Same.
6. Same. Though I'd like to re-iterate that there are people out there who can do a much better job of developing these import/export components than me. Above all, let's make it easy for them to develop such functionality.

--

David Rutten

david@mcneel.com

Permalink Reply by Ernesto Bueno on July 31, 2014 at 1:32pm

David, thanks for the reply. Is good to know that important things related to collaborative work and interoperability are being considered for GH2. I didn’t think it so much. Now that you mention it, yes, making the SDK more accessible could engage more people in developing plug-ins, facilitating a broader covering of formats to import/export (plug-in developers probably have this already in mind…).

Thanks also to Marc for pushing this threat. Actually, points 3 to 6 where to address Marc’s questions on plug-in gaps to fill.

David, what do you mean with:

(...) I'd very much like to 'hide' this from the users. In my mind, extrusions are just a more memory efficient way to store certain breps and they shouldn't be 'on the surface'.

I think that if we bake the geometry output of an Extrude component, and turns out to be an extrusion element in Rhino, this geometry type shouldn’t be hidden for us in GH. Having this functionality on bake time, but reading the output in GH as brep will be confusing. Why not having an extrusion parameter, as we have the box parameter? After all, you could manage the internal conversion to brep if we connect an extrusion to a brep input, like for example, in Brep|Plane Intersection. You do that for boxes already. I don’t know if it’s easy to implement, but I think this would be a good improvement, which would be consistent with both Rhino capabilities and GH conversion logics already implemented.

--Ernesto

Permalink Reply by David Rutten on July 31, 2014 at 1:43pm

By hiding I mean that it's not interesting to the regular user how a piece of geometry is represented internally. Do you care whether a curve is a degree=1 nurbscurve or a polyline? Do you care whether a mesh supports quads and triangles, or only triangles and ngons? Do you care whether your brep is stored as a collection of faces, trimming curves, loops, vertices and edges or whether it's an extrusion object?

Unfortunately the Rhino C++ SDK is very open which meant we couldn't 'hide' extrusions without breaking the SDK. However in Grasshopper this is an option that remains open to me.

Ultimately, by 'hiding' I meant that "yes, GH should deal with extrusions whenever it makes sense, but no, you do not need to worry about whether you're dealing with a Brep or an Extrusion.

--

David Rutten

david@mcneel.com

Permalink Reply by peter fotiadis on May 17, 2014 at 2:33am

BTW: Here's a "visual" puzzle to understand that without components dealing with some nested block management (at bake time) ... er... you are dead:

See this? It's a WIP yachting club "sketch"  (very early stages - Generative Components) for some country that has more money than common sense.

The space frame (NOT some academic wireframe thing or a pointless collection of spheres and pipes) is rather easy to do with GH (clash detection is a must > FEA follows > changes > redo>...> excel lists related with drilling axis - send the stuff to MERO Germany):

Now... portions of the "facade" (that bizarrely develops into a "roof" in some other places) are covered with a custom planar glazing/gladding system like this one (parametric children driven up to a point by parent's orders, bottom to top in extremes etc etc) :

Now...we are ready: "combine" all the above, consolidate 3d things ... and talk to CATIA (in a nested assembly/component way, that is).

Get the point?

Moral: all king's horses and all king's men...

• ‹ Previous
• 1
• 2
• 3
• 4
• …
• 22
• Next ›
• Page