AR'ed!

It seems that I'm a liar and cheat.

On Friday someone purchased one of Virrginia Tombola's and mine Birds of Prey and something happened to interfere with the delivery. The person who made the purchase sent an IM to me at about 7:30 AM SLT - 10:30 local time for me, telling me that the delivery hadn't gone through. Since I was offline - it being right in the middle of the work day for those of us who are employed and living on the east coast of the US, SL sent him the standard "User is offline..." message. 20 Minutes later he sent another IM threatening to AR me - presumably for fraud, and about an hour later he filed an AR.

As soon as I received the messages - around noon SLT - I tried to correct the situation. The sales log on the Hippo page showed that the delivery was pending so I sent another bird and sent myself one as well to check the delivery. He claimed that it wasn't delivered either and asked for a refund. As I wasn't able to log into SL at the moment I told him I'd send one as soon as I could, and when I was able to log in did indeed refund him the full purchase price.

I've since learned that he also logged an alt on with an attached object that stood in front of the shop spamming everyone who came within range accusing me of being a thief.

Naturally there was no thank you or - god forbid - an appology for his behavior.

And so I pretty much quit.

I've spent the morning shutting down MIM. I've pulled all my aircraft from SLX and removed the few satellite vendors that I had out. I'll leave the airstrip and trainer at Loch Avie up for anyone who'd care to use them, but all of the vendors and demos are gone. And as I'm feeling somewhat scroogish I've also pulled my freebie aircraft from all the locations where they were available.

What more could be expected of a liar and thief such as myself.

Thanks for your attention and interest...

IM

Nails, Straws and Imaginary Motoring

Firstly, my apologies for my prolonged absence. As you may have noticed of late the grid has been especially "choppy". I had thought that it was a problem that I was experiencing on my own, or that perhaps it was a transitory issue, but then I read Zoe Connolly's blog on the "weather" in SL and started to wonder if it was perhaps something that could be addressed with improvements to the scripts and so I've been working on that.

But then a week or so ago Caledon's Guvnah, Desmond Shang sent out a note card which contained two interesting bits of information. The first item (I'll delve into the second in another post) concerns the effects of introducing an object containing Mono compiled scripts into a sim, vs the same object containing the same scripts but using standard LSL.

A brief technical aside. Scripts in SL come in two flavors. LSL and Mono. The scripts themselves look and behave identically, but those compiled in Mono have a process applied to them when they are saved to the server which... Well according to Torley Linden's video tutorial "...you'll benefit from less server side lag and better performance".

In brief the issue is that numerous residents have reported that an object containing Mono scripts causes a disproportionate amount of lag when it's introduced to a sim. The object can be ridden such as a vehicle, worn as an attachment, or simply rezzed from one's inventory. According to the reports the effect is both easy to reproduce, and dramatic enough that it can't be missed.

With this information I decided to do a few quick tests of my own. First I recompiled all of the scripts in a copy of my Voisin bomber using LSL instead of Mono.

Then I created a simple object which would display the sim time dilation every .1 seconds. Time dilation as I understand it is the difference between when something happens on the server and when it's displayed on one's viewer. A "perfect" score is 1.0. A value of .95 or higher seems to indicate that all is well. As I'm more than a touch obsessive I try to keep Loch Avie at .99 or higher at all times.

My dilation detector was a simple script:

default
{
state_entry()
{
llSetTimerEvent(.1);
}

timer()
{
llSetText((string)llGetRegionTimeDilation(), <.7, .7, .7>, .7);
}
}

The idea was simply to rez the Mono version of the plane, watching the changed in dilation for the sim, then repeat the process with the LSL version and compare the results.

I logged out, cleared my cache, and logged back in again, then gave the detector a moment to settle down from my arrival.

The first "experiment" was to rez the Mono version of the Voisin. Keeping an eye on the dilation value I dragged it from my inventory to the platform on which I was working.

Let me take a moment to describe how the dilation detector looks when working. It's a plain prim cube with a number between 0.000000 and 1.000000 flickering above it 10 times a second. The number changes every tenth of a second in response to sim performance.

Let me also point out that the detector is in no way shape or form associated with the vehicles I was rezzing as part of the test. It simply checks the simulator time dilation value and reports the results.

I'm stressing this information because when I rezzed the Mono version of the Voisin the detector stopped.

I'll say that again. The detector - a script which has effectively one line of code which is run once every tenth of a second - STOPPED. It did not update it's value a single time for about 2.5 seconds.

In other words adding one object with 17 Mono scripts in it completely stopped the execution of a totally unrelated script in that sim for 2.5 seconds.

Once it started reporting again I saw the dilation value drop from .99+ to .11+, though I honestly thing that it went lower and .11 was simply the first time that it was able to respond.

Leaving the Mono Voisin on the platform I next rezzed the LSL version. Since the vehicles are identical other than the script compile methods I anticipated the LSL version would rez more quickly because all of the textures and sculpt maps were already loaded into the cache thanks to the Mono version.

Once again carefully watching the detector I dragged the plane from inventory to the deck.

This time the detector did not stop, and the dip in performance was from .99+ to .75+, roughly 24%.

For the third test I deleted the Mono version of the plane then waited a moment and rerezed it. My thought was that the LSL plane - which was still rezzed, would provide the textures and sculpt maps thereby reducing rez time.

I was wrong. Once again the dilation detector froze for approximately 2.5 seconds. This time it reported a drop from .99+ to .22+ though the over all effect was identical. The script simply stopped working for 2.5 seconds.

The final test as to remove both vehicles, then re-rez the LSL version. Without the Mono version the being present it actually only dropped the dilation from .99 to .88.

While I'll admit that my test are hardly the Manhattan Project they do seem to be fairly straightforward and do seem to point to a definite problem.

Now for the bit that has me agitated. This issue was originally reported in the public JIRA - the system LL uses to report and track bugs and other issues with SL - on 24 February of this year. This is not a new problem. Numerous people confirmed and commented on the issue, but it wasn't until 3 August of this year that a single - THE single - Linden response came in and that was something to the effect of "I can't duplicate this".

Since then of course the situation has worsened. Vehicles which are compiled with Mono are effectively crippled, but that's not the only issue (much as I'd love it if vehicles were the center of the SL universe I realize that a few people do other things). This behavior is caused by the introduction of ANY Mono scripted object to a sim. That means if I fly my Voisin across the sim line, or rez it on the runway, or attach it and TP into the sim, the effect is the same. Of course who would wear an airplane when TPing from one sim to another?

As I said, it's not just vehicles. Mono scripted attachments also cause the lag spike. This includes radars, the resize scripts which are now found in many shoes and hair styles, HUDs, BDSM collars, neko tails and ears, weapons and combat systems... Each one of them slamming the simulator when the wearer TPs into the sim.

Is it any wonder that SL has become a mire of lag?

Rudderless, Part II - Revenge of the Script

Okay now that we have a rudder we'd probably like it to move, right? Luckily that's pretty simple - or at least it was after several months of gradually refining the process down. At this point a little familiarity with LSL would really help a lot. You can probably make this work simply by plugging it into a Cubey DIY plane script (I haven't looked at them in quite a while but it used to work), but to follow what's happening you might need to dust off the LSL.

We'll need to use the llMessageLinked command to pass information to our rudder, and add a small script to the rudder (and all of the control surfaces) to receive the instructions. decode what's being said, and possibly act on them.

For the most part when you're operating a vehicle in SL it's done using the same keyboard command keys you use to move normally. There's a way of intercepting those command keys in a script and diverting them so that instead of your avatar turning left or right your vehicle turns left or right. Collectively these are called the Controls commands and you can learn lots more about them at http://www.lslwiki.net/lslwiki/wakka.php?wakka=controls.

For our purposes the most important thing to know is that each of the control keys generates a specific and unique number. When you press the left cursor key LSL sees a control value of 256**. Assuming your script is like most vehicle scripts there will be a section which starts out with

control(key ...

That marks the beginning of the control event and that's where we'll start playing around. I've built a little rudder example that I give out to people. It's just two prims and two little scripts. Here's the main script

vector avPosition = <-0.0, 0.00000, 0.3>;
rotation avRotation =  ZERO_ROTATION;
integer lastLevel;

default
{
    state_entry()
    {
        llSitTarget(avPosition, avRotation);
    }

    changed(integer change)
    {
        if(change & CHANGED_LINK)
        {
            key agent = llAvatarOnSitTarget();
            if(agent != NULL_KEY)
            {
                llRequestPermissions(agent, PERMISSION_TAKE_CONTROLS @ PERMISSION_TRIGGER_ANIMATION );
                llStartAnimation("motorcycle_sit");
            }
            else
            {
                llResetScript();
            }
        }
    }

    run_time_permissions(integer perm)
    {
        if (perm & (PERMISSION_TAKE_CONTROLS))
        {
            llTakeControls( CONTROL_RIGHT @ CONTROL_LEFT @ CONTROL_ROT_RIGHT @ CONTROL_ROT_LEFT, TRUE, FALSE);
        }
    }

    control(key id, integer held, integer pressed)
    {
        if (pressed) llMessageLinked(LINK_SET, held, "", NULL_KEY);
    }
}

IMPORTANT - In the above code I was forced to use the @ symbol in place of the vertical bar (which I STILL can't type but on most US keyboards it's Shift and the \ key). If you want to use this code in your projects make certain to replace all of the @ symbols with Shift and \.

Looks daunting doesn't it? Well the majority of it - in fact all but one line, isn't necessary if you've already got a working vehicle script. Look all the way down at the bottom - the last line of actual text. That's all that's necessary to pass the commands to all of your control surfaces. Let's break down what it's doing.

First let's look at the line of text directly above it. This starts a control event meaning that LSL will capture and act upon the specified control keys. There are three pieces of information that can be collected from a control action.

The ID of the avatar pressing the key, which we've named id.

If a key is being held down, which key (or keys). That's named held.

And when a key is pressed or released. That's named pressed.

With that in mind let's look at the second line.

if (pressed) llMessageLinked(LINK_ALL_OTHERS, held, "", NULL_KEY);

There are two sections to it. The first looks to see if a key has been pressed. If it has then the value for pressed won't be zero. That's essentially what if (pressed) means. If it's not zero, then do whatever follows.

In this case whatever follows is the somewhat intimidating

llMessageLinked(LINK_ALL_OTHERS, held, "", NULL_KEY);

It's actually not that bad, it's just all the underscores and commas. the llMessageLinked command simply sends a message to one or more prims in the object. It's like a prim to prim intercom. The four items inside the parenthesis are:

Which prims we want to send the message to. In this case we want our control message to go to every print in the vehicle except for the root prim - it's the prim that this script is in and we already know what's happening so there's no need to duplicate the effort. To sepcify all the other prims we use the command variable LINK_ALL_OTHERS. To send it to every prim we'd use LINK_SET, and to send it only to the root prim we'd use LINK_ROOT.

Next you'll see held which might be a little confusing especially if you're a little familiar with LSL already. The llMessageLinked command can send three pieces of information. A number, a text message, and a key. Since we've only collected numeric data at this point, that's all we have to send, and really all we need to send, so we'll pass just the value of the key which is being held down.

The empty double quotes means we're not sending any sort of text message. Originally I would specify "RUDDER" or "FLAPS" but since it's unnecessary, and since I operate under the assumption that every byte of data I send is one more byte of data SL has to cope with, I started leaving it blank.

Lastly is NULL_KEY which is the equivalent of sending a user ID key of "". We don't need it so why burn the bytes sending it.

So what does this do? Well in English, it waits until the pilot presses a control key. At that point the value for pressed stops being zero for a moment, so it sends the value for held - which will be the same as pressed to the other prims in the object. An instant later pressed returns to zero, but we ignore that so our rudder has been told 256 or left.

Once we've completed out turn we release the left key. The value for pressed jumps to 256 again - remember it changes when ever the key is pressed or released, but not when it's held. Now the value for held is zero because we've released the key, so we tell the rudder zero.

Of course the rudder has to know what to do with all this information, so we'll need a script in there as well won't we?

rotation center =   <0.00000, 0.00000, 0.70711, 0.70711>;
rotation right =    <0.00000, 0.00000, 0.92388, 0.38268>;
rotation left =     <0.00000, 0.00000, 0.38268, 0.92388>;

default
{
 state_entry()
 {
  llSetLocalRot(center);
 }


 link_message(integer sender, integer num, string msg, key id)
 {
  if(num == 0) {llSetLocalRot(center);}
  if(num == 256) {llSetLocalRot(left);}
  if(num == 512) {llSetLocalRot(right);}
 }
}

This one is actually pretty simple. The first section - the three lines that start out rotation are simply setting up the rotation values for each position of the rudder.

The state_entry bit is run every time the script is reset and simply rotates the rudder to the center position.

The link_message event is where most of the magic happens, and now that you're passingly familiar with the llMessageLinked command you should see some similaities. Again there are four components:

The sender is the prim number of the prim sending the message. We aren't using it at the moment so I don't do anything with it.

The rudder position is being passed in the num variable. It's likely to be all sorts of numbers in the course of a flight since every control function will send something as well as any other script commands that use the llMessageLinked command.

The msg variable would contain the text message if we'd sent one, but we didn't so it's empty.

And the id would contain an id key but again we didn't send one so it will be all zeros.

So whatever was passed as num will tell us what to do. That's the next three lines and they're practically English (well in terms of LSL they're practically English). If the main script sent us a zero we reposition the rudder back to the center position. If it sent a 256 we move the rudder left, and if it sent a 512 we move it right. Anything other than zero, 256, or 512 we ignore.

If you'd like a full perm version of the working example upon which this article is based just drop me a note in world and I'll be happy to send it along.

** It's actually a little more complex than that because you could be pressing page up and left at the same time in which case the LSL control would see 288 - 256 for left and 32 for page up, but we'll ignore that for the moment.

Rudderless? Not us!

So we've got a fuselage, cockpit and wings, next we need control surfaces. The Taube will be a pretty simple example of this because it's only got a rudder. In the RL Taube lift and roll were controlled by literally twisting the shape of the wings, which doesn't translate well into SL - I suppose I could sculpt a different set of wings and flip the sculpt maps when someone is climbing or descending, but it would be such a subtle change that no one would be able to see it.

A quick break for pilot lingo lessons. In airplanes (and boats for that matter) it's possible to rotate along any of the three axes, and naturally there are specific names for this. When the plane's nose moves up or down that's called pitch. The wing tips moving up or down is called roll. And the act of turning the plane left or right is called yaw. I usually remember it as pitch is up or down, roll is clockwise or anti-clockwise, and yaw is left or right.

So, one control surface, easy, right?

Well....

Y'see the problem is that when one rotates a prim in SL it always rotates on the central axis, which makes sense, but it also makes for funny looking rudders (also doors which work more or less the same way). It's a relatively simple matter to overcome in a door - which is generally a rectangle that pivots on on edge, by simply rezzing a cube, then using the Cut function to halve it.



Since the center point of the prim stays in the same spot but we only have half of the prim left, the door rotates on it's edge and all is swell, right?

Well....

Mostly. Our other problem is that rudders and elevators can be fairly complex shapes. While it's a simple matter to rotate one prim in a linked object, rotating several in sync is a little more problematic.

So what's the answer?

Come on, it's me, you know that I'm going to say "sculpties" :)

If you'll harken back to the sculpty tutorial on Bounding Boxes you'll recall that we can pre-defined the space that the sculpty will take up, then resize the sculpt map to fill that space so that when it's uploaded and rezzed in SL it doesn't create a giant "no man's land" around the prim where the invisible bounding box makes it impossible to walk. We're going to do the same thing but with an extra step to create what I call an offset sculpty (I'm sure that there's a better and more official name for it, but surely by now you're realized that I'm making this up as I go).

Basically what we're going to do is create our rudder in Wings 3D just like any other sculpty. Once we're happy with the shape we'll create a bounding box and resize the rudder to fit the box, and move it so that it's exactly centered inside.

Normally at this point we'd export our sculpt map and upload it into SL, but we've got a few new steps to perform. Instead of trying to cut the sculpty once it's in SL - impossible since there's no option for cutting paths on sculpted prims - we're going to scale it down on the Z axis by 50%, then move the object so that it only fills the back half of the bounding box. Since most of this is stuff I've already covered at great long winded length, I'll just gloss over the initial steps.

Gloss gloss gloss - look, it's a simple rudder with the bounding box around it, rescaled and moved just like it's ready to export as a sculpt map!



Start out by pressing control and A to select the entire rudder.

Next right click to open the menu and select Scale / Z.

Press the Tab key and type 50 and hit Enter.

This should squish the rudder and recenter it into the middle of the bounding box.



Now we need to offset it.

Press the space bar to deselect everything.

Click the Face button at the top center of the Wings 3D window.

Now press the Z key to move the camera to the Z axis. You should be looking directly at the front of the rudder. You want to click on the single face where the blue Z axis line hits the rudder.



Once that's selected click on Tools / Center / All to move the rudder so that it's centered on that face.



And now you're set to export, upload and rez. Once the sculpty rezes you should be able to rotate it and - if we've done everything right, you'll see it pivoting on the leading edge.



Oh and remember you scaled it up to fit the bounding box in Wings 3D which means you have to scale it down some to make it look right.

Here's the finished sculpty that I uploaded for those of you NOT playing along at home:



Now that we've gone to all this trouble making an offset sculpty to use as a rudder how about next time we make it move?

Taking Wing (not Wings 3D)

So with moon landings, sculpty tutorials, and struts behind us let's get back to the Taube. My fingers are tired so I'll try to keep the next few entries on the brief side.

Let's talk about wings (and for a change NOT the 3D modeling program). There's lots of ways to make a set of wings in SL. Ranging from a single flattened prim to the swept, gull wing with angled flaps that I'm working on for my new version of one of my all time favorite vehicles - the Moewe. As with everything in the world of physical SL vehicles, the first consideration is prims. A simple wing generally means less prims, but that can also mean less detail. There are times when this is a negligible trade off and the time savings of a stretched and flattened prim vs a sculpty make it a no brainer.

Unless you're me of course. For me a sculpty is generally a simpler solution than finding a way to do the same thing with non-sculpted prims, but that's just me. Of course I pay for it when time comes to texture things but I'm very much the "live for today for tomorrow I may FINALLY learn how to bake textures onto an object in Wings 3D or Blender" sort.

What I'm getting at is use which ever construction methods are best for the project, and best for you.

Back to the topic at hand, wings. After the whole drawn out sculpted vs traditional prim debate has been resolved the next question is usually whether this is a single prim which encompasses the entire wing span, or multiple prims which are joined to create the effect.

The wings on the Taube are actually two identical sculpties. I did this so I'd have more space for wing details like the swept back tip.




The Supermarine wings are actually seven non-sculpted prims not counting the flaps. Hard to believe isn't it? Me not using sculpties. But have no fear, the fuselage, float struts, propeller and some of the highlights are sculpted (and there's a really good chance that the S6.b will be rebuilt from the ground up).




And the fairly complex Moewe II wings are a single sculpty (plus two non-sculpted prims for the flaps and two more which serve as particle emitters and turbulence dampeners). The wing shape also forms most of the upper body of the Moewe. By using a single sculpty I'm able to make it a smooth and almost organic looking object without any prim join lines.




Just going over it in my head I think I'd need between nine and 13 traditional prims to duplicate the single sculpted prim I'm using on the Moewe - plus about a billion aspirin because all those rotations would make my head ache :)

The RL Taube had a pretty massive wing span - 14 meters, and since I was trying for some level of accuracy that's what I wanted as well. The large swept back wing tips made it unlikely to impossible to craft the entire wing assembly from a single prim and preserve the amount of detail I wanted, so a two piece wing assembly it was (all glory to the person at LL who implemented the Mirror function for sculpt maps by the way).

You may have noticed that my version of the Taube lacks control surfaces on the wings. That's because the RL taube was what's known as a "wing warper". Rather than flap to adjust lift, the pilot was able to twist the shape of the wings to alter performance. This is the same method the Wrights used in their original flier and was common up until the start of WWI when the need for higher responsiveness.

In our next exciting installment we'll revisit Wings 3D a little to learn about off setting prims to make things like rudders and flaps.

Same bat time....

Same bat chan - errr, blog....

Happy Rezday to Me

Happy Rezday to Me

Meh. One thing my typist and I both share is an appalling lack of concern over our respective birthdays. But today's date is important.

20 July, 1969 is when Neil Armstrong and Buzz Aldrin landed on the moon.

Roll the words around in your head a moment. Landed. On. The moon.

It's important to me because that's where I grew up. Not the moon but more or less right next door. My father was one of thousands of civilian contractors who worked at KSC, or as it's more popularly known, Cape Kennedy. Merritt Island, Florida was essentially the on ramp that lead to the moon. Many of you watched the launch on television, I watched from the roof of out house about 17 miles from Launch Complex 39A.

Umm, and also on television because my slightly fanatical father and older brother wrestled our giant RCA up a cheap folding ladder onto the roof so we wouldn't miss anything.

Without hitting Wikipedia I can't say for sure - I think the old Soviet Vostock was larger, but the Saturn V is certainly one of the largest rockets ever launched. At the moment of lift of it's producing something like seven million pounds of thrust. And even with that it takes several seconds for the entire thing to clear the tower. Our house was over the horizon so we couldn't see the tower, but at primary ignition - that's at the seven second mark in the count down if my memory is correct - we could see the blast start to appear. At zero the horizon glowed and ground shook and we all tried to watch both the sky and the TV - no small feat since our 1960 something color TV was almost completely washed out by the glare of the sun.

In my mind I know it was probably about 10 seconds, but in my memory it was hours before we could make out Apollo XI. I'm certain that Merritt Island was one of the few places in the country where everyone was excited to get binoculars for their birthday, and of course we all had ours at the ready. I remember thinking that she looked like a grain of rice riding a pillar of flame.

Somewhere in there the secondary shock wave and the roar rolled past the house though I honestly don't recall it. Something that most people don't know - the explosive power of the fuel and liquid oxygen in a Saturn V at the moment of launch is on a par with the early atomic bombs. Even a "small" launch of a satellite or a military test produced shock waves strong enough to shatter windows if they weren't left ajar. Being a glazier in Merritt Island in the late 1960s was a growth industry.

From 17 miles away it was hard to gauge how fast she was moving. A quick factoid check tells me that two and a half minutes into the flight Apollo XI was at an altitude of about 39 miles and a distance down range of close to 55 miles. Within 12 minutes she'd reached stable orbit which means she was traveling at about 17,500 miles per hour. About 30 minutes after that she boosted to escape velocity - about 25,000 miles per hour, and transitions into the lunar transit portion of the flight.

Of course by then the show in Florida was over. Again if memory serves, flight control switches to Houston as soon as the booster clears the tower, so for us - well, our parents - it was time to get to work on Apollo XII.

Well that and to drag the TV down from the roof.

So I imagine that I'll be a little reflective today. I'll think of Laika a stray dog from the streets of Moscow who became the first space traveler. Of Yuri Gagarin the first human being to leave and safely return to Earth.

I'll think of Grissom, White, and Chaffe who died in the launch pad fire on Apollo I.

I'll think of Armstrong, Aldrin, Conrad, Bean, Shepard, Mitchell, Scott, Irwin, Young, Duke, Cernan, and Schmidt who are the only members of the most elite group in the world.

I'll think of Boorman, Anders, Staffard, Collins, Gordon, Lovell, Swiggert, Haise, Roosa, Worden, Mattingly, and Evans who came so close but didn't get to walk on the moon.

I'll think of the 502 people so far who have left the Earth and returned and for each of them the hundreds or thousands of people on the ground who make it possible.

I'll think of Walter Cronkite who never, ever was at a loss for words, speechless at the news "The Eagle has landed" - goodbye uncle Walt.

I'll think about Newton and Goddard and Von Braun who gave us the knowledge to go.

I'll think about Verne and Wells and Heinlein who gave us the fire to go.

I'll think about the X Prize and Virgin Galactic and all the other mad dreamers trying to usher in the second age of space travel by moving it to the private sector.

And I think that when the sun sets I'll take the evening off from SL and go outside and see how my old neighbor looks 40 years later.

Looking Sharp

By now you may have somehow gotten the notion that I use a lot of sculptys in my vehicles.

Well... It's true, I do. With the prim limitations on physical objects in SL the only way I can get the look I want and preserve the smooth and responsive performance of a physical vehicle is by relying heavily upon sculpties.

Happily - for me at least, my computer is on the beefy side with a sparkly new nVidia 9800 1 GB graphics card and 4 GB of RAM, so I can safely max out my video settings and - as long as I keep an extra fan blowing on the video card - things look great.

At least up close.

Welcome to the wonderful world of Level of Detail or LOD as it's more commonly called. This is what causes nice sharp edged sculptys to turn into a non-descript blobs as you move away from them. As I understand it the thought process was that by dropping the amount of detail on the sculpty at a greater distance it would reduce the amount of resources used to render it. All well and good in 2007 when there were six sculpties in all of SL, but we hates it in 2009.

Happily there is something we can do about it. Like so many other things in the SL Viewer, there is an obscure and arcane setting to change the way LOD works. It's called RenderVolumeLODFactor - no idea why so don't ask. The default setting for my system with all that RAM and sparkly video card is 1.125 - 1.125 what I can't tell you so don't ask. I've taken to keeping it at 16 - I've been told that 4 is the maximum setting, but the system accepts 16, and it seems to increase the range of the LOD blobification so that's what I use.

A quick disclaimer at the insistance of the boys down at Engulff & Devour, Esq. To the best of my knowledge changing these settings can't harm your computer, interfere with SL or cause your hair to fall out, but I'm not an expert at any of these things, so - should you choose to make the changes outlined below, you do so at your own risk.

Oh that sounds scary doesn't it?

Luckily making the LOD change takes less time to do than it takes to read how to do it - especially when I'm the one doing the writing.

We'll need to change a debug setting which is done via the Advanced menu in the SL viewer. If you don't see an Advanced menu you can activate it by pressing Control Alt and D. Once it's visible, click on Advanced and locate and click on Debug Settings.

The Debug Settings window should appear. It's drab and lacking in any sort of informative... Errr... Information. If you click on the arrow to see all the settings... Well you might feel a little overwhelmed

Luckily I know where we're going. In the white text field near the top of the window start typing RenderVolumeLODFactor. The Viewer will start filling it in as you type. In the lower portion of the Debug Settings window you should see the current setting. Make a note of that value just in case we need to go back to it.

Now it's time to change the setting. As I mentioned I've got mine set at 16 and haven't noticed any negative side effects. To be safe you might start at 4 and see how your system responds.

Oh, there's no Save or OK button in the Debug Settings window. As soon as you type something it's changed (wierd I know), so go ahead and close that window and see how your sculpties look now. Ideally you should be able to see them without blobification at two to three times the distance now. At 16 I can generally still see the details on my sculpties at the distance when the object itself starts to get too small to see.