Random Update
Just a few things that have been on my mind lately in SL.

First, ran across this Planet Karen webcomic a bit back. Yes! Exactly! It's surprisingly difficult to work in extended conversations in the limited space available in a comic frame. Quite a few times, I had to go back and re-shoot a frame because I changed the dialogue, and couldn't make the proper left-to-right order work out in the space allotted. And quite a few more times, I didn't but should have.


Second, a quick picture of a new addition to the SkyLounge tower. I've added free-floating faux laser show butterflies to the sculpture garden on level one. (They're somewhat clearer in person. JPGs don't handle pure colors very well, even at low compression.) Kind of an interesting bit of manufactured future-retro tech, that. It would be quite easy to have near-photo-realistic butterflies flitting around up there. In fact, I have several flocks of realistic particle Monarchs flying about at ground level now. ([plug] Available at Mo-Tech Industries for only L$250! And remember, all proceeds go to Relay for Life! [/plug]) The trick was to come up with something obviously not intended to look real, and fit the somewhat futuristic feel of the Lounge. Finally settled on this. The orb at top center is a varying cone of RGB lasers, intended to simulate projectors for the associated RGB outlines of butterflies below. Kind of reminds me of the old laser rock shows down at the local planetarium, before they got shut down for excessive drug use by the patrons. Strangely enough, Laser Pink Floyd attracted potheads. Who knew?

Of course, this kind of free-floating display is technically impossible without additional schemes to block/show the light (screens, smoke, etc). Light doesn't just spontaneously stop in clear air. I briefly considered trying to come up with some kind of head nod toward addressing that (perhaps a light fog of stage smoke in the area of the butterflies), but decided I was being overly pedantic about it. We can all fly and teleport. I don't think it's breaking the illusion overmuch if I assume some minor revolution in free-floating volumetric displays, too. In any case, it's kind of a neat effect, if I do say so myself.


Third, last weekend I decided to pull the old stationary bicycle out of storage and have another go at wiring it up. I decided to scrap the existing scheme and start over from scratch. Instead of using a reed switch (which for some reason never seemed to work reliably), I went with a simple spring-loaded lever switch and a bit of bisected dowel rod on the main sprocket. Every turn of the pedals, the dowel passes by the switch and depresses it. Simple enough. I'm a little concerned about wear issues there, since it requires moving parts in the switch. I'll have to see how it works out over time.

Right now, all I've got is elevation control. To maintain altitude, I have to keep pedaling at a given speed. I settled on a range between about 10 and 15 MPH (according to the speedometer built into the bike). Pedal slower, and the Heli-Bike loses altitude. Pedal faster, and it gains altitude.

From a programming perspective, this wasn't all that difficult to work out. In order to minimize lag effects, I divided the work into two scripts. The first script monitors a key (the Page Up key, in this case) and reports the time between keypresses (in hundredths of a second) via link messages. It also contains a timer to determine if the user has stopped tapping the key altogether. The timer is reset each time a key is pressed. If the timer lapses, keys are being pressed slow enough to be considered a full stop.

The second script takes that time and compares it against various numerical ranges: hover, rise slowly, rise quickly, fall slowly, and fall quickly. This proved to be somewhat complicated. Longer periods between keypresses correspond to higher numbers. If the period is longer (more hundredths of a second have passed), the user must be pedaling slower. This proved to be quite confusing and counter-intuitive (one would expect higher equals faster), especially after banging my head against the wall for a couple of hours. About halfway through, it occurred to me that a simple change of interpretation (such as working in frequency, 1/seconds, instead of period, seconds) would have made things somewhat more intuitive. But by then it was too late, and everything had been sorted out. And working in whole numbers (whole hundredths of a second is sufficiently fine resolution for my purposes) is still more convenient. Still, worth keeping in the back of my mind next time something like this comes up.

Worse, the ranges had to be determined by trial-and-error, actually using the bike in question to find comfortable (yet challenging) speeds. This involved a few hours of climbing on the bike, pedaling for a few minutes, observing the various numerical data being spewed out in debug, climbing off, tweaking code, and repeating. (My legs were so sore this morning, I could barely climb out of bed.) Fortunately, I had the foresight to work out the various ranges as offsets from one "neutral" number. Right now, everything centers around approximately 12.5 MPH, which corresponds to one full pedal revolution per 0.73 seconds. This method allows me to tweak speed ranges simply by changing one number, and having the software adjust all the ranges for me. I may even build in a method to do this on the fly, so I can make the Heli-Bike more or less demanding to keep aloft as needed.

So, I had code to interpret speeds as rates of climb/descent. The next trick was to come up with some kind of simple physical engine to drive it all. I've decided to stick with attachments for this project, mostly to avoid the frustrations of SL vehicles and sim crossings. This leaves me with normal avatar flight, and various forces to enhance or cancel a flying avatars normal buoyancy. Basically, the attachment applies an llSetForce along the avatar's Z axis, with positive forces lifting upward and negative forces pushing downward. Again more confusion there, with the inverted fast/slow/high/low/up/down scheme I'd backed myself into. Very frustrating after the umpteenth change of greater-than to less-than and plus to minus.

Originally, I created a linear equation directly relating pedal speed to force. Pedal faster to apply stronger forces and climb faster. In practice, this worked well enough from a purely physical standpoint, but proved irritating to watch. It's impossible to maintain a perfectly constant speed (even assuming lag effects didn't cause fluctuating time readings). So the pedal periods would vary slightly even when attempting to maintain a constant speed, causing associated minor variations in lifting forces. Normally, a minor (a few percentage points) change in force from second to second wouldn't be noticeable. But the effect became quite pronounced when followed by the normal SL client camera. What would appear to be a reasonably smooth climb to an outsider became a stuttering, jerking, motion-sickness-inducing movement when viewed through the damped, delayed motion of the default follow camera. I suppose I could have come up with some kind of custom camera parameters to minimize (but likely not remove) this effect, but instead I settled on breaking the forces out into the five speed ranges described above. The force only changes magnitude if the speed moves from one broad range to the next. Less realistic, but considerably smoother and easier on the eyes when viewed through my own camera. And, really, that's the important thing here. If I can't stand to watch it in action, it doesn't matter if the movement is realistic or not. It'll quite realistically stay parked on the ground or in my inventory.

So, anyway, I now have a helicopter that can move up and down. From there, it's simply a matter of hardware. Normal flight can be used for forward motion and steering, without additional software. I just need to come up with an appropriate controls scheme. Considering that I'll need at least three switches (left, right, and forward), possibly more, integrating this all into my handlebars is going to take a little thought.

More to come.

Addendum
Finished this project, more or less. Seems to work pretty well.
Posted by Moriash Moreau at 12:15 PM