Friday, October 30, 2015
Wednesday, October 28, 2015
Tuesday, October 27, 2015
Last night's Supergirl premier hit every plot point Man of Steel did, except did it as entertainment. First superhero TV show premier that just got to it, she saved a plane before the opening credits were completed. I hope the super secret government laboratory doesn't become the high-tech hall of exposition like in Flash and Arrow. Interesting that DC doesn't mind Supergirl as competition to Gotham. Calista Flockhart should be funny, with the old Lois Lane role, of not being able to see past a pair of glasses.
All the TV I watch is superhero, or angry, sociopathic, black women (Shonda Rhimes), the former being some sort of vindication, I guess.
Monday, October 26, 2015
Sunday, October 25, 2015
Saturday, October 24, 2015
Tuesday, October 20, 2015
Main recurring title wording would be
UNCLE GOGGLE"S TALES BEST READ WITH...
Maybe not 'best read'. Maybe just 'read.'
UNCLE GOGGLE"S TALES READ WITH...
UNCLE GOGGLE"S TALES FOR...
Uncle Goggle's tales of horror
Monday, October 19, 2015
Trying to do some lessons on cartoony animal design...but it's hard to shift gears from the realistic stuff!
Sunday, October 18, 2015
Saturday, October 17, 2015
Text from my Tumblr Post
“While working with a laser saw that demolishes material as it spins, Lab Assistant, Rodney Vapid, blunders into its path and disintegrates. Working feverishly, Dr Blend has Vapor 90 percent reconstituted when the machine explodes, mangling the Dr’s body but giving him Technopathic powers. Vapor and Blend with the artificially intelligent, talking, Sunbeam roadster, fight for right and avenge the wronged.”
Below-Doodles before I had an idea. I was going to make a robot with an octopus for a head.
Here it is enormous. As a file I'm giving to the printer
I wrote him an email reply to one of his solicitation emails- 5 minutes later he told me the name of the brush.
CLEAN AS A WHISTLE is the name.
The art here is just bad doodling. But the line and how it comes out is pure joy.
I'll do something worthwhile with it soon.
Wednesday, October 14, 2015
Tuesday, October 13, 2015
Monday, October 12, 2015
Saturday, October 10, 2015
Thursday, October 08, 2015
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.