Hey!
Some time ago i found a picture in the internet of a slider where you can input a domain and then slide between these min an max values.
but im not sure if this component really exists because i do not find it in grasshopper.
has anyone an idea where i can find this “slider” or does this component not exist?
I’m pretty sure it’s photoshopped. It certainly doesn’t exist within the standard toolset.
I searched the image with google and here is the source.
aaaahhh ok, too bad!
thank you!
I think a lot of users have been looking for this, for quite some time… any chance that this can be added to the GH wish list?
It has been discussed many times, I’d like to know your answers to these questions:
There is a feature in the metahopper plugin that allows you to adjust the slider’s domain from the outside, although it does not solve the problem that @DavidRutten has pointed out…
Years ago I clustered this principle into a ‘Tree/List Viewer’ utility that makes it easy to examine data trees of geometry. One cluster remaps ‘0 to 1’ to select a branch, the other remaps ‘0 to 1’ to highlight a geometry item in that branch,
vuTreeList_2017_Jan19a.gh (20.0 KB)
I am necromancing this thread with a degree of trepidation and the fear that any further comments on it will be dismissed by @DavidRutten out of hand, but I specifically registered to the McNeel forums reply to this post and hope that with adequate finesse, I can convice David to give it a second thought.
I’ll start by emphasizing why I find the idea of this component important: repeatedly I have fallen into the situation where a “Domain Slider” is exactly what I need, but do not have. This the situtation where out of preceding logic, I have a range of values to choose from, and use the work-around of remapping to a domain of 0 to 1 so that I can pan through the results with a number slider. The problem is, that while I can get a rough idea of what’s good real world measure of things, I can never zero in on the exact value I want. For example I’m playing around with the slider and see that an angle of 30° is with in range values I can get. Great! I’ll take that! So now I’m fiddling around with the slider to find the value between 0 and 1 that directly translates to 30°, but to no avail, because, of course, Math; no mapping exists within the stepping accuracy of the slider that directly corresponds to 30°. And this is important because I’m not doing abstract shapey-shapey, I’m trying to construct a real world object that relies on rounded units and components that exist only in certain sizes.
Now I’m not a programmer, so I hope I understand David’s questions and well enough that I’ve provided sensible answers to them here:
What happens if a null domain is provided?
Input null, output null. I am assuming that since components such as the “Insert Items” component without an Items list input can produce nulls, forwarding nulls out of a “Domain Slider” wouldn’t be a problem?
As an indication of the circumstance, the slider grip could disappear. In the “Edit…” dialogue of the slider, the “Numeric domain” and “Numeric value” would remain editable, but grayed out. These values would be used for the number slider if no domain is given, superceded, but not changed by the domain input if a domain input is given, and, as mentioned previously, ignored by the slider if provided null.
What happens if a singleton domain is provided? Note that domain whose absolute length is less than the accuracy of the slider may as well be singleton.
If a singleton domain is provided, the grip remains fixed and immovable in the center of the slider. If the slider accuracy is less than the domain length, it will only toggle left or right to the lower and upper bounds of the domain. Even when the slider accuracy is greater than the domain length, hitting the lower and upper bounds of the domain should be a thing when dragging the slider grip fully to the left or the right. So, for example, if given a single digit post decimal precision on a rational number and a domain of 3.65 to 7.43, the slider should snap 3.65, 3.7, 3.8,… 7.4, 7.43.
How should decreasing domains be handled? Make them automatically increasing, backwards sliders?
I am not sure what you mean by this and a “backwards slider”, but it seems to be a question closely related to your last. Any change in the input domain should influence the slider in the same way that going into the slider editing dialogue of a regular “Number Slider” component and changing the min. and max. values of the slider does.
What happens if you provide more than one domain to a single slider?
… An error? Look, I think all we are envisioning here is a regular number slider that takes a domain to define on the fly what we would manually have to go into the number slider to change. A number slider that automatically remaps to a given domain. When you slap down a regular 'ol number slider it doesn’t produce a list of values. If the user wants to map a value to multiple domains, let it be their job to split the domains apart and feed them into separate “Domain Sliders”.
Think of the nightmare in terms of the graphical interfacing when trying to get a “Domain Slider” to accept multiple domains alone. What are you going to do? Superimpose grips on a single slider line? Let the component explode with hundreds of slider lines for each domain given to the slider? No, no, no… K-I-S-S. Keep it Simple, Stupid. :x
What happens if the domain changes? Does the slider value remain as unchanged as possible, or should the slider factor remain constant?
See above. It should be the slider factor that should remain constant, not the value since the value can be mapped to a value outside the bounds of its original domain. Also, a “Domain Slider” should only accept rational numbers since that’s what domains usually turn out to be and you don’t have to deal with a soft type-conversion. Although you could.
Necromancing again in the hopes that it might generate some interest. Just wanted to say that I second all of @Volker_Rakow’s suggestions to @DavidRutten’s questions. Even if you wanted to make it more complicated (maybe you want to give people the option to choose how the slider behaves in some of the situations described above), double-clicking the number slider already opens a dialog box anyway, so I imagine that you could add those options into that dialog box if that was the issue. For the changing domain, for example, I could see both unchanged values and proportional values being useful depending on the situation.
I don’t have any experience with programming/coding, so maybe this is a lot harder than it seems, but I don’t think this would be an unreasonable or even that much of a luxurious feature for the sliders. I’ve been sporadically using Grasshopper for a little over 3 months, and there have already been multiple situations where a variable domain for the slider would be a really nice option to have.
So I tried to vibe code this for fun . But don’t see how it would add additional functionality over existing GH number slider component?
code for reference (need to fight a lot with ai for UI/UX):
DomainSliderComponent.Attributes.cs (19.5 KB)
DomainSliderComponent.Registration.cs (6.0 KB)
DomainSliderComponent.Core.cs (8.3 KB)
Bit of an unlikely scenario due to the extreme dimensions, but it’s just an example:
Say you were to make a parametric door/window, and you wanted to have a slider input for both the width/height of the window, and the thickness of the frame. If, for some reason, your window becomes a lot smaller, you can suddenly start running into the issue where the thickness of your frame is larger than the total width/height of your window/door, which generally completely messes up your geometry, and for more complicated models you may not even know what’s causing the issue at first.
Having a variable domain for the slider would allow you to make the domain of the frame thickness slider dependent on the width/height of the window/door (or vice versa), which would prevent this issue.
AFAIK, right now, this can only be done by making one of the sliders percentage-based, instead of using the exact number you want.
Maybe something like this?
Accepts 1D domain from number, domain, curve. Allows preserve percentage or value.
Has Step size control
Add multiple grips.
