Updates to Web Viewer to allow values outside of 'uisoftmin' and 'uisoftmax'

[paytonGilbertson]

(#1817) Allow for users to manually input values outside of the soft min and soft max in the web viewer

Changes made in

• viewer.js

[jstone-lucasfilm]

This looks very promising, thanks @paytonGilbertson!

As it turns out, we introduced a subtle bug in the MaterialX Web Viewer yesterday, and I've written up a proposed fix at #2931.

Since your work depends on the correct functioning of the Web Viewer, I'd like to review and merge the fix above before reviewing your improvement, so that your work can be tested in the full context of the working viewer.

[kwokcb]

I think you need to keep track of a soft and hard min/max as if there is a soft min/max but no hard min/max it will compute a different step size with this change.

[jstone-lucasfilm]

@paytonGilbertson In addition to Bernard's review note above, which sounds logical to me, I'll just mention that #2931 has now been merged to main, and you can merge from main to your PR if you'd like to test with the full range of material examples.

[kwokcb]

Sorry for being nit-picky + lack of clarity and in the previous comment. Step is computed based on both hard / soft min / max. So to preserve previous logic soft min / max still needs to be stored somewhere and used here. Maybe just keep a stepMinValue and stepMaxValue ?

[jstone-lucasfilm]

Thanks for diving into this issue, @paytonGilbertson, as well as to @kwokcb for the great feedback.

Taking a step back to the original goals of #1817, we're hoping to allow users to type values beyond the soft range in the Property Editor, not to widen the range of the slider itself. In MaterialX terms, uisoftmin and uisoftmax are meant to describe the range of UI sliders, while uimin and uimax are the hard limits the application should enforce. So the ideal behavior is:

• Slider range and step: continue to drive these using the soft min/max (with the existing fallback to hard min/max when not present).
• Typed input: clamp only to the hard min/max, and allow unbounded entry when no hard limit is defined.

The subtlety is that lil-gui's folder.add(obj, 'value', min, max, step) uses a single min/max pair for both the slider geometry and the input clamp. So the cleanest path forward is:

1. Restore the soft min/max logic for minValue/maxValue/step (this also fixes the common case of inputs that define soft limits but no hard limits).
2. Read the hard uimin / uimax into separate variables (defaulting to negative/positive infinity when absent).
3. After creating each controller, adjust only the controller's input clamp to the hard range, leaving the slider geometry untouched.

Does that sound like a reasonable approach to you both?