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

Perlin Particle 02

Adblock

perlinParticle02_movie04
Originally uploaded by warpcat

It's been a while since I've been in Processing, but it's good to be back. Lately, most of my time has been taken up learning the Harmonica ;)

I started out trying to make a particle system to render snow falling. And I actually had pretty good results (post on that later). But in the process I wanted to add a bit of "randomness" to the snowflakes, so I started investigating Perlin noise.

In this linked movie, you can see the background cycle through the different noise maps:

• The first background (in color), is the combined map, which is the 'x-map' in the red channel, the 'y-map' in the green channel, and the 'z-map' (speed) in the blue channel.
• The second background is the "x-map": Lighter values move particle the the right, darker values move particle to the left.
• The third background is the "y-map": Lighter values move the particles up, and darker values move the particles down.
• The fourth background is the 'speed map' Lighter values speed the particles up, darker values slow the particues down.
• The fifth background is... no background at all.
• And finally, it loops back to the first background.

When the sketch starts, it generates the x, y, & z maps (each based on random Perlin noise) and saves them to an off-screen buffer. Then as the sketch runs, the particle queries its position on each map, and modifies its position based on the above rules.

If I get a chance to advance the code, I'm going to try to have it calculate the noise on the fly (rather than pre-generating it and saving it as multiple maps) allowing me to animate the noise over time, giving it an even more varied look.

Find source code on my Processing Wiki
Find three other movies on Flickr

Learning Harmonica...

My grandfather could play the harmonica. And the accordion. In fact, I have his instruments, although they are in a bit of disrepair. I used to play harmonica with my old roomates back in LA, in the mid-90's. But that faded over time. Decided to finally get back into it.

Other than picking up a nice Lee Oscar Major Diatonic in the key of C, I found a swell instructional book that has both a CD, and a DVD. The DVD is great, since it visually shows the holes being played as the music is going on.

I personally like the concept of the harmonica being that it's such a small insturment: Easy to take with you, fun to play, and enjoyable to play with others. Only problem is it cuts into my other project time...

Progressive Beginner Harmonica @ www.learnToPlayMusic.com

Processing 1.0 released!

http://processing.org/
Not that I've had a chance to use it yet, but 1.0 is finally out. I'm looking forward to see why this one finally got the "1.0" badge :)

Processing Monsters

Picture 1.png
Originally uploaded by mb09

Ran across some of this stuff in Flickr, which took me to the main site:
http://rmx.cz/monsters/
Cool simple interaction in Processing with "monsters". Source code available, good resource.

Bad curves

The animation lead on my team started cursing this morning. When I went over to his cube, he showed me these animation curves in Maya's Graph Editor. This was an animation he was asked to "fix"...

The horror....

"A tiny plastic box! I must put my head in it!"

The original post is over here.
But I just had to host this video. The funniest part is, by the end the cat seems to be totally fine with its situation.

Dead Space is live!

As of yesterday, Dead Space, the last product I worked on, has gone out on the shelves. It's getting great reviews!
http://deadspace.ea.com/
As of right now on Metacritic, it's getting a 90 on PS3, and 89 on Xbox 360. The PC version should be out on the 21st I believe. It's currently the 8th highest ranked PS3 game of all time on Metacritic, not bad!
There's a new trailer on the main site link above. Gives is a "movie trailer" feel.

If you're wondering, my roll on the game was "Technical Character Director". I created and\or supervised the creation of the overall technical character pipeline from art to engine: Character\creature\weapon\prop rigging, skinning, building, export, and a lot of animation tools. Basically, if you see it move in-game, I had some part in it.

Edge detection in Processing, take 2.

A few new things: There is a base set of circles called "planets" that bounce around, getting smaller towards the top of the screen, and larger towards the bottom. They emit gravity on the "orbits", which are fixed sized circles bouncing around the screen. The planets try to pull the orbits to them if within range: the smaller the planets get, the less gravity they have. The orbits are also rendered to an off-screen buffer where a glow is created, then the buffer is reapplied back to the final image.

Adblock

ballExperiment02
Originally uploaded by warpcat

ILoveSketch

http://www.dgp.toronto.edu/~shbae/ilovesketch.htm
Wow. I really want to try.
ILoveSketch from Seok-Hyung Bae on Vimeo.

Python 2.6 released

Ye-ha. See the goodness here:
http://python.org/download/releases/2.6/

Edge detection in Processing.

Adblock

ballEdgeDetect01
Originally uploaded by warpcat

After a few month hiatus (darn that Python), I thought I'd get back into Processing. Taking an old sketch, I wanted to try a few things: Simple motion in a confined space, and edge detection of colliding volumes. I solved the issue of edge detection by code found in "Processing - A Programming Handbook for Visual Designers and Artists" (by Casey Reas and Ben Fry, good book) dealing with 'convolution'. If you're interested in that convolution code, you can find it here (Unit 40 (Image 5), example 12) . My first crack at it, but it pulled off the effect I wanted perfectly. However, this only gave a very thin edge as a result. I wanted the edge larger. To pull this off, I ran a blur filter, then a threshold filter to blast out the blur to pure white and black, then another blur on top of that. The sketch got pretty slow, about 1 fps on my older laptop. For the motion, the circles get smaller as they move to the left of the image, and larger as they move to the right. Some circles are solid, while others have the opposite fill, givng them a donut effect, and I think providing a more interesting look overall as opposing values collide.

I was going to post the source for this, but my Processing Wiki currently isn't letting me update it... frustrating.

Dots in procs?

I've pretty-much made the switch from mel (Maya's scripting language) to Python. And what I describe below is standard in Python (implemented differently, but similar visually). But I just recently learned that you can include dots (periods) '.' in mel procedure names. While this doesn't in any way change their behavior, it does let you organize your procs in a more intelligent way based on their names.

Background: In Maya, if you have a global procedure in a mel script, and the global proc and the script share the same name, when you call to the name (via some other proc\script), Maya will search in its 'script path' for the script with the name, then search in that script for the global proc with that name, and (if it finds it) execute the proc. Furthermore, any other global procs in that script are now sourced and can be executed outside of the script by other procedures. Nothing new here. The 'dot in name' convention though lets you associate the script name with the other global procs in the script. When calling them in other procedures/scripts, you'll have a visual reminder of where they came from via their name. To explain this a bit better, an example:

// foo.mel

global proc foo.boo()
{
print "doing .boo() work\n";
}

global proc foo.shoe()
{
print "doing .shoe() work\n";
}

global proc foo()
{
print "foo.mel -- I do nothing.\n";
print "My global procedures:\n";
print "\t.boo()\n";
print "\t.shoe()\n";
}

The above code resides in 'foo.mel'. Inside, there is a global proc called 'foo()', that doesn't really do anything other than print some info. But its there so when the user calls to 'foo()', the other global proces will become sourced. There are other global procs in the script that do the actual work. When you execute 'foo()', the other global procs 'foo.boo()' and 'foo.shoe()' are sourced, and can be called to inside of that script, or other scripts\procs. If you're calling to them inside that script, it's fairly obvious where they're coming from. But say you have some other script called 'goo.mel':

// goo.mel

// Execute foo(), making its other global
// procs available in this script.
// Could have optionally executed 'source foo;'
foo;

// Execute foo's global procs:
foo.boo();
foo.shoe();

'goo.mel' executes (or optionally sources) 'foo.mel', thus giving 'goo.mel' access to 'foo.mel's' global procs, and then can call to each of them. By having 'foo.' in front of each proc, it's plainly clear to the user where they originally came from, which is a great aid in troubleshooting. This is a simple example, but imagine if you have goo executing procs from foo, moo, hoo, doo, etc, and you can see where this can come in handy.

So again, the 'dot in proc' is by no means required, but it's another tool in your organizational toolkit.

Dead Space on Metacritic

The last game I worked on, Dead Space, isn't out until Oct 14th, but it already has its first review up on Metacritic. 91! Very Nice. I've played through the game, and it's one of the first games in a long time that I worked on that I actually enjoyed playing though.