My ideas for future features

Hi all !

(and especially to David Rutten)

After the response to this thread , i decided to make a thread with only my ideas. everyone is welcome to comment on them, but if you have your own ideas, please don't post them here, but make a separate thread in respect to Davids request.

I keep adding new ideas (from small useful tweaks to component proposals), but you have to check the latest pages.

1st idea: receivers for everyone! (the crowd goes wild)
i'm thinking, why not make each input hook be able to work as a receiver. it could be chosen from the right-click menu, and the waves graphic can appear (as in the receiver component) around that hook.

an advantage of this would be, that if you start with a bunch of components near the input components area, and then decide to make room in between this two sets for a new set, it is useful to get rid of the current connection lines that would make that area messy. it would be easier to just change the status of the hooks, rather then create a receiver for each input data needed, and redraw the connections.

2nd idea: preview selected only button
near the "preview mode" button, there could be an on-off "preview selected" button,that when is pushed, only displays the component(s) that is/are selected

it happens often that i am working in one part of the definition, that generates a certain geometry and i need to see how this geometry relates to other stuff in the scene, so i need other components visible, but i also need just to check if the resulted geo looks right, and it's hard to see with other objects overlapping in the display. i currently do this: bake the current component, and then close grasshopper, or chose no preview, then switch back to shaded preview. that button would make things easier.

thanks for the interest!
awaiting some feedback

Replies to This Discussion

Permalink Reply by David Rutten on January 24, 2010 at 2:02am

Hi Bibo,

I don't have time now for making a tutorial, but here's the idea behind it:

1) Define any number of anchor points {P}.
2) For every anchor point, define a motion vector {M}.

Geometry that is close to {P}i will be deformed primarily along {M}i, geometry that is in between {P}i and {P}j, will be deformed in equal measures by {M}i and {M}j.

If you define only a single point and a single vector, the Spatial Deform acts as a Move operation. If you define the same motion vector for all points, you will also get a Move operation. It's only when motion vectors are distinct, that the geometry will be stretched or squeezed.

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

Permalink Reply by Suryansh Chandra on January 13, 2010 at 8:36am

Small correction.. FitCrv is available directly in the SDK. Just never used it!

Permalink Reply by David Rutten on November 5, 2010 at 10:52pm

Patch and NetworkSrf are not in the SDK, so I'll have to wait for the core team to expose these functions. It's wished for all the time so I hope it won't take too long. I just added FitCrv (available from the dropdown only).

How do you want Split to work?

--
David Rutten
david@mcneel.com
Seattle, WA

Permalink Reply by Andrei Raducanu on February 4, 2010 at 8:04am

6th idea: add a close button to the drop-down list of opened files (the one in the upper right corner)
it would be easier to just close from that menu the opened files you no longer wish to have, rather then selecting them and going to File>Close

Permalink Reply by David Rutten on November 5, 2010 at 11:21pm

Done.

--
David Rutten
david@mcneel.com
Seattle, WA

Permalink Reply by Andrei Raducanu on February 4, 2010 at 11:15am

7th idea: point input on the multiply component
if i use the multiply component and input points, it should automatically multiply all 3 coordinates of the points and output a list of the updated points

Permalink Reply by Andrei Raducanu on November 6, 2010 at 4:46pm

this already works i see

Permalink Reply by Andrei Raducanu on April 11, 2010 at 1:53pm

8th idea: tree outout of nested vornoi
the 2nd generation output curves should come in paths that correspond to their mother cells

Permalink Reply by Andrei Raducanu on November 3, 2010 at 3:25pm

9th idea: graph mapper reparamatrize option
graph mapper should have a "reparamatrize" option, so that the values that are processed are scaled so that they fit the 0..1 domain that path mapper has as default. After the data is processed, the output values should be scaled back to drawing scale.

it would eliminate the effort to "map" the domain of the values to 0..1 (since the domain of the graph can't be set parametrically) and then scale it back to drawing scale.

Permalink Reply by Andrei Raducanu on November 3, 2010 at 3:41pm

10th idea: more options for tree manipulation
Options like shortest/longest/crossover list should be present at tree level. At the moment, from what i've seen, components that have 2 input hooks usually combine the branches using the "longest list" logic, but there are cases when the other two types would be useful.
Also, i think components that are present for lists would be really useful on tree level.
ex: tree length (= nr of branches), cull branch, dispatch branches, weave branches
i realize that there are workarounds around these problems, but those aren't necessarily easy or quick to implement.

Permalink Reply by Andrei Raducanu on November 3, 2010 at 3:55pm

11th idea: the simplify component should also delete indexes that are after the actual increasing index
if i have a tree that has branches like tis:
{0;0;0}
{0;1;0}
{0;2;0}

and i use simplify, i get this:
{0;0}
{1;0}
{2;0}

i would like to get this:
{0}
{1}
{2}

I think it would be useful if you intend to use a stream component and you have trees that have only one increasing address index, yet different address lengths, like this:
{0;0;0;x;0}
{0;0;0;x;0;0}

or if you want to use integers as input for the Extract Branch path input hook
(would be easier, and more generic them using path mapper)

Permalink Reply by David Rutten on November 5, 2010 at 8:29pm

Working my way down this list. Wish #1 is done. I've hidden the Receiver object from the toolbars and every floating and input parameter now has a submenu for wire display. It works a bit different from the old Receiver logic, if the parameter (or one of its sources) is selected, normal wires are drawn no matter what the setting.