Pain Points in Grasshopper

Replies to This Discussion

Permalink Reply by Armin Seltz on April 14, 2015 at 9:47am

So I was just trying to use the solid and mesh intersection components and I have to say they are the worst so far in GH. So many times it comes up with errors. It says "Boolean intersection set is empty" but displays some intersected geometry. Sometimes it just fails for no reason at all. Sometimes simpler things make it fail more than more detailed ones.

All in all a very frustrating few hours trying to use them. David, we have come to know better than that!

ps: if anyone knows a plugin that can do solid or mesh booleans in GH properly, please let me know. 

Permalink Reply by beardface00 on May 21, 2015 at 7:35pm

Wire Options:

- Wire shouldn't have a gradient colour effect applied to it when selected, as this makes it get lost when I have to search through a nest of crisscrossing wires all connecting in roughly spot of the canvas. Usually i have to pull the component out to a strange angle so i can more easily track the wire. (This is particularly a pain when the components are within a group).

- Assign wire colours, transparency, lineweights, other settings, etc.

Rhino Commands ported to Grasshopper:

- FlowAlongSrf rhino command to be built as a Grasshopper component. Would enable design methodology of drawing facade design in unrolled elevation and then "wrapping" it around façade, delaying the creation of 3d geometry until the last necessary moment

- Build the "Unroll Srf, Create UV Crv, Apply Crv" Rhino workflow as grasshopper commands to avoid the need to custom build this process within grasshopper. This method is used particularly when creating spiral staircases with a landing half way up it and the design task is to create a simple, elegant accompanying balustrades that is able to mediate between the slopes and the flat area. Much easier to design in 2D and then wrap around the shape. 

I understand that there are ways to achieve these results in Grasshopper already, but they are cumbersome, so considering the rhino commands exist, hoping they can be reinterpreted.

I also vaguely recall that there was move to ensure that Grasshopper was 64-bit, and that each of the commands within grasshopper were being rebuilt to these new specs to utilize available processing power.

Hoping this is still the case.

Cheers!

Permalink Reply by David Rutten on May 22, 2015 at 2:33am

It is possible to set custom wire colours for the ends opposite selected ends, but it requires editing the xml settings files by hand. GH2 will have a decent skin editor (in fact I'm writing it now as I've begun with the interface code).

64-bitness is guaranteed in the future as GH2 will only run on Rhino 6+ which only comes in 64-bit.

As for the components, these are usually fairly minor jobs that can be done whenever as nothing else depends on them. Just keep asking every now and again if it hasn't happened yet.

Permalink Reply by Daniel González Abalde on May 22, 2015 at 4:49am

David, you give an opportunity to the transparent canvas?
http://www.grasshopper3d.com/profiles/blogs/transparent-canvas-worm...

Permalink Reply by David Rutten on June 6, 2015 at 11:05am

Most likely no. One thing I'm interested in in getting GH to run in a viewport rather than a separate window, but no more.

Permalink Reply by Mateusz Zwierzycki on June 18, 2015 at 6:21pm

What happens with the menu bar/components tabs and so on when GH is docked as a viewport ?

(I would prefer it to disappear, so there is only canvas).

Permalink Reply by Ángel Linares on June 6, 2015 at 10:28am

A new pain point that could be solved more or less easily (depends on how deeply the wishes are satisfied :P):

When you are coding a custom component (using python, c#...) it's very annoying when you have lot of inputs/outputs and you cannot visually differentiate them in clear blocks/groups (for instance numeric values, geometry, etc).

So I propose to create graphic separators in coding components. It could be done creating not usually legal inputs-outputs names as "-", "_", etc. This could be improved even more letting the user name those input/output groups, changing the background colour behind them, etc...

This could be integrated with ZUI so in smaller zoom levels you will only display perhaps different colours/separators, and if you zoom in the names will appear...

What do you think about it?

Permalink Reply by David Rutten on June 6, 2015 at 11:14am

I have been thinking about separators, but every time I try and come up with a solution I end up thinking that it's a mistake to have many inputs/outputs to begin with. If a component requires 6 numeric and 4 geometric values to run, there should be other components that aggregate these values (like the Loft component does).

So the 'final' (C#) component would only have two inputs, and there'd be two other components which collect some values each and group them into a single structure.

The latter is of course possible, but requires a lot of coding at the moment. I'm thinking the most useful thing to do is to make it possible to very easily add data types that are just collections of other data types.

Permalink Reply by Santiago Diaz on June 6, 2015 at 11:42am

The scope of a variable in GH seems to be defined explicitly by the wires carrying a variable to other components. Is there currently a way to declare a variable as being accessible in any component on the canvas by just typing its name?

I don't think variables have names in GH to begin with (correct me if I'm wrong), but in the design process, most variables are not humanly considered 'important enough' to have names, however there are always a few variables that need names, and are intuitively given names by designers because they become part of the language of the project they are working on.

David, have you considered addressing this in GH2?

Permalink Reply by David Rutten on June 6, 2015 at 12:13pm

I've started addressing it. There will be a way to specify certain values using global names (I haven't decided on a naming rule yet) which will make them accessible to all other parameters in the same document and all expressions in the same and all nested documents. 

So you can have a slider which is called @width (let's assume for the time being everything with a @ prefix becomes a global variable, which I don't particularly like) and then width becomes available in all expressions (even expressions inside input parameters).

This is a mockup, it's not actually working.

I've made sure that expressions in GH2 can handle remote variable names (or rather, I've made sure that code which runs an expression can resolve variable names)*. 

There are several problems with this approach still:

• It makes it hard to see (for users) where data is coming from and where it's going to.
• It makes it hard to see (for code) where data is coming from and where it's going to.
• It makes it more difficult to copy paste chunks of a network.
• It makes it more difficult to design document agnostic clusters.
• It's not entirely clear what should happen if a global datatree is used in an expression. In the example above, what if @Width is not a slider but a tree of numbers containing 300 branches and 100k values? Should the expression run 100k times?

Major benefit of course is that it will allow people to drastically cut down on wires, which is what ultimately chokes a large file. It's not a large amount of components that make a file hard to read, it's having too many wires. Unfortunately global variables will also make it possible to create very hard to read files.

tl;dr

Yes I'm trying very hard to get this to work in GH2. Numerous problems (both logically and user-interface wise) remain unsolved.

* I've also rewritten expressions to allow for multi-line C#/VB code (python will probably follow suit some day), so they'll be a lot more powerful and a lot faster.

Permalink Reply by Mateusz Zwierzycki on June 6, 2015 at 6:14pm

Can't we just simplify that by having a list of global variables for the document ? Like an additional canvas widget visible with some shortcut ?

Permalink Reply by David Rutten on June 7, 2015 at 12:31am

I don't want to give up on the possibility to compute global variables too quickly. That sounds like a very useful feature.

• ‹ Previous
• 1
• …
• 17
• 18
• 19
• 20
• 21
• 22
• Next ›
• Page