Add Nullable ValueGradientDrivers.

[ModernBalloonie]

Is your feature request related to a problem? Please describe.

Sometimes I want to drive a nullable value with a gradient driver, like a nullable float or something, but you can't make a valuegradientdriver of type Nullable<float>, so I need to do a few things. Those being:

Make a gradient driver, drive a float ValueField, Source that ValueField in ProtoFlux, pack it into a nullable float, then drive what I need to drive. This is a little frustrating because it adds some flux to an otherwise only component thing that i'm making.

Describe the solution you'd like

A nullable ValueGradientDriver, so I can just do this with one component.

Describe alternatives you've considered

I've tried using NullableSourceDriver with WriteBack, but you can't actually drive the fields because they're already being driven.

Additional Context

No response

Requesters

ModernBalloonie

[Frooxius]

I don't really see how would this work?

ValueGradientDriver works by interpolating values. However you can't interpolate over null values - lerping between a null and non-null value is not really defined operation and there's not a single way to handle something like that.

[ModernBalloonie]

ValueGradientDriver works by interpolating values. However you can't interpolate over null values - lerping between a null and non-null value is not really defined operation and there's not a single way to handle something like that.

Can this not be handled like a valuegradientdriver of type bool? I'm curious. Unless there's another way to do it, say a component to seperate the float, and checkbox of the nullable to be driven with a normal bool, and float value.

[XDelta]

Presumably and how I'd see this work would be to set the value null at a progress of 0, having the progress driven by something time based, and at a delayed time say 0.2 progress it becomes not null and with a value. Would be possibly helpful for animating things using the ValueGradientDriver as a naive timeline.

Although as mentioned interpolation would be undefined behavior. It would need to make assumptions. from that 0.2 progress, if we went to 0.1, should that treat the progress 0 value of null as the default value of the T type or should lerping between those just not occur and 'snap' to the closest value as if there was not interpolation. I think implementation of nullable types for lerping often just returns null if either lerp target is null.

Without this being added, you can currently do so with protoflux to define what you want to happen for null values along with packing it into the null value (you are driving a nullable type with an alway non-null value). Should you need to have null values driven in, you can have the protoflux compare the value and certain conditions such as if the value is greater or equal to 0, pass it as is, if the value is less than 0 then drive the value with null.

[Frooxius]

The fact that we need to make assumptions and that they are kinda arbitrary is what's a bit of a problem here.

E.g. say we choose to interpret the null values as default values - is that what the user wants? But also what does this bring you in terms of interpolation mechanism, that you wouldn't get by just putting 0 as the value in there instead?