Tuesday, February 17, 2009

The end is here...

Blogger experiment complete! This should be my last post on this site. Please, for all your future needs, see my new blog:


I hope to see you there!!!

Thursday, February 12, 2009

Changes are coming...

I finally bit the bullet last night and got a fully registered domain through Bluehost. This blog was my first "experiment"at blogging, to see what it was like. My main frustrations with blogging sites like Blogger is that you can't (or maybe I just don't know how, quite possible) add in our own applications like say, a Processing sketch. Obviously, with my own domain, this should be cake. Plus I can start uploading imagery and movies without having to host them through some site like Flickr or Youtube.

I've decided to go with WordPress as my blogging software of choice, and just picked up WordPress For Dummies (2nd edition) to help me along. So at some point in the near future this blog will be rolled into that one if all goes as planned.

Time to expand my brain.

Monday, February 9, 2009

Python and XML

AH..... XML. We store the shading data for out game assets as xml files, via the Collada schema. It's prettymuch a custom, in-house implementation of what Collada has to offer. In the past I've had to read data from these files, but rarely did I have to edit them via code. I'd written a variety of mel scripts to suck info out, but recently I've been required to edit them as well. Python to the rescue, right?

Weeeellll, sort of. Python seems to have many different methods to interact with xml: xml.dom, xml.dom.minidom, xml.sax, etc. I started out with minidom (the "mini" part lulling me into a false sense of security), but it was nothing but pain. I'm new to this, and no expert, but it seemed like a pile of extra code required to do the simplest things. And, when I'd save an xml file, it'd mangle the formatting: Technically it'd still be a valid xml file, but it would start to put element\tag data on the wrong lines, reducing its human readability. I started querying many differnt development communities, and either no one could really explain what was going on, or didn't understand it.

Enter xml.etree.ElementTree. SO much easier to use than minidom.. much less code, and it just makes more sense. But even it had a similar formatting problem to minidom. It just didn't make any sense.

Finally, I got some feedback: Apparently, those modules will treat the "return\tab\whitespace" chars in the xml files as pseudo-secretive xml 'text' nodes. If you add a new element, you need to jump through a bunch of hoops in relation to these mysterious\hidden text nodes, so when you print\write to your xml, it looks correct. I still can't believe this is the default behavior of those modules.

What it boiled down to was this: If you make a new xml from scratch using minidom or ElementTree, the formatting will be a-ok. But if you edit a pre-existing xml, adding new elements, it you're not careful, you can mangle the formatting.

I documented the whole technical mess over on my Python Wiki, with source code examples for the solution.

Friday, February 6, 2009

Remote debugging Python from Wing to Maya

Ever since Maya 2008 enabled Python scripting, I've been trying to do as much scripting in Python as possible. But, I grew up with Maya's scripting language Mel, and Maya's built-in IDE, the 'Script Editor'. The script editor leaves a lot to be desired, but one thing it has that I love is "evaluate selection": You highlight some code, hit Enter, and the code is executed: You don't have to create a whole new script with just that code and execute it, etc (which seems to be standard practice in other IDE's). When I picked up Python, I had a terrible time finding any Python IDE that had 'evaluate selection'. But then I found Wing, and fell in love.

Even though I may have a pretty firm grasp on Mel scripting, I was still a programming noob: I've never had any formal 'programming' training (for example, I didn't know anything about OOP, since Mel simply doesn't support it), and never worked with a debugger, or an advanced IDE. Wing has been a great learning experience for me, teaching me these fundamentals (along with a lot of help from my compatriots as well).

I started out by authoring plugins in Wing that would let it send it's 'evaluated selection' Python code to Maya, letting me bypass Maya's script editor entirely: Code in Wing -> execute in Maya. But soon I had modules written in Python that relied on a currently open Maya scene file. I learned how to import 'maya.standalone' in Wing, giving me a physical Maya session in Wing. This let me physically open Maya files in Wing, and run Python code on them, which was pretty cool. But Wing's debugger seemed to have an issue with this: I and others believe this is a function of Maya's poor Python implementation (and I'm still trying to figure out why it doesn't work). Open Maya file in Wing, and execute modules on that file = success. Try to debug those modules on the open Maya file = fail. Now what?

A buddy of mine turned me on to remote debugging: From Maya you can open a scene file, launch your Python code (in the script editor), and with Wing open and 'listening', Wing can actually debug the code executed externally in Maya on the fly. This is really powerful, and making my life much easier to troubleshoot broken code. Too bad it only works for Python, and not Mel too :-P

I've setup some notes on my mel wiki covering this stuff:
If you do any type of scripting in Maya, and especially Python scripting, I'd recomend you taking a look at this. FYI, Wing comes in 3 flavors, and you'll need the "Professional" one to get this stuff working.