UI-Viewport information and interaction flow

Replies to This Discussion

Permalink Reply by David Rutten on November 5, 2016 at 4:42am

The main reason GH manages its own geometry is because of the overhead involved if it were to use the Rhino document. Objects that are added to the document are duplicated by Rhino (because it doesn't want anyone else to have access to geometry in the document) and they are associated with attributes (which means adding a lot of additional bytes to even the simplest types of geometric data). Furthermore when objects are replaced or deleted, they don't disappear from memory, they are moved into the Undo buffers.

So instead of using the Rhino document as a central repository for all geometric GH data, data is stored locally in parameters where it can be updated and deleted with a minimum of overhead. The above however does not (on a theoretical level) rule out manual interaction with objects. The problem there is something else entirely.

Imagine you use Grasshopper to generate 5 cubes. Then you want to draw the middle cube a little upwards with the mouse. So you -somehow- select it in the viewport, then either drag it, move the gumball or use some command to change the location of it. How do you imagine this operation is encoded in the Grasshopper file? Is it completely hidden? Should a special component be inserted which encapsulates this motion? Should all the components be inserted needed to replicate the motion in GH?

Permalink Reply by Daniel González Abalde on November 5, 2016 at 12:01pm

A while ago I tried to make a script that using a line and a domain as inputs, allowed to display in rhino that line as if it were a slider, returning a number within given domain. It is somewhat trivial to implement if you have some experience with handling mouse events in the viewport. I thought it was cool, because for example, you could put a line from a circle point to its center and thus control the radius graphically. But it was just that, a slider, which perhaps asks you for more effort than reward you receive, and I left it aside.

Here are other examples of manual manipulation of geometry from gh.

http://www.grasshopper3d.com/video/gumball-for-grasshopper

http://www.grasshopper3d.com/video/transform-manually

http://www.grasshopper3d.com/video/deform-a-mesh-manually-from-gras...

And as you can see, it is possible to do it, but is against nature of gh somehow. Manual manipulation is out of the algorithm. It works well as a final or initial process, but not in the middle of an algorithm. You can take the transformations you make, such as move, rotate.. but it's not parametric. I'm afraid this can only be useful if is implemented from bottom to up.

Perhaps if each component that visualizes geometry can implement a way of manual modification (unique for each component in some cases), to modify its input parameters. For example, for the circle, allow you to change your radius by dragging the figure. If the circle component has a slider plugged in, the value of the slider is modified, if you have an object other than an emitter parameter plugged in, disable this function. For numerical parameters I think it is simple to imagine and could work very well, for geometry parameters is not so clear.Just allowing the modification of numerical parameters would already be a great thing, sometimes it bothers me to have to put values in the conventional way for example to make a cylinder bigger than the default.

From my point of view, solve this issue is a pending task that has grasshopper. In fact, it may be the logical evolution to take. Bring programming and model closer together.