www.doriengunnels.com/blog

Well, here it is…

I’ve finally uploaded my final project from my MEL scripting class. I created a small lighting toolkit that can be used to automate several commonly used tasks when lighting a scene in Maya. The script as well as a PDF description on how to use it can be downloaded from my links page.

Enjoy!

Yeah… I’m kind of an idiot…

if (`modelPanel -exists dcg_lighter_guiElem_modelPanel_lightLooker`) {
deleteUI -panel dcg_lighter_guiElem_modelPanel_lightLooker;
}

I forgot the -panel flag…

I can now close my “Light Looker” window and reopen it without having to create a new scene.

Well, I think I might have a solution to the modelPanel issue in my script.

I spoke to my professor today about the issue. He suggested explicitly deleting the UI element using an “if” statement similar to the way you would delete/refresh the entire UI if the script is run twice without the window being closed.

Deleting the UI:

if (`window -exists dcg_fp_lighterUIWindow`) {
deleteUI dcg_fp_lighterUIWindow;
}

Deleting the UI element:

if (`modelPanel -exists dcg_lighter_guiElem_modelPanel`) {
deleteUI dcg_lighter_guiElem_modelPanel;
}

I thought this would fix my script, end war, fix the economy, and eliminate poverty. It turns out that, as it stands, it did none of the above. When I added the delete-modelPanel block to my script, its almost like it ignored it. When the UI is closed and the script is run a second time, it still errors out saying that the name “dcg_lighter_guiElem_modelPanel” is not unique (in other words, it didn’t delete the modelPanel).

I tried each line individually…

modelPanel -exists dcg_lighter_guiElem_modelPanel;

This returned a value of 1… true… it still exists. Ok, let’s delete it…

deleteUI dcg_lighter_guiElem_modelPanel;

Maya crashes…

Sooo… problem not solved… yet…

Well, tonight’s been a pretty long and trying night…

As part of my MEL scripting final project, I’m trying to expand upon a “light dropper” script writen by Jordan Rempel (http://jordanrempel.com/links.html).  This script creates a spotlight with the same translation and rotation value as the perspective camera.  Simple… but pretty cool!

I’m trying to provide the user with the ability to press a button, drop a light (in this case a spot light) at the location of the perspective camera, and quickly look through it using a pre-defined modelPanel.  I would also like to be able to have an object selected.  The light would then auto-correct its rotation (while keeping its translation values the same as the perspective camera) and essentially focus on said object.  The user would then have the freedom to fine-tune the light’s location interactively without having to go to “Look Through Selected”, adjust, then switch back to perspective mode.  Every type of Maya light should have a dedicated button.

I honestly thought that this was a pretty straight-forward task.  It was not meant to be the major part of my final by any means…  I have a lot to learn…

Before I could really start, I had to create a rough User Interface consisting of a button to create the spotlight and a modelPanel with which to look through the light (as well as some other layout elements… trying to plan ahead).  I’m quickly starting to feel that modelPanels are the devil.  To make a long story short, I’ve been wading through layout and parenting issues for hours.  ModelPanels seem to interact much differently with Interfaces than other objects.  Also, aparently modelPanels are not deleted when windows are closed.  Thus, if the script is run a second time, the explicit name I gave the modelPanel is no longer unique, resulting in the script crashing.  I tried letting Maya name the modelPanel and storing it under a variable to call back later.  However, say the script is run two dozen times.  There are two dozen newly-created modelPanels now cluttering up your scene.

Anyway, I now have a very temporary GUI to work with.  After all this, beginning to write the light generation procedure seemed extremely easy.  There are, however, a good many kinks that can’t really be worked out until I figure out a way to manage the modelPanel issue.

I shall now leave you with a script I accidently wrote…

When trying to figure out the best way to judge the distance between an object and the newly created light, I came up with this:

global proc dcg_distanceBetweenObjects()
{
string $selection[] = `ls -selection`;
float $translateObject1[] = `xform -query -translation $selection[0]`;
float $translateObject2[] = `xform -query -translation $selection[1]`;
string $distanceBetween = `distanceDimension -endPoint $translateObject1[0] $translateObject1[1] $translateObject1[2]
-startPoint $translateObject2[0] $translateObject2[1] $translateObject2[2]`;
}

Simply select two objects and run the script (excluding the “global proc” line).  A “distanceDimension” will be created used to interactively show the distance between them.

aaaaaaand it’s 4:12 in the AM…

Goodnight.

One of the things I wanted to do with my MEL final is to automate the process of looking through a selected light.  One thing that was suggested to me was to use the “scriptJob” command.  After doing a little research into this command, I’ve created this simple test script.  The script simply creates a procedure that will query a selected object and print its name.  The scriptJob command then runs this procedure each time the selection is changed.  If nothing is selected, nothing is printed.  If multiple objects are selected, all objects are printed on separate lines in the order they are selected.

global proc selectionLister()
{
string $object[] = `ls -selection`;
print $object;
}
scriptJob -event “SelectionChanged” “selectionLister”;

After discussing this command with my professor, it was pointed out that the scriptJob command creates a node in Maya that checks for the correct conditions to run the command given by the user.  Once run, the node is ever-present in the scene even when closed and reopened.  Thus, if used improperly or in uninformed ways, the scriptJob command can actually have the effect of corrupting one’s scene.  This is especially dangerous if one uses the command to run a script when the scene first opens.  If that script proves to have an unforseen negative effect that might prevent continuing work, it would be impossible to debug because the script would be run every time the scene is opened.  In order to prevent anything like this from happening, I will be saving my test files out as MayaAscii files until I am confident everything works properly.  This way, if I screw anything up, I can manually remove the node from the scene via a text editor.

Research from:

http://caad.arch.ethz.ch/info/maya/manual/Commands/ELFCommands/ELFCmdsOverview.html

I started on my final project for my MEL scripting class a couple weeks ago.  I realize it’s a bit late, but I’m finally getting around to documenting my progress.  Tonight, I’m just going to describe the idea as a whole.

I’d like to write a small lighting toolkit that will help to streamline my general work flow when it comes to lighting CG scenes in Maya.  In my project proposal I wrote for Professor Huff, I listed quite a few tool ideas I thought would be useful.  Here are a few excerpts from this proposal that will help to shed light on my goals (no pun intended):

“There are several repetitive tasks that I feel can be streamlined. One is the initial process of creating the lights themselves. I always seem to go to Create>Lights>Spotlight, Panel>Look Through Selected>position the light, Attribute Editor>adjust settings, and repeat for every needed light. I’ve seen several solutions geared towards speeding up the creation of light rigs. One of which is Jordan Rempel’s (www.jordanrempel.com) light-generation script which simply creates a default spotlight with the same translation and rotation settings as the perspective camera. I thought this was an awesome idea. However, after playing with this script, I found myself using the script only to get the general placement of the light. I would still adjust the light’s cone angle settings and go to Panel>Look Through Selected in order to fine-tune the light’s placement. My solution to this is to have a dedicated viewport used for looking through lights. This would work nicely with Jordan’s script in the sense that whenever a light is selected (or created), the viewport would automaticly look through it, allowing the artist to fine tune the placement without having to repeatedly go through menus.”
“Another useful tool would be to have a light-centric Attribute Spreadsheet. Maya’s default attribute spreadsheet has the ability to control quite a few perameters. However, many are not intuitive and other useful perameters are not even present. You have no way of selecting many lights and turning on and off “Illuminates by Default”, “Emit Diffuse”, or “Emit Specular.” Being able to adjust these across many lights can be extremely useful when organizing render passes. You also have no way of changing the “Decay Rate.” It is possible to change the Light Color and Shadow Color. However, you have to do so by typing in individual R, G, and B values. I believe it would be much more intuitive if you could use a color picker the same way you can in the Attribute Editor. Also, while you can set Layer Overrides in the Attribute Spreadsheet, you have no feedback saying that there is currently an override unless you access the Attribute Editor for that particular light. It would be nice to see feedback for overrides for all lights in the spreadsheet.”