Grasshopper

algorithmic modeling for Rhino

Can anyone tell me how, or if it is possible fundamentally to have:

 

2 sliders that are inserted into a function, and as one slider is changed the other slider is affected, for example as the fist slider is increased, the second decreases according to the function?

 

Thankyou!

Views: 2468

Replies are closed for this discussion.

Replies to This Discussion

Thanks Danny,.

 

Danny, could take a look at the last question I just posted?

 

http://www.grasshopper3d.com/forum/topics/how-to-arrange-this-list-of

 

It is driving me NUTS!

 

Andres

 

This is what I've been asking for long time but it's hard to get a response.

The method by Boyes is great but many times the real need is to have the Slider really have those parameter adjusted inside AND with the right visual feedback.

I don't know if it's a matter of programming, priority or just not enough demand for it.

 

David what's wrong with such a request in the wish-list?  :(

I need it too Mark.

OK. Lets have a prayer.

I wish I had the skills to create a component with similar characteristics, but I'm so busy working I can hardly keep in touch with this forum, never mind learning this.

David this is a PLEAD....

Hi Mark,

 

it's neither of those three. It's certainly not a programming issue and priority and demand are basically the same thing. This has been asked for before by quite a few people, but I don't really get good answers when I ask questions in return (I just asked a few again in response to Mårten's post).

 

I can see a minor benefit to this, but I also see a lot of quirky an unintuitive UI and a break from how Grasshopper normally works. Now, I'll be the first to admit that there's already some quirky UI in there but it is my goal in life to reduce the incidence, not make it worse.

 

But please do post an example* of the UI as you envision it, I'd love to know.

 

--

David Rutten

david@mcneel.com

Poprad, Slovakia

 

* napkin sketch will be utterly sufficient

I'm just thinking out loud... but what if the slider had a small input node (grip) which would accept a domain value corresponding to the lower and upper limit of the slider.  If nothing is attached, then it will just use the default values, but this way you could still set dynamic bounds.  Thoughts?

 


 

 

Actually, on second thought... this isn't really a good solution.  I can already see several problems... like what happens if there is a list of domains.  Also, this was more to fix the dynamic bounding problem... but doesn't really help out the original poster.  While I do think it would be nice to have dynamic bounds, and the above solution might be a simple solution, I do see some of the downsides.  Any other ideas?

The biggest one is indeed the multiple-inputs problem. I either have to start throwing errors when someone supplies more than one domain or ignore all but the first.

 

Here's another question I have, lets say the setup at some time is like this:

 

min = 0.0

max = 10.0

val = 3.0

 

Then the dynamic domain changes to:

 

min = 5.0

max = 10.0

 

What happens to val? Does it stay as close to 3 as possible (i.e. 5.0)? Does it get remapped to the same percentage (i.e. 6.5)?

 

--------

 

Or let's assume that due to some fluke the dynamic bounds are identical:

 

min = 6.0

max = 6.0

 

Now at least it's obvious what should happen to val as there's only one value possible, but what should happen after the domain becomes valid again? Should I store the last valid value or percentage and restore it?

 

--------

 

What about rounding in case of integer sliders?

 

min = 0

max = 10

val = 3

 

When the dynamic domain is slowly adjusted one integer at a time until it reaches:

 

min = 8

max = 10

 

how do we prevent the massive amount of intermediate rounding that goes on which may push the final value percentage way off the original?

 

--

David Rutten

david@mcneel.com

Poprad, Slovakia

Yeah, I agree... the way I suggested is probably not the right way to do it... and I had thought of a few of the circumstances that you presented, but couldn't come up with a consistent behavior for the right way to handle each situation.  Thanks for clarifying though.  I'll keep thinking on it, but clearly this is a difficult problem to solve.

I may be a little simplistic but those issues are confronted manually if indeed I need to make those changes in the slider.

So it follows that I would then create those circumstrances in the workflow to feeedd the slider as if I was doing it manually with the advantage of having GH doing it form me out of a calculated SET of predictable safe scenarios.

 

For example in my business I deal with Jewelry Manufacturing and Stone sizes are some of the output of the sliders.

According to certain parameters in the rings the stones range needs to change, and so the the visual feedback on the slider, in order to pick the right stone (without having percentages or other equivalent ratios).

Sometimes we need the slider to work below 1 and other times above 1 and up to whatever "end" of a specific range. And again we have many ranges. If we need to pick 1.27 or 0.62 or 5.43 the slider should exactly be able to step on those numbers so that anyone using the Definition can do it without guessing an Equivalent Value that mathematically equals what we need but visually is something else.

 

There are other instances like Finger Sizes, Prongs Diameters and a host of ranges that needs to be applied in so many ways based on technical and financial factors that really need a Slider with an exact visual feedback and precise value to be picked.

It's just so much more practical and intuitive to see what you want and what you get out of a Slider.

 

This would make a Control Panel ( and the Sliders in general) more usable because WYSIWYG.

I also guess that a Loop situation could be created and this could be a problem that should be taken into account somehow.

 

What do you think David?

Don't worry about loops, those are already detected so if you hook it up wrongly it will just abort the solution.

 

It sounds to me like a slider is actually not the most ideal UI for this altogether. It seems like a check-list with a collection of constants makes more sense.

 

How about a component which has two inputs. One list of strings (text) and a list of generic data. The strings are then displayed as a list with checkboxes on front of each item and the associated data with that string is outputted.

 

Something vaguely akin to the Legend object, except it allows for selection and outputs data as well.

 

ps. just so I'm clear about this, this request is completely different from the original request in this thread right?

 

--

David Rutten

david@mcneel.com

Poprad, Slovakia

That's sound great and I have use for it for sure!

 

But can the following be accomplished with the right feedback and values picking?

 

IF fingerSize = 6.0 (Slider, decimal)

THEN

stoneCount = Min 20, Max 30 (Slider, integer )

ELSE..... etc.

--------------------------------------------

IF stoneCount >15 and stoneCount <40 (size is then calculated)

THEN

prongDiameter = Min 0.7, Max 0.85 (Slider, decimal)

etc. etc.

 

This gives freedom to pick anything in between right at the Slider Level.

Can that Component you are referring to be made in such a way to display these value ranges using a regular Slider in one of its inputs?

 

Sorry David for my persistence but the more we express our need the more GH evolves and spreads to other industries as well as Rhino has done with UDT and the Jewelry design's demand.

 

Thank you.

 

ps. I'm thinking that it's still within the original post idea. I hope.

RSS

About

Translate

Search

Photos

  • Add Photos
  • View All

© 2024   Created by Scott Davidson.   Powered by

Badges  |  Report an Issue  |  Terms of Service