[Bf-committers] S-DNA and Changes

[Leo Sutic]

On 2010-11-25 23:40, Peter Schlaile wrote:
> Hi Leo,
> 
>>> 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.

Ah, ok.

I'd still try to stick with integer frames and a parameterless next().
Allowing the client to specify the advance in the next() method makes it
too much of a random-access method (there is no guarantee that the
advance is to the "next frame", which is the whole purpose of the
iterator interface).

I'd do it this way:

Suppose we have a scene where we want normal speed for frames 1-10, an
extreme slowdown for 11-12 and normal speed from 13-20.

Strip 1: Scene, frames 1-10. This strip covers frames 1-10 in the VSE.
Strip 2: Scene, frames 11-12, with a framerate of 1/100th of the output
framerate. This strip covers frames 11-211 in the VSE.
Strip 3: Scene, frames 13-20. This strip covers frames 212-219 in the VSE.

When the sequencer renders this, the next() for strip 1 and 3 will
advance one scene-frame. The next() for strip 2 will advance 0.01 frames.

That way, the VSE code only ever sees integer frames (although it does
see different frame rates), and we can guarantee machine precision in
the slowdown frame number calculation. The renderer, however, sees the
fractional frames - but this is hidden behind the scene strip's code.

(This also enables us to take a scene that was designed for 24p and
render it at 60p with everything lining up properly.)

Would this take care of the issue?

I realize that we suddenly have a "VSE cfra" and a "Scene cfra", but if
you're going to have retiming through the VSE, then you already got that.

/LS