Hisssssssss! Slithering around rocks in Python...

Its been a week of teaching basic 101 programming in Python, and I must say that I'm getting a real taste for Python as a language for scripting.  Having experience in many different languages over the last 30 years, Python takes me back to my early BASIC days of the 80's, where as kids, we'd learn to program by writing our own games, something that was common back when off-the-shelf software wasn't as prevalent as it is today.  In fact, this home computing phenomenon was what built the foundations of the gaming industry in the United Kingdom.  And some software stores here in New Zealand would offer to sell games and pay royalties - something completely unseen these days...  But I digress...

Python's syntax is simple and easy to understand, and when they said its designed to produce readable code, they weren't kidding.  This made teaching programming for me a piece of cake.  Of course, the hardest part of teaching such a subject to our future 3D artists who are excited to produce animation, models and render can be tricky.

Everything around us is a challenge looking for a solution

That leads me to something in regards to this...  Other than programming, one of the things that I most enjoy about working with CG is that it is indeed all about being able to problem solve to find work-arounds, or ways to "cheat" to produce a shot or effect (or solution to a tool limitation, a rig problem, and the list goes on and on).  So the logical process that goes into problem solving is not just a skill for programming.

But programming is something that creative artists are not all "wired" for.  While it looks technical,
programming is really about executing a list of logical steps - In fact everybody does it in their day-to-day life, stringing logical steps together to perform a task:

1. Withdraw cash from ATM
2. then go to the store
3. and purchase a lottery ticket
4. go home
5. check ticket
6. If we win $1,000,000 - live happily ever after 
7. otherwise try again next week

But of course, life makes "sense" to everybody as its something tangible and physical - in fact we've done it all our lives, so its also subconsciously processed.  That analogy doesn't always work when it comes to looking at steps to solve computer related tasks.  Its like mathematics - solving a trig equation isn't the same as balancing your cheque book.  Which reminds me...

Only maths guru's can operate 8-bit computer's...

In the 1980's, I wasn't great at maths at all - and according to my teachers, if you didn't know maths then you couldn't operate a computer.  That meant no access to the school computers (at the time, the popular Apple][ ).  Of course, that was a fairly small minded look at computers in schools back in the 80's - after buying my own computer from a years worth of newspaper deliveries - a Sinclair ZX81 with 1kb of RAM - suddenly that perception changed , and from that my life had changed for the better! :)

Creative brains

So what can I do to approach this in a different way and cater to the creative side of non-coders?  Here's two approaches that I felt helped solidify things just a tad for a few... 

 

We look at the problem visually by breaking it down with sketches and notes

 

The sketch approach works by drawing up the solution as a bunch of "if we move this, then this..." notes.  The exercise I went through over two days was based on a suggestion from one of my students who was developing a game along with others in class.  How could we produce a simple rock generator to make assets for their game engine?

Admittedly, when I started out on this exercise, I went for the "heres how we code this" approach - but that was starting to throw some of the students off, and we ended the first day by producing a "pebble" maker instead - a spherical shaped mass where we flattened the base of the model.  Some students were lost - so my plan for delivery in the next class had to change.

On the second day, I wanted to take that simple starting model and look at how we can push and pull the vertices about to turn our "pebble" into a shaped rock.  This time around, I approached it more visually and stepped away from the computer and across to a whiteboard.  Using a quick image, we looked at what would make a rock look like a rock.  The general idea was to raise and lower random vertices on the top of the model to produce a lumpy shape.  To make sure it looked less like a lumpy sphere, we would also need to push and pull it horizontally to deform it as seen from the top.

 

 

We explain the process in "normal" human language through pseudo-code

A little pseudo-code to explain the process in words helped (and hand-writing it on a whiteboard, rather then typing it up on screen I found makes it much more accessible) and then time to discover the appropriate Maya functions and methods required to do this were put into practise.  The result - hopefully a relatively nice simple rock generator!

The first thing that came to mind was just randomly selecting a collection of vertices over the model and shifting them up and down...  The issue here?  Spikey rocks just don't look like rocks!  So...

Instead, a better idea was to use Maya's soft select and then move vertices to get a softer area of deformation.  Vertices above the ground would be moved up and down.  Using vertices that ran around the bottom edge (at Y = 0) would be moved horizontally to deform the shape from above.

The final product

For anybody interested, I've attached the source code below - I've commented it heavily, and it should  hopefully make sense.  Be aware that it could be polished a lot, and that this was designed as a very simple introduction to making some kind of tool in Python for Maya for students who are new to basic programming...

DOWNLOAD MAYA ROCKMAKER SCRIPT (PYTHON)

I hope it helps those new to programming in python for Maya by showing how such a tool can be created quickly and easily.  In fact, the hardest part was simply finding the right Maya functions and methods to call.

Enjoy!