We’ve had 2 separate patches submitted in a relatively short timespan to allow Action Constraints to be controlled with a single float property input, rather than requiring a bone target. This is useful for a variety of reasons which have already been discussed at great lengths;
As far as I can tell this is what we seem to be leaning towards as far as the general design goes, but perhaps there’s a more descriptive name than “Time Factor”
IMO this is the most intuitive way to do it, but people might prefer to have an unbounded input (not a slider) and set a start/end range on that. I’m not a fan of that design since chances are this property is going to be powered by a driver, and any remapping of values should take place there rather than in the constraint (it’s what drivers are designed to do after all).
I’d also like to just reaffirm that I had no idea there was a patch submitted already - mine looks like it follows a lot of the suggestions made under that one, but that’s a genuine coincidence (even down to calling it “Time Factor” haha)
I agree with this! This is a feature that would let Action Constraints be a lot more flexible for rigging purposes when you want to drive actions by something other than a bone.
This particular implementation design by Lateasusual seems intuitive enough. It doesn’t change the Action Constraint from its original design unless the checkbox for “Use Time Factor” is enabled. Once enabled, the Time Factor slider appears, and all irrelevant information is hidden for extra clarity.
This allows you to simulate the passage of time within the Action Range without a target object or bone in a very intuitive way. The user can then add a driver to the slider (or keyframe the slider) to control the action constraint directly.
Overall, I think it feels pretty intuitive. It doesn’t change the way you use the Action Constraint by default while still adding functionality.
Two people independently calling the slider “Time Factor” means that there is at least some consensus here about the name. Since it is limited to a factor of 0-1, I think that a percentage would be clearer (just pass PROP_PERCENTAGE instead of PROP_NONE in the RNA definition).
I also like that enabling “Use Time Factor” removes all the irrelevant options, making it visually clearer that it replaces certain functionality. I think having a [0-1] range is also a good idea, rather than having arbitrary bounds for that value as well.
I’m still not sure about calling it a “factor” though, but I can’t really think of a better term either. What I would like is to have a name that makes the relation to the Action Range fields clear. Here are some of the alternatives that went through my head:
Part of Action
Portion of Action
Action Fraction (nice rhyme here)
Time Percentage in Action
Action Progress
Time Progress
Percentage of Action (but that could just as well be “percentage applied”, a.k.a. “influence”)
Update: I’m starting to quite like Action Fraction
The follow path constraint has a similar toggle called “fixed position” which the user then controls through the “offset” property. Both that one and the new “action fraction” offset something along a normalized range, maybe it’s worth making them consistent.
I personally prefer it to have “Time” in the name at least, and figured “factor” is usually what’s used to indicate something mapped to a range. The closest other usages are the “offset” properties on other time-related constraints/modifiers - but that’s because they update automatically, so the offset is actually an offset, while in this case it’s not offsetting anything… the other is “Value” for shapekeys, but i think “Time Value” is a bit vague.
with that said I would go for "Time Factor, “Time Fraction”, “Time Value”, “Time Input”(?)… Action Fraction is fun but too silly I think
Edit: Also, I think a “factor” is better than a percentage - if it’s going to be controlled by drivers mainly then a 0-1 range is better than 0-100 (unless i missed something in the RNA definition, 0-1 shows up as 1%?)
@sybren , thanks it’s nice to be here good to see you too!
Hmmm, yeah the name is tricky. I figured Time Factor would work simply because so many other 0 - 1 sliders are named Factor. But I gave it some thought and I agree that if the slider had the word “Action” in it, it would feel more closely tied to the Action frame range. However, it does feel a bit redundant since the constraint is already named the Action Constraint. Maybe if there’s a way to make it obvious without using the word “Action”.
The issue with Offset is like what Lateasusual already said: it implies an offset that isn’t there technically. Also, the Offset value for the Follow Path constraint doesn’t have limits like this one does, nor does it take into consideration the length of the frame range.
I would personally narrow things down to “Time Progress” vs “Time Factor”. However, Time Progress doesn’t feel like an input as much as it feels like a “progress bar” output. So in that sense, I prefer Time Factor. However, I do agree that Factor is a pretty vague term. It’s not immediately clear if there are other influences of Time that affect the Action. Therefore, the goal is to find a name that makes it clear that it’s an input and that it’s the sole contributor to the Action’s playback.
My suggestion would be “Time Control”, as it is more obvious as an Input, and “controlling” Time in the Action Constraint should be obvious that it’s for the specified Action. Moreover, it makes it more clear that the Slider should be the sole contributor to the Action’s playback. It seems to satisfy all criteria. What do you guys think?
“Time factor” sounds good to me, even though I feel “factor” alone would be enough.
the Offset value for the Follow Path constraint doesn’t have limits like this one does, nor does it take into consideration the length of the frame range
It does, it uses the length of the curve remapped to 0…1
I do quite like “Evaluation Time”, and sticking with the 0-1 slider range rather than 0-100%
It maybe doesn’t hint strongly enough that it’s mapped to a fixed range, but I think the fact that it’s a slider is more than enough to counteract that!
This sounds better than Time Factor to me now anyway.
EDIT: This would use eval_time, ACTCON_USE_<TIME/EVAL_TIME> in place of time_factor and ACTCON_USE_TIME_FACTOR, how does that sound?
(even down to calling it “Time Factor” haha)
good to see you too!
