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
Showing posts with label tools. Show all posts
Showing posts with label tools. Show all posts

Saturday, May 16, 2015

spelchek

Spelchek

I’m planning one of the worst things that can happen to a TA: a big massive file move-and-rename operation. Much as I love my team, we have a poor record as a company when it comes to spelling, and it occurred to me that I’d like to at least have some degree of automatic spell checking on the names of the new files, folders and assets.
It turns out that there’s no good spell checker for Python that doesn’t come with some kind of extension module (BTW, I’d love to be wrong about that - if you know one definitely post it in the comments). PyEnchant for example is great, but it’s got 32-bit only Windows extensions that I can’t distribute without a hassle.
I did, however, find a very neat example of Python Power in a little post by Peter Norvig, who put together a simple spellchecker in a few dozen lines of plain, readable Python code and great explanations here.
I shamelessly borrowed his structure, with a couple of minor and not very creative tweaks. Peter’s original is built around Bayesian analysis: it guesses the correct word by looking at the relative frequencies with which variants show up – if ‘meet’ shows up 1000 times in your database but ‘mete’ shows up 5 times, that’s a good indication that ‘meet’ is the correct first guess.
Since I’m in a rush, I didn’t use that functionality very much. I scrounged around for as many sources correctly scored words. Unfortunately the only free source I could rely on turned out to be the venerable ‘GSL’ or ‘General Service List’, which has great data but only for about 2000 words (I used the version found here, by John Bauman as a the core of the list, and then scrounged the internet for other free sources. Since all of these were less common words than the ones in the GSL I gave them pretty arbitrary Bayes scores (4’s and 5’s for common words, 3’s for variants, plurals and participles). This is not sophisticated linguistics, but it’s close enough for horseshoes.
The result is up on github as spelchek, which I affectionately refer to as the cheap-ass spell checker.
It is hardly rocket science, but it does work. You can do something like:
   import spelchek
   spelchek.correct('vhicle')
    # 'vehicle'
or
    spelchek.guesses('flied')
    # ['filed', 'flied', 'flies', 'lied']
I would caution against using this for hard-core text work where perfect accuracy matters -- like database stuff, a customer-facing website, or a word processor -- since I did not go with high quality commercially or academically vetted word lists. I’m reasonably certain that there are some mis-spellings or oddballs in the 75,000 or so words I ended up with from various sources. Still, the module useful for my intended use, which is making sure that we don’t get things like ‘floder’, ‘frunishings’ and ‘vetegation’ (all of which shipped with in State of Decay, I’m sorry to admit).
As always, MIT licensed so go to town.

Thursday, January 22, 2015

The Trust Fund

A recent discussion on TAO reminded me of this old GDMag column from 2010. Tech artists always have to fight to stay focused on the relationship at the heart of our business: no amount of technical wizardry matters if your artists aren't actually benefitting from what you do.

While much has changed in the last five years, a lot of this still seems like good advice (to me, anyway, but I'm biased).  I might add a couple of sentences about 'more unit tests' and 'continuous integration' and similar buzzwords but that's just fluff: taking care of your users is all that really counts.

Sunday, October 5, 2014

The Dismal Science : Technical Debt For Technical Artists

From the estimable +Paul Vosper  an excellent discussion of technical debt: the long term costs you incur by prioritizing the here-and-now demands of everyday life over technical and architectural needs.


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

Saturday, July 5, 2014

Save The Environment 2: I am the .Egg Man

In my last, bumper-sticker-laden post I offered to share a little bit about the way I pack up my tools for users.  This time I'll try to actually describe the process.

After a all the buildup, I wish I could make this sound more high tech and impressive. Basically, I just pack up what I have and send it all out to my users in a big ol' zip file.  The zip ends up on their Maya's PYTHONPATH, and gives them exactly the same stuff I had when I created the zip.  That's kind of it.  It's basically a simplified version of a python egg; however since I'm distributing an entire ecosystem in one shot I've opted to do the packaging myself instead of relying on setuptools and all of its complex dependency management arrangements.

Simple as it is, this system has saved me a huge amount of time and energy over the last few years. It's been a long time since I've had to worry about a mysterious import failure or the wrong version of a module.  Simplicity and robustness are very important, especially in the foundation of a pipeline. Of course, they don't always make for the most engaging blog posts  But I'll do what I can, even if it means resorting to some pretty lame egg puns.

Thursday, June 26, 2014

Binary bonanza!

Here's a very complete source for a variety of python package binary distributions, covering a pretty broad variety of platforms, python versions and bit depths.  A good page to bookmark next time your scrounging for a rare extension module you can't compile.

Tuesday, June 3, 2014

Save the environment!

+Rob Galanakis  posted this on Google+, and as I started to reply I realized this would be a useful thing to put out to a wider audience.  Or maybe useful isn't the right word - it's just something that bugs me so I want to bloviate about it.
Hey +Cory Mogk , +Brad Clark, +Steve Theodore , and whoever else in #techart . Has anyone figured out a viable model for reusing Python libraries in Maya, like other Python applications with pip/virtualenv/requirements.txt do? Is there a conversation anywhere?
The short answer to Rob's question is : I've tried to go this route, but I couldn't get a virtualenv-based approach to match for my needs.   For the long answer, read on...

Friday, March 28, 2014

New(-ish) Tools Watch: 3D Coat 4.1



Version 4.1 of 3DCoat just came out - details in the video above or at 3D-Coat.com.

3DCoat is an interesting voxel-based alternative to Zbrush. It deserves a lot of credit for really pushing the retopology business forward, and also for early PTex support. The interface is less idiosyncratic than Zbrush's but less by-the-numbers than Mudbox.

Plus, it's made in Kiev - buy a copy and stand up for Ukrainian independence!

Some cool feature videos if you're curious:

UV tools
Curve-constrained sculpts
Ptex texturing


Wednesday, March 26, 2014

(?:regex){1} (haterz)+

If you hate regexes as much as I do - which, honestly, seems scarcely possible - you should check out these regex preview sites which make like a little easier when you're trying to work out a particularly nasty one:

Python: Pythex 

C# / dotnet : Regex Storm 

Both of these offer big productivity boost over the usual tweak-run-check cycle

Tuesday, March 25, 2014

New tools watch: MARI

Lately - particularly since the demise of the late, lamented XSI, I've been increasingly worried about getting too locked in to any one vendor for my tools.  I go way back with Photoshop - I once emailed a bug report directly to John Knoll on my Compuserve (!!) account.  I was in the audience for the Maya launch at SIGGRAPH in, I think it was 1997.

Jeez, I'm really fricking old. But I digress.

The point is, I love those tools. They've been part of my life for a long time. But I don't like being too beholden to anybody, especially not an anybody who's a big public company that has to answer to shareholders and analysts and is not particularly worried about competition.

For that reason I'm actively looking for alternatives to supplement or even supplant the old standbys.  And this GDC gave me some up-close and personal time with a very promising one: Mari, the 3-d painting app from the Foundry.

Lots of Mari work on Avatar

More after the jump.

Tuesday, March 11, 2014

A little bit of innovation

If recent demise of XSI has you all depressed about the state of 3d software, here's a little preview of a new Modo feature that will make some modelers very happy



http://community.thefoundry.co.uk/store/plugins/meshfusion/

Tuesday, March 4, 2014

*Sigh*

It's bad enough we just lost Harold Ramis.

Now we've also lost SoftImage.

Although I've never used XSI professionally, I was incredibly impressed by the people who made it, and I've always felt that XSI was a superior product to Max or Maya: making better use of modern hardware and showing off really innovative concepts in an industry that's gotten pretty damn stale for something that's sounds so high tech and is occasionally so magical.

In honor of the passing of this great piece of software, I'm going to reprint an article I wrote for Game Developer back in 2008 when the sale of XSI to Autodesk was first announced.  I'm afraid I may have been a little too optimistic. However I do think that the basic idea of the piece - that we let ourselves in for this kind of treatment by not being more informed and flexible consumers - is still true.

In the mean time, I'm going to go have an Irish wake for a poor old XSI.  (BTW, if you're waiting on the follow-up to Rescuing Maya GUI From Itself, I'm cleaning up the code and writing tests before I go blabbing...)

Update: Came upon this interesting set of charts (espceially the next to the last one at the bottom) which explains a lot of what's going on on here. Doesn't make it hurt less, though.

Equally relevant: Autodesk's upgrade lockdown. 


The M-Word


If you’ve been in a crunch-time media blackout for the past month, or shut down your internet connection to avoid election news,  or are the only games artist on the planet who’s never received a youtube link via email you may have missed an interesting little tidbit of news. On October 23 we learned that Avid is going to sell SoftImage, the Montreal-based developer or SoftImage|XSI to Autodesk.  If and when the deal goes through, all three of the biggest 3d modeling and animation packages will all belong to a single company.

Even if you managed to miss the announcement, you can probably predict the immediate reactions anyway.   In the XSI community, the dominant mode was shell-shock.  The “Resistance is Futile” jokes and Borg-themed Photoshop jobs could not disguise the level of emotion in the air -- the poster on the XSI forums who simply said “I think I’ll cry” wasn’t kidding.  There was a smattering of optimists suggesting the deal would give more people access to some of XSI’s best tech.  A few pragmatists found consolation in the idea that the conglomeration would give cross-package data transfer the attention it deserves.  But the most common reactions were shock and anxiety. 

It’s hardly surprising that the possibility of being forced to abandon the comfort and security of a familiar environment would give XSI users the heebie-jeebies.  The official Pixel Pusher line has always been that any professional game artist should be competent in at least two packages. But even traditional artists are famous for being emotionally attached to their tools (never, ever venture an opinion about Kolinsky sable brushes in mixed company!) For us, who spend so much of our lives poking at one particular set of dialogs or buttons, the thought of being forced to swap them for a different, unfamiliar set of dialogs and buttons is deeply disturbing.  The fact that some XSI fans were so distraught they’d consider switching to Blender out of pique is an index of how emotional this issue can be.

What’s surprising, though, is that a similar miasma could be seen in the Max and Maya forums after the buyout announcement. Emotions ran high even for those not affected directly. Hardcore Maya fans suffered flashbacks as they relived the 2006 buyout of Alias.  More commonly, though, users were grimly pondering the future of graphics software in general, rather than the fate of any particular package.  Some naysayers worried that technology would stagnate without the underdogs like XSI striving to gain an advantage through innovation. Others fretted that consolidation in the industry means the exciting, Wild-West days of graphics are really over.  And many users of all three packages speculated that the lack of competition will lead to price gouging.

You Are Elected Chairman of the Board


Before we pronounce the graphics software business dead, we ought to look at this deal in its historical context.  These kinds of corporate dramas are unsettling for artists because they are an unsubtle reminder that we creative types are dependent on huge, impersonal corporations to get anything done. Masters-of-the-Universe style MBA analysis isn’t part of our job descriptions, so it’s hard for use mere users to figure out how to respond. A little bit of history, however, is often a good way to get some perspective; so here’s a very abbreviated walk through the life and times of SoftImage to help you understand today’s news.
XSI may be the youngest of the big three graphics packages, but SoftImage the company is one of the oldest firms in 3d graphics software.  The original “SoftImage Creative Environment” debuted in 1988, but in an economic environment very different from todays.  3D graphics was very closely akin to rocket science – for one thing, it was mysterious new high-tech discipline and for another you needed an exotic workstation that cost upwards of $50,000[1] to do either one.  It was a very esoteric, very pricey business.

SoftImage|3D  was the first commercial application to offer artist-friendly IK (1991) and it quickly became the gold standard for computer animation.  Many seminal CGI films of the early ‘90’s were animated in SoftImage, most famously Jurassic Park.  Those early days of the CG revolution were heady times. Hollywood stood ready to firehose money onto anybody who could render a good looking triangle  -- SIGGRAPH veterans still murmur nostalgically about the heydays of studio parties – and the boom times were good for the company. In 1992, the Montreal firm went public to much acclaim.
Success also changed the way the industry worked.   By the mid ‘90s, the explosion of 3d game development shifted the industry dynamic: the ranks of 3d artists and animators expanded enormously, but few games companies could afford to put the equivalent of a luxury sports car under every animator’s desk.  Affordable PCs with primitive graphics cards started stealing business from workstations and PC based packages like Autodesk’s 3d Studio started making inroads against pricey workstation software.

From Sale Of Stock You Get $45 


Microsoft, naturally, wanted to see the PC forces prevail . In 1994 they bought SoftImage for $130 million – a pretty high price given that the whole 3D software market was only around $60 million a year back then. But box sales weren’t the real goal: Microsoft needed to port a top-end workstation graphics package to Windows and legitimize the market for high end graphics on Windows. 
For many SoftImage vets, the events of last month may have an eerily familiar ring, right down to the “you will be assimilated” jokes (although,  in 1994 the reference was forgivably fresh).

 The MS acquisition was not a very pleasant experience for SoftImage users. Not only were many Unix devotees forcibly converted to a new OS, but the demands of porting and cross-platform development shunted innovation to the sidelines.  It took almost 7 years for SoftImage|3D to get from version 3.0 to version 4.0 , and the package lost a lot of its technological edge to newer platforms like 3dStudio Max and Maya.  It’s not surprising that the survivors of that first buyout react suspiciously to the latest.
By 1998, Microsoft had achieved its strategic objective: Windows had triumphed and graphics workstations were headed for the history books.  SoftImage became superfluous.  Microsoft sought out a buyer and found Avid, a rising power in the digital video editing business which coveted the company’s VFX and compositing tech.  Even if the core 3d business was losing steam, the deal still ran a cool $285 million – a price that might have been inflated by internet bubble, but it’s still pretty impressive.

Avid’s stewardship was a lot healthier for SoftImage as a tech company. SoftImage XSI, the long overdue gut-rehab of the aging SoftImage|3D, was released in 2000.  The product started out a bit slow – version 1.0 had no poly modeling tools! – but gained steam with impressive tech and clean new architecture. Many artists have lusted after XSI’s GATOR system for mapping one mesh onto another (supporting everything from texture transfers to skin weight matching) , its non-linear animation mixer, Face Robot facial animation technology, and most recently the high-perfomance ICE system for node-based custom object creation. 

Second Prize in a Beauty Contest, Collect $11


Unfortunately, the eningeering success of the product did not translate into success for SoftImage’s owners.  Avid’s core business has been hit hard by the proliferation of lower-cost video editing software like Apple’s Final Cut Pro.  Even though the SoftImage was profitable, it wasn’t profitable enough: to get a sense of the scale, you might note that the $35 million sale price for the company won’t even cover Avid’s losses for the 3rd quarter of this year.  As times got leaner, Avid needed to focus on protecting its core video editing business, so it started hunting for a buyer early this year.  Autodesk, as home to both of XSI’s a main rivals, was not the first buyer who was approached… but it was the final one, which is the one that counts.

What lessons can you learn from this little history?

First, it doesn’t provide a lot of evidence for conspiracy theories about monopoly power.  The fact is, supplying 3d software is pretty small potatoes in the grand scheme of capitalism.  It’s been said that there are only about half a million seats of full 3d packages in the world – sounds like a lot, but that’s smaller than the number of people in the beta program alone for Photoshop.  It’s not a market where achieving dominance is a huge financial win.  All three turnovers at SofImage  have been driven by strategic concerns that didn’t have to do with monopoly power or market domination.  Microsoft bought SoftImage to catalyze the switch from workstations to PCs. Avid bought it to solidify its FX and compositing business and saw modeling and animation through that prism.  The most recent sale didn’t originate with a sinister plot from inside of Autodesk, it originated with Avid’s accountants. 

The more interesting – but also more depressing – aspect of this story, though, isn’t concerned with money. You could read the whole thing as a stirring tale of steadfast devotion. It was user loyalty that sustained SoftImage during the drift of the Microsoft years, when technical sluggishness might have let Max and Maya completely marginalize the original SoftImage.  The emotional reaction to the news is proof of how viscerally loyal users are to their favorite tools.

Unfortunately, that loyalty is a two edged sword.  The last few version of XSI were consistently excellent -- but no combination of cool features and good design managed to seduce away enough users from other packages to secure SoftImage’s future.  They competed on tech and features and did a great job – but it wasn’t enough to overcome the entrenched loyalties of Max and Maya fans. Individual artists might admire this feature or that bit of UI, but collectively we’re reactionaries: we stick with what we know. On top of that, most studios have tools and processes are designed around a particular package and aren’t eager to chuck those investments for the sake of sexy icons or a cleaner interface.

The fact is, we don’t really reward tools companies for pushing the envelope.  Even when something new does break into the scene, we try to shoehorn it into our existing workflows rather than embracing the new. We’re the last people to start denouncing monopolies and phoning up the Federal Trade Commission. Most of us have already folded our hands by letting ourselves become emotionally attached or technically beholden to particular bits of software.  If you’re in the same camp as the XSI user who posted “they’ll have to pry my license from my cold dead fingers,” you live in a virtual monopoly already.

Get Out Of Jail Free?


That’s not to say that things aren’t going to change. The absence of major-league alternatives will definitely give Autodesk a much freer hand in choosing both its price points and research directions. T fact that their track record to date is pretty benign is comforting, but the knowledge that we’re dependent on their altruism from here on out should give us pause.  Autodesk has put some genuine effort into trying to explain the deal to users (there’s an interesting interview featuring the GMs of Autodesk and SoftImage up on the Autodesk website, with more info promised as the deal solidifies) but apart from reassurances that XSI isn’t going to go away overnight, the magic 8-ball is pretty cloudy.

The uncertainty is tough, particularly for anxious XSI users but for all of us. We all know the mantra, “it’s the artist not the tools” – but in practice it’s sometimes hard to say where the artist leaves off and the tool begins. The feeling that such an important part of our lives is out of our control is unnerving. 
What can we do about it? As individuals, that means being open to new software and new ways of working, so that we make an environment where companies have a real incentive to give us new and better tools. As studios we should invest in in-house tools rather than relying too faithfully on any single vendor.  As an industry we should push harder for more consistent, open standards in data formats and for open source tools so we can make our pipelines less dependent on the ups and downs of individual companies.  None of these steps will magically unwind the clock but they will give us a little more input into this critical part of our lives.

Or, we could all switch to Blender… But man, I hate the way they do their menus. It’s not like Max. You couldn’t pay me enough to switch.







[1] That’s $65,000 in today’s dollars.  For a machine less powerful than an iPhone.

Sunday, February 16, 2014

Pity for the outcast

I don't think it's too far over the top to say that everybody hates Maya's internal GUI system. It combines a very 1990's selection of widgets with a very 1970's coding style: it's a  1970's/1990's Frankenstein monster as horrifying as Ashton Kutcher in That 70's Show.



Not surprisingly a lot of TA's feel like they have to turn to PyQT if they want to deliver polished tools with a modern UI.  Unfortunately this is also less than ideal - while PyQT is a very powerful framework, it's got a very distinctive idiom of its own to learn, and moreover its hard to distribute since it depends on C++ dlls.  If you want to share a tool across studios or with outsourcers on a variety of boxes, OS'es and Maya versions it can become a Dantesque journey into DLL hell.

Because we do a lot of work with outsourcers, I've been looking into ways to render native Maya GUI a little less irritating. A quick review of my own pain-points in Maya GUI development showed me three main problems with the existing system


Icky syntax

Default Maya GUI is purely imperative; while Maya creates an in-memory object for every widget you create, you can only interact through it with via commands: In the typical idiom you create a button:

cmds.button("big button");

but your can only interact with it by calling more commands:

mybutton = cmds.button("big button")
cmds.button(mybutton, e=True, w=128)
cmds.button(mybutton, e=True, label = 'Red button'))
cmds.button(mybutton, e=True, bgc = (1,.5, .5))

This gets old pretty fast.  It's particularly bad for GUI components like formLayout, which can easily require whopping big arguments like this:

cmds.formLayout( form, edit=True, attachForm=[(b1, 'top', 5), (b1, 'left', 5), (b2, 'left', 5), (b2, 'bottom', 5), (b2, 'right', 5), (column, 'top', 5), (column, 'right', 5) ], attachControl=[(b1, 'bottom', 5, b2), (column, 'bottom', 5, b2)], attachPosition=[(b1, 'right', 5, 75), (column, 'left', 0, 75)], attachNone=(b2, 'top') )

Which is, frankly, stupid.

Lousy event handling

Another big knock on Maya's native gui is it's lousy callback system. The python version is bolted on to the original, string based MEL version and confuses a lot of people with uncertain scoping and unclear syntax (Check out these threads on Tech Artists.Org and  StackOverflow for some examples of how people get lost) .

Even when default Maya GUI callbacks do fire, they don't usually indicated who fired them off. This means you need to capture any relevant information ahead of time and encode it into the callback. In lots of GUI systems, you could handle a raft of similar functions like this pseudocode:

button_codes = ['red', 'green', 'blue']
for code in button_codes:
    button(code, tag = code, handler = apply_color)

def apply_color(button):
   target.color = constants[button.tag]

In Maya, on the other hand, you need to compose the callbacks with the right context when you create them using a functools.partial or a closure.  This makes coding up anything like dynamic model-view-controller UI into a real chore, and forces you to interleave your layout architecture and your data model in clumsy ways.

Moreover, Maya GUI callbacks are single-function calls. Its common in other frameworks -- for example in C#  - to have multicast delegates which can trigger multiple actions from a single callback. This makes for cleaner, more general code since you can split UI-only functionality ('highlight this button') from important stuff ('delete this model').

No Hierarchy

It might not be strictly fair to say that Maya GUI has 'no hierarchy'; anybody who has ever mucked around with cmds.setParent or cmds.lsUI knows that the actual widgets are composed in a strict hierarchical tree; hence UI objects with names like
window1|formLayout57|formLayout58|frameLayout38|columnLayout5|button5
The problem is that Maya doesn't manage this for you - you are responsible for capturing the pathname of every UI widget you create if you ever want to access it again, which imposes a useless maintenance tax on otherwise simple code. Moreover the names aren't determninistic, thanks to Maya's rule against identical paths: that means you may want a button called 'Button', but it may decide to call itself 'Button1' or 'Button99' and there's nothing you can do about it. As if that weren't bad enough, the strongly imperative style of the Maya GUI code also requires manual management. If you declare a layout and start filling it up with widgets, you're also responsible deciding when a particular container is full. A missed cmds.setParent can easily screw up your visual layout or the ordering of a menus and it's possible to shoot yourself in the foot without any corresponding gain in power, productivity or even prettiness. This limitation is why Maya has to offer all those redundant command sets for multiple-column rows and grids. When a monstrosity like cmds.rowLayout(nc=5, cw5=(100,100,50,50,80), ct5 =("left", "left", "both","both","right")) is a win for code cleanliness and legibility you know something has gone horribly wrong.


So What?

All of that amounts to a long-winded way of restating the obvious: nobody likes coding in standard Maya GUI.  The question is, can something be done about it?

Actually, quite a bit..  Next time out I'll talk about some practical ways to make Maya GUI coding... well, let's not say "fun", lets run with another 90's retread:


For 'Windows 95' substitute 'Maya GUI' and you've got the idea (For the origins of this authentic 2400-baud era meme, click here.) 

Wednesday, January 29, 2014

Talking to Photoshop via TCP

A recent thread on TAO got me thinking about communicating with Photoshop from Python. In the past I've done this Adam Plechter-style using COM ( from both C# and Python) and it's worked for me, but I know some people have problems with COM for a variety of reasons relating to windows versions and DLL hell.
Using COM always makes me feel like Mr. Yuk.


Since I had to learn a few JavaScript tricks back when I started looking into Python web development, I thought it might be worth investigating what could be done to cut out COM.  It turns out that ExtendScript - the JavaScript flavor that comes with Adobe products (at least since CS 5, and I think earlier) includes a socket object which allows for TCP communication.  That's not kosher in 'real' browser based JS - but ExtendScript cheats a little (that's also why it allows you to do things like hit the local file system, another JS no-no).

The Adobe docs have an example (around page 196) which shows how you can implement a chat server or a web server running inside Photoshop. That might not be practical but it provides a simple framework you can hijack to turn Photoshop into a remote procedure call server.  Here's an example of a super-simple server that can be run inside Photoshop:
Note: You'll need to save the file as a .JSX (not .JS!) for Photoshop to allow the ExtendScript functionality which makes the socket objects work.

This example is very bare bones, but it is easy to extend - just create function objects and add them to known_commands dictionary and then send them over the socket. The way it's written here the commands and arguments are split on spaces (similar to the way a shell command works) -- if you need to get at them in your JS functions you can get at them using the arguments() keyword:.  For serious work I'd probably use the ExtendScript XML object and send the commands and responses as xml since that gets you out of having to worry about stuff like 'what if I want to send an argument with a space in it' -- however this purpose of this excersize is just to demonstrate what's possible.

I should note that while the server is running, Photoshop is locked into the wait loop so it will not be accessible interactively -- like a Maya running a long script, the main thread is just waiting for the script to continue. For the typical 'remote control' application that's what you'd expect, but it may not answer for all purposes - so be warned.

If you're trying to talk to Photoshop from Python, it's incredibly simple:


That's all there is to it - of course, the real problem is getting useful work done in the clunky Photoshop API -- but that's going to be the same no matter whether you talk to PS via COM or TCP/IP.  Anecdotally, I've heard the PS scripts are faster in JavaScript than when using COM or AppleTalk or VB, so perhaps this method will be competitive on speed as well.  For small tasks it's certainly a simpler and less irritating way to send a squirt to and from PS 

Sunday, January 12, 2014

Maya's (mildy) Magical Modules

If you're doing tools work in Maya, you've probably seen a lot of ways of distributing scripts and tools. The most common, alas, is also the wonkiest - dumping a bunch of scripts into the users's script folder or maybe fiddling with Maya.env to point at a shared drive on the local network.  

Eventually, you'll rum into situations where you can't just litter files all over your user's machine. Maybe you're supporting multiple projects in the studio and you need to have users hopping back and forth between toolsets. Maybe you're dealing with multiple versions of maya and your tools have been forked into different environments. Maybe you're dealing with outsources who don't want to permanently alter their own environment just to get your tools for one project. Whatever the reason, someday you'll run into a situation where you want to be able to drop in a whole maya toolset as a unit and to remove or disable it the same way.

Maya has always a had a facility called 'modules', can be useful for this purpose. It used to be used for things like  cloth sim or hair that were tacked on to the main package (back when hair was a $9,000 add-on!) .  Since then it's largely fallen out of favor, but it's never gone away -- and it has some useful properties that are great for tools distribution.

A module is really a sort of virtual file system.  Maya's most important folders are those for scripts, plugins, icons, and presets -- the same ones you typically see in your maya user directory.  If you place a special text file in your module path, you can add to extra paths for maya to search for scripts, plugins, icons and presets.

The big advantage of modules is the ability to manage complete set of files at once - scripts, plugins and so on can all be included (or excluded) from your Maya in a single place (Hint to Autodesk - it would be very nice to give users a UI for this.  The 'Modules' setting in the preferences, confusingly, does not refer to these modules.).  Parts of a module can be kept independent of the user's private stock of scripts and tools. For outsourcers and contractors, in particular, the ability to completely uninstall a toolset you don't need anymore is a godsend.

Another handy feature of modules is that they can point Maya at shared network paths as well as paths on disk. This makes it far easier to keep a whole team on a common tool set by pointing a module script directory at a shared drive.  I'm not personally a big fan of the shared drive as a distribution method (more on that some other time) but it's fairly common and this makes it easy to establish and manage.

Finally modules do a little bit of automatic versioning. A module can specify different paths for different Maya versions, OS'es and processors.  This means a tool author can produce a single distribution for all customers and give them identical installation instructions without worrying too much about the details of the individual workstations on the receiving end.  You can pack up all of your distributions into a single zip file, and users merely unzip it into the modules folder of their local settings and the installation is done .

Basic Setup

Modules are defined by a simple text file with a ".mod" extension.  Maya will look for module files in all the directories in the MAYA_MODULE_PATH environment variable if you have it set, or in the modules directory of your maya user directory (for example, in My Documents\maya\modules). Here are the default locations where modules can be placed:

Default for Windows

/My Documents/maya//modules
/My Documents/maya/modules
C:/Program Files/Common Files/Autodesk Shared/Modules/maya/
C:/Program Files/Common Files/Autodesk Shared/Modules/maya/modules/

Default for Mac OS X, Linux

$MAYA_APP_DIR/maya//modules
$MAYA_APP_DIR/maya/modules
/usr/autodesk/modules/maya/
/usr

A module file is a plain text file. The official documentation for the format is here (the 2012 version is here - there are some pretty significant differences between 2012 and 2013+), but for the simple case it looks like this

+ moduleName 1.0 c:\path\to\moduleName

The module name is what shows up in the Maya UI, the 1.0 is a version number, and the path points Maya to the location of the module folder.  This example would point to a folder called "ModuleName". If that's all that goes in there, then maya will look for scripts in

c:\path\to\moduleName\scripts

icons in

c:\path\to\moduleName\icons

and plugins in

c:\path\to\moduleName\plug-ins

You can test this out by making the folder c:\path\to\moduleName\scripts and popping a userSetup.py ( or a userSetup.mel, if you're feeling old school) into it with a print("hello world")  in it. When you restart your maya you should see it printout in the maya output window as Maya loads. It's the output window for python because the script will execute before the Maya UI has loaded (something to keep in mind in your startup scripts!).

You can avoid hard coding the paths by using an alternate syntax in the mode file.  You have a can, for example, include an environment variable using ${variable} in place of an absolute path. For example


+ moduleName 1.0 ${PROJECT_LOC}\mayatools


will point look for your module folder in the location defined by the environment variable named project_loc.  One side effect of this is that uou can put your modules into the modules folder (alongside your mod files) without having to hard-code paths:

+ moduleName 1.0 ${MAYA_MODULE_PATH}\moduleName 

 You can even point your modules at a network share:

+ moduleName 1.0 \\net\shared\modules\moduleName

 

Fancy stuff in 2013+ 


Sometimes setup requirements are more complex than dropping in a single folder (not a good idea if you can avoid it - but you know how it is...). In 2013 and later,  you can use the module file to override particular paths and do some more flexible setup.

For example, in 2013+, you can also define the path relative to the module file location:

+ moduleName 1.0 ..\moduleName

should point at a folder above the directory where the module file is located. Just remmber: 2013+ only...  If you've looked at, for example, Cyrille Fauvel's post on modules you'll see a bunch of advice that only works for 2013+.  Be aware :)

The other neat addition in 2013 is the ability to override specific sub-paths of the module. Thus

+ moduleName 1.0 ${MAYA_MODULE_PATH}\moduleName 
scripts: //network/share/scripts

would point the scripts at the shared network scripts  drive, while leaving the plugins and icons folders in the module location.

 2013+ also offers the ability to set environment variables from inside a module

+ moduleName 1.0 ${MAYA_MODULE_PATH}\moduleName 
HAS_FANCY_2013_FEATURES=YES

Will set the environment variable HAS_FANCY_2013_FEATURES to 'yes' inside your maya session. 2013 even has some funky syntax allowing you to append to existing variables and so on . There's no point in recapitulating it here, the description in the docs is a concise as I could do - my only commentary would be: seriously, people? It's 2014 and still with the funky syntax crap?  I'm supposed to recognize that  PATH += and PATH +:= bin are different? 

Adding to paths can be extremely handy for some things, but unfortunately this won't solve a particularly thorny problem for tools teams, which is making sure that the OS can find binary dlls: if you have dll dependencies in a binary plugin, its 'too late' to fix it by appending the dll locatins to the system path once Maya has loaded. Which stinks -- and is another reason to avoid binary plugins like the plague they are if at all possible.


 One stop tool distribution... or not

For any busy TA, the business of distributing and maintaining toolsets on lots of other people's computers is a constant headache.  Modules can offer some significant assistance with this, since they allow you some control over Maya's search paths without requiring your to write code. It's a simple solution to the chicken-and-egg problem of getting Maya to do what you want before you've got tools loaded up to tell Maya what to do.

Modules, on their own, are not a complete solution to that problem.  But they are a help.

Modules basically just tell maya to look in a few extra places for things like scripts or plugins - they don't automatically run startup code or do initialization, and they don't have much in the way of smarts -- they can't for example, allow you to quickly switch between two project-specific versions of your maya tool set. You can install modules for toolsetA and toolsetB, but something smarter than a module file has to decide which one to pick on a given occasion (I'm going to talk about that problem in another post, but for now  However they do allow you to mix and match install locations, which is a big start; they also allow you to install outside the user's script folders, which is a key element in the good-fences-make-good-neighbors relationship between TA tools and the user's private maya preferences.  Plus, they are explicit: you can look at the file and tell what its trying to do, which beats any number of magic naming and location rules.

At some point in the near future I'll try to post something on the second half of the distribution puzzle: running startup code cleanly and intelligently.


Friday, January 3, 2014

First find of 2014: A Scriptable DCC app in the browser?!?!

Just stumbled across this link to clara.io, which is an in-browser 3D editor from Ecocortex, one of the vendors behind the Alembic file format. It's a 3d modeler that runs in a browser.  And it's free.

Sheesh.

And look at the bottom - a script console!

I'm not entirely sure what to make of this, beyond totally wicked. I'm not going to try to review clara here - I just found it today, after all, but it's such an interesting find that I can't help but comment.

The UI is a riff on familiar ideas, so it's easy to pick up for any TA, or for that matter anybody with more than a passing familiarity with the usual suspects. It doesn't break any new ground in productivity or ease of use - but that doesn't bother me in this context. Like the dog that walks on it's hind legs, it's not done perfectly but one is surprised to see it done at all.  This is, after all running in a browser. Yikes.

The app is still kind of wet behind the ears - it feels a trifle slow (some kinds of UI operations seem to trigger a perceptible refresh in all of the 3d views, for example). There are host of poly modeling tools -- notably booleans -- that Max/Maya users will miss pretty quickly.  All that said - the idea of running a zero-configuration, instantly deployable app from anywhere -- a tool you could be sure was the same for your outsources in Bangkok and on your own desktop right now -- along with inherent cloud data management?  The ability to run remote commands via web push commands, so you could set up a That is beyond just a curiosity. This app doesn't suddenly obsolete Max or Maya or XSI, but it might be the first rumblings of a big change in how things get done.  As a side benefit, it's got a several different file IO options and could perhaps make as decent waystation for people crossing product boundaries.

The TA who immediately asks "what scripting language" will be pleased to note that there's a script console down at the bottom; unsurprisingly for a web app the scripting language is JavaScript.  JS may not be my favorite language -- by a long shot-- but it's the natural language of the web. Most importantly, the scripting system makes it fairly easy to extend the application by writing your own plugins: this example on their website shows how to make an OBJ importer.

Most important of all, though -- did I mention this? -- it's a browser app. Which means you can so things like this:



Which, you must admit, scores pretty well on the Gee-Whiz scale.
Overall, this is a really excellent developmnt. The 3d market has been painfully sluggish for a decade now - we've got better bells and whistles but on the whole we still work in 2014 more or less the away we worked in 2004.  We need new companies with fresh ideas to shake up this market.  We also need to embrace web development as a part of how we build tools.  This is a big step in the right direction and we should do what we can to help it along.