[Soc-2013-dev] Weekly Report #1 Cycles Motion Blur

[Brecht Van Lommel]

Hi Gavin,

On Fri, Jun 21, 2013 at 4:13 PM, Gavin Howard <gavin.d.howard at gmail.com> wrote:
> However, I ran into a problem. I went through Cycles' code and found
> the implementation for the Triangle struct. It is simply a struct with
> an array of three ints: the ID's of the vertices that make up the
> triangle. I wasn't able to see how that would be extensible for
> creating a MovingTriangle struct. Granted, I am not experienced in
> Cycles' code; because of that, I will continue to look into having
> MovingTriangles. Until then, I had to come up with something. I
> thought that extending the current Mesh implementation would be
> better. The MovingMesh would have a vector of Meshes, one for each
> export step, and the BoundBox of the MovingMesh would be the union of
> all of the BoundBoxes of the children meshes.

I don't think a new MovingMesh class is necessary, probably it is
easiest to extend the current Mesh class to support storing vertex
coordinates of multiple frames. There is actually some support already
in that attributes can store ATTR_STD_MOTION_PRE and
ATTR_STD_MOTION_POST, which are the vertex coordinates for the
previous and next frame. But this is not suitable to an arbitrary
number of frames.

Attributes currently have a fixed size per element, but this could
changed. If you look at the Attribute class, it has some functions to
determine storage size: reserve, element_size and buffer_size. You can
give those a "int numsamples" parameter (default to 1), and allocate
more space depending on how many motion samples the mesh stores. The
Mesh data structure then would have a "int num_motion_samples" member
variable as well.

For vertex coordinates you want to store a location for each motion
sample, but for UV coordinates for example it would be more memory
efficient to just store a single sample, so only somes types of
attributes would need multiple samples. So it's quite important not to
have multiple Meshes if we want to keep memory usage lower.

> At this point, nothing is set in stone. I could very well find a way
> to make MovingTriangles work. (Quite frankly, I expect to because that
> was Brecht's suggestion.)

A MovingTriangle struct isn't needed in Mesh, the Triangle struct just
has vertex indexes and those stay unchanged during motion, it's only
the vertex coordinates and normals that can change. I don't know if
the moving triangle must be explicitly represented as a struct or
class somewhere, maybe it's convenient in the BVH builder for example,
but in Mesh I wouldn't do it.

Brecht.