Quasi Remote Control Idea - Proxy Components

I have an idea of how to create a remote control type function. This idea is based on my everyday use of grasshopper. Using a "proxy component" would, for me, be a more useful addition to the grasshopper platform than the remote control panel of earlier versions. Here is what I mean by a proxy component.

Challenge: After I build the definition and prepare to decide what the slider and constant settings will be in order to bake the geometry, I always drag selected control components to a clean canvas area so I can see all the sliders in a single place to make the adjustments while watching the rhino view port. This creates a wire nightmare and this drags the sliders and other control components away from their original position on the definition thereby making the definition very difficult to read and modify without returning the control components back to their original position.

Please consider this as a possible solution. The Idea is to create "Proxy" Components. By this I mean to have a virtual clone that remains permanently sync'd to its source component partner. The proxy could then be moved anywhere on the canvas yet remains sync'd with its source components (original component). In my perfect world, either the proxy or source component could be changed and both would remain sync'd. The proxy could be moved away from its original position yet leave the original component in its place. Wiring would not be necessary; only the internal link would be necessary. When you highlighted either the proxy or source component its partner would highlight as well.

It would be nice if all the components had this feature but the components that would be most helpful to have the ability to be proxied would be the "special parameters"; i.e., sliders, text panes, graph interfaces, all the things that one manipulates to decide on what to bake.

Is there a clean way to achieve this already?

Thanks for any feedback to this idea. Would such proxy components help anyone else?

Stan

Replies to This Discussion

Permalink Reply by David Rutten on January 15, 2011 at 10:43am

Hi Stan,

interesting idea. There's no way to accomplish this as of yet, I'd have to store an additional list of pivot points on all objects (so they can be drawn elsewhere as well), then hack into the display and mouse logic.

I'm typing on the Remote Control Panel right now, and I'm abstracting a lot of grasshopper GUI elements for this purpose. I wonder if it will be easy to 'embed' a Remote Control Panel into the canvas as well as have it in a separate window. This would I think accomplish what you're suggesting.

David Rutten

david@mcneel.com

Poprad, Slovakia

Permalink Reply by Stan Carroll on January 15, 2011 at 1:48pm

Hello David,

One aspect that would be very helpful is to have the ability to arrange what ever control elements you end up with. Many times there are 20 or 30 control components. Ability to visually arrange the control components logically helps the management if the quantity of control components gets gross. That was one of the less desirable qualities of the previous control all the sliders; they were just simply listed. A good analogy for arrangement would be the dash board of a car. Different arrangements make them more workable. After all the people who naturally gravitate to GH are already visually oriented. I know I am.

Thanks for your sincere consideration of the proxy idea. I am sure what ever you decide will be spectacular.

Keep up the great work.

Stan

Permalink Reply by David Rutten on January 15, 2011 at 3:21pm

The idea I have for the new RCP is that would be allowed to both pick which objects get represented, and in what order, and even in which subcategories. A subcategory is basically a collapsible panel with a custom name+colour containing one or more proxies.

It would also be nice to be able to specify a number of different layouts for the RCP, so you could define a 'simple' control with only 3 sliders, or an 'advanced' one which has proxies to more inputs.

Finally, I'm hoping to add RCP-awareness to a lot more types of objects. 2D sliders, colour pickers, text panels, you name it. Heck, maybe I can even make everything (even components and parameters) publishable by providing a default interface.

Anyway, lots of ideas. And I definitely like the notion of being able to put an RCP layout onto the Canvas.

David Rutten

david@mcneel.com

Poprad, Slovakia

Permalink Reply by Stan Carroll on January 15, 2011 at 5:48pm

Fantastic.

That sounds terrific. It sounds like we are on the same page. The subcategories will be great for organizing the proxies. I like your thought of having all components capable of being on the RCP. When ever I gather all the control components together for easy manipulation, I always bring the bake component into the picture as well. I love the notion of simple RCP and a more complex customizable one as well.

See...I told you what ever you come up with will be spectacular. I can't wait.

Power onward and upward,

Stan

Permalink Reply by Benjamin Golder on December 13, 2011 at 4:47am

This sounds fantastic. I really like this.

Permalink Reply by Andres Gonzalez on May 12, 2011 at 7:19pm

Yes, that is more or less what we are looking for!

Also, it would be great to call your definition or RCP from Rhino with out opening GH!

Permalink Reply by Stan Carroll on December 13, 2011 at 2:07am

It would be really useful if along with this proxied remote control idea, the core of the definition could be hidden and accessed only with a password.

I am writing definitions for a client and would like be able to send it to them so they can use them without revealing my definition. I have heard a .dll file has this ability in .net programming languages. It allows use without giving away the guts of the code.

The best scenario would be to have the ability to expose the proxied input and output components; i.e., the sliders, parameters, panel variables, and the output components, but hide the core of the definition.

The ability to protect the intellectual property embedded in the core of the definition would really be helpful when trying to actually make a living with grasshopper. Allowing an unknown unscrupulous client to use a definition can end up being a giant intellectual property loss.

Or...if anyone has any other ideas of how to allow use of the definition without exposing the core of the definition would be very much appreciated.

A password protected cluster could possibly be an rough "work around" to perform this function if set up correctly.

Sincerely,

Stan

RSS