algorithmic modeling for Rhino
Tags:
Hi ShynnSup!
Referring to:
here http://www.grasshopper3d.com/forum/topics/find-object-name-of-an-ob...
and here http://www.grasshopper3d.com/forum/topics/find-object-name-of-an-ob...
i managed to pull out something like this:
As always(?) this definition may not follow all the GH rules, with risk of looping C#, not expiring the solution, going in conflict with other stuff, etc etc...
I have no idea what it could do, at worst it might kill you!
Use at your own risk, save your work before testing this.
XD
To work, sliders that will share value and the c# component must be in the same group, and merge all the slider's values together and link it to c# component (as in the .gif).
Sliders MUST have a nickname and in the whole GH project you shouldn't have two sliders with the same nickname.
As you see in the .gif , different sliders seems to share limits, precision and such.
Unluckily it doesn't correct the value exactly all the times...
I don't know ho to fix it... those are my limits...
I'm already not aware of what i'm doing, i'm just cannibalizing Peter Fotiadis work... NOM!
in some days i'll forget everything again T_T
Hope it helps
Let me know for anything else.
Cya!
oops
That's kind of cool, but I dont understand whats wrong with invisible cables. Especially since this kind of brakes as soon as you change the value range of one, because those are not synced. So you have to go through all of them to change that.
This would be more sensible with digit scrollers since they dont have domains.
I don't think we are talking about a finished gh definition, but a work-in-progress one, or such.
Sometimes you have to "search" for a slider.
It happens to me to "carry with myself" the slider, dragging it around to where i'm editing the definition.
In a big definition, i understand the struggle ShynnSup is talking about.
His idea of having sliders with the "ability of ubiquity", would be an interesting solution, indeed.
Hm, okay, I see your point and know what you are talking about now. Remote Control Panel is pretty nice for that, becasue then you have your controls right there next to the viewport no matter where you are in your Grasshopper patch.
It would be nice if it would work across clusters, because often I work inside a cluster and would like to change a slider that is on the "outside" of it.
Hello, thats really nice! Something like that I was hoping for. Yet, without the need to connect the sliders to a merge and then a c#. That kinds defeats the purpose. Having to do that with many sliders would still make a mess of my definition I think.
Thanks anyways for your approach and the gifs!
Hm, not really sure what you mean, but I guess you want one slider to control several others, right? I dont really see how that would work though. If they have the same range and values, then why not just use one? If you change one, you would have to change the other as well.
First of all though, dont be annoyed by many cables - its kind of normal and I dont see a reason for bother. Organising things and clustering stuff goes a long way to not have to resort to such messy things as somehow connecting 2 sliders.
Big patch, controls:
Inside:
Also there is a nice way to switch all wires to normal, faint or hidden at once. I usually use faint wires for everything. I'll attach it in a file. I cant remember where I found it before, so I am not taking any credit for it!
Hey thanks,
What I meant was the possibility to have a slider, and instead of connecting this slider to every input, be able to generate a "clone", which only moves when the mother slider moves. This way, you could have a component that has a title such as "width" and shows a numeric value, which change as you change the mother slider.
So every time you need to use the "width" values, instead of having cables that go all along your definition, you have nice, tidy, synced sliders that are connected as closer as possible to the component that is using that number.
Hm, I get what you are saying, but the good thing about the cables is, that you instantly know what is connected and what isn't. So if I received the patch from you I would much prefer to receive the first one. Of course its different if you are just building it for yourself, but I always tend to build it "like its for someone else" (but maybe thats just my OCD). Usually I have all controls aligned on the left and use faint wires for all the variables that are connected far down the patch. The main data flow is in normal wires and only very rarely do I use the hidden wires.
If you want to have centralised control over all your variables you should use the remote control panel. Do you know about it?
Of course everyone is different and I do think it would be nice to have some sort of system of global variables, which could be in the shape of sliders and other inputs that can be replicated and are linked.
Thing is the tittle would help you know what is what.
So if you have the slider named: "Width of Rail" then you know all sliders named like that come from the Width of Rail mother slider.
Maybe its as simple as having a slider with an input and its cable hidden.
I do know about the RCP, but I dont use it much. Its not that I want to achieve globalized control, as the clusters do, its more like wanting to organize the inside of the clusters so that each step can be seen clearly, explained, and understood.
what I'd do is I make a slider named "width of Rail" and then plug that into a number parameter with a visible wire, name the number parameter appropriately. Then make a copy of the number parameter, connect it to the original number parameter with a hidden wire.
Now you can keep copying this number parameter wherever you need to use the width of rail value.
I know a screenshot would have explained this much better, but I was too lazy :)
Welcome to
Grasshopper
Added by Parametric House 0 Comments 0 Likes
Added by Parametric House 0 Comments 0 Likes
Added by Parametric House 0 Comments 0 Likes
Added by Parametric House 0 Comments 0 Likes
© 2024 Created by Scott Davidson. Powered by