## Add frame time parameters for motion blur interpolation

Discussion related to the LuxRender Material system, programming API and Scene file format.

Moderators: jromang, tomb, zcott, coordinators

### Add frame time parameters for motion blur interpolation

Hi,

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
May contain traces of nuts.

Lord Crc

Posts: 4455
Joined: Sat Nov 17, 2007 2:10 pm

### Re: Add frame time parameters for motion blur interpolation

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
jeanphi

Posts: 6577
Joined: Mon Jan 14, 2008 7:21 am

### Re: Add frame time parameters for motion blur interpolation

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.
May contain traces of nuts.

Lord Crc

Posts: 4455
Joined: Sat Nov 17, 2007 2:10 pm

### Re: Add frame time parameters for motion blur interpolation

Hi,

Why not use RenderMan constructs?

Jeanphi
jeanphi

Posts: 6577
Joined: Mon Jan 14, 2008 7:21 am

### Re: Add frame time parameters for motion blur interpolation

jeanphi wrote: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.
May contain traces of nuts.

Lord Crc

Posts: 4455
Joined: Sat Nov 17, 2007 2:10 pm

### Re: Add frame time parameters for motion blur interpolation

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
jeanphi

Posts: 6577
Joined: Mon Jan 14, 2008 7:21 am

### Re: Add frame time parameters for motion blur interpolation

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 1MotionEndMotionBegin [0.0 3.0]    Translate 0 0 0    Translate 1 0 0MotionEnd

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.
May contain traces of nuts.

Lord Crc

Posts: 4455
Joined: Sat Nov 17, 2007 2:10 pm

### Re: Add frame time parameters for motion blur interpolation

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
jeanphi

Posts: 6577
Joined: Mon Jan 14, 2008 7:21 am

### Re: Add frame time parameters for motion blur interpolation

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?
May contain traces of nuts.

Lord Crc

Posts: 4455
Joined: Sat Nov 17, 2007 2:10 pm

### Re: Add frame time parameters for motion blur interpolation

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

Lord Crc wrote: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.

Lord Crc wrote: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
jeanphi

Posts: 6577
Joined: Mon Jan 14, 2008 7:21 am

Next