Cutting Bait Part 2
Technical Issues
Have you ever thought about what what it might have been like to be a filmmaker in your prime in the mid to late 1930’s? To have thought about cinematography issues for the first half of your career in reference to black and white film and then trying to achieve mastery of color… it must have been a big challenge indeed.
Such is the nature of the situation Gumbo faces as we lurch into this new millenium. A lot has changed, and most of the changes are very very good indeed.
For example, in the days when Gumbo was conceived, a machinima film just about HAD to be constructed such that it would play back as a scripted sequence (demo) within the game engine; almost no one had the patience or bandwidth to download gigantic Indeo or Cinepak-encoded video files. These were the days before DivX / Xvid, and Quicktime wasn’t the staple of quality and efficiency it can be today. Encoding to MPEG was an option, but the tools to do so weren’t widely available or known. And not to mention, most of machinima’s community was just plumb against the idea (myself included) as going to video seemed to contradict machinima’s definition at the time.
The migration of machinima to use digital video as its distribution platform was indeed essential, though. Thank you, Joe Goss. Not only did it solve the distribution problems inherent with in-game machinima, it also provided us the palette of post-production techniques, and gave a great deal more freedom in how filming had to happen. Now, one could construct their film a shot at a time if one wished to. Machinima process thus became more like “real” filmmaking, and a little less like hacking (though hacking is still a big, big part of good custom machinima).
Another big plus was in regards to sound. Most machinima platforms prior to 2000 had a sound engine which only supported lower-fidelity .wav files. And since most machinima was distributed as an assets package rather than a movie file, these .wav files proved to often be the largest component of the distribution filesize. Strange Company came up with a nifty utility at the time which allowed you to distribute the sound for a Quake 2 film as mp3s and then convert them to .wavs after downloading… but even then, the .wavs had to fit the specs of Quake 2’s engine, namely 22,050Hz mono. Digital video can have 44,100Hz stereo sound (twice the fidelity PLUS dual channel sounds), even 5.1 surround sound if you have the tools to sculpt that mix.
Add to that the fact that, as far as Quake 2 goes, since id Software released the full source code for the game, several new versions of the engine have been released (Quake2Max, Q2 EGL, etc.) which add support for higher resolution textures and skins with 32-bit color depth, shaders, higher poly models, and so on. Binary Picture Show is the standout example of what these improvements can yield.
So all of these things are very good for machinima. They are not, however, necessarily good for Gumbo.
For example, the skins for Gumbo’s dozen or so characters are all low-res, 256 color Quake 2 palette (six of the 12 characters need lipsync skins… that’s 4-6 skins each). The dozens of custom textures are the same. Palettizing a high color image to an 8 bit color image is a relatively straightforward process; going the other direction is just not possible in a linear sense anyway. Those images need to be recolored from scratch.
About 75% of the voiceovers for Gumbo are recorded; unfortunately, they are 11,025Hz sounds, which sound very “cheap” compared to the quality machinima uses today. Very few of them would be usable at all, and need to be redone from scratch.
The demos (.dm2) are recorded, but nearly all of them need extensive packetentities editing to get the animations looking deliberate. The lazy approach that was tolerable for people in 1999 (FFB) just doesn’t fly today. And then there’s the lipsync, which I consider a must, and which Doc Nemesis can testify can be a bit of a bitch.
So when it’s all said and done, “finishing” Gumbo is, in a sense, much like starting a new project over from scratch. Now I’m not one to shy away from work, but the degree of time this effort would consume has led me to do some introspection about whether this project is worth that output.
And what has me leaning a bit toward “no” has very little to do with any of the above in itself. I’ll delve into that in my third and final entry on this subject.
RSS feed for comments on this post. TrackBack URI
Leave a comment... or, take it to the forum (click here)
Well, I’m not sure the distribution problem is really solved. I still see scores of productions only being available in ridiculous file sizes. Hundreds of megabytes for pieces a dozen or two minutes long just because they don’t bother with compression.
“We want the utmost quality” is often an excuse, but it’s just that, an excuse. Sure, make the 300mb lossless version available, but no one but the most hardcore will watch it. One needs to make a >50mb version available for those of us that value our time and bandwidth.
At least for me, if I don’t have the choice, I’m not gonna bother downloading it unless I first hear from the community that it’s a masterpiece that needs to be watched.
Sorry for a big rant on a small part of the post.
- Mu
Comment by MuNansen — August 7, 2006 @ 11:24 am
I agree. By “distribution problems inherent to in-game machinima” I was referring to the audience size limitations which come naturally from requiring a particular commercial product to watch the film. With the move to digital video formats, it became possible to easily share machinima with the world, and the only user who really requires any special software are its creators (’cept maybe a missing codec, which can flummox the uninitiated).
The “etiquette” of sharing digital video is a topic on which more widespread education would be nice; there’s surprisingly little writing on the specific how-to of this topic, at least in the machinima world. Maybe some of us should collaborate on a fairly comprehensive article and submit to M.com and the OMFF Wiki?
Comment by Overman — August 7, 2006 @ 6:26 pm
Would be good. I actually brought it up at M.com before. I would contribute, but I’m far from a compression expert. A certain person starting making demands, though, and it killed my motivation. If it got started back up again I’d be glad to help.
And you’re right that it’s not just compression, but an etiquette that could be discussed, as well.
- Mu
Comment by MuNansen — August 7, 2006 @ 8:30 pm
Where the hell have I been? Sorry for joining the Gumbo..er..party..so late. Fascinating story behind this project, Overman. It’s hard to say if the project is worth continuing. I’d say, “yes”, simply because it would be an interesting challenge to creatively re-do your early work. Mu’s comment on Part 1 of your post is a good one, “you don’t really abandon a work”. This story is in your imagination. Perhaps you could re-tool it as a cautionary tale about mass murder. It all has to do with whether the story/material still inspires you. If it’s just dead material now, then put it aside. But if not, then you might have something you can tinker around with for a while.
A wiki post on compression would be mighty welcome. There’s lots of information out there, but it really comes down to trial and error at the present.
Comment by gToon — August 8, 2006 @ 12:12 pm
Compression: we find that the major choice these days is what bitrate to use. The three codecs of choice are .wmv, DivX or XVid (which are pretty much identical) and H.264 for Quicktime (which is stunning if very, very slow to encode).
FYI, we use 1200kbps for video and 128 for audio, at 800×450. Download numbers suggest it’s not worth producing a smaller version - we were producing small-size versions of the BloodSpell episodes, but they got about 1/5 or less the download numbers of the large versions, and since we’ve stopped we’ve had exactly 0 complaints.
Flash streaming video is a little trickier, and it’s still a bit of a black art. We’re currently working at 600 pixels wide and around 800 kbps, but it still has problems in higher-action sequences. A lot of that is simply that the Flash 8/9 video encoders aren’t really mature yet, and the earlier Flash video formats aren’t anywhere near as good as modern-day downloadable equivalents.
Comment by Hugh "Nomad" Hancock — August 8, 2006 @ 1:16 pm
and there’s a good start. Though I think Hugh could use a bit of help from a “Choosing a Stable Host” section
(can never get the downloads on archive.org to work)
Comment by MuNansen — August 8, 2006 @ 3:12 pm
Hugh, I’d say that H.264 is not a standard choice yet - it looks great, but it actually requires a higher end computer to run smoothly (higher than the average internet goer anyways), so it’s not practical for public consumption just yet.
Standards still seem to be good old WMV or Sorenson 3 Pro, and DivX and Xvid for those who don’t mind bigger sizes at the cost of exceptionally sharp video.
I wanted to write a compression guide a while back also, and I started on it, but somehow I just lost interest as well. =/
Comment by Executor VI — August 8, 2006 @ 11:01 pm
thanks for the info, Hugh. Especially on download vs size. Syncs with what I’ve been working with. H.264 has been hell with my system, but Sorenson 3 works like a charm. Exec, please do the compression guide. I really think it would help a lot of folks. I’d use it for reference because at times the compression issues can be complex even when you have some experience.
Comment by gToon — August 9, 2006 @ 1:04 am
Aren’t all the movie trailers on Apple.com running in H.264?
Comment by MuNansen — August 9, 2006 @ 2:09 am
Looks like they are… but I think that has to do more with Apple’s push for the codec more than anything. Higher resolutions (even below HD) still lag and jitter a bit on my old computer. Though even 1080p works great on my new one. =P H.264 definitely is an awesome codec when used correctly.
I think maybe in one year or so, people will be using more of H.264 instead of Sorenson Pro, but for now I’d probably recommend the independent producer to stick with the standards for maximum “compatibility”.
Comment by Executor VI — August 9, 2006 @ 1:45 pm
Ja das ist fantastish!
buy viagra
cheap viagra online
G’night
Comment by dasfanvia — December 10, 2006 @ 2:14 pm
Thanks for good post! Thats what i’ve been looking for.
Comment by MattGar — May 17, 2007 @ 6:01 am