Grasshopper

algorithmic modeling for Rhino

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: 4989

Replies to This Discussion

1st has been suggested and (you'll have to check with David) but it might be already in the works.
2nd Would be nice to have such a toggle...
3rd idea: random color automatically assigned to new group
each time you make a new group, it should be colored randomly, instead of the same color each time.

it's just easier to distinguish them...
Hey Andrei,

Nice ideas, I can see the benefits of all 3, and i personally would find them very beneficial!
cheers!
4th idea: when clicking a component, the "radio" links should appear as well
when you click a component, the links to recevers should also appear

i often find myself in this situation: i have a component that has a few links from it's output hooks, including links to receivers.
i apply additional components that modify the output of that component (say i have a tree-like list, and i add a flatten component). i then have to draw new links to all the components that are currently linked to my initial output hook. i want to see which these components are, but the links to receivers don't show, so i have to search through the definition for receivers that are linked to that initial component.
Since receivers will be phased out I will not pursue this. In the new parameter wire display scheme the wires are drawn normally if either end is selected.

--
David Rutten
david@mcneel.com
Seattle, WA
5th idea: bake component
a component similar to the geometry variable component, only that you can input bake properties

it would eliminate choosing the different options each time you bake
Last I read was that David was planning on selectable wires with editable properties.. I'm guessing that would be visible/dashed/hidden or something on those lines. That should answer your 1st & 4th idea. For the 5th idea, you could either look at Giulio's definitions, or this plugin to GH.

GH could/should have custom attribute baking functionality natively, but I'm not sure if that would make into a copyright issue since there already is a plugin to do that now.

While we're at it, personally I'd like to see some of the more advanced Rhino routines made available in GH such as Patch, FitCrv, Network Surface, Split, etc. that are not available directly within the SDK either.
EdgeSrf is available directly in the SDK, so its not hard to script. The method is called RhUtil.RhinoCreateEdgeSrf.

I would love the cage functionality to appear in GH, but I am uncertain of two things:

1. Processing time -- this is a major major setback, even when working in Rhino with a decent amount of geometry.

2. Method of Control/Interactivity -- CageEdit would make the most sense if you could intuitively move the points in the viewport, and not have sliders for X,Y,Z values of every individual point (wouldn't that be such a pain!).. So to first create a 3d grid of simple point objects in Rhino, and then somehow select them in order into to do a CageEdit seems a bit messy to me... perhaps a neater way of applying the 'intuitive interactivity' of a cage edit needs to applied to GH. Right now, the SurfaceMorph is closest thing GH has to a CageEdit.
Have you guys tried [Spatial Deform]? It's slow, but pretty flexible.

--
David Rutten
david@mcneel.com
Poprad, Slovakia
Ah yes! It indeed is the closest GH has to cage. Somehow never really got around to using it... but just did for the first time now..
Hi David,
May you please add a video explaining the spatial deform or upload a definition?
I have tried it several times but failed to go a step forward!

RSS

About

Translate

Search

Videos

  • Add Videos
  • View All

© 2024   Created by Scott Davidson.   Powered by

Badges  |  Report an Issue  |  Terms of Service