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

[Gavin Howard]

All,

I had a few minutes before I went to work, so I was able to retitle
and reformat my report. It looked like there was a specific format I
missed as well, so I did that too.

== Weekly Report #1 Cycles Motion Blur ==

21 June 2013

'''Note:''' These reports are due every Friday. However, because of my
place of residence is eight hours behind Amsterdam (Central European
Time), where the Blender Foundation is located, and because I have
work every Friday morning until 13:00 (21:00 in Amsterdam), I will be
sending out these reports on Thursday nights (early morning Amsterdam
time).

==== What I did this week ====

Technically, the start of coding was only four days ago, but I have
been working since I found out I was accepted a few weeks ago.
Therefore, I am going to cover that period in this report as well.
Don't worry; it still won't be too long.

I have been asking a lot of questions mostly. What are the major
considerations in coming up with an effective design? What are the
possibilities? What are the tradeoffs of each option? During this
time, I learned a lot about programming for graphics in general, but
more importantly, I started to come up with a basic initial design,
which will extend Cycles' current code to add a class called
"MovingMesh" (see above). This design is based on suggestions by
Brecht, who said that he would like an implementation that used a
"MovingTriangle" struct.

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.

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.)

I also spent a lot of the time browsing Cycles' code in an effort to
understand what is going on. In doing that, I have come away with a
basic knowledge of how Cycles' code is set up. There are a few things
I am starting to understand. I was able to figure out a little bit how
the addon syncs with Blender, but it is still pretty confusing for me.

Also, I spent a lot of the time before this week setting up my
workflow. I have many Bash scripts that help me do the things I need
to do often. If anyone is interested in my scripts setup, you can find
it at my workflow page. (This page will not be done when I submit this
report. It's past midnight, and I need to go to bed. However, I will
get it done ''very'' soon.)

==== What I will do next week ====

I will continue working on the details of the design. When I start
coding, I want to know exactly what I am doing, so the coding
shouldn't take very long.

==== Questions ====

I would like to ask Cycles and Blender developers to comment on two
things: first, please give your feedback on my design. (Remember that
it is really basic. Details will come later.) Brecht and Stuart, I
would really appreciate your feedback, especially if the
MovingTriangle can be explained to me in greater detail. Second,
please tell me how I can improve these reports.

-- Gavin Howard, 21 June 2013