[Bf-cycles] Extraction of Motion Information
Brecht Van Lommel
brechtvanlommel at pandora.be
Tue Dec 6 15:56:21 CET 2016
Interesting, I wouldn't expect video encoders to use Z motion.
The code can indeed be confusing. When you say that "motion_pre =
transform_point(&tfm, motion_pre);" only returns the center value,
what kind of scene setup do you have? This is supposed to contain the
world space position of the object in the next frame. So if the object
is moving then it should be different than the center. If only the
camera is moving then following world to camera transformations will
make the difference.
For the perspective/orthographic cameras I would expect there to be a
usable Z component after the transformation to raster space, and for
panorama you could use code similar to camera_distance()?
The split kernel shouldn't haven't influence on this code I think? The
code is shared with the megakernel, and if it's for research purposes
just doing a CPU render might be enough anyway.
On Mon, Dec 5, 2016 at 1:11 PM, Michael Ortner <fau at michael-ortner.de> wrote:
> I’m a student at Friedrich Alexander University in Erlangen. I was tasked to
> extract motion information for both, Perspective Camera and Fisheye Camera.
> That can greatly help in the development of Video coders such as HEVC, to
> test new algorithms for motion estimation and compensation. The initial
> tests showed the great potential that Blender has to offer in that area of
> I could use some help on the motion extraction part. For weeks now I’m
> trying to understand the relevant parts of the source code.
> I was able to use the Vector Motion Pass to extract the motion vectors for x
> and y motion using the Compositor. The relevant file is the
> geom_primitive.h. The part I have trouble with, is to extract the z-motion.
> Motion of the objects in depth in relation to the camera.
> It seems that tfm = object_fetch_vector_transform(kg, ccl_fetch(sd, object),
> OBJECT_VECTOR_MOTION_PRE); does not contain the information I need for the
> So consequently motion_pre = transform_point(&tfm, motion_pre); only returns
> the previously initialized value form center. Of course, then the z-motion
> in the end is zero.
> Now, I tried to track down where that relevant information is initialized,
> but had no luck so far. At some point I hit a wall, because that entire
> split kernel setup confuses me. I’m not that experienced in programming in a
> project of that magnitude. So I would greatly appreciate if someone could
> point me in the right direction. After weeks of digging through the code I’m
> not ashamed to admit that I need help with that.
> I’m looking forward to hearing from you
> Bf-cycles mailing list
> Bf-cycles at blender.org
More information about the Bf-cycles