New toys for scripting

It's been a while since I noticed changes to the calls available in LSL that have interested me. The last time I can think of was when llGetAgentList turned up on our region. Today's RC release adds some handy extra items to llGetEnv. Whereas before the values that could be acquired were:

dynamic_pathfinding
estate_id
frame_number
region_idle
sim_channel
sim_version

it's now been extended with:

agent_limit
estate_name
region_cpu_ratio
region_product_name
region_product_sku
region_start_time
simulator_hostname

I can see some of these new ones being handy for information and diagnostic uses. region_start_time is especially useful in that it renders part of my region restart notifier script moot (the part that lets you know when a region last restarted). It also means you can check the update of any region you're stood in by simple use of an easily-scripted HUD.

simulator_hostname also looks handy in that it pretty much replaces any need to use llGetSimulatorHostname and, in doing so, removes the forced delay cost.

I'm also a bit intrigued to see the addition of OBJECT_LAST_OWNER_ID. That could have some interesting uses.

How to make your product annoying

I've written a few times in the past how much I appreciate people who sell their products with modify permission. Sure, I get that sometimes not having modify on makes sense; the content of objects (scripts, notecards, textures, etc..) always makes sense, as does items given away as gifts or in hunts, etc. I'm fine with that. But if I'm buying something with actual money and especially if I'm going to need to fit it then modify permission is wonderful.

On the other hand, if you want to make your product annoying...

1) Make it no-modify.

2) Make sure it's something that won't fit out of the box, and see rule 1.

3) Add a resize script to it because apparently I'm incapable of resizing an object on my own.

4) For real fun and annoyance, make the maximum resize step hilariously tiny.

5) And then, just to top it off, just to make it perfect... Make sure that, when you code the resize script so that when you select the hilariously small maximum resize step, you don't have the dialog show again, thus forcing the user to have to touch the object again to get the menu up. (this of course is even more hilarious if the object in question is small enough that it's wholly embedded in the victim's customer's body so they have to force a touch from inventory)

I'm sure it could be a lot worse, but these easy 5 steps should be a good start.

Get a region's map tile URLs

Earlier today I found myself in a position of needing to grab a handful of map tiles from the Second Life map API. There's an image that needs making that requires a number of map images so grabbing them from that API made sense.

To help do this job, and to help work out what the URLs are for a given region, I knocked up this script:

Just drop it into a prim and touch the prim to get all the URLs for all the map tiles, at all zoom levels, for the current region. Alternatively, say the name of a region on channel 1 to have it do the same for that region (the script is coded to only listen to the owner).

The output looks like this:

Using a variation on this script I was able to create the image I needed without too much effort (in my case I needed to get the tiles in a specific area, at a specific zoom level, so I could paste them together to make a bigger map).

I'm starting to wonder now if using something like this, in combination with media-on-a-prim, could be used to make an in-world interactive map (yes, I know, you could just browse maps.secondlife.com on a prim but where's the fun in that?).

Potential idle-time project at some point.

Kinky dancing

As predicted back at the end of February, this blog's a fair bit quieter than it has been the past year or so. It's not that things are quiet, far from it. In the background I'm pretty busy in my Second Life, working on the usual releases while also building a mini-range I've being meaning to sort for some time. This mini-range will be held back until June when Z&A is taking part in an adult fair.

Meanwhile though I do try and ensure I get out of the workshop once or twice a week. Yesterday was one such event. Miss Eve was DJing a kink-themed dance over at VT. For me themes around Femdom and kink are Miss Eve's best sets so there was no way I was missing out on that!

As always I took a whole load of photos while there, which can be found over on imgur.

Boiled latex bunny

The first of yesterday's dances over at The Velvet Thorn was bunny-themed and Miss Eve was going to be the DJ. Given that I was progressing okay on the couple of small projects I've got going at the moment I thought I'd make a point of going.

The choice of outfit was fairly easy. I decided I'd do a sort of latex bondage bunny thing by taking the Z&A Bunny Hood and swapping out the textures for black latex, throwing on a latex catsuit and adding a pair of MD mittens to the mix. However, something was missing. I felt it needed something extra, something a little more silly.

And then, while making dinner, it came to me. When I got back to my desk I did a quick little build and...

That, of course, wasn't the only photo I took. You can see all the photos from the dance over on my imgur.

Calculate LOD switching distances

During the process of getting to the bottom of yesterday's bizarre mesh problem I got to see a really handy script in action. It dumped massive amounts of information about the mesh object it was dropped into (most of it went right over my head -- there's still a lot I need to learn about how mesh works and reacts in-world and in the viewer). One handy bit of information it gave was the distances at which the different LOD switches would happen.

I like to think I have a fairly good feel for how the different LODs for a mesh should look, and indeed when I can even leave them out. In some situations I will leave out the lowest and low LODs if I feel that they'll never be seen (although I've noticed that the lowest can often be seen very close when an object first comes into view, or first comes back into view after being hidden by another object, or looked away from; but that's a different story). This can, of course, save a ton of land impact. So normally I just mesh away, upload, make sure my viewer's RenderVolumeLODFactor is set to no more than 2 and then cam around and away like crazy and see how the object reacts and looks. This has generally served me well.

Fact is though, as is detailed in Beq's article in this issue of Prim Perfect, there's an actual calculation that can be done to know exactly what the distances are. That's just too handy and some hard numbers will always trump a vague feel. So, given that, I took what's given on the Wiki and wrote the following script to give the bare minimum information.


Hopefully that's useful to someone else too.

A solved confusing mesh issue

I finally have an answer to the confusing mesh issue that was bugging me earlier today (and has been troubling and confusing me most of my evening too). After I wrote the issue up Beq Janus was kind enough to pop over to my workshop and have a look at it with me. She helped eliminate a number of possible causes (all of which I'd not thought about) and she also helped me better understand the interplay of bounding box scale and LOD levels. Sadly though we just couldn't get to the bottom of the problem.

Eventually, later on, while trying a few things, I got desperate and copied the "problem" linkset and set it all so it only had a single texture. I meshed it and uploaded the result and the resulting mesh behaved as I'd expect it should! I could place the two mesh, side by side, and watch the 4-face one collapse far too quickly while the 1-face one would collapse at the rate I expected. Both were very different rates.

At this point Beq started asking around various groups, one of which was the Sweet Meshes group (the group that supports Mesh Studio). One of the ideas we were entertaining at this point was that it was a problem with Mesh Studio itself.

Turns out this was the best place to ask as this reply came though:

[13:51] Rey (chinrey): Sorry, just noticed the discussion here. Somebody's got problems with LOD of a 4 face mesh?
[13:51] Rey (chinrey): If so, that's an old, well documented bug
...
[13:52] Rey (chinrey): What happens is that the size along the z axis is ignored when the switch points between the LOD models are calculated

That was it! That was exactly what I was seeing! Given the description of the bug it seemed like there were two workarounds available:

[13:54] Antony Fairport: So if I throw a couple more faces into it that I don't need it should fix it?
[13:54] Antony Fairport: or....
[13:54] Antony Fairport: If I turn the build on its side and mesh it?
[13:54] Rey (chinrey): Yes, those are the two solutions
[13:54] Antony Fairport laughs -- 90deg rotation happening right now.

And that was it! That fixed it. If I took the resulting mesh, turned it upright and set it alongside the the mesh made from the exact same source linksets, only with a different rotation, it behaved!

For anyone who's interested and who, like me, doesn't know of it, here's a discussion about it. It's a very odd one but, now I know, I can always work around it in the future.

Many thanks to both Beq and Rey for their help. I would never have got this solved without them.

VT April Fool dance

Yesterday was a fairly busy time in-world for me; not only did I finally finish off a project that had started six months earlier (well, actually, more than six months earlier, but the results became visible six months earlier), I also then did a quick build I felt needed doing so I could make something fun available to people this weekend.

After getting all that done I noticed there was a "wear something silly, it's an April Fool dance" thing going on over at VT. Normally I'd just carry on pottering away in the workshop -- it's rare I go out to events at the best of times, let alone mid-week -- but I'd seen a thing on the marketplace the other day and this was the perfect time to wear it.

That and, actually, sitting back in the chair and listening to some good tunes did hold some appeal. So this was me for an hour or so:

Although I wasn't there for the whole thing, having turned up rather late, I did do my usual thing of grabbing a bunch of photos. You can find them over on imgur.

A very confusing mesh issue

As part of a very long-term Raven Park build project, I'm currently working on creating some mesh components. As usual I'm making them with Mesh Studio. Earlier today I made a mesh version of a "prototype" object to see what the land impact would be like and to also see how well it held up to being viewed at a distance. The test went well and I was satisfied with how it turned out, both in terms of how far away it could be seen and the resulting land impact.

Fast forward to later on in the day and I now have a fully-textured source linkset (the "prototype" had a single texture applied to it and so only had a single material face -- this final version has 4). I go through the usual exercise of making the 4 LOD levels and the physics shape (as I did with the prototype), throw them all through the Mesh Studio servers and upload the result. The final land impact was slightly higher than the prototype because I needed to keep some extra faces down through all the LOD levels but it was still well within what was acceptable for the build.

Here's the textured "final" mesh next to the untextured "prototype":

Aside from the textures, and a couple of very small tweaks to the size and position of one or two of the prims that made the source linkset, they're identical. Their overall sizes are identical (< 0.6, 0.6, 7.501 > in both cases).

Only... as I start to cam away things start to differ. At around 18m away from the objects this happens:

(forgive the quality -- this is a scaled up crop, for obvious reasons). What's happened is that the "prototype" is still showing either the high or medium LOD model (it's pretty much impossible to tell which just from looking -- which is how I try and design the medium LOD) whereas the "final" object has already dropped to the low LOD. Not much further away and the "final" drops to the lowest whereas the "prototype" seems to stick with the high or medium all the way to the edge of my draw distance (which I normally have at 128).

I just can't fathom it. I've tried tweaking the source linkset and looking for any differences between the "prototype" and "final" and.... I can't see what the issue is.

I've even gone so far as going over the mesh steaming cost article on the wiki, via the mesh LODs article by Beq Janus in this magazine, to try and calculate what should be happening. That, however, has left me a little more confused. In both cases they talk about the radius of the bounding box but the concept of the radius doesn't seem to be defined anywhere (I know what a radius is, of course, but when the object in question doesn't have a bounding box whose ratios are 1:1:1 it helps to know exactly how it's defined). That issue aside though, it seems clear that two mesh objects with the same sized bounding box should collapse to the next LOD down at the same time at any given camera distance.

Shouldn't they?

Edit to add: I finally got to the bottom of this, with the help of others.