algorithmic modeling for Rhino
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
Views: 4943
Replies to This Discussion
-
Permalink Reply by David Rutten on
-
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
-
Small correction.. FitCrv is available directly in the SDK. Just never used it!
-
-
-
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
-
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 -
-
-
Done.
--
David Rutten
david@mcneel.com
Seattle, WA -
-
-
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 -
-
-
this already works i see
-
-
-
8th idea: tree outout of nested vornoi
the 2nd generation output curves should come in paths that correspond to their mother cells -
-
-
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. -
-
-
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. -
-
-
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) -
-
-
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.
--
David Rutten
david@mcneel.com
Seattle, WA -
About
Welcome to
Grasshopper
Translate
Search
Photos
Videos
© 2024 Created by Scott Davidson.
Powered by
