On LucasArts’ Shutdown

I’ve got to admit, I took the sting of the LucasArts “shutdown” a bit personally yesterday, as I had been anxiously awaiting a response from their HR department regarding my internship application. While this is not exactly how I expected to find out, at least it’s unambiguous.

Oh well, that just makes my summer shortlist shorter and my decision simpler (though I won’t say easier). Can’t say my other options would disappoint me ;]

In a less insensitive light, I’m rather sad to see LucasArts go, but the LucasArts of yesterday (make that two days ago) was admittedly not the LucasArts I grew up with and still cherish. I fell in love with the classic Adventure Games of LucasArts and, of course, jumped onboard with Grim Fandango and its siblings immediately. Granted, Star Wars 1313 was not exactly along those lines, and besides the fact that LucasArts hasn’t really developed any memorable in-house titles in the last decade, 1313 probably didn’t fit too well with the new Star Wars image that Disney is trying to promote.
For more exhaustive accounts and details of the shutdown, you’d best hit up Google. Current Events were never really my strong point, but you know, “everyone makes a good critic”.

Oh well, at least there’s still publishing of new Star Wars IP through what remains of LucasArts that might not be so kid-targeted and cuddly as I fear the upcoming trilogy will be.

 

zSpacePortalLogo

zSpace Visits the VizLab

Excited to say that zSpace visited the VizLab last Monday. While I’m not sure how well it would work for content creation yet, I’m definitely sold on the zSpace’s promise for content exploration. It probably would have helped to see a 3D interface for a familiar interface like Maya to understand how one would actually model with it… in stereographic space… with a stylus…

Now that I think about it, that doesn’t seem so far-fetched  and certainly can’t be any less intuitive compared to actually sculpting a model than using a mouse is. I’ll chalk one up for getting one step closer to the real thing and not think so limited.

My favorite part was playing the Unity3D AngryBots demo on a zSpace. I could literally look around corners for enemies. That’s the kind of interesting mechanic I’d like to see brought into gaming, and I honestly don’t mind wearing glasses (for now) if that’s what it takes to get it.

Check out their online reels at zspace.com

Justin

March 23, 2013

Found an hour of time to play Gorogoa today. If you haven’t, it’s well worth it.

http://www.gorogoa.com/

Git in the Classroom?

I had a thought today about how using git in a classroom setting would not only facilitate many current obstacles, but also provide an educational introduction into version control. While I haven’t researched in to whether or not this is already being done (and I am sure it is, or at least has been thought of), humor me for the moment, oh you who actually frequent my blog.

The professor of the class has a git repository for each of his students, named after the school (abbreviations), the course number, and the last name. I suppose the year and semester might be necessary as well, not sure. Anyway, before I get bogged down with details*: The professor makes a repository for each student. Each student is then required to fork his respective repository and work inside it. When the work is completed, the student sends a pull request to the professor.

Potential Benefits:

  • Students are introduced to Version Control (or it is reinforced as worthwhile)
  • Students learn to program in a greater community
  • Homework turn-in is a time-stamped pull-request. Simple
  • Homework, by nature of DVCS, is easily pushed to a cloud, like GitHub, and thus is:
    • backed up
    • accessible from any connected device
  • Professors can alter student code or distribute helper modules to students via pulls
  • Professors can track what parts of code they helped with per student, so long as they edit from their own account

I’m sure there’s more benefits as well as a few drawbacks, so I’ll keep considering this model. For starters, keeping repo names unique across semesters while still remaining scalable for variable sized courses might be a challenge. For small classes though, it is probably not an issue, and old repositories can be safely pruned on the professor side at the close of each semester or so.

This could turn out to be very useful if I get a technical TA position in the future

 

* This could possibly work more compactly with a single repo and branches, so long as proper permissions were utilized...

Justin

March 12, 2013

Best warning in Maya so far happened late last night:
“Cannot parent components or objects in the underworld”.
Thank you, Maya, I’ll cherish this wisdom in the afterlife.

Decompose Matrices

At the suggestion of an industry pro and fellow Aggie (thanks Doug!) a week or two ago , I decided to give decompose matrices a try in a scripted rig today in lieu of point, orient, and scale constraints. While I can’t say that one method is objectively better than the other, I do prefer the wokflow of the decomposeMatrix, not to mention the cleaner hierarchy. It helps too being in linear algebra (and viz), so I actually get the math behind it all.

Justin

March 8, 2013

Today, I realized I had about 1 week’s worth of unstaged changes in the pipeline-tools git repo. Two hours later, I’m pushing 16 well-organized commits and am loving the flexibility of both commit patching and stashing. How did I let myself forget about those?
Git Cheat Sheet

Justin

March 8, 2013

Giving reloader a look to alleviate my frustration with the shorting-comings of the Python’s builtin reload. Hopefully this adds a little more snap to my workflow in Maya

https://github.com/jparise/python-reloader

Maya Workspace Hinting with PyMEL

Two of the classes I’m working on for the vertical studio pipeline tools are called MayaProject and MayaProjectManager, stored in the (slightly ambiguous) pipeline.pymel.project.py

I’m pleased to say that the initial versions of these should be ready in time for tomorrow’s dailies. Both classes are the result of a feature request, nevermind a long time frustration of mine, that most beginning Maya users don’t understand referencing and project space (Workspace), and it the case of undergraduate, particularly group projects, thus cause time-consuming local referencing, fosterParent situations, end up rendering personal work to quota-enforced network shares, etc.

MayaProject allows you to define an expected project space based on a name (used mostly for pretty-print and GUI messaging) and a root. This root, naturally, is the location of workspace.mel.
MayaProjectManager allows for several of these expected projects to exist without allowing the roots to be duplicated. This root is* should always be calculated on userSetup, seeing that particularly in the case of network shares or Dropbox, one may need to consider user environment variable expansions, check internalVar locations, or deal with external drives.

Why, you might ask, do we need a redundant record of workspaces if Maya handles this all internally? The simplest explanation, as stated previously, is that MayaProject is an account of an expected workspace.
Given the current workspace, the current scene filepath (the path of the file currently open in Maya), and an expected workspace, we can deduce a handful of typical scenarios useful for prompting users to check whether or not they are in the correct project space.
Note: much of this runs on the assumption that all files are stored below the root location of workspace.mel. If this is not the case, the current checks are less accurate, albeit occasionally helpful nonetheless

For example, if my currently opened file is beneath my expected project space, but my project is not set, I may need to change my project. In this case, a popup would offer to open Set Project… for the user or automatically set the project and reopen the current file for you. While the latter is convenient, I’m more a fan of the former, because it educates users about project space.

Similarly, if the currently open file is outside of an expected project space, but the project is set to the expected project space, then the user may be working on a desktop file that needs to be moved to the appropriate share, or may have forgotten to change their project to a personal or default project. A prompt to automatically change to the default workspace or open Set Project… is given to the user.

There’s a lot that can be done with this simple setup for users who are new to maya and don’t have a pipeline with a launcher to set all of their environment variables for them ahead of time. While current situations don’t require a very robust MayaProjectManager for multiple expected MayaProjects, I’m still enjoying evaluating and iterating it as an educational exercise if nothing else.

Spring Break is within the next week, so I may post again about the hooks I am currently utilizing, as well as show some screenshots/screencasts of the script in action.

 

* this is up to implementation. Whether or not an end user decides to dynamically calculate or statically load MayaProject workspace definitions is their perogative

Vertical Studio Tools Update

Today was a bit long playing catchup with the vertical studio pipeline tools. As layout and coordination lead, I’ve barely had time to open Sublime this week, but fortunately, I was able to block some time today. Better yet, I realized that because we’ve foregone completely porting the graduate tools 1:1, I don’t have to use the complicated install methods I devised last year to copy scripts to each user.
After all, there’s a reason all the industry pros just use an network drive, and dropbox will do a fine job of that.

Lastly, I received the good news that account authentication at the graduate level is hitting a major milestone, which (fingers crossed) could mean that the render farm will be online to vertical studio. Let’s toast to that hope.