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 Andrei Raducanu on December 9, 2009 at 6:55am

i'll write a few down, in case there is a solution already, and i just don't know about it:

1. external output for max and min value of sliders
2. the same for graph mapper
3. use the same graph mapper with different input inputs
4. adaptive panel height depending on list length (maybe with a max value, in case enormous list lengths occur)

Permalink Reply by Jes Tonsgaard on December 9, 2009 at 7:11am

- Nested Array support for C# components
- Wireless recievers to inherit the name of the parent component
- Unlimited zomming out
- More than size 60 in the new text thingy

thats what I can think of atm

Permalink Reply by Andrei Raducanu on December 9, 2009 at 8:05am

hi, and thanks for the answer!

sorry, but on the first 2 points i made a mistake, i meant to say input, not output.
i would like the slider/graph mapper to be able to inherit the min and max values from another component within the file.

on 3, i'm not quite sure what you mean. i am looking to use the same graph but have 2 inputs and 2 outputs. OR make 2 graphs while the second one should get the graph info from the first one but use different input values. otherwise said, i want to with only one graph to control 2 (or more) series.

on 4, i might have not been clear what i was referring to. sorry about that.
what i am saying, is that the panel component should adapt it's height so that it shows all list elements. Therefore if it receives a 15 element list, it should adjust the height accordingly, and if the list length changes, it should modify it's own height so that it isn't bigger or smaller than necessary.

Permalink Reply by David Rutten on December 17, 2009 at 6:33am

1. This will be available eventually.
2. Which parent? In fact, I'm planning on removing Receivers altogether and instead allow you to assign display properties to individual wires.
3. I can raise the limit for zooming out. The 5% I'm currently using is pretty arbitrary. What zoom percentage do you want to reach?
4. That's easy. 60 is another completely arbitrary limit which is easily adjusted.

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

Permalink Reply by Jes Tonsgaard on December 17, 2009 at 7:12am

2. When using a reciever to fetch data from some distant place on the canvas, say from my curve parameter component called "InputCurves", it would be nice if the reciever would then automatically be named "InputCurves Reciever" instead of just "reciever"... The point is, that for large definitions, it can become frustrating to have to scroll to the end of the reciever wire to see what sort of input it has...
:-)

Permalink Reply by Jes Tonsgaard on December 17, 2009 at 7:12am

and for zooming I dont know... I have just sometimes felt that it was not enough for large definbitins... maybe 1-3% then?!

Permalink Reply by David Rutten on December 17, 2009 at 6:28am

1. & 2. are planned. I have some ideas on how to solve this consistently within the entire GUI.

3. I don't get it...

4. I'll add this to the list. As far as I know this hasn't been wished for before.

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

Permalink Reply by Carlo Beltracchi on December 9, 2009 at 7:41am

In my opinion it would be great to have a command that recognize equal (or similar,with a tolerance) data. A sort of "seldup" grasshopper command.

It could be usefull in the perspective of creation of an "automatic branches output generator" button..

I mean...an intelligent sorting command that recognizes branches grouping similar data responding to functions or laws

Permalink Reply by Jes Tonsgaard on December 17, 2009 at 2:41am

I came to think of some more functions that might be usefull...

- A dimension component. As an architcect it would be great in everyday use to be able to dimension lenghts, radii and so forth...

- This might be a bit more tricky.. - If you do geometry for architectural use you will often need sections, elevations and plans, so a component that takes your GH geometry and generates a 2D section / forward / backwards view in a given plane and places it in the rhino viewport would be great!

- And personally I would really like to see some better help for the VB and C# components...

Don't take it wrong David, I think GH is great as it stands, but there is allways room for improvement ;-)

Permalink Reply by David Rutten on December 17, 2009 at 6:31am

- dimensions are complicated objects. They require a lot of data to define a single one. Also, a lot of dimension properties are tied to document settings (dimension styles etc.). I think I'll hold off dimensioning until after we've switched to the new SDK.

- Sections should be fairly easy, provided the Intersection code works. The trouble is attaching meta-data to geometry so I know whether a section is supposed to be hatched or not, which hatch to use, which line-width to use, which line pattern to use etc.

- Better help how?

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

Permalink Reply by Chris Wilkins on December 17, 2009 at 6:50am

While this thread is open...
1. Make the primitive parameters display values like a panel. We are using panels to feed values into components, but the data type is string, and it would make sense to be feeding correct data types in. This is not a problem, except when you feed into a Function component, and then you must cast the string value using a primitive parameter or otherwise.

Permalink Reply by Theunis du Toit on December 17, 2009 at 9:21am