In keeping with the other career articles I've been reposting, here's a favorite old piece from Game Developer about career arcs in games. The illustrations are from the absolutely priceless Old School FRP Tumblr, which is a treasure trove of 1980's era RPG artwork that any gamer ought to check out. Know your history!
A blog about technical art, particularly Maya, Python, and Unity. With lots of obscurantist references
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
Tuesday, September 16, 2014
Friday, September 5, 2014
The Game Artists Resume Guide (Revisited)
I noticed that my recent repost of the old job hunting guide, Read The Damn Ad, has quickly amassed a lot of views and links. In the interest of completeness, therefore, I thought I'd also repost the bookending article (also from Game Developer) on the nuts and bolts of applying for a job.
The whole thing is after the jump...
The whole thing is after the jump...
Thursday, September 4, 2014
2015 Bug watch: ls()
For people switching to Maya 2015 here's an irritating bug in the 2015 Maya python layer.
In all Mayas before 2015 (as far as I can check, anyway), calling cmds.ls() with a string that was not a valid Maya object name was allowed. You could for example, call
and you'd get back an empty array. In 2015, however, it looks like they have changed the way maya.cmds is converting the string into a dag node reference; it you call the same thing in 2015 you'll get this instead:
This is a bit more serious than it seems at first glance, because ls is such a common command. Any ls operation which includes a string that starts with anything other than a letter or a number with raise an exception, so there are a lot of places which used to just chug along silently that are going to start raising exceptions.
My workaround is to patch cmds.ls on startup so that it safely renames any bad string before passing them to Maya. I do this in my bootstrap routine so I don't have to chase down every occurrence of ls anywhere in my code (1,001 of them, or so PyCharm tells me...).
This makes sure that existing code works as it did before and I don't think it will break anything, since the invalid character strings were never going to be ls'ed into anything anyway. Ordinarily I'm not a big fan of magical behind the scenes fixes but this is a pretty serious change to the behavior of ls which doesn't seem like an intentional upgrade so much as an oversight on Autodesk's part. So, at least until the old behavior comes back I'm gonna try it.
Update: Hat tip to +Robert White for pointing out that the original regex I posted did not handle namespaces. Code above includes the fix. Never would have figured it out without Pythex!
Update 2: Updated the safe_ls procedure to handle more of the allowable syntax in older mayas
In all Mayas before 2015 (as far as I can check, anyway), calling cmds.ls() with a string that was not a valid Maya object name was allowed. You could for example, call
cmds.ls("@")
and you'd get back an empty array. In 2015, however, it looks like they have changed the way maya.cmds is converting the string into a dag node reference; it you call the same thing in 2015 you'll get this instead:
# Error: Syntax error: unexpected end @ at position 1 while parsing:
# ; ; @
# ; ; ^
# : @
# Traceback (most recent call last):
# ; File "", line 1, in
# RuntimeError: Syntax error: unexpected end @ at position 1 while parsing:
# ; ; @
# ; ; ^
# : @ #
This is a bit more serious than it seems at first glance, because ls is such a common command. Any ls operation which includes a string that starts with anything other than a letter or a number with raise an exception, so there are a lot of places which used to just chug along silently that are going to start raising exceptions.
My workaround is to patch cmds.ls on startup so that it safely renames any bad string before passing them to Maya. I do this in my bootstrap routine so I don't have to chase down every occurrence of ls anywhere in my code (1,001 of them, or so PyCharm tells me...).
import re
import maya.cmds as cmds
VALID_OBJECT = re.compile("""^[|]?([^a-zA-Z_\?\*\:\|])|([^a-zA-Z0-9_\?\*\:\|\.\[\]])""")
as_u = lambda p: p if not hasattr(p, 'addPrefix') else unicode(p)
def safe_ls(*args, **kwargs):
'''
Patches maya 2015 cmds.ls so that it does not except when passed illegal name characters.
'''
if not len(args):
return _BASE_LS(**kwargs)
if len(args) == 1 and hasattr(args[0], '__iter__'):
args = args[0]
test_args = [VALID_OBJECT.sub('_', as_u(i)) for i in args]
return _BASE_LS(test_args, **kwargs)gs)
cmds.ls = safe_ls
This makes sure that existing code works as it did before and I don't think it will break anything, since the invalid character strings were never going to be ls'ed into anything anyway. Ordinarily I'm not a big fan of magical behind the scenes fixes but this is a pretty serious change to the behavior of ls which doesn't seem like an intentional upgrade so much as an oversight on Autodesk's part. So, at least until the old behavior comes back I'm gonna try it.
Update: Hat tip to +Robert White for pointing out that the original regex I posted did not handle namespaces. Code above includes the fix. Never would have figured it out without Pythex!
Update 2: Updated the safe_ls procedure to handle more of the allowable syntax in older mayas
Wednesday, September 3, 2014
Sony's Open Source Toolset
I noticed on Gamasutra (hat tip +Jon Jones ) that Sony is open-sourcing its Authoring Tools Framework.
Monday, September 1, 2014
Size is the enemy: an oldie but a goodie
While googling my way around some strategy issues lately I rediscovered this 2007 post from Jeff Atwood which neatly sums up a few important things that have been factoring very large in my thinking lately: Plus, I've spent the last 4 days in the madness that is Pax (shout out to all the great folks who came by the booths, by the way!) so I'm a little grumpy.
The reasons why are enumerated after the jump.... (Update 9/3) see below
The reasons why are enumerated after the jump.... (Update 9/3) see below
Subscribe to:
Posts (Atom)