future features discussion proposal

i think it might be useful to have a discussion where people can input ideas for new features that could be incorporated in future releases. some good stuff might come up!
i don't feel i'm entitled to open such a discussion though, but a moderator might..
anyone on board?

(PS; if such discussion already exists, i apologize)

Replies to This Discussion

Permalink Reply by David Rutten on December 17, 2009 at 10:25am

Why don't you like the method on the left? Why would it make more sense to feed in the correct data-type right away? Converting a single String into an Integer takes no time flat, so it can't be a performance issue.

Reasons why I don't want to change the Integer parameter:

1) what about Number, and String, and Boolean, and Point, and Vector, and Line... should they also display the value? Or is the integer parameter supposed to be different from all the others?

2) what if you have multiple values inside a parameter. Should it grow to display them all? Should it grow to display only the first ten? Should it automatically switch to Icon-display?

3) would value display be a fourth kind of display type (alongside Name, Icon and App-default)?

--
David Rutten
david@mcneel.com
Poprad, Slovakia

Permalink Reply by Chris Wilkins on December 17, 2009 at 12:18pm

Yes, those are all sound reasons. No reason for fourth display type either. I didn't think thru that too far.

Funny thing - The main reason I was asking is that I wanted the panel to enter a list of values, but then while typing this reply (like 30 seconds ago), I realized for the first time what the "Multiline Data" checkbox does. So I CAN enter a list of integers using the panel!!! Duh...

The second reason was due to frequently resizing panels into tiny yellow boxes. Maybe some way to toggle between tiny size and defualt size? Not sure. Just being whiney at this point. Thx.

Permalink Reply by Jes Tonsgaard on December 17, 2009 at 6:56am

I don't really know how complicated these things are... I just hope that some of the above suggestions might inspire you to further develop grasshopper...

I've defined basic dimensions with a couple of components, but it would be a lot easier if there was a magic component to du just that...

As for Sections: - again - I dont know how how this could be done... But it would for sure be helpful... :-)

For C# and VB: Help for learning the stuff.. like a list of all available objects, classes and such...
Grasshopper in itself is nice and allmost self explanatory, but the C# and VB components are still a bit of a mystery to me...
-Being an architect with self taught and fairly incomplete scripting knowledge it would be great to be able to have some sort of place to lookup the classes, objects and functions of the scripting components... Maybe with nice colorful illustrations and examples... :-)

by the way.. I have had quite some problems with the region boolean components which when given a list of objects seem to fail on some of them... Is there some sort of tolerance that one can change in terms of the the objects' fitness on the base plane used...

cheers

Permalink Reply by David Rutten on December 17, 2009 at 3:26pm

Hi Jes,

basic documentation about VB and C# is already available on the web and in numerous books.

Basic documentation about the Rhino SDK is something we indeed need to supply, though preferably it should be part of the SDK itself as opposed to a separate document. Our new SDK will have much better xml comments, which will show up as tooltips inside any code editor. It should also be more intuitive to begin with, so when you're comfortable with DotNET as a platform, most of it should make sense.

Basic documentation about the Grasshopper SDK is also something we need to release. I'm still changing a lot on a day to day basis so it's a bit of a bi... drag to keep updating the docs.

--
David Rutten
david@mcneel.com
Poprad, Slovakia

Permalink Reply by Jes Tonsgaard on December 18, 2009 at 12:48am

yeah, I know you are constantly developing the software, and I'd surely rather see a better performing software than documentation... - But in a perfect world one could wish for both ;-)

Permalink Reply by Phil Davis on December 17, 2009 at 9:06am

I know this is easily accomplished in VB, but I would love it if there were a Mesh/Curve intersect component. The people I work with sometimes have to parse or modify my grasshopper scripts, and they are kind of code averse.

Also, I haven't had the time I would like to delve into the latest version, but is there a way to control whether a component is enabled or disabled based on the output of another component? This would be a quick way for me to do conditionals in a way my co-workers can easily see.

Permalink Reply by Danny Boyes on December 17, 2009 at 10:40am

Can you elaborate a bit more on your needs. Do you mean stop the component from working or stop the component getting data?

In v43 you can enable/disable components by manually toggling them either from the context menu for individuals or from the toolbar for multiple selections, but this can not be done by other components.

Or do you mean restrict the flow of data to a component based on some kind of IF statement and therefore preventing any further down stream calculations. Have a look at this thread and see if its on similar lines: http://www.grasshopper3d.com/forum/topics/boolean-toogle-streaming

Permalink Reply by Andrei Raducanu on December 17, 2009 at 2:20pm

a "switch" might come in handy. what i am thinking of is you have a component with one input and 2 output grips. what it does is it directs the data on one of the two routs that come out of the component (and the other gets a "none"). You can therefore build two independent definition chunks that process that data in different ways, and switch between them with this switch component.
you can also leave one of the output grips empty, then it works as an on/off switch for the data flow through that connection, if you want to switch off a part of the definition for some reason.

it can also have more than 2 exits, and you select the route you want to activate with a mouse click (there can be these small "led lights" for each grip, and the active one is lit)
If it's a 2-way switch, you ca double-click it like a boolean component to toggle between down and up positions of the switch.

there can also be a complementary component that has as many inputs as the switch has outputs, but only one output grip. what this should do is collect the different outputs from the independent definition chunks that resulted from the switch. It communicates with the switch, knowing which route is active and it uses the data that came on that route as its own output data.

Attachments:

switch.jpg, 70 KB

Permalink Reply by Andrew Lyon on December 18, 2009 at 12:29am

Can't you do this with a and if then component and a boolean toggle. I know there are a lot of GUI concerns but i actually think a big step would be to make the tree structure more intuitive. especially reordering trees. I know that very often I need to reorder columns of data into rows and vice versa. I know this can be done through the path mapper but its sometimes pretty obtuse.

Permalink Reply by Luis Fraguada on December 18, 2009 at 3:16am

You can do this now with dispatch...

Permalink Reply by Stan Vinokur on January 5, 2010 at 10:58pm

Hey David!

1. it would be great if there was visual feedback if the data was flattened.
2. the new sort grid component is awesome! any chance its possible to put the points in each collumn in a separate paths like when you create a grid from the grid component. ?

Permalink Reply by David Rutten on January 6, 2010 at 1:33am

Sort grid? I only just woke up and I'm confused...

--
David Rutten
david@mcneel.com
Poprad, Slovakia