Monthly Archives: August 2011

PAX 2011 Redux

This year, I was fortunate enough to inherit a 3-day pass to PAX Prime 2011, courtesy of my long time friend and compatriot, Nick Hernandez.

Even though I’ve seen the various PAX episodes on PAtv, but nothing prepared me for the sheer magnitude of the expo.

To give you an example of what I’m talking about, here is a picture of the demo area for the game Prototype 2.  You can see, they didn’t just put up a projector to demo stuff… they built an entire helicopter prop with sounds… and this was on the tame side as far as booths go.

Probably the most extreme example of commercial promotion of a francise was Halo Fest.  Basically, it was a mini convention …. within a convention!  There were complex dioramas.. scale vehicles like this Warthog.. and TONS of space dedicated do game play.

This isn’t to say that PAX is not just some orgy of AAA title marketing… there are a LOT of for-the-community things… like the Classic Console Freeplay.  Ever want to play an original NES game but couldn’t afford it as a kid?  This is the place for you.

All in all, my PAX experience was awesome.  I am totally going back next year. Period.

A Case for Mars

About 3 weeks ago, I wrote a post about Robert Zubrin‘s book Entering Space.  My full review (although admittedly kinda terse) went up today on the I Smell Sheep review blog.  It was a pretty good read… and added a lot of insight into what the history/mythology of the Project: Mars setting.

Even though, this book was written *AFTER* the book I’m currently reading… I am glad that I picked up the books in the order that I did.  A Case for Mars is a far more in depth (not to mention thicker) book than Entering Space and it concentrates heavily on the early settlement of the Red Planet.

One of the most interesting bits that I hadn’t considered as far as my podcast concept goes… is, Mars is likely to be over 100 years into a terraforming process.

In a LOT of science fiction, we constantly hear about terraforming being a process that takes centuries.  According to this book, a huge chunk of the process of converting Mars into something habitable by Earth life could take place in as little as 50 years.  By the time of the podcast, Mars’s atmosphere will be about the same as Earth’s as far as temperature and pressure go; though still unbreathable to humans. (We’ll have to walk around with breathing aparati).  That’s pretty amazing…  No need for pressure suits… that’s HUGE.

Once I’m done with this reading, I’ve got to look over some of the most recent findings about the planet… specifically around underground water.  A location near or on top of a large underground water table will be the best spot for a settlement… and once I have a location, well… then the fun begins :)


Eureka! Strange pose behavior solved!

A while back, I had posted about a strange rigging behavior that I was seeing.  I’m not sure that the description that I was terribly useful… so I decided to make a couple animated gifs to help with the visuals…

Here you see what a proper rigging is supposed to look like.  The block rotates with the rotation of the “Bone”. Now, The following image illustrates what I was looking at…

You can see here, the cube is actually moving faster than the rotation of the bone.  The exaggerated motion caused all kinds of stuff to get out of alignment.

The way you associate the Armature or Skeleton to an object is you set the Armature as the “Parent” of the object.  In this case, the object is the cube.  You do this by simply selecting the cube, then the Armature and hitting CTRL-P (You can also parent by going through the menus).

When I created the simplified case of the single bone and a single cube, it worked just fine.  On a hunch, I decided to un-parent then re-parent the object and armature… and voiala! the problem was reproduced.   It turns out that in Blender 2.5, you’re not actually “parenting” you’re setting a modifier on the object… so clearing the object’s parent does NOT clear its relationship with the armature.  When you then re-parent the two, you create a SECOND modifier between the object and the armature, so any changes to the armature are magnified 2x… which is the behavior you see in the 2nd image.

Okay. Well, this is all well and dandy, but if you can’t un-parent, how do you get rid of the armature to object relationship?  It ends up in the object modifiers tab.  Here’s what it looks like if you’ve got an Armature associated multiple times with an object…So… all you really have to do at this point is figure out which of the two modifiers you want and X the other one(s).

In the situation with my aperture, I had created 3 modifiers.. so the pose was affecting the object three times as fast.


Structured Audio C Major Scale

I’m continuing to experiment with MP4-SA.  This time around I have a bit more refined infrastructure built.  The major trouble that I had with my previous audio file, It needed to be refined from the raw .wav generated by sfront.

My end goal was to have a process by which I could write instruments and score files and in a single command produce a properly ID3 annotated mp3 file that I could then use to play via the WordPress Audio Player.

Using macports, I was able to quickly install Blade’s MP3 Encoder, and id3tool.

Once all of these packages were installed, I wrote a simple template bash script that takes all of these disparate pieces and forms voltron.

The result is the following, very modest, audio file rendering a simple C Major scale…

Audio clip: Adobe Flash Player (version 9 or above) is required to play this audio clip. Download the latest version here. You also need to have JavaScript enabled in your browser.

Yeah it’s still rough… I’m not entirely sure what the popping sounds are after each note.  It probably has to do with the signal being cut off abruptly… That’s something I’ll have to work out in the instrument file itself…

Ok. Well, what does a C Scale look like in MP4-SA?

0.00  @INSTRUMENT@ 0.40 261.626 0.8
0.50  @INSTRUMENT@ 0.40 293.665 0.8
1.00  @INSTRUMENT@ 0.40 329.628 0.8
1.50  @INSTRUMENT@ 0.40 349.228 0.8
2.00  @INSTRUMENT@ 0.40 391.995 0.8
2.50  @INSTRUMENT@ 0.40 440.000 0.8
3.00  @INSTRUMENT@ 0.40 493.883 0.8
3.50  @INSTRUMENT@ 0.40 523.251 0.8
4.50 end

The strange @INSTRUMENT@ markup is part of my tool chaining.  Prior to running the sfront program on this file, my shell script replaces all occurrences of @INSTRUMENT@ with the actual instrument being played… in this case it was a sine wave.  The first number after the instrument turns out to be duration of tone.  In my last post I had mistaken this field to be stop time.  The 2nd value is frequency.  This has also changed from my first attempt… instead of a fairly arbitrary decimal value, this is an actual measure of frequency in Hertz.  Finally we have amplitude which pretty much changed the same…

To facilitate the changes in what the parameters mean, I also changed the basic sine instrument that I wrote.  Here is the new, improved sine

instr sine(f, a) {
   asig x, y, init, arate;
   if (init == 0) {
      init = 1;
      x = 0.0;
      arate= f * 3.14159 * 2 / 32000;
   x = x + arate;
   y = sin(x);
   output(y * a);

You can see here, that I’m actually using a for real sine function now. The arate variable computes the x value of sine based on the sample rate of the composition, in this case 32000.  In reality, this should be a global variable of some kind but I could not seem to get that to work.

One thing I will probably do in the future is change the frequency numbers of each note to be aliases, much like the @INSTRUMENT@.  This will make it easier to score more complex songs.  I should also do that for note duration.

Messing with Structured Audio

It’s time to seriously consider what Seña will sound like. To accomplish that, I’ve started messing with structured audio.  What does that mean?

It seems that part of the MP4 standard includes a section involving programmatically generated sound.  Basically, making synthetic sounds with programming.  It’s visually pretty drab, but if you’re into coding like I am… it’s pretty cool.

The audio programming language takes 2 major components, a SAOL file, and a SASL file.  The SAOL file is where you define your “instruments” and the SASL is where you sequence your instruments playing notes…

I made a test SASL and SAOL based on the example scripts they provided.

instr sine_tone(f, a) {
    asig x, y, init;

    if (init == 0) {
        init = 1;
        x = 0.5;

    x = x - f * y;
    y = y + f * x;

    output(y * a);

Here I added two parameters, f and a. This allowed me to control the frequency and amplitude of the approximated sine wave created by the x= and y= expressions.

To actually play the instrument, I made a SASL file:

0.25 sine_tone 0.50 0.196307 0.10
0.50 sine_tone 0.75 0.296307 0.10
0.75 sine_tone 1.00 0.396307 0.10
1.25 sine_tone 1.50 0.196307 0.20
1.50 sine_tone 1.75 0.296307 0.20
1.75 sine_tone 2.00 0.396307 0.20
2.25 sine_tone 2.50 0.196307 0.35
2.50 sine_tone 2.75 0.296307 0.35
2.75 sine_tone 3.00 0.396307 0.35
3.25 end

Here you see I invoked my “sine_tone” instrument with various parameters. The leading number and first parameter represent start and end times in seconds. The last two parameters map to the f and a variables of my instrument.

I wasn’t able to get the audio player plugin to work properly with the resulting .wav file nor was I able to get it to play with an itunes converted m4a…

UPDATE: I managed to get a proper mp3 toolchain going. I might describe that in more detail on Thursday. For now, here is a proper flash audio player

Audio clip: Adobe Flash Player (version 9 or above) is required to play this audio clip. Download the latest version here. You also need to have JavaScript enabled in your browser.

Seña Wireframe

She’s still untextured, and not all of the mesh is there… but we’ve got a good, healthy start!

Like most designs, as the pieces come together, I’m sure changes will need to be made.  The overall curvature of the front will be one alteration that I need to make.  This particular change is necessary for the eye to rotate through its frame properly.   Another change that I want to make is to the rear wheel.  I have a double-wheel in this design, but I think that I want to change that to a single, larger wheel.

I suspect that the texturing of the robot will be fun… but to get to that point, I’ve got to do UV Unwrapping.  This has got to be one of THE most arduous tasks ever conceived.  It’s more or less the same problem as representing a round globe on a flat map… except instead of a globe, you have this robot.

Looming on the horizon is the task of sound.  What’s this robot going to sound like?  I don’t just mean the whirring of motors or other familiar sounds… A great deal of effort in the design was to make Seña emotive… and to complete that task I need to come up with a voice.  No, this voice isn’t going to speak English, but in the tradition of R2D2, or the cute little robots from Silent Running, I’ve got to come up with a distinct, synthetic voice.

My current plan is to use a sine wave that’s got a base frequency.  The base frequency will change a little up or down depending on the emotion being conveyed.  This base frequency will have “words” added to it as bursts of other sine waves added in. The first few attempts may simply be a sped up and perhaps reversed Morse Code.  I realize that it’s unlikely robots would communicate through something as archaic as Morse Code, but screw it, I’m writing fiction here!

Rigging, It’s tougher than it looks…

So I spent the last few hours trying to figure out why my aperture lines up correctly in one pose but not in another.  I’m sure that there’s a simple solution to the problem… and looking back I’ll think, “D’oh! yeah, that was a dumb newb mistake.”   In a previous life, I was told that experiences like these are “learning opportunities.” sigh.

For anyone curious what a vertically slatted optical assembly looks like rigged in blender? Check it out… It’ll change over the next few days I’m sure, as I figure out my alignment issue, but to date, this is the most complex rig I’ve ever done. Go me!

So what you’re looking at here are the rig “bones” for the aperture which allow the aperture to open and close.  Behind it, you see a fan-shaped set of bones which control the segmented slats above and below the eye that telescope in or out depending on the inclination of the optical assembly itself.

.The specific problem that I’m having at the moment is, if I incline the eye, the aperture drifts slightly to the left.  I’ll experiment on it this weekend and hopefully find a good solution.  Learning Opportunity, right?

In the meanwhile, I actually did a little bit more concept design work around how Seña will express emotions.  Here are four basic emotions that I tried to express using the eye that I designed for her.

Actually drawing out the eye pieces in different emotional states, it showed me just how important coloration will be.

See if you can figure out what these emotions are…

Robo Optics

I’m finally getting into the grave details of modeling robot optics.  There is something that I’ve noticed about sci-fi movie optics that make no real sense logically, but they definitely add drama and emotiveness… the idea of eye color.

In just about all movies we’ve seen featuring robots, bad robots have red eyes.   Often we see as a robot makes a transition from being a good robot, the lights on that robot itself change from say blue to red.  I decided to add this color change concept to the robot optics I’ll be using for Little Robots.

The way I’ll do this is, behind the aperture, I’ll have a set of three colored lamps.  As I want to express different emotional states, I’ll dim or intensify the corresponding colors.  I’ll probably look up the Mood Ring color scale and just use that as my palette.   The lights themselves will reflect off a white surface at the back of the optical cylinder and should show up through the aperture of the robot.  Nice and tidy.


Speaking of apertures… I discovered that well… I had no idea how a mechanical aperture worked.  Instead of chickening out and using something lame like a square aperture, I messed around and discovered that really, apertures are just little sheets of rectangular metal (well, more like trapazoids) that rotate about 15 degrees.  Check it out:

Here you see my aperture which is made up of eight rectangles.  On the left, it’s in its closed state.  On the right, I posed it open.  Each aperture blade rotates a small amount in place and whammo… you have an open aperture.

Entering Space

It was clear to me from the inception of Project: Mars that I’d need to do a lot of research. In order to get down into the nitty gritty of what I want to write/record/produce, I need to come up with a mythology for the world I’m about to create; ostensibly the world we as a race will create in about 150 to 200 years.

My goal with reading this is to understand the problems of current space flight so that I can come up with a plausible history.  Whatever humble beginnings lead to colonization of Mars will dramatically affect the culture there.

At about 50 pages into the book, I’m very impressed with the technical details and frank opinions expressed by the author, Robert Zubrin.  While I get that there are far more complex issues involved with manned space flight than I’ll ever fully understand… I think that this book will provide me with what I need to spin a story about early mars habitation and the pioneers who dared to have the right stuff to do it.

When I’m done, I’ll have a full review of the book over at I Smell Sheep at some point.  Look out for it!