We've Moved

The blog has been retired - it's up for legacy reasons, but these days I'm blogging at blog.theodox.com. All of the content from this site has been replicated there, and that's where all of the new content will be posted. The new feed is here . I'm experimenting with crossposting from the live site, but if you want to keep up to date use blog.theodox.com or just theodox.com

Friday, March 27, 2015

Maya Bug Watch: API2 and GetPoints()

In general I’m more or less a fan of Maya Python API 2.0. It’s more pythonic and feels faster than the old version. However, it’s not without its quirks and I just found one that really bit me in the behind.
If you want to get the vertices of an object in the api, the usual formula is:
  1. Get the dagPath of the object
  2. make an MFnMesh
  3. call the ‘GetPoints’ method of your mesh
  4. party on.
Something like this, which returns a list of MPoint objects for the verts in the mesh
import maya.api.OpenMaya as api

def get_verts(mesh):
    mobj = api.MGlobal.getSelectionListByName(mesh).getDagPath(0)
    # that's lazy, it assumes that the first child is the mesh shape.
    # in practice you need to be more careful...
    mfn_mesh =  api.MFnMesh(mobj)
    vert_array = mfn_mesh.getPoints()
    return [i for i in vert_array]
This works fine and dandy… except:
If the mesh has 256 or more verts, the first vertex comes back as garbage
Here’s an example, using the same function:
mesh, _ = cmds.polyCube(sw = 1, sh= 1, sd = 1)
print get_verts(mesh)[:4]
#> [maya.api.OpenMaya.MPoint(-0.50000000000009082, -0.5, 0.5, 1), maya.api.OpenMaya.MPoint(0.5, -0.5, 0.5, 1), maya.api.OpenMaya.MPoint(-0.5, 0.5, 0.5, 1), maya.api.OpenMaya.MPoint(0.5, 0.5, 0.5, 1)]

# this looks good... Here's the same thing for a 226 vert cube:
mesh, _ = cmds.polyCube(sw = 8, sh= 8, sd = 3)
print get_verts(mesh)[:4]
#> [maya.api.OpenMaya.MPoint(-0.50000000000005185, -0.5, 0.5, 1), maya.api.OpenMaya.MPoint(-0.375, -0.5, 0.5, 1), maya.api.OpenMaya.MPoint(-0.25, -0.5, 0.5, 1), maya.api.OpenMaya.MPoint(-0.125, -0.5, 0.5, 1)]

# but up the vert count to 258:
mesh, _ = cmds.polyCube(sw = 8, sh= 8, sd = 4)
print get_verts(mesh)[:4]
#> [maya.api.OpenMaya.MPoint(5.0277956463997711e-315, 5.0313386899592279e-315, 0.5, 1), maya.api.OpenMaya.MPoint(-0.375, -0.5, 0.5, 1), maya.api.OpenMaya.MPoint(-0.25, -0.5, 0.5, 1), maya.api.OpenMaya.MPoint(-0.125, -0.5, 0.5, 1)]

# that first point is gibberish: python can't go to the -315th power!
I’ll leave it to wiser heads to figure out why it works out like this. My guess is that something is borked in pointer math going on inside the wrapper around MfnMesh, but I don’t know. Luckily, there’s a workaround: if you create new MPoints out of the items coming back from the GetPoints() call, you get good data. I’m not sure why but this should be so but it appears to be reliable on my machine (Windows 7, 64 bit maya 2015). Here’s the workaround:
def safe_get_verts(mesh):
    mobj = api.MGlobal.getSelectionListByName(mesh).getDagPath(0)
    mfn_mesh =  api.MFnMesh(mobj)
    vert_array = mfn_mesh.getPoints()
    return [api.MPoint(i) for i in vert_array]  # creating new MPoints fixes the issue

mesh, _ = cmds.polyCube(sw = 10, sh= 10, sd = 10)
print safe_get_verts(mesh)[:4]
#> [maya.api.OpenMaya.MPoint(-0.5, -0.5, 0.5, 1), maya.api.OpenMaya.MPoint(-0.40000000596046448, -0.5, 0.5, 1), maya.api.OpenMaya.MPoint(-0.30000001192092896, -0.5, 0.5, 1), maya.api.OpenMaya.MPoint(-0.20000001788139343, -0.5, 0.5, 1)]

Tuesday, March 17, 2015

Markdown Wrapup

A while back I blogged about how much I longed for a good Markdown based blogging platform. Since a couple of people inquired about how that’s gone, I thought I’d mention my (meager) findings since then.

Monday, March 16, 2015

You kids get offa my lawn!

I didn't get a chance to go to the GDC panel on ageism this year, but it's definitely a topic that I've thought about a lot as I've gradually metamorphosed into an  old codger.  Seeing the panel and related articles reminded me of one of the very first columns I wrote for Game Developer, all the way back in 2004 when my back didn't make those bizarre noises every time I bend over.

Some of the observations here are a bit dated -- most notably, the article is pretty optimistic about the options for climbing the corporate ladder, since it was written at a time when team sizes and big mega-game-conglomerates were growing instead of looking increasingly rare.  However the problems seem to be very much alive today.  As somebody with very talented and accomplished friends who've fallen off the industry tightrope in their 40's and early 50's I can attest that the problems are real.

Saturday, March 14, 2015

Site updates

I've finally gotten around to re-hosting the slides from the Character Rigger's Cookbook talk.  You can also get the original audio on the GDC Vault.

For the tiny handfull of you how were using my Unity course notes, I'm in the process of moving them to a new host.  So the old link at theodox.com is no longer correct (if you follow it you'll get a work-in-progress page; I'm experimenting with a cool new markdown based wiki that is much nicer than the old one at tryscribble.com, but I have yet to make 'real' pages).  I'll announce it here when they go live again.

While moving things around I also added redirect so you can find this blog at blog.theodox.com as well as the usual blogspot link. 

Saturday, March 7, 2015

Back from GDC

Another year, and another horde of game developers have washed over the Mosconce Center like a tidal wave leaving devastation, half-eaten Peruvian chicken sandwiches, and flyers for UE4 in their wake.
hot times on the hiring floor this year!
This was a pretty upbeat year at the show. It was big -- numbers aren't final yet but it looks like the biggest one yet -- and buzzing: the show floor and (perhaps more interesting to the crowd here) the hiring floor were pretty busy. For an old GDC vet it was still a bit of an odd scene on the jobs floor -- the titans of old (EA, Blizzard, Sony, and Microsoft) no longer dominate the space with huge booths and long lines of art school kids -- the biggest booth was from wargaming.net and the busiest ones were hiring for things like VR or even SpaceX (by the way, that rumor I've heard about SpaceX hiring tech artists is not true, at least not according to the folks at the booth this year).  The job market for TA's looks to be pretty hot too: there were a lot of people in the TA roundtable looking to hire. Of course, everybody want to hire "senior" TAs, which is a tough thing for the less-senior to contemplate. Much discussion of how to get people from the entry level to the big leagues, I think there's a future post in there somewhere.
A different kind of change is the vastly expanded demographics of the show -- it's a much bigger, more diverse and more interesting set of faces than you used to see back in the day. The tech art round tables (thanks as always to +Jeff Hanna  for that pillar of the community) had a great mix of people and good questions from all over. Even the dinner at Bucca's had lost a bit of it's pallor, at least until the end when the bottle of chianti and 6 pound calamari plate had circled the table one too many times.
Here's a few things that stuck out to me at the show:

  • the TA Bootcamp was bigger and more badass than ever. We're not afraid to tackle the controversial subjects, from a rigging system in Max to processing budget reports! By all means check out the bootcamp sessions on the GDC vault(link) when they go up in a month or so.
  • the animation bootcamp has also grown into a big treasure trove of great information. If your job involves supporting animation, you should check it out and make sure you know what the animators care about when they aren't whining about where you put the sliders or the shape of your nurbs handles.
  • PBR Rendering has definitely become ubiquitious -- now that Unity, UE, Crytek and Stingray are all offering PBR it's going to be the AAA standard in a year or two if it's not already. I suspect that mobile will stay with conventional forward-rendered shaders for a while yet -- Marmoset's Skyshop(link) is beautiful and all but it labors to render a single model at speed on my iPad -- but I would not be suprised to see cheap-ass versions of the PBR workflow being ported back to mobile either. Start getting ready to pronounce 'metallicity' a lot, and while you're at it check out the talks from Certain Affinity at the TA bootcamp on their PBR pipeline, as well as last year's Order 1886 rendering talk.
  • Almost as can't-swing-a-dead-cat common as PBR was Substance from Allegorithmic. Lots of sightings in talks and in various booths around the show floor. One thing I picked up from their sponsored talk: the batch tools in Substance are python-scriptable, and include notification callbacks for things like texture changes: this could be a very useful trick for the perennially unkempt fringes of the pipeline. I expect I'll have a blog post on this one in the near future once I learn what's going on (or, more characteristically, before I learn what's going on).
  • I think a lot of TA's will find some value in this book from David Lightbown:
     His talk was great, with insights into many of the things we often get backwards in tool development.
  • VR, VR, VR.  Yadda yadda. I'm not jaded, just a little motion sick.  Although that will all be better once I get a virtual nose.  Bootcamp FTW!
About the only disappointing thing about the show was the lack of really stunning tech talks (fair disclaimer: between meetings and checking out talks I helped out with, I didn't see as many talks as I'd have liked to). The only graphics talk I found really compelling was from Q-Games on their bizarro Stalinist platformer The Tomorrow Children.

The renderer does some really interesting non-standard tricks. It's got a real-time 3-bounce GI system, using a hardware voxel representation of the world -- I think even the Enlighten middleware (used in Battlefield, for example) only does a single bounce. They also use what seems like a volumetric method for doing sub-surface scattering that does an amazing job for things like icebergs and waxy surfaces: unlike all the conventional screen space tricks it renders the effects of light sources (including indirect sources) behind a surface. The techniques looked hellaciously complicated, but the results were pretty impressive and visually unique.

I'm sure I'll come up with some more stuff as I sort through my notes, but there's a quick set of expressions from a great show. Hope to see you all there next year!