Saturday, March 15, 2014

Working Node!

Turns out changing inputData.asNurvsCurveTransformed() to inputData.asNurbsCurve() fixed the error I was getting. I now have a very basic node that puts placeholder geometry on the CV points of a curve. Next step is to implement the node expansion algorithm.


Attributes and Such

I'm testing the RiverNetworkNode right now and running into a few issues. First off, I realized I don't actually know which attribute of the curve I need to connect to the node. For polygons in our previous assignments it was the .matrix attribute. I took a look through Maya's connection editor, and it seems like only borderConnections is able to connect to the node's inputCurve attribute.

RiverNetworkNode takes in a CV curve and outputs a set of points to be fed into an instancer

However, when compute runs, I get an error creating the curve function set. Currently trying to debug this; will update with findings later.

The MEL commands I'm currently using are as follows:
// Create a CV curve using the CV curve tool
createNode RiverNetworkNode
connectAttr -f curve1.borderConnections[0] RiverNetworkNode1.inputCurve;
polyCube;
instancer;
connectAttr pCube1.matrix instancer1.inputHierarchy[0];
connectAttr RiverNetworkNode1.outputPoints instancer1.inputPoints;
EDIT: using connectAttr -f curve1.worldSpace[0] RiverNetworkNode1.inputCurve; got me further in the compute function. Now running into an error retrieving the CV points on the curve. Will investigate further tomorrow.

Friday, March 14, 2014

Pi Day Update

Happy Pi Day!

Last week I emailed our previous lab director Joe for advice on the tool implementation, as I had some questions about the Maya API as well as uncertainties on how best to approach it. I'll summarize some takeaways here:

The authoring tool will most likely be a collection of nodes and commands, where each node represents a modular portion of the overall task. This piece of advice was really helpful, since I originally envisioned the tool to be one monolithic node. He also clarified that nodes add pieces to the underlying Maya engine in the dependency graph, while commands make new features available to the command engine (namely calling nodes and issuing updates right away), so the tool will most likely require a combination of both. Previously I had thought nodes and commands were an either-or case, which it clearly is not.

I also asked about the viability of storing an overall state for a collection of nodes (for my river node network), and was told that while it could be done, the general paradigm in Maya is to propagate information down. Taking that into consideration, I'm currently working on creating a new RiverNetwork Maya Node. It will take in as input a CV curve as the river contour, and output an array of position values for the generated set of river nodes. These can be visualized with a simple sphere connected to an instancer.

One thing I'm still not sure how to handle is how to represent the parent-child relation between the generated output (this information will be needed to visualize the river graph part). To my [limited] knowledge, Maya nodes can only output objects that are MFnData, and it might take some extra work to figure out how to make one of the following data types work:

kInvalid Invalid value.
kNumeric Numeric, use MFnNumericData extract the node data.
kPlugin Plugin Blind Data, use MFnPluginData to extract the node data.
kPluginGeometry Plugin Geometry, use MFnGeometryData to extract the node data.
kString String, use MFnStringData to extract the node data.
kMatrix Matrix, use MFnMatrixData to extract the node data.
kStringArray String Array, use MFnStringArrayData to extract the node data.
kDoubleArray Double Array, use MFnDoubleArrayData to extract the node data.
kIntArray Int Array, use MFnIntArrayData to extract the node data.
kPointArray Point Array, use MFnPointArrayData to extract the node data.
kVectorArray Vector Array, use MFnVectorArrayData to extract the node data.
kComponentList Component List, use MFnComponentListData to extract the node data.
kMesh Mesh, use MFnMeshData to extract the node data.
kLattice Lattice, use MFnLatticeData to extract the node data.
kNurbsCurve Nurbs Curve, use MFnNurbsCurveData to extract the node data.
kNurbsSurface Nurbs Surface, use MFnNurbsSurfaceData to extract the node data.
kSphere Sphere, use MFnSphereData to extract the node data.
kDynArrayAttrs ArrayAttrs, use MFnArrayAttrsData to extract the node data.
kDynSweptGeometry SweptGeometry, use MFnDynSweptGeometryData to extract the node data. This data node is in OpenMayaFX which must be linked to.
kSubdSurface Subdivision Surface, use MFnSubdData to extract the node data.
kNObject nObject data, use MFnNObjectData to extract node data
kLast Last value. It does not represent real data, but can be used to loop on all possible types

Wednesday, March 12, 2014

Self-Reminders On Setting Up New Maya Plug-in Projects

Been running into a few issues when I tried setting up additional projects for Maya plug-ins in my project solution. Figured it might be helpful to keep track of what fixes I used here:
  1. Make sure the path to Maya has been set to environment variable, $(MAYA_PATH) in my case, in project properties -> C/C++ and Linker sections. This is mainly for collaborating with people who have different versions of Maya (my partner has 2013 and I 2012)

  2. In Build -> Configuration Manager, verify that the settings are "Debug" for configuration and "x64" for Active Solution Platform (and all the other solution platforms)

  3. If the project throws error MSB4044: The "CppClean" task was not given a value for the required parameter "FoldersToClean", make sure the Output Directory name contains $(Configuration) and not $(ConfigurationName) (via EatMyRandom)

  4. Always set the MTypeId value in the .cpp file, otherwise the project'll throw an error. 

Friday, March 7, 2014

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. 

Monday, March 3, 2014

CIS 660 Advanced Topics in Computer Graphics and Animation: Authoring Tool Project

The authoring tool project is a semester-long endeavor where students in the class pair up and implement a SIGGRAPH paper from the past 6 years. The paper my partner and I chose is from SIGGRAPH 2013 and titled "Terrain Generation Using Procedural Models Based On Hydrology". Procedural generation has always been an interest of mine, and I think it'll be fun to take a break from buildings and focus on something a bit more organic.

We're naming our tool HydroTerrain (creative, isn't it). And we broke down the paper into two main components: river network generation and terrain generation. I will be mostly responsible for the river networks and my partner the terrain. Our complete design document can be seen below, and our progress can be tracked here.

2