Adding Details

Most of this week was spent on looking through sample scripts to see what command patterns other people use to generate building details. One thing I've realized is that although I'm fairly comfortable with MEL and python commands in Maya at this point, I still lack a lot of the experience that comes from long-term use of the languages. The most difficult part for me is knowing what commands I should use for a particular task. For example, the code I had before the alpha review had attempted to move the pivot of a model by using the move command in MEL. Now I know the the proper way to go about it is to use the xform command instead, since there is a scalePivot flag specifically for this operation. The python function I wrote for this looks like :

def movePivotToBottom(obj):
    piv = cmds.xform(obj, q=1, ws=1, scalePivot=1)
    newY = cmds.getAttr(obj + '.boundingBoxMinY')
    piv[1] = newY
    cmds.xform(obj, ws=1, scalePivot = piv)

I've written a few helper functions like this one that have been helping me understand the maya commands better. Something else that confused me for a while is the difference between, say cmds.scale(...) and cmds.setAttr(... +  '.scale'). I've tried running both of them, and from what I can tell they both do the same thing. I just haven't figured out circumstances under which each command is advantageous.

Another thing I've realized is that there are MEL commands that aren't found in the online documentation at all. After a frustrating few hours, I found out from a forum that these are either run time commands, or procs that come with maya. To check, you can run whatIs , and Maya would either tell you it's a run time command, or give you the path to the file containing the proc. At first I was worried that I wouldn't able to use certain commands/procs in python, but the maya.mel.eval command saved the day.

I'm almost done writing the function that adds columns to the base of the building. One problem I'm trying to fix right now is that the column-generation code relies on the subdivision of the footprint mesh, and my building-body mesh runs on the assumption that the footprint doesn't have any subdivisions. I'm planning on just making a copy of the subdivision-less footprint, adding subdivisions, and deleting it after the columns are generated. The only remaining problem is to make sure the columns are never intersecting with the building body, which I hope to solve by tomorrow. As I become more familiar with what I like to call "design patterns" for creating building assets, I hope to speed up my process and have images ready by the next update. Until then, stay tuned!

Some Change in Direction + Updates

One of the comments that really stuck with me from the alpha review was why bother creating a building generation script so similar to City Engine, when City Engine already exists. I spent the weekend re-evaluating my project, and came up with some changes that I feel would set my project apart from most of the existing building generators.

The majority of building/city scripts focus a lot on generating sufficient randomness, so the city doesn't look repetitive. Because of this, the user usually doesn't have a lot of say on what types of architecture should be generated at a particular location in the city (in CityEngine this is doable, but requires scripting on the user's end).

I felt this would an interesting issue to address, so I decided to alter my project a bit, such that it focuses on generating a city with different building types, located according to user specifications. I started out identifying three basic types of architecture that exist in a typical city: business buildings, residential structures, and recreational areas, and listed some of their properties below.

 

During one of my review sessions, Norm had suggested the use of a heat-map to specify the placement of different architectural styles. Using that as my start-off point, I plan on having my project take in an image from the user, with each component of the RGB value corresponding to a building type. For example, R = business, G = residential, B = recreational. For colors that have multiple values, I can determine the building type by the dominating RGB value, or by a probability function. This will allow my project to be extensible; additional building types can be added anytime as long as an RGB pattern is specified.

Since Python has an excellent image processing library, I decided to continue my project in python from now on. Currently I'm in the middle of porting my code from MEL to python and thinking about setting up an inheritance structure (if any) for the different building files.

Some links that were really helpful in getting me up to speed with python/maya was Chad Vernon's tutorial site and Autodesk's list of python commands in Maya. Check back in a couple days for more updates.

Wrangling the Maya Plug-in Wizard

This week I started exploring the Maya plug-in for Visual Studio. Since the whole process took a while to figure out, I thought I'd document the steps I took in case someone else needs it later. The basic set of instructions can be found on the autodesk site here, but additional steps are needed to make everything work (which I will mention below)

1. The MayaPluginWizard.zip file is found in the devkit/plugin folder under wherever you installed Maya (for me it was C:\Program Files\Autodesk\Maya2012\devkit\pluginwizard). From there, open the MayaWizardReadme.txt, which will give you step by step instructions on adding the plugin wizard to VS (take note there are different instruction sets for 32 and 64 bits.
   
2. Unzip the MayaPluginWizard.zip file (I had to copy this onto the desktop first due to permissions). After navigating into the extracted directory, open the MayaPluginWizard.vsz file in a text editor like Notepad++, and make sure Wizard=VsWizard.VsWizardEngine.9.0 refers to the correct version of Visual Studio (VS2008 is 9.0 so I didn't have to change anything).
   
3. Copy the following files to the "C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\vcprojects" directory:
       MayaPluginWizard.vsdir
       MayaPluginWizard.vsz
       MayaPluginWizard.ico
   
4. Copy the *outer* "MayaPluginWizard" directory to "C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\VCWizards".  NOTE: there should be a MayaPluginWizard directory within a MayaPluginWizard directory after this step.
   
5. Now, since my version of Maya2012 is 64-bit, and VS is 32-bit, I needed to configure my VS for 64-bit applications. I followed the directions listed here (basically you need to install the missing x64 compiler and tools). This requires you to have the VS installer on hand, which was a pain. 
   
6. Close VS if you have it open. Right click on the icon and select "Run as administrator". If you don't do this, you'll get an extremely vague popup saying "project upgrade failed". Figuring out this part was extremely frustrating.
   
7. Now you should be able to create a project using the Maya Plugin Wizard. (Start Microsoft Visual Studio 9.0 and invoke File -> New -> Project -> Visual C++ Projects and select MayaPluginWizard.)
   
8. The project will be created and then the solution can updated and built.
   

Alpha Review Thoughts

After going through the comments on the Alpha Review, I've noted a few areas I could improve on, such as going into more detail on my project context as well as overall progress. The comments were helpful in giving me advice for resources as well as directions to consider for the project. Next I'll address some of the major points in the comments.

Will the final project be procedural generation of a city or just buildings?
This is something I've been thinking about since a few weeks ago. There are two parts to procedurally generating a city: the generation of the building itself, and then the creation of a city by populating city blocks with buildings. While I originally intended to focus on generating the building model, it's something that has been explored many times already, and I think it'd be more interesting to explore different ways the user can interface with Maya to generate a city.  Norm suggested I could have my script import a color-map from the user to determine which types of buildings should be generated in each region of a city. I feel this is a good point to start off on once I finish implementing the functionality to generate a basic building.

How is this different from CityEngine and how does the user benefit from using a plug-in in Maya?
At the moment, most of CityEngine's building generation is done through user-created files. I think it'd be neat if my script can offer a more visual approach like the one I mentioned earlier. Right now I have a couple ideas I'm planning on trying out next week. Until then, thanks for looking!

Alpha Review

Jump to see my current code

Shaping Up the GUI

TO DO:
Have a GUI that creates a very basic building according to user specifications [3/6]


IN PROCESS:
Fine tune details for implementation [1/6]



COMPLETED:
Set up SVN [0/1]
Research dis/advantages of using Python vs. C++  API's for Maya [0/3]
Experiment with MEL UI creation [0/3]
Read about Maya Nodes[0/5]
Read about Maya C++ API, MEL Scripting [0/10]
Build basic plug-in for Maya in MEL[0/4]
Set up framework [0/5]

While looking through tutorials on making MEL GUI's, I came across this page that introduced groups of controls, such as intFieldGroup. Previously I had been trying to create my GUI with individual text labels, fields, and buttons, but this simplified the process a lot. Right now I have a GUI with frame and column layouts. I also figured out how to extract the user input as a button command, so my next step is to finish creating the geometry from these inputs.

The name is a placeholder for now...

For now, I plan on limiting the generation of the building to just user interaction with the GUI. Once I complete all the functionality listed in the current GUI, I'll start incorporating dynamic resizing. From this tutorial,  the process seems like it will have to incorporate scriptJobs. I haven't looked very closely at this section yet, but plan on reading more about it in the future.

A small problem I hadn't foreseen is global variables in MEL.  I initially had a global proc that extracts all the user inputs from the GUI and dumps them into variables, since it's easier to keep track of what's what (see below):

// Retrieves all values from the GUI and assigns them to variables
global proc retrieveGUIValues(){
    //building attributes
    $buildingName = `textFieldGrp -q -tx Building_Name`;
    $footprintName = `textFieldButtonGrp -q -tx FootPrint_Name`;
   
    //floor attributes
    $numFloors = `intFieldGrp -q -v1 NumFloors`;
    $floorHeight =`floatFieldGrp -q -v1 FloorHeight`;
    $ledgeHeight = `floatFieldGrp -q -v1 LedgeHeight`;
   
    //window attributes
    $windowHeightRatio = `floatFieldGrp -q -v1 WindowHeightRatio`;
    $windowWidthRatio = `floatFieldGrp -q -v1 WindowWidthRatio`;
   
    //check
    print ("creating building named " + $buildingName + " with " + $numFloors + " floors! LOL Just Kidding! \n");
}

 However, I soon realized that these variables are out of the scope of all the other procs, and I need to specify them as global to rectify this. Using global variables requires an additional step of declaring it within each proc, which in the end isn't much cleaner than just re-extracting the user input whenever I need it, so off to the recycle bin this goes.

Another Update

TO DO:
Build basic plug-in for Maya in MEL[1/4]

IN PROCESS:
Fine tune details for implementation [2/6]
Set up framework [2/5]


COMPLETED:
Set up SVN [0/1]
Research dis/advantages of using Python vs. C++  API's for Maya [0/3]
Experiment with MEL UI creation [0/3]
Read about Maya Nodes[0/5]
Read about Maya C++ API, MEL Scripting [0/10]  

Kind of a short update for this week. I've finished reading the first 3 chapters of Complete Maya Programming, which covers the Maya Dependency Graph and MEL scripting. Right now I'm trying to create a simple GUI that lets users extrude the body of a building from a custom "footprint". At the moment I'm having some trouble with executing commands when the user interacts with the GUI, but hopefully that will be fixed shortly. I will have another update when that's done.

Thanks for looking and have a great fall break!