List unique textures in a build (revisited)

As much as I love making mesh objects in-world with Mesh Studio there's one issue with this approach (and it's an issue with the approach, not really with Mesh Studio itself) that can be a bit of a pain: keeping mesh faces the same across each LOD level.

When I'm making something with Mesh Studio I have this approach (with appropriate resolution tweaks along the way):

1. Make and texture the source linkset that's exactly how the final mesh will look.
2. Shift copy it, remove any faces that I can afford to lose for the next LOD level down.
3. Shift copy #2 and start to remove more faces and even whole prims.
4. Shift copy #3 and really go crazy on removing prims and faces while keeping the same overall shape and, of course, the same number of texture and tint combinations (for those who don't know, a texture+tint combo defines a face in the resulting mesh).

The problem with this approach is that, as you start to remove faces, and especially as you start to remove prims, it's possible that you'll change the order in which the Mesh Studio script will encounter a texture+tint pair. This means, in turn, that in one of the resulting mesh objects (which are uploaded in the LOD slots in the uploader) can have the mesh faces appear to have the wrong textures.

Mostly this isn't a problem -- the lowest LOD should only really be visible from such a distance as to make textures a bit of a moot point. Thing is I've noticed, with recent Firestorms (for example), that a mesh object can sometimes get "stuck" at the lowest LOD when it first comes into view after being obscured by another large object. That in itself is a bit of a bother but it's made all the more worse if textures appear to get swapped.

So, with all that in mind, I got to thinking that I should be able to script something to help with this. While I wouldn't really be able to script my way out of the problem, I might be able to make a tool that lets me compare each of the linksets and ensure that the texture+tint combinations are all first encountered in the same order.

And then I realised that this script that I wrote later on last year more or less did the trick. The only problem with it was that the output didn't quite lend itself to easily scanning over the results and visually comparing them. So I made a few tweaks and the result is this:


First off I've made use of modern viewers' ability to hyperlink text, like this:

[http://www.google.com/ Visit Google]

Which, in local, results in:

Visit Google

Using this I've made the UUID of the texture just be the UUID while still being a hyperlink so you can view the texture online.

Secondly, I've stored the results and then try and output them in a single llOwnerSay. I say "try"... if the output will end up being too low so as to blow the 1024 limit, I then fall back to doing it line-by-line (I'm almost tempted, at this point, to do the whole thing via llHTTPResponse).

Finally, just for kicks, the colour data is now shown as RGB and it also links to a site that shows the colour.

The result of all of this is that, whereas the output of the old version of the script looked like this:

The new version looks like this:

When comparing two objects to check that the lists are the same I'm finding the latter a lot easier to quickly scan over.