Extreme number changes when I use the slider

So, like the subject says, when I move the slider in some twirl down menus - say 'particles per second'  - it will jump from 60 to hundreds of thousands with the slightest adjustment.  It happens in other twirl down menus as well, though not all of them.  For example, transform controls don't give me grief.  

There are more but I can't recall or replicate them at the moment. I'll post more as they occur.


  • Some controls have a very large range that they allow. The slider control has a limited range of movement in pixels. The slider can quite small/short depending on how you arrange your UI panels. The ends of the slider still need to set the largest/smallest value in the allowed range. So in this sense it is expected that the slightest slider movement, one pixel, will have big jumps for certain controls. 

    To get finer movement you can click and drag on the numeric entry entry field, left or right. The value movement will be finer than moving the slider.

  • edited October 2017

    I see, Norman.  Thanks for the response.  Just for reference, I was just moving the slider for 'speed' under the movement variation for a particle simulator and it went from 200 to well into the 200,000's at the slightest adjustment.  Pulling the slider all the way to the right yielded a value of 2147483648.0.  Is that normal?  That seems like an impractical level to me but I am certainly not an expert on such things.  I'm sure it has its uses.

  • One can argue that a range of 2 billion for speed is impractical and thus makes the UI for sliders not usable for dragging but realistically it (the allowed range) is set in stone. I have used 3-5000 for speed and that has some good speed so something like 100k should be crazy quick. I'm not sure even 100k is useful. 

    Just drag the numeric entry field on big range items. I find myself dragging the entry field a lot. For rotation it is really a lot easier than the little circle.

    For particle speed because the slider is useless and dragging the entry field is too slow, I always use enter numeric values. Actually for a lot of things in the particle sim, just entering a value makes more sense. At least to me. Things like grading brightness, contrast, color wheels, masking feather and such, a slider/drag is really useful.

  •  @NormanPCN just out of interest, why is it that the range on that slider is so high, and why/how is it set in stone?

    I'm  sure I remember at least one control in HitFilm where the field can be set numerically to a value beyond the range of the slider control, so is it reasonable to assume that it is possible to implement similar behaviour for other sliders?

  • Only FxHome knows why the speed range is so high. It seems beyond useful, but then, I don't know jack.

    Set in stone is my way of referencing backwards compatibility requirements.

    If the Hitfilm UI allows a numeric entry field to have a range greater than the associated slider then the particle sim speed property is one where this would be useful given the large allowed range. 

  • Triem23Triem23 Moderator

    @NormanPCN it's probably as simple as assigning a 32-bit word to the parameter. That said, if that slider could dial down to a top range of maybe 32000 or so while leaving the valid range as two billion that would make the slider more useful while holding compatibility. 

  • edited October 2017

    I was going to suggest a +-10,000 slider range. Anything low five figures is good. If a slider is 100 pixels then we are dividing a 20k to 64k range instead of a 4 billion range into a reasonably fine increment.

    While we are yammering about the particle sim. The particles per second range is 0..1,000,000. The slider there gets big jumps as well.

    1 million particles per second is an aggressive/optimistic upper limit given the single threaded nature of the sim and the synchronous UI. 55sec per frame with a 4Ghz i7 CPU and 1080 GPU. Built-in smoke texture. The GPU barely blips at the end of each frame.

  • Triem23Triem23 Moderator

    Is it a million particles per second? Why did I think it maxed out at 100k?

    0-10k is probably a good range for a slider...

    Hmmmmm. Given that some effects have numeric input exceeding a slider's range now I'm wondering if there could/should be a graphic indication for those sliders... Maybe a "+" at the high end? 

  • @Triem23 "Given that some effects have numeric input exceeding a slider's range "

    Which ones?

  • Triem23Triem23 Moderator

    @NormanPCN see, I'd have to go searching for a few, cuz I don't remember offhand. @JMcAllister and @NxVisualStudio have encountered that as well (NX pointed it out to me), but Hitfilm does have parameters with sliders where one can manually set a value beyond the slider. If I come across a concrete example I'll let you know what it is so you can re-verify the behavior.

  • I finally found some in the native effects. Scale in Fractal noise. Distortion and Scale in Fluid distortion.

    Some fields in particle sim should probably get the same treatment.

  • Triem23Triem23 Moderator

    @NormanPCN and that's likely true across all the Distortion effects as those are "same stuff, different fractal equation."

    So... Back around to wondering if it's possible to add a graphic indicator to fields where numeric input exceeds slider range.

    I'll Wishlist it shortly. 

  • @Triem23 I'll +1 the indicator wish idea. I think your "+" idea is simple, compact and workable. There really should be something letting us know.

  • Here's a few more examples. I was going to go through and find them all, but I got bored around about the time I started on the "generate" folder... 

    examples I found: 

    -All of the sliders in "360 text"

    -All sliders in "Vignette exposure"

    -All sliders in "Depth Mask"

    -All sliders in "Depth Matte"

    -Most sliders in "Energy distortion" (and likewise "Fluid distortion", "Heat distortion", and "Smoke distortion")

    Sorry I didn't provide any examples earlier, I was on my linux computer so I couldn't check

This discussion has been closed.