I'm using SeExpr in Natron and Curve() doesn't work as expected.

[3Dmattias]

I'm trying to understand why these two things are not doing the same thing:

$Reds=0.7;
$Hueoffset=curve($H,0,0,1, 0.5,($Reds),1, 1,1,1);

outputs zero at all values between $H=0 and $H=0,5 then rises to 1 at $H=1

$Hueoffset=curve($H,0,0,1, 0.5,(0,7),1, 1,1,1);

outputs zero at $H=0 rises to 0,7 at $H=0.5 and then rises to 1 at $H=1

Obviously both should output the stuff that the second expression does.

Am I doing it wrong or is this a bug or is it just not possible to use variables as inputs in the Curve function?

[brentb]

It is a limitation of the curve function that variables are not supported for the cvs. This is because the cvs are evaluated at parse time for efficiency. It seems like a bug that the var ref is not reported as an error.

[3Dmattias]

Unfortunate. It is possible to do some really cool stuff if those CV:s where able to take variables. I would very much like to be able to take the performance hit whenever i used a variable...

I used to love it back in the day when I used Nothing Real's Shake and I could do these advanced color expressions using their curves and having variables as CV:s. It was incredibly useful.

Perhaps the curve function could have a flag for crazy people like me that want to be able to calculate everything at runtime?

[brentb]

It's a good sug. Constant arg evals are actually fairly cheap so there might not be a downside to just always keeping it live. We're pretty busy with SeExpr2 development though (LLVM support, some new language features) so it probably won't happen soon unless someone volunteers the effort.

[aselle]

Yeah, as an aside... if we are talking about only using variables for the
range of the curve (rather than the domain (i.e. time)), then it is not an
efficiency problem necessarily. The up front processing is to sort the time
values so you can do binary search to figure out what spline part you are
in. However, there is also some preprocessing involved in finding monotone
adjustments to the tangents which would need to be done in a less optimal
per-segment way in order to make that work. But it remains the same, if the
time values don't change and only the values change it is pretty doable,
but the comment about our development focus being on LLVM SeExpr2 that
Brent indicated is still true.

On Wed, Apr 27, 2016 at 1:14 PM, Brent Burley [email protected]
wrote:

It's a good sug. Constant arg evals are actually fairly cheap so there
might not be a downside to just always keeping it live. We're pretty busy
with SeExpr2 development though (LLVM support, some new language features)
so it probably won't happen soon unless someone volunteers the effort.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
#37 (comment)

[3Dmattias]

That makes a lot of sense. It would be very powerful just with the addition of dynamic range values. Being able to slide in time as well is obviously more complex. (especially if time values are not in order and or if they change order and such.) I fully support the decision to concentrate power on SeExpr2 but would be very happy if someone where to address the issue at some later point.

[devernay]

@3dMalmer that issue came up today on the Natron forum, and there is a solution using a python expression that produces a SeExpr script where all cvs are constants: https://discuss.pixls.us/t/seexpr-curve-and-ccurve-color-bug/18746/8?u=devernay
The Python expression is evaluated once per frame and produces a valid SeExpr script.