Sphinxmorpher
 |
Some trickery is going on when connecting an IntSlider to a HDR Map input. It seems like the integer value is scaled into 0..1 range. Please don't do that. People can enable Remapping and resort to such things there.
This is very impractical and I haven't found a way to get the true integer value into HDR Map Inputs without a script. A usecase: You setup a loop that loops IntSlider value times. The loop adds up samples and you want to divide the result by IntSlider value...but no. |
|||
| Posted: May 15, 2019 2:18 pm | ||||
Indigo Ray
 |
||||
| Posted: May 15, 2019 8:21 pm | ||||
|
Sphinxmorpher
|
Thanks, but that is exactly what I want to avoid - you now have two sources that define max value which you must keep in sync. If you change IntSlider max, you have to update the multiply. This is not much different than using the remapping option.
|
|||
| Posted: May 16, 2019 2:25 am | ||||
|
Sphinxmorpher
|
Here is a demonstration of the problem. Try bypassing the script (IntSlider -> Divide).
The script is btw the only known workaround if you want to keep a single source of truth. Intslider Conundrum.ffxml |
|||
| Posted: May 16, 2019 2:35 am | ||||
|
Sphinx.
|
Bump. It would be nice if 1 = 1 and 2 = 2 etc.. the current behavior is counter intuitive and force you to redefine constants.
Here is a real world example from Emme's sampled blur - notice how the max iteration count number (16) is entered both in the Integer control and the HDR color remapping modifier: https://www.filterforge.com/upload/for...v001.ffxml  |
|||
| Posted: February 16, 2020 8:12 am | ||||
|
Sphinx.
|
..and the copy of the constant due to forced remapping logic:
 |
|||
| Posted: February 16, 2020 8:14 am | ||||
|
Sphinx.
|
A possible solution would be a checkbox in the Int To HDR Color remapper, that forces it to use the direct integer value.
|
|||
| Posted: February 16, 2020 8:16 am | ||||
| emme |
+1
HDR checkbox or a separate HDR IntSlider would be nice. |
|||
| Posted: February 17, 2020 10:41 am | ||||
|
GMM
Moderator
Posts: 3491 |
It would be nice but... our component infrastructure doesn't allow for remapper versioning. A change like this would mean versioning of all the components that can accept IntSliders. This requires months of work, I'm not exaggerating. For non-library filters (when you don't care about submission warnings) you can simply replace the IntSlider with a Value component. |
|||
| Posted: February 18, 2020 9:25 am | ||||
|
Sphinx.
|
Ouch! I didn't think it would be that extensive an effort. Well, I hope you find a way around it at some point. Perhaps a change like this can be introduced without backward compatibility issues and the need for versioning. Fingers crossed  |
|||
| Posted: February 19, 2020 1:59 pm | ||||
Join Our Community!
Filter Forge has a thriving, vibrant, knowledgeable user community. Feel free to join us and have fun!
33,711 Registered Users
+18 new in 30 days!
153,531 Posts
+36 new in 30 days!
15,347 Topics
+72 new in year!
Online Users Last minute:
27 unregistered users.
Recent Forum Posts:
- Kaleidoscopic Variations Vol. 2 by jhantares by jhantares
September 10, 2025 - Polygonal Images Set by Ramlyn by westdale
September 10, 2025 - FF Killing Resolution by SpaceRay
September 9, 2025 - Geometry Spinner by Rachel Duim by Rachel Duim
September 6, 2025 - Channel Glitch by Martin Naumann by SpaceRay
August 31, 2025 - Circuit Glitch by Martin Naumann by SpaceRay
August 31, 2025 - Groovy Rays by Ramlyn by Ramlyn
August 31, 2025 - Is Ultraforge dead? by dpankros
August 30, 2025 - Component Instances by AussieDecalf
August 27, 2025 - Hyperbolic Tiling Challenge by AussieDecalf
August 27, 2025 - Chaos Fields by SpaceRay
August 27, 2025 - New awesome TEXT component FF 14 - How to get the most of it? by SpaceRay
August 20, 2025
