[Bf-cycles] Motion Blur Implementation

Constantin Rahn crahn at vrchannel.de
Mon Jun 10 20:52:48 CEST 2013


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 <mailto: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
>     <mailto: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
>         <mailto: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
>             <mailto: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
>             <mailto: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 <mailto: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 <mailto:Bf-cycles at blender.org>
>             >> > http://lists.blender.org/mailman/listinfo/bf-cycles
>             >> _______________________________________________
>             >> Bf-cycles mailing list
>             >> Bf-cycles at blender.org <mailto:Bf-cycles at blender.org>
>             >> http://lists.blender.org/mailman/listinfo/bf-cycles
>             >
>             >
>             > _______________________________________________
>             > Bf-cycles mailing list
>             > Bf-cycles at blender.org <mailto:Bf-cycles at blender.org>
>             > http://lists.blender.org/mailman/listinfo/bf-cycles
>             >
>             _______________________________________________
>             Bf-cycles mailing list
>             Bf-cycles at blender.org <mailto:Bf-cycles at blender.org>
>             http://lists.blender.org/mailman/listinfo/bf-cycles
>
>
>
>         _______________________________________________
>         Bf-cycles mailing list
>         Bf-cycles at blender.org <mailto:Bf-cycles at blender.org>
>         http://lists.blender.org/mailman/listinfo/bf-cycles
>
>
>     _______________________________________________
>     Bf-cycles mailing list
>     Bf-cycles at blender.org <mailto: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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/bf-cycles/attachments/20130610/4fd46736/attachment.htm 


More information about the Bf-cycles mailing list