I mentioned in the comments to one of Tom's posts a few weeks ago I've been trying to transmogrify myself into a technical artist -- i.e. one of the guys on a production team artists go to for help with tool deficiencies, automation or to help translate artist-speak to engineer-ese and vice versa. Part of that has been to learn Python and, particularly, PyMEL: the Maya-specific melding of Python with Maya Embedded Language (MEL). It's been a challenging, often-frustrating, but ultimately rewarding experience thus far. I'm heads-down in a lot of books that do their best to make the abstract tangible and the complicated simple. I started learning Python last year and I guess I would say I was a baby in the world of programming then. Now, I'm kind of a toddler looking forward to preschool (not yet ready for kindergarten, I think).
One angle to help me learn has been to take tools written by other techincal artist types and put them through their paces. You'd be surprised what's out there and what has been done with them. I came across the website of Matthew Breit a few years ago. He's a professional game artist who has made several community-celebrated Quake III maps as side projects. One of his maps is a cubist dream set in the sky. While it's a beautiful map in its own right (and fun to play, too), it's also a testament to leveraging technical know-how inside an ancient (in terms of game technology) engine. The Quake III engine (or idTech 3) is 16 years old and certainly not cutting edge. But Breit was able to squeeze out an amazing looking map by using Python inside Maya to supplement Radiant, the spartan toolset used to make levels for Quake. You can read about his design theory here and the technical postmortem here.
Breit released his workhorse script, CubeSpew.py, to the public after he was done with the map for anyone interested in how it worked or who wanted to learn. Curious, I downloaded the script and thought I'd give it a spin to see what I could produce. Breit freely admits the script is presented as-is, with no GUI or documentation other than the comments in the code. I contacted him directly through email a couple of times and he's been nice enough to answer questions, although it's been three years since he's touched the script and has moved on to other things. I only hit him up for bread-crumb clues whenever I was completely and utterly stumped. His answers were not of the 'here's how it works' variety, but were helpful and offered insights into the various functions and methods, which gave me something to chew on as I tried to reverse engineer the methodology.
I've persevered and been able to figure most of it out - but it has been a mind-bending butt-kicker. The script itself is quite organically complex (Breit said it just evolved over the years). It's some 1200 lines of code and not all of it is about building little cubes (although that is the bulk of it). The script evaluates an imported Quake brush (the basic building element of a Quake level) and generates little instanced cuboids of random size on the surface of the brush. Each instanced cuboid is a chunk held in memory inside Maya. You have to manually 'dimensionalize' that chunk (and all subsequent chunks) as a Maya 'polyCube' that can be digested back into a Quake brush when you export your work back to Radiant for an eventual playable Quake build. Each cuboid-turned-polyCube will be flush to whatever side/surface of the larger block you specify as reference. The little cuboids are randomized, yet all fit together like Tetris-pieces on the surface.
When creating the cuboid with the Python script, the instance that is created also stores texture alignment data which can be filtered via command line. The resultant output is five coordinate values you input into Radiant's texture alignment tool if you want to mimic the kind of precise UV alignment you would get using Maya's UV editor. That's only necessary if you are trying to get better edge definition with Quake III's shader system. This is all very Quake-and-Radiant-specific workflow stuff. You probably wouldn't do the texture alignment this way in another engine. You're kind of forced to do it this way with Quake III as it doesn't treat brushes the same way Maya handles polygonal meshes.
Parts of the script are for importing/export brushes from Radiant, and I had to figure out how that works. Parts of the script generate the coordinates for surface texture alignment inside Radiant - had to also figure out how that works. My initial discovery was that I had to fall back to an older version of Maya. Maya 2016 uses a different version of Python which breaks the math in the script. Luckily, I have Maya 2012 and the script runs there, so that's what I've been using.
So...I don't really have any sweet screenshots or anything to show (yet) but I'll post one that shows that I can now spew cubes with the best of them:
This has been a very rewarding (and often frustrating) experience. It really forced me to dig in and think. Ultimately, I feel I did learn a LOT - and I'm still learning. And now I have a greater appreciation for more advanced and user-friendly tools like Unreal 4 and Unity that are more powerful and have easier workflows.
13 comments:
Excellent work Ronnie. Great choice to make yourself a programmer of anything. That method sounds like a genius way to make the learning stick. When I first knew you through email it was as a guy that was doing his own Quake character mods.
Thanks, Ellis. I'm having a good enough time learning this stuff. Very satisfying when it starts to 'click' and you get something to run. Feels magical at times.
Hey Ronnie! Great to hear from you about your latest endeavors. Yeah, I played around with Mel years ago when Maya first started to take over the industry, but I never got very far into it. Sounds like you are way beyond the beginner's stage, and like Ellis said, it's a smart move re-gearing your career to one as a technical artist. Once you're in, it should guarantee that there will always be plenty of work for you. Are you currently seeking a position or are you holding off until you complete your self-training? (Not that your training will ever be really finished in such a steadily advancing field!)
That's great, Ronnie! Have you checked out the CG Circuit site...? They have lots of good tutorials on that sort of thing. I think me n' Ellis's pal Carlo just finished some Python-y instructional videos. Take a look and see if there's anything of interest, maybe I can work a deal for you.
They are very hi-quality instructional videos. CG Circuit--seriously, check it out! You might find it really useful!
Tom - I am maybe not the best judge of whether I'm really ready to seek a position as a technical artist just yet. Personally, I still think I have a ways to go, but I have surprised myself by actually solving real problems, writing some real code. But I'm not at a level where I could be hired to do hard-core, write-from-scratch code. I can sort of scrape by, but I have to bang my head a lot to get anywhere. This cube thing has taken me the better part of three weeks to absorb and apply. I think a guy who has the chops might struggle on the really hard stuff, but would probably find the things that frustrate me laughable because those things are likely so elementary. I'm determined, though, to not stay a novice. I think it's not giving up that's key here (as it is with just about any skill, in my opinion).
Marty - I'm definitely down for more training. I have some spectacularly good books right now, but I don't think you can know too much. I will give CG Circuit a look and if I can spare the shekels, I'd love to have more arrows in the quiver.
You know, now that I think of it, you might want to reach out to some tech artists who are already working and see just how much knowledge they have to do their job. You might be surprised by how far you have come and how ready you are already. If you like, I can see if I can put you in touch with some folks I know.
Good idea Rick. My guess is that the knowledge required for a given job is very company specific. That's the way it was when I was doing particles and special effects for SOE. In fact, it was team specific. I had to learn two or three different systems depending on which project I was creating effects for.
That means that sometimes the most an employer can expect when hiring a tech artist is that the candidate is broadly "tech-wise" enough to be able to learn the company's proprietary software through on-the-job training.
In fact you might want to learn some particle-engine technology in case a job like that comes up somewhere. "One more arrow in the quiver," as you say Ronnie.
Rick - I'd love to talk to your contacts. I had lunch with a friend a few months ago who is over at 343 and is a technical artist on the Halo team and I've also contacted another friend who is now at Blizzard. They've given me good advice, helped me get the lay of the land a bit. I'd love to hear what your contacts say.
Tom - I agree that FX is a good area on which to focus. I've toyed around with a few particle tools in the past. One program I've spent just a smidgen of time learning is Houdini, which seems to be Maya and PyMEL taken to a completely radically awesome level. Most of the big splashy effects you see in movies and games are made with Houdini, but you can also use it do other things like build procedural models, intelligently and quickly fracture models, etc. It's on my to-do list to learn.
Unity has a decent particle engine. In my last job we bought some FX from the Unity Store and I was able to reverse engineer some of the stuff in there. It was useful to see how some other FX had been created.
I'll look into some of my contacts and get back to you. What email address shall I give them?
Rick - My gmail address would be best. Thank you. Shuriken, Unity's native particle engine is pretty good (certainly gets the job done), but I think Cascade, Unreal's native particle system is the more powerful and sophisticated. I bought Particle Playground from the Unity store. It's a tool that extends Shuriken's capabilities and is fairly easy to use. Also, I have contacts with the PopcornFX guys, who have an amazing bit of tech that plays well with both Unity and Unreal. And I have a friend who was an FX artist at SOE on the Agency and who is working on the Call of Duty franchise now. I can hit him up, too.
I would highly recommend Tech-Art.org, I haven't been doing tech art in a while but most of the TA's and the Lead TA's and TAD's in the industry where there. TA's are great about helping each other out. In fact many start out just like you're doing, self taught and learning a great deal by what others have done. So if you hit a road block the forums should be really helpful.
My best unsolicited advise is to take small production problems and write one off scripts that address the issue.
If you can get a couple under your belt you're 90% there, since in reality that's the bulk of the work for most TA's at studios. Many scripts are short and sweet but really smooth out the kinks Artist deal with day in and day out.
Joe. Thanks for the comment. Sorry if it went unnoticed very long. I guess the thread is only a day or so old.
Thanks, Joe. Really appreciate the advice!
Post a Comment