Friday, April 20, 2007
Building at 100,000 Meters
As you may know (especially if you've heard me yammer on about it on this weblog), the absolute maximum object limit in Second Life is 4,096 meters. Any unattached object that is rezzed above this ceiling, or otherwise moves above it, quickly disappears. This is normally not an issue, unless you're performing some high-flying acrobatics with an SL jet. It can be quite disconcerting to have one's flying machine suddenly evaporate four kilometers above the ground.
However, as I discovered early last year, this effect is not instantaneous. An object that finds itself above the build ceiling will last a fraction of a second before disappearing. Not a terrifically useful distinction, of course, but still interesting.
On the evening of April 6, 2007, I performed a little experiment high above my land in Louise. Using a battery of seven scripted HUD attachments (the seven gold buttons shown in the film below), I attempted to create a solid floor at an altitude 100,000 meters. (The green and white HUD is the flight assist I used to reach the test elevation.) Each HUD is composed of 50 simple rez scripts and a master timing script. Every second, the timing HUD calls each of the 50 rez scripts in turn (one rez every 0.02 seconds, with distributed rez scripts to help circumvent the built-in scripted delays for llRezAtRoot). This is a theoretical maximum of 350 temporary floors per second (50 per HUD, seven HUDs). (The distributed scheme was used in order to avoid the "grey goo" fence.) In reality, the overall rez rate is likely somewhat less than this, due to lag effects and built in delays. If I ever attempt this experiment again, I will likely go with a larger number of rezzer attachments, with a longer delay time for each master timing script.
The rezzed object is a simple, temp-on-rez prim. The floor prim is five meters by five meters by 0.01 meters. This size was a compromise: large enough to easily stand on, but small and light enough to minimize rez delays due to object mass. Following is a film of one experimental run in action.
As you can see, Will Webb and I are able to stand on the rapidly rezzing, rapidly evaporating floors. In earlier experiments, only one rezzing HUD (only 50 floors per second, max) was used. In that case, we were perpetually in the free fall animation, as our avatars continually lost support and fell a couple of millimeters, only to be buoyed by the next floor rezzed inside our bounding boxes. As more rez HUDs were added, we spent less and less time in free fall, until finally we were able to stand more or less normally (give or take the occasional fall and jitter). The experiment filmed above had a small, but noticeable (approximately 0.3 dilation) effect on simulator performance.
It seems likely that, if one were to greatly increase the number of rezzer objects, a stable and largely flicker-free structure could be created. But such a construct would likely be quite costly in terms of simulator resources. One could also optimize the system by controlling the rez timing across all of the rezzer objects. Currently, each of the rezzer HUDs operates independently, and it's likely that the overall periods between rezzed floors is not uniform.
In any case, it seems unlikely that a high altitude construct like this could be made permanent. Even if some form of self-replication could be programmed that was fast enough to rez a duplicate and transfer inventory before the original object dissipated, yet slow enough to miss the grey goo fence, one lag spike would break the chain and cause the whole build to disappear. And, of course, there is little that could be done in such a build, beyond jerkily wandering around and saying "Yep, I'm at 100 kilometers." Chairs and poseballs would disappear before they could be used, and scripts would not have time to execute anything more than the most basic commands.
Alas, it seems that ultra-private skyboxes and the like are still limited to 4,096 meters and below.