Hi David Thanks for replying.
Point one (1. the connections shoud be an arrow indicating the direction of the flow of information) was only a visual remainder of the direction of the flow but I see now that it makes sense only if you can make diagrams in any direction (8) and this in turn is only possible if the inputs and outputs can rearrange themselves in order to avoid crossed connections (7)... I can see that it can be difficult to achieve automatically this but it can be solved manually by allowing to position the connectors around the node...( the black part of the node would be in the center and the inputs and outputs would be color coded and attached around the center and movable around it. The ability to switch globally to straight lines (9) would also improve legibility of the diagram. For nodes alignment (3) you could have a grid snapping in the node's middle point or maybe it would be better to have a toolbar with the classic aligning tools Point 5 (you can drop a node over a connection to put it in between twonodes) can be much more difficult than it is in Fusion but you can check for the best match in types of data... I know it's complicated... Anyway all of the above are not something very important... they' re just some of those things that would make a better work flow but that don't change the essence of the software... What I consider to be essential is the cluster's ability to become a node with custom inputs and outputs... that can be saved and shared, and so a myNodes tab would be necessary and a hard drive folder to drop them in... Maybe they can be saved in the same ghx format so that any definition can be used as a node in super-structures of course there would have to be a way to define I/O of definitions... needs a bit of thinking but it would be very flexible... Maybe you would need also to allow to create an encrypted node to promote developing and selling nodes... 11. The other thing that would help legibility is passing the connectors of a selected node over the overlapping nodes that are in front to see them clearly... 12. Pasting should occur in the mouse position and not over the copied nodes 13. This one is tough... Grasshopper should be a part of Rhino so that every action taken in Rhino had a node representation... For instance I draw a box (corner to corner, height) with the mouse and I want to select that geometry within Grasshopper... I select the geometry node and set that box as my reference... The geometry node is now a cluster of actions used to create that box... so I can open the cluster and inside I find three point nodes connected to a box node that has three inputs and a G output... I can then modify the positions of the points of the box with my graph... Frane Zilic On Mar 20, 11:48 am, David Rutten <da...@mcneel.com> wrote: > Hi Frane, > > I'm running late, I'll have to be brief: > > 1. Data always flows from outputs to inputs. You cannot reverse > components so data can only ever flow in a single direction. > > 2. I'm planning this, but not any time soon. At the moment the > connection are just pointers from one parameter to another. I need to > rewrite this entire segment of the core so that wires can have > properties. > > 3. With grid alignment, what parts of the components should snap to > it? The centre? The upper left corner? All corners? > > 4. How do I know which new parameters are supposed to replace which > old parameters? Most components have different inputs/outputs, so it's > not obvious which connection make sense if you switch out a > component. > > 5. I can make this work for parameters, probably. But not components. > How would I know which input parameter is supposed to grab the > connection? > > 6. I'm planning to expose more objects on the Remote Panel. At any > rate, the Remote Panel is overdue for a massive face-lift. > > 7. This is way too difficult :) No way am I even going to think about > that! > > 8. ..see (1) > > 9. This is something I'll be looking into once connections can have > custom settings. Or do you want a global switch? > > 10. (& 11 & 12 & 13) The next big project on the list is to rewrite > Clusters from the ground up. We want clusters to behave like fun-sized > networks. Pretty much like what you've described. > > ----------------------------- > > 1. You can use a Merge Multiple Component to orderly connect input > streams. It has variable inputs so you can always add more. Another > feature I'm planning is to draw little text tags over wires, that > indicate in which order they are joined. > > 2. It's probably not that difficult to disable specific output > parameters (for example, you could disable Origin, X and Y in > [DecomposePlane], leaving only Z), but actually changing the type of > outputs is very complicated and also puts a huge amount of > responsibility on Component Developers. I'm trying to keep the > Component SDK as simple as possible (not sure if I'm succeeding). > > 3. Agreed. There's very little I can do about this, maybe Rhino5 or > the RDK will offer some solutions in the future. Basically, I'd have > to bake the geometry anyway or else the Render engine won't know it > exists. If I start to bake stuff all the time, there's be a huge > overhead slowing everything down and absolutely hogging the Rhino undo- > system. > > -- > David Rutten > da...@mcneel.com > Robert McNeel & Associates
