Progress Report 3/6/14

The past week involved mostly research, ramp-up, and setup.

Tasks I finished
1.2: Create source images- we now have two simple, ellipse-based image maps that define the river and terrain slopes.
1.3: Set up framework- I set up a running solution based off of homework 2 that exports a .mll plugin for use in Maya.

Tasks I'm Working On
I'm still working on creating the necessary river node data structures. The will inherit from a base node class that my partner is still in the middle of implementing.

Roadblocks and Time Sinks
A lot of time went into ramping up on git and figuring out how to collaborate with my partner on github. One of the first problems was figuring out which files to exclude so we wouldn't overwrite each other's data with our user-specific files generated by Visual Studio. After we spent a fair amount of time doing trial and error (there were instances where my partner's project wouldn't build, but then we'd discover it was because he had set his debug platform to win32 instead of x64).

In the end, I found a standard list of file types to include in .gitignore for visual studio projects. It can be found here

Another issue I encountered was with the Github for Windows program. While I was committing changes to my local repository located in my 660 folder, I noticed that the Windows interface was not picking up any of my changes. Further inspection led me to find that the program clones another copy of the project within a folder called GitHub under My Documents.

Finally, my partner and I found out Windows for Github handles merge conflicts very poorly by throwing a fairly generic-sounding error. When I took a closer look, it seemed that git didn't have a built in merge tool beyond command line editing, and I spent a few hours figuring out how to set it up. Just for posterity, here are the steps to set tortoisemerge as git's default merge tool:

1. Download TortoiseGit
2. While installing, select OpenSSH and NOT Putty as the preferred ssh tool
3. Open your .gitconfig file and add the following lines
   [merge]
    tool = tortoisemerge
[mergetool "toirtoisemerge"]
    cmd = \"C:/Program Files/TortoiseGit/bin/TortoiseGitMerge.exe\" -base:\"$BASE\" -theirs:\"$REMOTE\" -mine:\"$LOCAL\" -merged:\"$MERGED\"
[merge]
    tool = tortoisemerge
[mergetool "tortoisemerge"]
    path = C:\\Program Files\\TortoiseGit\\bin\\tortoisegitmerge.exe
4. References for above: devstuffs and stackoverflow
5. Read the thread for fixing merge conflicts in git on stackoverflow. 

While working on the tool UI in MEL (Task 1.1) I realized that, since we are creating a maya node, I don't know how I would consolidate the UI values with the node attributes. Maybe instead of having a MEL-based UI, we should make all the fields shown in the mockup node attributes? When creating the design doc, we had not considered how to combine these two inputs into one source. It's something I plan on looking further into this week. 

Another task I've been looking into (that was not accounted for in the design doc because we thought it was trivial but have since found that it's not) is how to read in initial user inputs. We had originally assumed that the user will create a CV curve to define the river contour, however I haven't been able to find a way to translate this into a concrete demarcation in the plug-in. I think I might have to look into implementing our own algorithm to check whether or not a point lies within an enclosed curve. For the interest of time, we might simplify our approach by starting with circles as curves and auto-generating river-mouths instead of taking in user input.