Add frame time parameters for motion blur interpolation

[Lord Crc]

Hi,

please see the following thread: viewtopic.php?f=16&t=7422

As mentioned in the reply, I suggest we introduce two new parameters which control the interval over which interpolation occurs, which is independent of the interval the shutter is open. If the new parameters are not present they are set to the shutter open interval to make it backwards compatible.

This should also make it easier to have correct motion blur for animations, since in a real film camera the shutter is open for only for parts of a full frame.

Thoughts, suggestions for better parameter names?

Cheers

[jeanphi]

Hi,

Yes, that's absolutely true. It is a pity that the transforms depend on the camera, they shouldn't. Introducing this would open the path towards having a much more generic system where you could define whole transform paths and then get the render at whatever time you want. I really believe we should devise the change towards this goal (it shouldn't be much more work actually).

Jeanphi

[Lord Crc]

Good point. We could perhaps associate a time when making the named transform? Would be slightly more complicated storing multiple transforms for the same time, but not significantly. Would mean we could retire the MotionInstance keyword as well.

While it could wait, it would be nice not introducing a short-lived keyword which would be hard to deprecate later on.

[jeanphi]

Hi,

Why not use RenderMan constructs?

Jeanphi

[Lord Crc]

Why not use RenderMan constructs?

Because I keep forgetting them I'll read up on it.

edit: Ok, so we introduce MotionBegin / MotionEnd blocks, and for now only allow transformation commands inside it? Should we do something like this then?

Code: Select all

TransformBegin
  MotionBegin [0.0 0.5]
    Translate 0 0 0
    Translate 1 0 0
  MotionEnd
  CoordinateSystem "MyMotionTransform"
TransformEnd


so "MyMotionTransform" would now be a path with two "knots", and using it for a camera transform or instance transform would result in motion blur?

edit2: And I suppose we can disallow nested moving coordinate systems initally? Otherwise I fear it will be somewhat complicated.

[jeanphi]

Hi,

That could do, however RiSpec way mandates that inside a motion block you can only use one kind of statement, so no nesting is possible. The motion block should create a motion transform object and if we encounter several consecutive motion blocks, they should be treated like transform statements, this is mandatory because if you need several statements to define your transform, you'll need that many motion blocks.

Jeanphi

[Lord Crc]

Ok, I read this Advanced RenderMan document which did seem to imply they could be nested, but yes, you couldn't do it directly.

Regarding multiple motion blocks... how do we handle the following case?

Code: Select all

MotionBegin [1.0 2.0]
    Rotate 0 0 0 1
    Rotate 180 0 0 1
MotionEnd
MotionBegin [0.0 3.0]
    Translate 0 0 0
    Translate 1 0 0
MotionEnd

Do we create a path which contains 4 knots, where the translation part of the middle knots is interpolated before they're concatenated?

edit: reading the Advanced Renderman document again I don't see where I found the nesting part, perhaps I was dreaming.

[jeanphi]

Hi,

Yes, the correct behaviour is that the complete path between 0 and 3 has 4 knots (0, 1, 2, 3) and the first transform is extended outside the [1,2] range with the limit values.

Jeanphi

[Lord Crc]

Allrighty then. I'll see if I can take a stab at this, if you don't mind.

I'll modify MotionPrimitive and Camera to accept a more general MotionPath class, which in essence holds multiple MotionSystem's, instead of the current start and end transforms. I'll also need a class to hold and combine the (time, Transform) pairs from a MotionBlock during parsing.

I think we can then deprecate the "MotionInstance" keyword, such that if there's a motion path when "ObjectInstance" is called a MotionPrimitive is created instead of an InstancePrimitive.

Sounds ok or?

[jeanphi]

Allrighty then. I'll see if I can take a stab at this, if you don't mind.

Not at all, please do

I'll modify MotionPrimitive and Camera to accept a more general MotionPath class, which in essence holds multiple MotionSystem's, instead of the current start and end transforms. I'll also need a class to hold and combine the (time, Transform) pairs from a MotionBlock during parsing.

Maybe motion system could be made a base virtual class so that instead of all the various code path selections inside MotionSystem::Sample you would have various subclasses selected at parsing time, and the MotionPath would be another subclass, that would prevent changing all users of MotionSystem and might lead to a cleaner interface, what do you think? The transform decomposition should then probably be a static member returning a MotionSystem pointer.

I think we can then deprecate the "MotionInstance" keyword, such that if there's a motion path when "ObjectInstance" is called a MotionPrimitive is created instead of an InstancePrimitive.

Sounds ok or?

Sure.

Jeanphi