[Bf-committers] Frame Rate: Time Remapping

[Daniel Salazar - 3Developer.com]

Troy I'd like to know what are you trying to do before saying
anything. You are trying to use an almost deprecated feature and there
are other options around. Are you handling live footage?

Daniel Salazar


2011/3/25 michael williamson <michaelw at cowtoolsmedia.co.uk>:
> 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
>
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>