Most Challenging Components to create during grasshoppers' development?

Replies to This Discussion

Permalink Reply by David Rutten on March 22, 2016 at 3:07am

From an algorithmic point of view most time was spent on delauney, voronoi, quadtree, and octree. However the graph mapper and gradient took a lot of UI coding.

Not sure I'm particularly proud of any of them, I do think Set and Field components are potentially *very* useful but they need some work.

Permalink Reply by Tyler Selby on March 28, 2016 at 12:37pm

Well I think what you've greater is incredible. I especially like the "special" components such as the color wheel you've created from a UI point of View. 

I havent used field much for my needs but make use of the set components pretty regularly right now. the biggest problems I have with using them is finding good information online abiut the ins and outs of how each of the componets work. I've always wished there was a small wiki setup with a page desicated to each component you've created. Or even better would be an interface that you could pick "component a" and "component b" and see all of the ways people have used those two components. 

How how much of the current components will remain a part of the GH 2 version?  

Permalink Reply by David Rutten on March 28, 2016 at 12:49pm

How how much of the current components will remain a part of the GH 2 version?

There will definitely be a lot of changes. I'm planning to replace a lot of number inputs (like circle radius, line length) with fields rather than numbers. Should make it a lot easier to create varying shapes (and of course any single numbers can always be automatically converted into a constant scalar field). Other core data types like Triangle will also change the topology of many a mesh component.

A lot of the data management components will be amended or removed or merged, there's too many of them and they're too inconsistent.

The Rhino6 SDK adds a few geometric functions, so I expect we'll get standard SubD components, a Make2D component, and so on.

There will be a range of new components that deal with metadata (a concept that doesn't exist in GH1 at all) and a slew of bitmap tools (drawing, sampling, importing, exporting).

One major problem all this change will cause is that it will become exceedingly difficult to open GH1 files on GH2 unless I either add a whole bunch of legacy components or come up with a large number of 'maps' from old to new components. Neither of which sounds like a particularly good solution and both of which sound like a heck of a lot of work.

Permalink Reply by Birk Binnard on March 28, 2016 at 2:16pm

Considering the number and complexity of changes appearing in GH2 I hope it will be possible to run GH1 and GH2 at the same time. I can see how a GH1 user would want to slowly convert his/her GH1 layouts to GH2 (I certainly would) and being able to run both at once would certainly make this a lot easier.

I can also see myself purchasing a 3rd monitor when this happens.

Permalink Reply by David Rutten on March 28, 2016 at 2:44pm

That's at least one benefit it GH1 and GH2 being completely separate projects, they'll happily run side by side, in fact they already are (not photoshopped):

Permalink Reply by ng5 Alex on March 28, 2016 at 3:05pm

nice! david, please consider some sort of heads up release, when time is right, for people that are teaching gh. to prepare definition, study differences etc.

best

alex

Permalink Reply by David Rutten on March 28, 2016 at 4:24pm

Oh we'll slug through another long beta process, but I won't be able to say how much of the file transfer process I can automate until GH2 is at least nominally operational and has a modicum of components.

Permalink Reply by ng5 Alex on March 28, 2016 at 4:39pm

great! automation sure sounds good for archiving past definitions. at the same time manual gh1-->gh2 could prove didactic.

i guess side by side gh1 and 2 is a good start.

Permalink Reply by Birk Binnard on March 28, 2016 at 3:57pm

Ooooohhhhhhh!  Look at that!  Woweeee!

I want to do that.

When can I do that?

Permalink Reply by Anders Holden Deleuran on March 29, 2016 at 4:02am

That's looking real pretty David, loving the look/feel so far!!

Permalink Reply by Tyler Selby on March 28, 2016 at 4:07pm

There will be a range of new components that deal with metadata (a concept that doesn't exist in GH1 at all)

David, with regard to your comment about metadata, how do you plan on having this work?  Does this mean information will be able to be embedded info the data itself?  Its exciting to hear about this possibility!

Neither of which sounds like a particularly good solution and both of which sound like a heck of a lot of work.

Thats really exciting to hear about the changes coming to GH2.  Im all for progress.  Id definitely be in support of dropping support for GH1 files completely in GH2 given they can run independently.  

Tyler

Permalink Reply by David Rutten on March 28, 2016 at 4:30pm

David, with regard to your comment about metadata, how do you plan on having this work?  Does this mean information will be able to be embedded info the data itself?  Its exciting to hear about this possibility!

Yes indeed. The idea is to allow custom key/value pairs to be assigned to all data where the key is a non-case-sensitive string and value can be one of several types of data, all of it readonly.. I will of course define a lot of keys as having special meaning, for example PreviewColour=DarkBlue, PreviewShade=No, BakeLayer=Section2, Bake=No, BakeName=Column_3_5, Expression="Pi / 2", ReferenceId=4634-ha7e... and so on. This basically frees me up of having to add all sorts of special fields on my own data-types for that stuff. But the real goal is to allow people to assign their own data, and then of course be able to select from a large collection of data only those items that match a certain meta-filter.

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