Where Several People Have Gone Before
There's been a bit of a space race in SL, starting in early October. I believe that Beatfox Xevious holds the record, with an altitude in excess of 40 trillion meters. I expect that this record will stand for a while, mostly due to the ultimate futility of the whole process. Once you exceed a few million meters, there's nothing worth seeing, save for the continuing degradation of your avatar due to floating point rounding errors. Basically, your avatar's parts go all haywire, because their exact locations keep popping up and down as their Z-axis locations round off to too large a number. (The system can only handle numbers out to so many decimal places, and adding a few million to the left side lops off precision on the right side.) Once you get beyond that, you're just staring at your HUD altimeter and waiting for something to crash. And given the improved stability of v1.7, you're apparently even denied that much excitement!

But, in any case, I can officially document my own attempts at Second Life's highest frontiers. This evening, using a thruster setup of my own design, I managed to reach 1.5 billion meters. Okay, I'm still well short of the documented maximum (by about 4 orders of magnitude). But, as a proof of concept, it seems to work quite well.


Click for Full Size View
This is the ultimate expression of the floating point errors. My avatar is permanently out of camera view, save for the eyes. Kind of spooky, actually.

The thrusters themselves are pure brute force. For this attempt, I used six booster assemblies. Each one is composed of 100 prims, which in turn each contain a script that pushes my avatar upward 10 times at the maximum impulse allowable. These are driven by a central controller that calls for 10 impulses per second. The net result is my av was being kicked in the pants 60,000 times per second, more or less.

I'm guessing it wasn't a comfortable ride, but it was a fast one. I did some quick calculations and time trials, and found that I was traveling upward at about 233,000 meters per second (about 704 times the speed of sound). And that was with only six thrusters. Someday, when I get truly bored, I may try it with thrusters placed on all thirty attachment points.

But, probably no time soon. As a proof of concept, it works. As an actual achievement? Well, I'm sure I can find something better to do with my time!
Posted by Moriash Moreau at 8:26 PM - 1 comments

 
SL Webcomic Tips, Part 4
Addendum 12/2/05: This is part of a four part (so far) series. Part one is here.

In this exciting episode of SL Webcomic Tips, we'll pick up where we left off last time, with poses and animations. Exciting, huh?

As mentioned previously, static poses can simply be placed in any scripted poser object. This is often all you'll need. Put the pose in the inventory of the poser object, edit the script to include the name of the animation, and you're good to go.

As for the poses themselves, I'll let you in on a secret: neither of us owns a copy of Poser. Nearly every animation we've used was either pulled from the canned Linden library or taken from a freebie pose box. If you have access to Poser, great. But if not, you can get by just fine without it. Just get ahold of every freebie animation collection you can find (expect them to be mostly duplicates), and become familiar with the built-in animations. Then experiment with different camera angles and poser object angles. Often, you'll find that the same pose can be used to convey different actions, simply by shooting it from a different angle. With a little imagination, those should work for 99% of the situations you'll be filming.

The main problem with filming actual animations (as opposed to static poses) is coordination. You can try telling your actors to make gestures and trigger them on cue (as we had Oliphant Ming do with the library LOL gesture here), but this is an exercise in frustration. The better bet is to make an attachment that triggers the animations by remote control.

I've modified a basic animation script for this purpose. It's nothing particularly sophisticated, but it seems to work. Just place it in an invisible prim (100% transparent or texture "alpha") and have the actors attach it in any unused location. Then call for the animation in the appropriate chat channel. For example, "/42 throw_r" would trigger the basic Linden throw animation. If the animation is not on the built-in animation list, you'll need to place a copy in the inventory of the animator object. (Built in animations can just be called by name.) I've also included a clear function ("/42 clear") to flush all the currently running animations. This is handy if an animation (such as the aim animations, or sometimes the jump animation) refuses to stop.

I usually make a gesture to trigger the animator attachment. Since capturing a moving animation can be a bit of a reflex test, it can be helpful to bundle a short delay into the gesture to give yourself time to find the screenshot key. Animations can also be combined this way. For example, Jon's pose in frame three of this strip is a combination of "stand_2" and "express_anger_emote." (The "_emote" animations are face only, while the base animations- like "express_anger"- include full body movements.) I just made a gesture to call both, one after the other. You can create all sorts of semi-custom poses this way, by either calling two animations in rapid succession, or by putting a static pose in a poser object and calling another with the animator attachment. Some will work this way, some won't, and some will react very oddly in combination. It all depends on the intrinsic priority and specifics of the animations in question.

In the same way, you can use the same gesture to trigger animations for multiple actors. The key is to make animator attachments on different channels. For example, in this strip, we had two animator attachments, one on channel 42 and the other on 43. I made a gesture to call the laughing animation on 42, wait a fraction of a second, and then call the same animation on 43. This kept the actors from executing synchronized belly laughs.

Sometimes, animations will go by too fast to photograph effectively. This is especially problematic when combined with the slight delay before the scene is frozen for a screenshot. We ran into this problem several times with the standard throw_r animation. Fortunately, there is a debug menu option to slow down your own animations. Check under Debug, Character, Slow Motion Animations. (Be careful with the other options under the Character submenu. Many of them, including the Flush Animations option right above Slow Motion, will crash your client.) This function will dramatically slow down your animations. Note that this only works on your animations. Everyone else will appear to be moving at the proper speed, and you will appear to be moving normally to everyone else. As such, the photographer will have to be the one running the animation in slow motion. (Keep this in mind if one of your characters will be using no-transfer avatars, costumes, or props.) Note also that this function is a toggle, even though it does not appear with an "X" in the pulldown to indicate its active status. You will have to select the function again to turn it off.

This probably goes without saying, but the most basic thing you can do to make your comic frames more realistic is to control where your avatars are looking. You will need to tell your actors to Alt-Click on a given target, whether that's another actor or a specific object. Fortunately, the camera pan controls (either using the various Alt, Ctrl, and Shift combinations or using the Camera Control window from the View pulldown) don't affect the direction your avatar appears to be looking. So the camera man can move his camera as needed to take the screenshots without affecting his avatar's position.

Here's a quick trick for pointing. If you need to have your avatars pointing at one another, you can simply use the point_you animation. This will point straight ahead, and will tilt with the torso to allow you to point up or down slightly in the direction the avatar is looking. If you should need finer control, or need to point at something substantially above or below, simply have the actor right click on an object target. As usual, he'll point his left arm straight at the object. The camera man can then go to View, Beacons, Hide Particles to turn off the edit particles streaming from the actor's hands. If necessary, you can airbrush out all but the index finger and thumb to form the normal splayed fingers into a convincing pointing gesture.

The included "stand" animation merits some special mention. This is the animation you will use most often, as the default standing rest pose. You will probably want to use it as the default animation in your poser objects, as well. The stand animation is actually a combination of four different stand poses:

• stand_1 - back straight, hands relaxed at sides
  
• stand_2 - standing with both hands on hips
  
• stand_3 - standing with right hand on hip
  
• stand_4 - leaning slightly to one side, hands relaxed at sides

The stand animation will periodically call each of these in random order, smoothly transitioning from one to the other. And, maddeningly, any of the numbered animations will start with the pose indicated, but will soon slide off into another randomly selected stand animation as well.

Normally, this behavior isn't a problem, but it can occasionally be troublesome if you're looking for a specific effect (such as irritation or heroic resolve using stand_2). And if your costumes are made of bulky prim attachments, or include large, poofy skirts it seems like the actors will spend half their time with their hands intersecting portions of their anatomy and/or clothing. There's no help for it but to use a static pose animation or repeatedly call for the intended stand pose.

And there you have it! Have fun, and I'll be back soon with more SL webcomic tips... Just as soon as I can think of something else to say.
Posted by Moriash Moreau at 11:53 AM - 0 comments

 
Exploding Goldfish
He who tooteth not his own horn will find himself untooted. - My Grandmother

Recently, I was commissioned to create the physical embodiment of an inside joke. For those of you who haven't been following the Herald for the last month or so, apparently there was some sort of incident involving Cory Linden and a goldfish at the 2005 SLCC. A couple weeks after the convention, I was contacted by Walker Spaight (editor of the Herald and owner of the teeth-clenchingly improbable Herald Tower located a stone's throw from the Garden of Mo). Apparently, the two-year anniversary of the Herald was coming up, and he was planning a commemorative gathering at the _blacklibrary. In hopes of luring Cory to the event, Walker wanted a sacrificial goldfish in attendance. That's where I came in.

Given that the party was just over three weeks ago, I'm guessing that Herald coverage of the event will not be forthcoming. (The editorial staff was a bit busy at the time, and it's old news now). I don't even know if Cory showed for the party. I only stayed for a couple of socially awkward hours, doing the virtual equivalent of standing in the corner and examining the potted plants. I hate parties, be they SL or RL. (If anyone knows how and/or if Cory reacted to the goldfish, please drop me a comment and let me know.) In any case, I'm kind of proud of how the project came out, so I'm going to talk about it here.

Anyway, Walker IM'd and e-mailed me asking if I could whip him up a goldfish bowl. He offered to pay me for the commission, but I declined for a variety of reasons. (First and foremost, he's a friend and he had a nifty project to play with. But there were other reasons- unrelated to Walker- that may appear in an upcoming rant, provided I can summon sufficient bile to properly write it.) Basically, he wanted a fish swimming in a bowl. Simple enough, people do that all the time. (I'm sure everyone has seen fish swimming in endless circles by dint of the LSL llTargetOmega command.) But he had a couple of additional requirements (from his e-mail):

1. When someone clicks the bowl, the goldfish jumps into the air and then splashes back into the bowl.
   
2. If Cory Linden clicks the bowl (this would just happen for Cory, not for anyone else), the goldfish and the bowl explode in a puff of flame and smoke.

Naturally, I was hooked right then and there. Who wouldn't want a chance to make Carassius auratus go 'splode? And, as usual, I went way overboard. A goldfish bowl, even one that explodes on demand, shouldn't require two pages of documentation. Oh, well. I gotta be me!


The fishbowl, in all it's splendor.
Here's the fish and the bowl. Rez the bowl, move it into place, touch it to rez the fish. Simple enough.


The goldfish gets some serious air.
When someone touches the bowl, the fish jumps into the air (over a meter!), then splashes back into the bowl again. This is accomplished with a rapid series of particle effects. The prim fish disappears, to be replaced by a particle fish. The particle fish is launched upward, then is drawn back to the fish prim. This is accompanied by a splash effect (particles and sound) at the beginning of the jump, and larger splash at the end. It's not terribly complex, although the timing was tricky. I think it works pretty well, especially given that it doesn't involve any actual ballistic physics.


The goldfish goes boom.
And here's what happens when Cory Linden (or anyone else on the explode list) touches the bowl. It bursts into crackling flames, as the silhouette of the goldfish makes one last turn before expiring. Then, ten seconds or so later, the glass shatters (okay, the bowl disappears), releasing the water with a sizzling splash that extinguishes the flames. All that's left is a "steaming pile of scorched gravel" (yes, the object actually changes itself to that name). After a minute, or the next touch, the bowl restores itself and the fish returns good as new.

If only that happened in real life.
Posted by Moriash Moreau at 3:00 PM - 1 comments

 
SL Webcomic Tips, Part 3
As promised previously, today we're going to talk about actor wrangling.

One of the main problems with SL, at least for our purposes here, is the lack of fine control. It is virtually impossible for an avatar to do many things the average human takes for granted. I'm talking about things like "take half a step to the left," or "hold that prop a little higher." To make matters worse, minor changes in rotation are often not conveyed to the servers. So an avatar may think he's facing properly, when in fact he appears 20 degrees off to someone else.

So how do we get around this? We take the control out of the hands of the actor and put them into the hands of the camera man/director. The easiest way I've found to do this is to make poser objects. These can be any normal pose ball, as long as it's big enough to easily edit once it's in use. Here is the script that I use. Usually, I just put it in a cube, because it's easier to eyeball rotations on a square object. (Mine are usually blue, but it can be useful to color each one differently for ease in stage directions, such as "Bill, sit on the green cube.") This script is virtually identical to every other sit pose script out there. Simply edit the script to use the proper pose animation (we'll talk more about poses and animations in a future installment), tell the actor to sit on it, and you're good to go.

Once the actor is in place, the director (who should also be the camera man, since he's the only one who can see the correct angles) can then edit the cubes to move the actor to the correct positions. This is will save a lot of headaches in the long run. (Just remember to keep their feet on the ground.) If the scene director (or his partner) has access to all the avatars for the various characters involved, he can also block out the scene as his own stand-in. This is very handy for scenes with large casts, as it saves quite a bit of boring fiddling with positions once your volunteers have arrived.

This one technique did more to make our lives easier than any other trick we've found. It's absolutely maddening to have a whole scene wrecked because one actor has a spot of lag and ends up pushing everyone out of place while trying to carefully take a step to the right. The downside is it's boring for the actors. Their entire job is to stand still while some guy fusses about taking snapshots. That's why having someone (usually my partner, in my case) act as cast coordinator is so useful, just to keep everyone in line and ready while the camera man twiddles with his camera controls. When we have large shots (more than we can get using our two avatars on our main machines, and the two ancient machines I have cobbled together to run alts), she finds the volunteers, explains the scene, and generally keeps them entertained while I muck about in complete silence and curse at my screen as I set up the shots.

Still, setting up a complex shot can be boring for everyone but the camera man. (The latter is usually surly and stressed out as he tries to figure out where everyone goes, then get his camera setup before the cast gets sick of standing around and/or otherwise has to bow out. I've come to the conclusion that it's better for all concerned if I don't even try to speak socially during this process. Oy.) There isn't much you can do about that. Just plan ahead as much as possible, explain their part in this hopefully-knee-slappingly hilarious comic, and work efficiently when the time comes. Consider uploading a copy of the raw shots and sharing it with everyone, if it's a particularly amusing scene. And, of course, use stock footage (start taking pictures of crowd scenes and nifty scenery ASAP) and bluescreen Photoshop tricks when you can get away with it, to minimize the live casting required.

One good thing about photo shoots in this venue is the models can talk amongst themselves, even while the camera's eye is upon them. Just be sure to (nicely) tell them to hit the "/" key to bring up their chat bar (as in "/Hey guys!"), as opposed to hitting enter or clicking Chat. The slash key will bring up the chat bar without triggering the typing animation, so everyone can talk as much as they like without disturbing the shot. (They can also use IM without outward signs, of course.) And if they forget, well, don't stress about it. This is supposed to be fun, remember?

Well, that's about all I know about working with the cast in a screenshot based webcomic. Next time, I'll talk about working with poses and animations.
Posted by Moriash Moreau at 4:50 PM - 0 comments

 
SL Webcomic Tips, Part 2
Welcome back to Webcomic Tips. Here's the previous installment, if you missed it. Today, I'm going to talk about lighting. Don't worry, we'll move on to some more useful tips in the next installment, once I get the basics out of the way.

Proper lighting will usually mean controlling the sun. (Stop and think about that. "It's too dark!" "Eh, just move the sun.") In order to do this, you will need to use some of the Debug menu functions. (If you don't already have it enabled, hit CTRL-ALT-D to reveal it. Be careful tinkering with this, as some of the functions routinely crash your client.) You've probably already tinkered with the daylight control functions, but I'll go ahead and explain them, just in case. Take a look at the World menu under the Debug pulldown. There will be two options that we're concerned with: Force Sunset and Mouse Moves Sun. (The third option, Sim Sun Override, is only usable if you're the owner of an Island sim. It can be used to set the sun position for everyone in the sim.)

Force Sunset will simply convert night to day (perhaps it should have been named "Force Sunrise"). Select it from the Debug menu (or just hit CTRL-SHIFT-N), and the sun will shortly appear and hang motionless in the sky (you'll have to relog to set it back in motion). Note that this function (and Mouse Moves Sun, described below) will only work on your client. Everyone else will see the Sun moving as normal, and any scripts that use llGetSunDirection to track it will be unaffected. This is also a handy tool if you're in the middle of build when the Sun goes down.

Force Sunset will sometimes be all that you need. But, more often, you'll want more specific control of where and how the light falls. In order to do this, you'll need to use the Mouse Moves Sun feature. I've found that it's much easier to use the shortcut (CTRL-ALT-M) for this function. In order to set the sun in the desired location, do the following:

1. Enter Mouselook.
   
2. Hit CTRL-ALT-M. The sun should shortly appear on top of your Mouselook crosshairs.
   
3. Using your mouse, move the sun to the desired location (you don't need to click or drag, just move the mouse).
   
4. Hit CTRL-ALT-M again to turn off the Mouse Moves Sun function.

You can also turn the function on from the Debug menu pulldown (turn it on, enter mouselook, move the sun, leave mouselook, and turn it off). But I've found the shortcut keys are usually more convenient.

In most cases, you'll want the sun either directly above, or above and behind the camera. You'll probably want to tinker with it a bit for the best effect. There is no limit to the sun placement. So if, for example, your characters are watching a sunset from the balcony, but the balcony faces South, you can simply drag the Sun to the southern horizon. The client will automatically adjust the color and appearance of the Sun (and its light) depending on its distance above the horizon, so you can create an instant sunset wherever you need it.

If you want to film at night, simply drag the Sun below ground. The Moon appears opposite from the Sun, so it will automatically appear when the Sun drops below the horizon. (Yes, the Sun and the Moon orbit the world in Second Life.) Thus, you can make a dramatic full moon (and that's it- no crescent moons) when necessary. Unfortunately, you can't grab the moon using Mouse Moves Sun. You can only manipulate the Sun, and control the Moon's location second-hand.

Unlike with Force Sunset, the Sun will continue to move from East to West after being placed with Mouse Moves Sun. It will not, however, move North or South. It will just keep moving westward from wherever it was placed. This is important when you're setting up a series of complex shots intended to only be moments apart. It's a dead giveaway when it's apparent sunrise in frame one, and nearing SL noon (only 90 minutes later) by frame four. Always remember to check the Sun's placement before shooting each frame.

IF you need a dramatically clear sky (such as when you want a clear view of the stars), you can also turn the clouds on and off using the Debug menu. In the pulldown, select Rendering, Types, Clouds to turn cloud rendering off. You can also turn off Trees and other obstructions, if necessary. All of the options under the Rendering, Types Debug submenu are safe, if you want to play with them. Surface Patch (that is, the ground) is handy for when you lose prims by accidentally setting your Z coordinates too low.

Locally lit objects can also be used for some effects, such as washing an area with a color. This is what we did here. We used two large prims, set to red and blue (or yellow and pink), and set them directly in front of the objects we wanted to photograph. We actually made the prims 100% transparent (use a script and the llSetAlpha command, or simply using the "alpha" texture from the library), so that we could film from behind them. The objects will still give off light, even though they are invisible.

So we've discussed making the scene brighter, but how about darker? This is considerably more difficult, especially with avatars. Maddeningly, you can place an avatar in a completely black room at the bottom of a well, and he'll still show up as if in full daylight. There are two ways to address this. One, you can film the scene in full daylight, then use the brightness controls in your favorite art package after the fact. If you plan on doing this, make sure and light the scene as if it were daylight. Otherwise, the internally lit avatars will remain bright even after the background objects are too dark to see.

The second method is simply to put a dark, semi-transparent prim between the camera and the subject. Take a big, flat prim, make it blank, color it black, and adjust the transparency to taste. You'll effectively be placing a pane of dark glass in front of your camera. This is the SL equivalent of a time honored method of filming night time scenes in old B movies. It's not perfect (be sure and get the moon up in the background, if it's to be visible), but it's a fairly close approximation.

I originally came up with this idea for use in a live-action, in-world play. Sadly, the project died of internal Drama before the first rehearsal. (Is that irony? Alanis Morissette ruined my understanding of the term, so I can't say for certain.) The stage was to have a large, thin pane along the front edge, designed to simulate darkness when needed by partially obscuring the view from the audience. Oh well, maybe someone can use the technique someday.

Well, that's about all I have to say about lighting. Next up: actor wrangling!
Posted by Moriash Moreau at 2:19 PM - 1 comments