[Bf-cycles] Motion Blur Implementation

Gavin Howard gavin.d.howard at gmail.com
Tue Jun 11 03:39:48 CEST 2013


     Hello all,

     Thanks for your suggestions and ideas. I have downloaded the code
for both Mitsuba and Appleseed. I will be going through everything I
can to get this done right. We'll see what happens.

     God Bless,
     Gavin Howard

On Mon, Jun 10, 2013 at 12:52 PM, Constantin Rahn <crahn at vrchannel.de> wrote:
> Gavin,
>
> and take a look at the Mitsuba solution for moving lights, please.
> http://www.mitsuba-renderer.org/devblog/?p=786
>
> Happy Blending,
> Conz
>
> Am 10.06.2013 20:39, schrieb Matthew Heimlich:
>
> Gavin,
>
> You may also want to poke around in the Appleseed Render source code, as if
> I recall correctly they have a pretty modern approach to deformation blur,
> and a very similar architecture to Cycles as a whole.
>
>
> On Mon, Jun 10, 2013 at 2:33 PM, Gavin Howard <gavin.d.howard at gmail.com>
> wrote:
>>
>>      Hello all,
>>
>>      Brecht, thank you. I will get going on that patch. Stuart, if you
>> don't think that's a good idea, let me know. Otherwise, I'll use that to
>> focus my code exploration.
>>
>>      Nate, because of the nature of deformation motion blur, it will
>> include curved blur. It has to. The reason is because most deformation is
>> done by rotation. My current plan is to simply add multi-step export to the
>> Cycles addon. (All you smart devs should yell at me if that's a bad idea.) I
>> am also going to browse LuxRender's source code to see how they did it.
>> Regardless, at the end of this summer, not only will Cycles have deformation
>> motion blur, it will get multi-step export (steps will be specified by the
>> user) and curved motion blur by side effect.
>>
>>      God Bless,
>>      Gavin Howard
>>
>> On Jun 10, 2013 9:39 AM, "Nate Wiebe" <natewiebe13 at gmail.com> wrote:
>>>
>>> Not entirely related, but will the scope of this GSOC cover curved motion
>>> blur?
>>>
>>> -NateW
>>>
>>>
>>> On Mon, Jun 10, 2013 at 11:29 AM, Brecht Van Lommel
>>> <brechtvanlommel at pandora.be> wrote:
>>>>
>>>> Yes Blender supports this, it does scene.frame_set(frame, 0.0) now,
>>>> the second value is a subframe value between 0.0 and 1.0.
>>>>
>>>> On Mon, Jun 10, 2013 at 4:58 PM, Gavin Howard <gavin.d.howard at gmail.com>
>>>> wrote:
>>>> >      Hello,
>>>> >
>>>> >      Does Blender allow exporting at arbitrary subframes? If not, that
>>>> > might
>>>> > be a problem. If so, then Stuart has me exploring the code, and I
>>>> > think that
>>>> > I could write the patch while doing so. Does that sound okay?
>>>> >
>>>> >      God Bless,
>>>> >      Gavin Howard
>>>> >
>>>> > On Jun 9, 2013 6:34 AM, "Brecht Van Lommel"
>>>> > <brechtvanlommel at pandora.be>
>>>> > wrote:
>>>> >>
>>>> >> We should support exporting at the exact shutter time. At the time I
>>>> >> implemented motion blur evaluation at subframes was actually broken
>>>> >> for shape keys and physics systems so I didn't use it, but that has
>>>> >> been fixed since.
>>>> >>
>>>> >> However, exporting motion from the frame positions may be useful to
>>>> >> keep as it may give more predictable results in some cases. When
>>>> >> you're editing animations that's the only thing you actually see in
>>>> >> animation playback, so the motion between those frames may contain
>>>> >> some unexpected things that you don't want to render.
>>>> >>
>>>> >> I don't know how common that is, did not look at .blend files yet to
>>>> >> see how different the results are, if it is an issue we should
>>>> >> probably have an option (off by default) to only export motion from
>>>> >> integer frame numbers and no subframes.
>>>> >>
>>>> >> On Sat, Jun 8, 2013 at 7:36 PM, Gavin Howard
>>>> >> <gavin.d.howard at gmail.com>
>>>> >> wrote:
>>>> >> >      Hello all,
>>>> >> >
>>>> >> >      I have a question about implementation. I have been told by
>>>> >> > Brecht that currently, the Cycles addon exports three steps for
>>>> >> > motion
>>>> >> > blur to the renderer: one at the previous frame, one at the current
>>>> >> > frame, and one at the next frame.
>>>> >> >
>>>> >> >      Now, my memory may not be serving me well here, so I may have
>>>> >> > gotten the details wrong. But if not, shouldn't the addon actually
>>>> >> > use
>>>> >> > the shutter time to determine the first and third steps? For
>>>> >> > example,
>>>> >> > shouldn't the addon export a step at the start of the shutter time,
>>>> >> > one at the current frame, and one at the end of the shutter time?
>>>> >> > Also, I think this type of reasoning should apply even when
>>>> >> > multi-step
>>>> >> > (more than 3) motion blur is added. (Multi-step blur is needed for
>>>> >> > my
>>>> >> > Deformation Motion Blur GSoC project, so I will add it over the
>>>> >> > summer.)
>>>> >> >
>>>> >> >      In short, I think that the shutter time should be the goto for
>>>> >> > exporting motion blur steps. If it is, then just ignore this. But
>>>> >> > if
>>>> >> > it's not, should we change it? Anyway, that's my two cents.
>>>> >> >
>>>> >> >      God Bless,
>>>> >> >      Gavin Howard
>>>> >> > _______________________________________________
>>>> >> > Bf-cycles mailing list
>>>> >> > Bf-cycles at blender.org
>>>> >> > http://lists.blender.org/mailman/listinfo/bf-cycles
>>>> >> _______________________________________________
>>>> >> Bf-cycles mailing list
>>>> >> Bf-cycles at blender.org
>>>> >> http://lists.blender.org/mailman/listinfo/bf-cycles
>>>> >
>>>> >
>>>> > _______________________________________________
>>>> > Bf-cycles mailing list
>>>> > Bf-cycles at blender.org
>>>> > http://lists.blender.org/mailman/listinfo/bf-cycles
>>>> >
>>>> _______________________________________________
>>>> Bf-cycles mailing list
>>>> Bf-cycles at blender.org
>>>> http://lists.blender.org/mailman/listinfo/bf-cycles
>>>
>>>
>>>
>>> _______________________________________________
>>> Bf-cycles mailing list
>>> Bf-cycles at blender.org
>>> http://lists.blender.org/mailman/listinfo/bf-cycles
>>>
>>
>> _______________________________________________
>> Bf-cycles mailing list
>> Bf-cycles at blender.org
>> http://lists.blender.org/mailman/listinfo/bf-cycles
>>
>
>
>
> _______________________________________________
> Bf-cycles mailing list
> Bf-cycles at blender.org
> http://lists.blender.org/mailman/listinfo/bf-cycles
>
>
>
> _______________________________________________
> Bf-cycles mailing list
> Bf-cycles at blender.org
> http://lists.blender.org/mailman/listinfo/bf-cycles
>


More information about the Bf-cycles mailing list