Wednesday, April 18, 2012

in defense of the generalist

        A while back (years almost, come to think about it), I made a post on a friend's facebook on why I thought generalist as it related to Tech Art was probably a bad goal to pursue in the long term. I'll admit at the time I was definitely not in the best of headspaces and not at all thinking straight.  I'd also been through a few interesting work stints that had me questioning the value of Tech Art in general, or in other words I was feeling sorry for myself and projecting onto other people, trying to "save" them from a professional fate worse than death.  Or something to that effect.  But as I alluded to in my post the other day and as I remarked (or maybe admitted) to the same individual who i had previously publicly lambasted for being a generalist, if it were not for my own background as a generalist, there's no way I could be doing the job I'm currently attempting to bungle my way through...

As with many things, happiness is found somewhere in between...

        It's true, at every stage of my career I've picked up more skills and honestly, the only reason I ended up where I was doing what I was doing was because I felt it necessary to fill a niche in production.  My first job was actually as a VFX intern, but I did some facial animation, rigging, cinematics, modeling, hell, I even have a sound credit from my first job, of all things.  So I, of all people, definitely appreciate the value of the generalist developer.

        Now, I'm probably not telling anybody anything that they're not already thinking, or more correctly, haven't already realized.  At the same time, I feel like I've been one of the more vocal proponents of the Tech Artist as Tools Programmer, or at least the notion that Tech Artists should specialize in something at some point.  And yet, here I am, finding myself not really specializing in anything, or even more ironically, specializing at being a about taking the red pill.

Just take both of the pills, seriously, the purple pill is f'ing wicked...

        I guess what I'm really saying is not to specialize or generalize, but more like don't pass up an opportunity to learn new things.  One of the most disheartening statements I'd ever heard uttered was something to the effect of "Well, i'm working in Max right now, I don't need to learn python".  Yeah, but you could!  It's not about learning python, or C#, or C++, or Lisp, or MSP, it's about LEARNING.  When I was at Bungie, sure, I was a Maya guy through and through, but that didn't stop me from taking advantage of the fact that I was working with some great C# developers and learning C#, a skill that's serving me really well now.  And once you're comfortable with that new skillset, Apply It!  Take some time and come up with some creative solutions, in the process you'll gain a deeper understanding of said skillset.  I started learning Django just for fun, but in the process, I realized what a great asset management system Django would make, or to be more specific, what a great asset management you could write on top of Django.  Being able to apply technologies in new ways is a great way to keep your interests up, especially if it's technology that already exists and is just waiting to be put to a creative use.  As Grandmaster Harper says "Take What's In Front Of You".

bloodymayhem gregharper_200x20
Tech Art...The Kajukenbo of Game Development

        The industry being what it is, you never know what your job sitch is going to look like in the next few years, heck even in the next year.  The skills you learn now are going to protect you for your entire career.  Who knows?  If it ever comes down to it and you have to jump from content creation, the fact that you used Python to do more than just write Maya scripts may be your saving grace.

        So in the end, expand your horizons, learn all you can, and embrace your generalist self.  I'm definitely not sorry I did, given the dividends it's paying now.

Saturday, April 14, 2012

prototyper's toolbox: pythonic edition

        I had a really good convo with a co-worker today and I realized I miss working in Python just a wee bit.  For prototyping especially, why wouldn't you use Python?   I'm surprised the thought hasn't really hit me until just now, but you know, the fast turnaround provided by working in an interpreted environment is fairly ideal for rapid prototyping, no?

        As much as I like Unity, it's definitely getting to the point where i'm having to do enough custom implementation that it's putting a damper in my relevant iteration time.  Don't get me wrong, i'm enjoying getting to dip my toes into other languages and features (learning P/Invoke has been pretty cool), but i feel like a Python based prototyping environment might get me a little further a little faster.  More often than not, Python modules work in whatever your Python environment is, and I understand that's not a 1-to-1 comparison as Unity is not a pure .NET environment, but still...

        So in my wanderings last night, I dug up a few different tools that seem like things I'll want to be diving into next.  I went to bed super early, so I haven't spent a ton of time with alot of these resources, but enough to feel like these will all be useful in the future.  Once i get done with this current demo cycle, I'm going to get out of Unityland and start writing standalone apps, just to get more practice writing big software projects.  I feel like I'll have more flexibility in a pure python environment and I'll probably get more done faster. Props to my co-worker Chris for inspiring my search...

        Most of these provide the full suite of lower-level functionality you need for prototyping/building media applications (event loop processing, input management, etc), just import whatever else you need alongside them and you're good to go.  Fair warning, some of these are NUI/MT specific, but then, that's really what I'm into these days.  I gotta say it's also made me realize how much of a gadgetwhore I am, but man, I hate spending money on them, which is probably why i don't have one.  That and it also makes me realize how much of a touch interface freak I am.  I can't say I'm huge on gestures, but touch is cool.  I actually found a fairly extensive list of game engines that would probably be make great generic event loop/input/rendering managers too, that's for another blogpost...

android-pythonPython for Android
I'm not 100% sure why i put this here but it seemed like a cool little aside. I only glanced over the docs a bit, so I can't make any recommendations, but I will say it's definitely more of a power tool than a ready to go development resource. More and more i keep finding reasons to want to get that Android device i keep threatening to get, but then i think, ugh, do i really want to spend money on another gadget? "Another", like i own a bunch of them already...

pygame_projects pygame and PyKinect
I lumped both of these together because most of the PyKinect samples run on pygame anyway, altho nothing precludes you from using your event loop manager (heretoforth referred to as ELMs) of choice. While this isn't necessarily MT, if you want to get started with NUI prototyping, this is honestly the way I'd recommend going. The Kinect SDK is super easy to write code against, you'll be doing crazy things in no time.

Alright kids, gather around, and let me tell you a tale of POVRay...yes, I just dated myself horribly, but then, i'm constantly getting told that I'm too old for...certain people anyway, so i guess it is what it is. But really, that's about what we have here, even to the point where VPython lets you export to POVRay renderable files. How cool is that? Also includes its own version of IDLE, but I'm going to have to frown on that...

From what I understand, this is the way to go for Python MT development. I found a few other options (PyMT, etc), but this seems to be the one everyone recommends. If you're an experienced pythonista or have an established development environment, you can skip some of the weird setup requirements and dive right in. Get started now and whip some cool stuff up for their next contest!

No discussion of MT development would be complete without including some TUIO bindings, so here you go! There are a few dependencies you might want to be aware of too (most notably reacTIVision), but once you've get everything down, this is another great way to get up and running with minimal hardware investment and setup. Make your own Reactable, actually, i've just hit on a plan...

Art IDEs
        Sure you could sit in a coffee shop and write a book, but let's be honest, if any chick looks over your shoulder and sees you rockin some cool interactive art in one of these apps, there's an icebreaker. Show her your camera or other input device, get her to play around with it a bit and it's all over except for the part where you embarrass yourself horribly trying to ask her out...Probably better to just get a bunch of buddies together and rock some interactive art jams on your laptops, takes me back to the days of laptop jamming with Live.  Or at least I think it would, i'll know more tomorrow, actually going to a group Processing session of sorts, should be fun. May even be the beginning of my social life...

nodebox_projectsNodebox 2
If you're a Maya or Houdini Tech Artist, or just an ICE freak, this one's for you.  I actually came across Nodebox a while back, but got a sad panda because it was MacOS only, altho I suppose it would have been a good use for my still not very used Macbook Pro. But yeah, this is basically Processing with a hypergraph attached to it, how cool is that? And Python to boot, so it's like Maya, but light and stable...ish.

Shoebot is the best-ish of both worlds in that you can run it from its own IDE or you can import it into existing Python projects. It's also a...well, let's say derivative, for lack of a better term, of Nodebox, so most of the docs you find for one apply to the other. Not to down on the work of the Shoebot guys, it's a "derivative" like pyprocessing or pycessing are derivatives of Processing.

Additional Reading
        A few last little tidbits to keep your head in the MT game, skip this if you're not interested in this sort of thing.

All sorts of really fun musings here, not much of a learning resource, but great for inspiration and keeping up with what all's out there for the MT pythonista...

pymt_projectsGetting Started With MT Dev In Python
Some dated and slightly specific tutorials, but definitely great for a quick dip of your toes into the whole world of Python MT/NUI development.

Part 1 | Part 2 | Part 3 | Part 4

        I've got some pretty cool interactive art projects in the pipe right now, no ETA on any of them yet, but hopefully I'll be able to post some stuff up in the near future.  Got some longer term "milestones", altho I'm not sure milestone is the proper term since they tend to equate to public releases or showings of some sort...Nothing like a little pressure.

Wednesday, April 11, 2012

with trees

        Updated to include Teck's suggestions so it looks less like machine and more like man(god?).  Now we get something that looks like this:


Yes, this looks much better methinks.  Only slight changes, just dropping in new terms really:

Tuesday, April 10, 2012

there is unrest in the forest

        You know, the thing with Unity is not so much the presence or lack thereof features, it's the same issue alot of software has, and that's the lack of not just documentation, but useful, relevant documentation.  I feel like too many companies assume that it's ok to just put out basic documentation for new users and then let the community pick up the slack.  That's alright I suppose, but that doesn't mean you can slack on the basic documentation.  For instance:
function GetHeight (x : int, y : int) : float
Gets the height at a certain point x,y
Really?  A function called GetHeight() that returns a height value?  No Shit?  How about some information about the input parameters?  What is the expected range of values, for instance?  How about the return value, what do the units come back as?  You know, little things, back to that whole idea of useful and relevant, right?  Sheesh.

...Captain Obvious is Obvious, Captain...

        My ire comes from a perfect case, one of today's tasks was to spawn trees on a Terrain based on the heightmap.  All the pieces are there, it's actually quite a simple process, but again, it's just not knowing the little things that results in probably a bit more experimentation than necessary.  Really I'm just whining, but i've run into so many cases of this sort of thing with so many software packages I've used (looking at you, Maya), that at some point you just wanna contract out and document the stuff yourself for them.

        So rant over, if you're interested in doing this sort of thing yourself, here's some code that might be useful:

        Obviously you'd want to add some sort of noise to the tree placement and maybe even add some simple tree variants so it doesn't look like a military haircut, but this code produces a good starting point, something like this:


        You could probably get even more headway by sampling other maps or attributes to add a bit more spottiness to the placement or maybe even do a radial tap per sample step, something like that. Dunno, if you make any useful changes to this, let me know! Otherwise I'm just going to do it myself and...well, i guess that's not that bad.

Friday, April 6, 2012

thoughts with sounds

        Nothing really earthshaking here except whatever you might come up with on your own;)  Haven't blogged in way too long and left some things hanging, which I promise I'll get back to in the near future, just had a real interesting time of late with some slight work randomization in the form of the build machine, but it's been a great project!  I'm actually really intrigues to setup a python tools pipe that uses some form of CI, minus the build step...or maybe plus the build step for custom extensions.  Dunno tho, this is the sort of thing I think i need to do in moderation, hehe, not to slag on past lives or anything, but dipping my toes back into pure pipeline work reminds me that I like not having to do pure pipeline work all the time!  Given some of this new info, I think I'll probably push back part 2 of the Unity/Git tutorial and expand it to being a complete Unity/Git/CI tutorial once I get Unity builds figured out.  Shouldn't be too hard...

        Taking a page from my co-worker Chris, I've started gathering little snippets of media on youtube and vimeo that I can draw inspiration from, I'm realizing I need to shift my focus a bit to really stay up in this game.  It's such a different thing we're trying to do here, ideas need to come from different places.

Taking a bit of advice from this guy...

        One of the more fun videos came by way of another co-worker, which is driving some other stuff I'm thinking about right now, too.  Looking at this sort of thing does really solidify how much I enjoy having tactile components beyond just a touchscreen.  Something to keep thinking about.  Check it out, fun times:

        Hmm...lastly I started playing around with another prototyping framework, trying to find a good sandbox for doing sound driven gfx or gfx driven sound or whatever other combination of those things I can come up with.  I gotta admit I was a little charmed to see it come up in a tk windows, of course my first thought was "aww, i miss IDLE".  But yeah, check out Pure Data, it's a bit sparsely documented, but it's fun.  If you're familiar with patch-"programming", you'll feel right at home here (without having to pay for Max/MSP!).


    Ok just kidding.  Lastly for real, here's some fun generative audio stuff to get you through any boring times you might encounter this weekend.  I wonder what an evolution on this idea of generative music might look like...

Otomata - Try this online!

Tonematrix - This one too!