Character Model Design (drawing)

As a fair warning, I'm a fairly novice art person.  We are doing a very short animation and as such, we designed a story and some characters.

Below is one of the main characters.  First, I did about 6 sketches, which resulted in throwing out the first 5 simply because they didn't look... acceptable.

Anyways, I scanned in the original pencil sketch, but as expected, it was really difficult to see anything, so we went ahead and inked them on paper, then put them up here.

This is, more or less, the design for this character model.

We'll be sending these over to Illustrator next and drawing this young lady in a whole lotta frames and getting her ready for animation in Toon Boom Studio.  If I have time, I'll do a color skit and try out various colors, but due to time constraints on this project, that will be one of the last things I do.

Naturally, she'll start looking more refined (in the cartoony way of course) as I get better at drawing this over and over again.

Line drawing in Illustrator

This took me a while to figure out the "best way" to do... but I eventually stumbled on to this blog:

http://danidraws.com/2007/01/08/creating-line-drawings-in-adobe-illustrator/

Good stuff.

Basically...

1) Take your hand drawn sketch, scan it in
2) Place it on a new Illustrator document
3) Turn it to a template
4) Make a new layer (this will be the inking layer)
5) Use brushes and a drawing tablet to "ink" the lines, don't worry about over-shooting lines
6) Use pen tool to add anchor points where lines intersect and overshoot each other
7) Use direct select tool to delete the overhanging parts

This is very useful because importing vector art in to Toon Boom Studio is how we're doing things on our end.  Drawing in TBS is nice, but really awkward correcting my line art.

Oh, and if you don't know how to import AI files in to TBS, you have to save your Illustrator art as CS2 format otherwise TBS can't read the data.  This information is current as of TBS version 7.1

Storyboarding, scripts, oh my!

Part of my studies in to animation requires the use of storyboards.  It makes sense, how do I know what to make and how to present it... and in what order?

Needless to say, my original "rough draft" outline for a quick story was totally redone after I ended up writing the script for it.  The basic ideas stayed the same, but actually focusing on how cameras move around, zoom, which characters are animated, things fading in and out... yea stuff changed.

I was asked today how my animation is coming along... my answer was "animation is the last thing I'll be doing".

Intro to Animation Endeavors

So, this blog has been mostly about programming, game development, design, smart phone stuff, technical rants, and stuff like this... and has been idle for a little while again.  Well, a small and somewhat crazy offshoot to all of this has been all about visual things that look pretty.  Worse yet, pretty things that move.

I've been learning more about how cartoon animation works and some of the software that powers these pretty cool things.  The adventure led me acquire Toon Boom Studio and take a related class or two at the local community college.  Ideally with the lofty goal of implementing pretty, moving things in our games and heck, maybe even do some of our own animation work!

I found a couple random blogs that really helped me out in addition to the classes.

Of particular note:
http://animationcraft.blogspot.com/2007/04/toon-boom-studio-learning-track.html

This guy is clearly an industry veteran with very helpful articles.

I also came across John K's blog (yea, one of the guys that did Ren And Stimpy back in the day).

http://johnkstuff.blogspot.com/

To get this party started, we had done various assignments for our classes, but with all things, it usually takes a wiping of all your old stuff before you feel somewhat confident enough to actually feel like it is going anywhere.  At any rate...

Here is my *second* ball bouncing animation that turned out pretty decent.

Java obfuscation, ndk, jni, and proguard.

We recently had the pleasure of posting an update to one of our apps - Bubble Zing - on to a couple Android markets.  Everything looked great on the development side and everything was pretty much tested and ready to go, so we exported our apk in Eclipse and sent it out!

Then the problems started trickling in (of course).

This was quite baffling that the same code running in Eclipse was completely breaking when running from an exported/signed APK file.  What was going on here?!  I googled around for various errors and almost all of them talked about missing libraries and such.  Well, none of those things were my issue.

I finally started getting some useful information from logcat about ClassNotFound and being unable to get new instances of *my activity* or various other failures about FindClass failing.

I was pretty stumped by the whole thing, so I ended up opening the APK like a zip file to check out what was actually IN the apk.  Everything looked as it should have been.  All my resources were there, the class path stuff was set as well (really confusing me why all this classnotfound stuff was happening now).  It wasn't until I ran apktool on my apk to get some actual additional information about my java files that I started to trace down the issue.  I noticed that all of my Java classes which were called from my native library were named "a.java" and "b.java", etc.  As opposed to all the normal java files which were not interacting my native shared library were fine.  So, it seems like we narrowed down what sort of thing was happening here.

Ok, somewhere in the export process, I was was losing my actual java names... and with things like fully-qualified names everywhere, I suspect this was a major problem.

So, I found that Proguard was obfuscating away my class names during the export process, meaning once my app was in apk form, calls from native code were completely unable to find half of what it needed to talk to for it to work!

For those interested, I added the following lines to proguard.cfg to inform proguard that I would like to keep most of my stuff unmangled please:


-keep public class [FULLY.QUALIFIED.PACKAGE.NAME].* {
public static *;
public static *;
private static *;
}

For us, only static methods were being called from native code.  We also set *all* of our classes in our package to be saved with the "-keep public class" line.


In retrospect, this totally makes sense, since during the apk packaging process, it realized that at no point were some of my chunks of java code being called by any other java code, so proguard figured it was ok to munge those up in to various cryptic alternate symbols.  I suppose it wasn't proguard's fault, but really my own misunderstanding of how the export process works and what proguard did for you automatically (or why).

I'm glad that was over, lesson learned?!  Always test an APK on my devices BEFORE sending it out to the market, even if we completely ran through all our tests before the export process.