From BlenderWiki

Google Summer of Code

I am going to use this page as the goto spot for all things about my GSoC project. I will even post my updates here (as well as send them to the soc-2013-dev mailing list).

GSoC 2013 Proposal

Deformation Motion Blur Design

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

Weekly Report #2: Cycles Motion Blur

28 June 2013

What I did this week

This week was very frustrating for me. Soon after I sent my last report, I got a compile error from trunk. I spent a lot of time trying to figure it out. I ended up reinstalling my operating system because I thought the libraries were corrupted. They were, but I also had to get set up again.

In doing that, I ran into a problem because I used install_deps.sh to get my dependencies. Now that Blender has moved to OpenEXR 2.0, I had to compile it. Unfortunately, I link dynamically, and the computer wouldn't run Blender because it couldn't find the .so file. I ended up adding it to the config in /etc. To prevent other users from running into that problem, I submitted a patch to modify install_deps.sh to automatically add OpenEXR to the config. I know that I have commit privileges, but I would only like to use them in my branch unless given explicit permission. Please review my patch and see if it will work.

Because I was fighting the compiler all week, I really got nothing done. I finally got the compile working again earlier this evening. Like I said, I am frustrated, but there's nothing I can do about it but work harder next week.

However, I was able to do some thinking about the current state of the Attribute class. I know about the AttributeStandard enum and two options it has called ATTR_STD_MOTION_PRE and ATTR_STD_MOTION_POST. Currently, under those, an Attribute only holds one mesh. Based on suggestions by Brecht and Stuart, I was thinking of extending those two to handle multiple meshes. The reason I want to keep them is that steps before the frame need to be treated differently from steps after the frame.

What I will do next week

Next week, I will be looking into the requirements of extending the Attribute class. That will include diving into the code for the CPU kernel. I need to figure out what changes need to be made there before I have an idea of what I need to do. To be honest, I am pretty frustrated with how little I have been able to get done by this point, so my hope is to attack this thing next week. Hopefully, I'll be writing code the next week.

Questions

First of all, please look at my patch for adding OpenEXR config to install_deps.sh.

Also, I would like current devs to comment on my thoughts for extending ATTR_STD_MOTION_PRE and ATTR_STD_MOTION_POST.

-- Gavin Howard, 28 June 2013

Weekly Report #3: Cycles Motion Blur

05 July 2013

What I did this week

I am not happy right now. I will be the first to admit that I am not a very experienced programmer, especially when it comes to version control. It seems that I did a bad merge sometime back because I am getting compile errors in my branch that I am not getting from trunk. I ended up basically resetting my branch back to trunk and starting over. I didn't know what else to do. At this point, I am pretty sure that I am going to have to spend some time reading the Subversion Red Book (I believe that's what it is called).

Oh, and to add to that, I had to switch IDE's in the middle of the week. I switched to QT Creator because KDevelop developed a weird bug where it crashed on startup no matter what I did. Thankfully, because of Campbell's information on this wiki, it didn't take too long.

Yes, I know. I have very little to show for the first three weeks. At this rate, I am not going to be able to finish the project this summer. However, I am not ready to throw in the towel yet. I won't do that until I fail the midterm or the final, if I fail them. But I plan to work as hard and fast as I can to make up the time. I just hope that nothing else gets in my way.

Anyway, before I had to reset my branch, I started touching all of the call sites for the AttributeElements I will be using.

What I will do next week

Pray hard that nothing else goes wrong.

Oh, and I plan to get the Attribute* classes extended for holding more than one mesh. If I can do that, I will move on to getting the addon code extended for multi-step export.

Questions

Do any of the developers know what I might have done wrong in my merging? I can't figure it out. If there are conflicts, I resolve them with either "theirs-full" or "theirs-conflict". If there are any suggestions, please let me know.

-- Gavin Howard, 05 July 2013

Weekly Report #4: Cycles Motion Blur

12 July 2013

What I did this week

Yes! No major problems surfaced this week. After thinking it through, I think that the merging problem was because I accidentally had "clean whitespace" set on KDevelop. Even after I set it back, there were problems. There were no problems merging this week, and even if there had been, I have set up my system so I can do conflict resolution by hand.

This week, I spent a lot of my time going through Cycles' Attributes and family line of classes, trying to figure out what they do and how they do it. And even with all of that time spent, I am stumped. I do know that the Attribute class has a vector of chars. It also returns a char pointer when it returns the data contained in the vector. The variable's name is "buffer", so I am assuming that the vector of chars can actually be turned into any type of data. However, assuming is never good.

At this point, I don't really know how I am going to extend the Attribute and family line of classes to hold vertex blocks.

I did a couple of other things this week. First of all, I added two new fields to the Object class: a bool for whether the object uses deformation motion blur, and a uint for the number of motion blur steps. I also managed to add code to get the viewport render to update when those are changed. That made me especially happy because it told me that the functions I wrote to pull those out of Blender both work.

I also started a design page on the wiki. As you can see by going there, I stopped adding information to the Attributes section because, quite frankly, I don't know what to do.

What I will do next week

Figure out just what Attribute and family do. Then I will add my preliminary design to my design page (see above) and begin work in earnest.

Questions

Can anyone explain in detail the Attributes and family architecture? How they do what they do?

Also, I was thinking about storing the mesh copies in the Attributes, and I think that exporting an odd number of meshes would be different from exporting an even number of meshes. However, I am not completely sure, considering that I don't know much about Attributes. Still, it seems to me that an even number of meshes would dictate that we don't even export the mesh at the "perfect" frame, while an odd number would be different.

-- Gavin Howard, 12 July 2013

Weekly Report #5: Cycles Motion Blur

19 July 2013

What I did this week

This week, I put in quite a few commits to start changes heading towards having multi-step deformation motion blur. This week was much easier than my other weeks; I felt like I got a lot done. I feel like I got more done this week than any other week.

I also was in contact with Stuart and Brecht. They answered a lot of my questions. I understand a lot more now about Cycles' internal architecture now, which was going to be the most difficult part of the summer. I still have to tackle the kernel though.

However, that said, I also had a difficult time toward the end of this week when some things happened in my other life. Everything is returning to normal, but I didn't get as much done as I would have liked. Again.

What I will do next week

I will begin making the first changes to the kernel. I will also see if I can get the export working. I believe if I can get that done, I will be able to finish the project by the end of the summer.

Questions

Like I said, I have been in constant contact with Stuart and Brecht over this week. They have answered all of my questions...for now.

-- Gavin Howard, 19 July 2013

Weekly Report #6: Cycles Motion Blur

26 July 2013

What I did this week

I wasn't able to get as much done this week as I would have liked. I have had some health problems crop up, and I had to spend some time fixing them.

Still, I got quite a bit done. This week, I put in a lot of work to get multi-step, per-vertex export working. There's quite a bit to do, but by this time, I have a fairly good understanding of the code.

First of all, I added code to gather the times that need to be exported. I also began working on changing sync_motion(). I have had to work around the current implementation of MOTION_PRE and MOTION_POST, but it's coming along.

I have also begun altering sync_mesh_motion() to add to the VERTEX_STEPS attribute.

What I will do next week

Today (Friday) and tomorrow (Saturday), I will be able to program for the majority of the time. I intend to get export fully working by then. If I do, I feel like I can finish the project by the end of the summer. So, the first thing I am going to do is get export fully working. Then I will begin work on the kernel.

I would like to ask Stuart, Brecht, and Ton to hold off writing my evaluation until Sunday. I will be getting a lot done before then.

Questions

No questions right now.

-- Gavin Howard, 26 July 2013

Weekly Report #7: Cycles Motion Blur

02 August 2013

What I did this week

This week, I finally finished multi-step, per-vertex export. Cycles is correctly receiving all of the information it needs to do deformation motion blur. All that is left is to add it to the kernel.

I wasn't able to get much else done this week because I was debugging the code to get it to work. There were a couple of pretty interesting bugs that I added. Nevertheless, I feel comfortable with what I have done this summer so far, considering all of the problems I have had to face.

What I will do next week

I will begin working deformation motion blur into the CPU kernel. I will admit that this part of the project makes me very nervous, but it is obviously necessary.

Questions

No questions right now.

-- Gavin Howard, 02 August 2013

Weekly Report #8: Cycles Motion Blur

09 August 2013

What I did this week

I didn't get much done this week. There are several reasons. First, I don't understand Cycles kernel code because there are a lot of macros. I am trying to figure out what they mean.

I'm pretty sure I have a good handle on some of them. For example, all functions with the macro "__device" are functions that are loaded into a device (CPU or GPU). Any function with "__device_inline" is a function that will be inlined in a device. Correct me if I am wrong on those macros.

Also, things happened in my personal life, so this week became a social week for me. I ended up with two dates lined up (one for later today, one for tomorrow morning).

So yes, I admit that I got very little done this week, but I proved that I can make up the difference already in the first half of the summer.

What I will do next week

I will continue to rip through Cycles' kernel. I am starting to get an idea of where the code I need should go, so if I can, I will start adding it.

Questions

Is there a "Guide to Cycles Macros" or something? :)

-- Gavin Howard, 09 August 2013

Weekly Report #9: Cycles Motion Blur

16 August 2013

What I did this week

I didn't get much done in coding this week. I was going through the kernel code a lot of the time, trying to put together macros.

The good news is that I think that I am actually starting to understand Cycles' kernel. For example, the "kernel_tex_fetch" macro wraps a function that just grabs some memory, and the first argument is a macro that tells what that function is trying to grab. The macro "__objects" means that it is grabbing an object. So I believe I am starting to see what is going on.

But yes, I admit that I haven't gotten much done. It is frustrating.

What I will do next week

At this point, I need to figure out which sampling algorithm is best for per-vertex sampling. That will be my target for the next week, as well as starting to actually work on the kernel.

Questions

Am I correct in my assumptions in the macros above?

-- Gavin Howard, 16 August 2013

Weekly Report #10: Cycles Motion Blur

23 August 2013

What I did this week

This week, I did better than the previous two weeks, although I did not do nearly as well as I wanted to do. I did finally start to know what questions to ask, and I asked them. Brecht was incredibly helpful this week (and also incredibly quick with code; see r59399). I don't quite understand all that is going on, but I am working on it. This was the reason I set the scope of this project to be quite small.

This week, I managed to finish a bit of code that calculated the larger bounding box for a mesh if it was using deformation motion blur. Brecht wanted me to include all of the motion samples in the mesh's BoundBox, and I actually managed to get that code to work. After that, I was asking questions by email and trying to sort out the patch that Brecht sent me.

What I will do next week

Better. I will do better. My schedule for next week is more predictable.

On the coding side, I will get the BVH done. I think that if that can be done, I can still make the pencils down date.

Questions

None right now.

-- Gavin Howard, 23 August 2013

Weekly Report #11: Cycles Motion Blur

30 August 2013

What I did this week

This week, thanks to Brecht's help, deformation motion blur is officially working! The important revision is r59544.

Unfortunately, it is definitely not optimized; a tile with deformation motion blur can take 10x or longer than a tile without. It will take a lot of code refactoring. Also, the CUDA build does not work.

This week, I have to admit that little got done, relatively speaking anyway. A lot of the time, I was wrestling with my mediocre skills. Fortunately, I ran into Brecht on IRC, and we figured out that I was overthinking the problem...again. It is something I tend to do, and I hate it. However, I learned quite a bit. Brecht answered my questions, and I should be able to continue working faster.

I am disappointed with my performance on this second half of GSoC. If I were completely honest, I would not give myself a passing grade at this point. However, I have three weeks left. I hope to do better.

What I will do next week

Next week, I will be moving into my new apartment and getting ready for school, but my other summer job will be ending. That should be an improvement. At this point, I feel that I have three tasks left: 1) Get the motion blur sped up until it's at an acceptable speed, 2) Get the code refactored so that Cycles will use the Woop algorithm for non-blurred objects, and 3) Get the CUDA build working again.

Next week, I will work on getting number 1 done, and if I can work on number 2, I will. Number 3 is not terribly important to me because it is not one of my deliverables.

Questions

None right now.

-- Gavin Howard, 30 August 2013