Relative Controls and Re-mapping

i may have mentioned this one once before. not sure. but what i was thinking about was if you have, let's say, 2 perlins and a scaling control on each one. i'd like it so that if were to change one slider, the other slider would re-scale itself or re-map itself to a different range. in other words, one control becomes relative to the other.

i know, it's rather an odd request, but nonetheless, i do run into uses for this from time to time.

thanks, vladimir. i know all of us regulars here are looking forward to beta2.

You can do that with curves for the green and the blue inputs, but not they grey (numeric) ones. In many cases, you can work around that limitation, although it makes the filter slower. It would definitely be easier (for us) with such remapping.

What about mathematics ?
… remapping one by another X(in) by Y(another in) = Z(out)

All mathematics operators should be available.

(It is in Vue's editor)

Yes, I imagined the math component in a similar way (but you'd have to declare input names and types in advance, and only after that you'd be able to refer to them in the expression). And I'd prefer a Lua script there instead of a simple expression

In your mock-up the component is gray, which means it's a new kind of component, say, a Scalar. We currently don't have infrastructure for that, but we're considering implementing it. As I said in my earlier reply above, it's not easy.

Also, there's a dilemma -- suppose that we have some math operations available as regular Filter Forge components. Do we need to implement the ability to 'call' these components from within the expression/script or we can use separate code for these? Will the users be able to 'call' non-math FF components from within the script? (e.g. "Color = Motion_Blur(Radius, 30, 0, TRUE)"?

(BTW, we're already playing with some map components that implement some math operations (Add, Sub, Mul, MulConst, Div, Power, Log) -- and they all work with unclamped HDR / double precision floating point numbers including negative values.)

I always loved the idea of math for controls... it's a must-have feature for more complex control wirings!

Quote
Vladimir Golovin wrote: In your mock-up the component is gray, which means it's a new kind of component

Make that the same gray as the regular Control components and file it under a new category: Control Ops!

We already have this categorization for Curve and Curve Ops components, so why not also introduce it for Control components? The Math curve ops could serve as a good example of what a Math control ops component could look like... just replace the two profile curve inputs with control inputs. Naturally, a full-blown 'Expression' control ops would be even sweeter.

[One could imagine other Control Ops (like 'Randomize', which I made a feature request for some time ago).]

I didn't yet understood evrything ( I never tried script neither HDRI )
But I think those tools should stay easy to use ( and if possible easy to implement ).
So let me propose this one :



The Blue remap would turn grey output and source, the moment the user plug a grey controler in the source.

( I've noticed that the inside (preview) of a tool is updated. Could its source and output color be updated too ? )

Or should it be a new tool ? (more tools = less easy for the user)

UPDATE: One prob. I can't solve : It makes no sens if the remap input is in 3D, like this :

…Unless the Remap output return (or stay) to blue, meaning 2D output, as a section (red) of a 3D.
( in the exemple the Grey output would mean 1D ( a value outputed ) as a section (red) of the 2D Gamma (or any curve)
Too complicated ?

Quote
Crapadilla wrote: By "compressing" do you mean integrating the existing Curve Ops components into a single Curve Script component, thus turning all of them obsolete?

No, they will remain. I meant, one non-visual Script / Expression component vs. 30 or so visual Math components (Add, Sub, Mul etc.)

Quote
Crapadilla wrote: I take it you don't like the idea of having a visual expression editor?

A good visual script editor capable of representing all constructs of a modern scripting language would take years, which is certainly not an option.

If we're talking about expressions (as opposed to scripts), then what's the point of having a separate editor for expressions when we can do it right in the Editor, just by adding some more components?

An important question is: Should assembling expressions/scripts be visual or should it be based on text-input. I'd lean toward a visual editor, but if this takes ages to develop then that's no good for any of us, obviously.

Furthermore, if the introduction of generalized script components takes years of development and raises so many questions of debugging, performance and threadability, then it might be prudent to opt for a 'simpler' solution specifically targeted at the need of users to design more streamlined and usable filters.

Many things could be automated via expressions, leading to filters with fewer yet more elaborate/powerful controls. All users would immediately benefit from that, whereas scripting support would probably target a much smaller part of the community.

I also feel that the area of usability/convenience for filter controls is a whole different beast than the introduction of scripting support a la 'Map Script' components. Being able to design filter controls to be more elegant/useable also appears more immediately desireable to me than duplicating something like processing inside FF.

As usual, that's just my personal 1.618 cents...