[Bf-committers] Frame Rate: Time Remapping

michael williamson michaelw at cowtoolsmedia.co.uk
Fri Mar 25 10:34:38 CET 2011


I used this feature for the first time about a week ago...
I'm using an svn build a week or so old and it works for particles if 
you bake...

I've heard it's not working for cloth and smoke has its own "time" value 
for simulations....

Part of the issue is that this feature doesn't seem to work for 
everything... and until it does then what would be "most intuitive" 
doesn't matter!

That said, It's quite easy to use as is, (if you find it in the first 
place)  but:

If the  renderer could have non integer frames then it could all be much 
simpler and "intuitive"


The first place I looked to slow down time was the render step size:
If you could set the render step size to a float value

step = 0.5  would render twice as many frames and so be half speed...

Done!


When that didn't work the second place i tried was the sequencer:
I set a  scene strip to have a "speed" effect strip that doubles its 
duration hoping it'd render the interpolated  frames...

Instead it renders as in source and just holds them as if they were any 
other image sequence...

Once I found the feature it was pretty easy to use, but with the quirks 
already mentioned by some (having to drag further on the timeline...  
non baked things going beserk...







On 25/03/11 08:42, Troy Sobotka wrote:
> On Mar 23, 2011 11:39 AM, "Tobias Oelgarte"<tobias.oelgarte at googlemail.com>
> wrote:
>> The
>> feature works partially, but some strange things are happening:
> Are you certain it still works in SVN? It seems potentially broken.
>
>> I would like to have this feature back or reimplemented, since it is the
>> only simple way to adjust the timing.
> As someone with a smidge of experience in film work, I could not agree at
> all that the implementation works or is, from the vantage of a motion
> picture tool, "simple".
>
> I wonder if there are things we could do that would serve motion picture
> artists better here?
>
> 1) Should time remapping be given the central piece of UI real estate where
> it is currently located given frequency of use?
>
> 2) Within other contextual application workflows, does the current
> implementation resemble or appear understandable to a motion picture artist?
>
> 3) Aside from (2) above, given understanding of the two adjustable
> variables, does it work as expected?
>
> I worry that in all of the above questions time remapping may be sub optimal
> in its current implementation and execution.
>
> Would this be more well suited as a technique to leverage out of the VSE? At
> the very least it would seem logical to migrate the current implementation
> to an alternate panel of lesser prominence.
>
> Sincerely,
> TJS
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers



More information about the Bf-committers mailing list