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:

http://www.akeric.com/blog/

I hope to see you there!!!

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.

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.

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:

• Remote Debugging in Wing
• Setup Wing to send commands to Maya
• General Wing Goodness

And

• Official Wing docs on remote debugging

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.

GrooveFlakes

I'm a big fan of SomaFM. In particular, their Groove Salad radio station. I'd been wanting to learn how to integrate audio into my Processing sketches via the Minim library. Originally, when I'd started my 'Perlin Particle' sketches (see three previous posts), they were spun out of the idea of making falling snowflakes. I wanted to have the snowflakes to "move" through the air with some randomness, and that's where the Perlin noise fit in. Once I solved that, I was able to move back to my snowflakes, and in particular, audio processing.

I got my "GrooveFlakes" sketch up and running. It streams in the GrooveSalad playlist, and samples the beats. When the kick, snare, or hat hits, the flakes will "pulse" to the music.
You can get the source, over on my Processing Wiki HERE. I still don't have a web site where I can upload the actual app yet... (lazy... maybe next year...).

Image Particle Path 01

Adblock

imageParticlePath_movie1
Originally uploaded by warpcat

This code is modification of my Perlin Particle 02 sketch.
In perlinParticle02, it would generate three random images based on Perlin noise,and those three images would control the x, y, and speed of the particles. This version, doesn't use Perlin noise at all, but an image placed in the sketch folder.
When a particle is born, it grabs the color of the underlying image, then travels based on the RGB image data.
The first 10 seconds of the movie show the particle motion, and the last 10 seconds show the particle motion plus the source image (of my wonderful, and tolerant wife)
Source code can be found on my Processing Wiki HERE.
Other Processing imagery\videos on Flickr

Perlin Particle 03

Adblock

perlinParticle03_movie01
Originally uploaded by warpcat

An update to my Perlin Particle 02 code: Now, rather than generating three buffer images for the x, y, and speed Perlin values, it calculates them on the fly. This has the added advantage of being able to animate time, which you can see in the above movie. However, it's also exponentially slower. This movie took about a second a frame, or ten minutes on my 5 year old laptop.
Find source code on my Processing Wiki HERE.
My other Processing imagery\video on Flickr