[Bf-committers] S-DNA and Changes
peter at schlaile.de
Thu Nov 25 23:40:27 CET 2010
>> Regarding your interface prototype: your interators should take a float
>> increment parameter. (There isn't really a well defined "next" frame in
>> float precision scene-rendering...)
>I decided against that due to the complications it resulted in - mostly
>because it became very difficult to get all frames to align in time when
>round-off errors may affect the float cfra parameter depending on how it
>was calculated. (It was also difficult for movie clip sources, again due
>to rounding errors, where you could end up on the wrong frame.) It was
>easier to just pretend, in the VSE, that each sequence was continuous,
>but sampled at a fixed rate. (So the "frame rate" should really be a
>"field rate".) That way, the only time we risk that the frames don't
>line up is when we do framerate conversion - and everyone kinda expects
>them to not line up then.
uhm, ouch. OK, do it differently, tell the next()-iterator the
absolute next-cfra not the increment, but please make it a float, because...
> I'm just guessing regarding the float cfra parameter: Is it for motion blur?
... it's not about motion blur, it's about retiming.
If CFRA is float, you can retime a scene strip afterwards and have it
render subframe precision frames (read: extrem slowdowns), which are
done the real way, not using fake interpolation.
More information about the Bf-committers