Yesterday afternoon Mistress had reason to play around with flexible path values for a linkset. In doing so she mentioned that it was a bit of a pain to have to set the parameters individually for each item in the linkset. Never having really played with this before, I was a little surprised to find that it's a prim parameter that you can't set on more than one prim at once; especially given it's one you can set on more than one prim at once from a script.
So, for fun, I knocked up a little tool that would let her experiment quickly and easily. Z&A Flex Linkset was born:
The script is designed so that it listens to the object owner in local chat, and accepts commands for setting the different parameters. When a parameter is given it's applied to the whole linkset. Commands include:
flex soft <value>
flex grav <value>
flex drag <value>
flex wind <value>
flex ten <value>
flex fx <value>
flex fy <value>
flex fz <value>
As well as commands for setting the flexible path parameters, there are also commands for controlling the script itself. To see the current parameters:
flex show
To reset the parameters to their default:
flex reset
And when you're done with the script and you want it to remove itself from the object:
flex done
And that's it. It was fun to knock together, Mistress had fun playing around with it, hopefully it's of some use to someone else too.
Showing posts with label Building. Show all posts
Showing posts with label Building. Show all posts
2017-11-06
2017-09-20
New workshop
It's around six years since I last made a new workshop. The one I made back in 2011 has served me well. It's had a few tweaks along the way, but it has mostly stayed the same. The one big change was the addition of a big platform surrounding it so that I could do lots of testing when I originally started work on the Z&A vehicles.
Given that I've recently rewritten the Z&A vehicle system I've being spending a lot of time out on that platform, and will continue to do so for a good few weeks yet as I carry on making "refits" of the existing vehicles (and also building some new ones -- do keep an eye on the Z&A blog of that's of interest to you). Because of this it's bugged me slightly that the vehicle development/test platform wasn't really "part" of the workshop. It surrounded it, I could get to it from the workshop, but I could only do that by walking through a phantom wall. For some time I've wanted an actual door, or something.
So, yesterday, I finally cracked and built a brand new workshop from the ground up. I started with the platform, made a sort of "garage" area as the base of the workshop, and then built up from there. It ended up being quite a big structure!
The build itself is a mixture of prims and mesh. It's mostly prims (so I can rez other prims against floors, walls, ceilings, etc, without any sort of rezzing errors) but with a bit of mesh here and there to help keep the land impact down on the more complex shapes. Normally the "complex shape" thing would not be a problem, but I also wanted to add some materials too, which meant everything would end up under the newer land impact accounting system -- LI20 or more for a single cut/hollowed prim is a bit much after all.
Internally it's still similar to all the old workshop layouts. There's a main floor for normal build activities that also has a mezzanine floor for me to hang out on while working on small stuff and while scripting.
Above the main build floor is another build floor aimed at working on cells, and then above that is a photo studio (which is all black, as I prefer for the background for my vendor boards).
Now to get back to working on the vehicle upgrades, the gifts for the Femdom Hunt VII, and working on the hunt itself.
Plus any new project I dream up in the next few months...
Given that I've recently rewritten the Z&A vehicle system I've being spending a lot of time out on that platform, and will continue to do so for a good few weeks yet as I carry on making "refits" of the existing vehicles (and also building some new ones -- do keep an eye on the Z&A blog of that's of interest to you). Because of this it's bugged me slightly that the vehicle development/test platform wasn't really "part" of the workshop. It surrounded it, I could get to it from the workshop, but I could only do that by walking through a phantom wall. For some time I've wanted an actual door, or something.
So, yesterday, I finally cracked and built a brand new workshop from the ground up. I started with the platform, made a sort of "garage" area as the base of the workshop, and then built up from there. It ended up being quite a big structure!
The build itself is a mixture of prims and mesh. It's mostly prims (so I can rez other prims against floors, walls, ceilings, etc, without any sort of rezzing errors) but with a bit of mesh here and there to help keep the land impact down on the more complex shapes. Normally the "complex shape" thing would not be a problem, but I also wanted to add some materials too, which meant everything would end up under the newer land impact accounting system -- LI20 or more for a single cut/hollowed prim is a bit much after all.
Internally it's still similar to all the old workshop layouts. There's a main floor for normal build activities that also has a mezzanine floor for me to hang out on while working on small stuff and while scripting.
Above the main build floor is another build floor aimed at working on cells, and then above that is a photo studio (which is all black, as I prefer for the background for my vendor boards).
Now to get back to working on the vehicle upgrades, the gifts for the Femdom Hunt VII, and working on the hunt itself.
Plus any new project I dream up in the next few months...
2016-07-08
Parcel Settings Checker
This is something I wrote earlier this year, and which I wish I'd thought to write a lot sooner. On Raven Park there's a handful of plots that are for rent and, as part of those rentals, there's a few rules to keep things safe and clean. Two big ones are that you don't have public build turned on, and that you also don't have ban lines (security tools are fine -- but no ban lines please, they're ugly!). So, of course, every so often, I had to fly around the region and check settings.
Which was a silly thing to do when I could have a script do the job for me! It was quick and easy to write and I thought I should finally publish it here in case it was useful to someone:
Of course, what you should do is change the value of EMAIL_REPORT_TO so that it points to an email address you want the report sent to (or leave it empty if you'd prefer it to be sent via IM). If you want to check other settings on a plot you can modify the code of ReportOnParcelAt. As it's written it does a check every six hours. If you want to change that just modify the value passed to llSetTimerEvent.
Hope it's helpful to someone else.
Which was a silly thing to do when I could have a script do the job for me! It was quick and easy to write and I thought I should finally publish it here in case it was useful to someone:
Of course, what you should do is change the value of EMAIL_REPORT_TO so that it points to an email address you want the report sent to (or leave it empty if you'd prefer it to be sent via IM). If you want to check other settings on a plot you can modify the code of ReportOnParcelAt. As it's written it does a check every six hours. If you want to change that just modify the value passed to llSetTimerEvent.
Hope it's helpful to someone else.
2016-04-25
A little adventure in live-editing a mesh body glitch layer
The other weekend the Raven Park dance was prison-themed. It was decided that I should go as Toni and that it would be fun to find a Toni-appropriate prison uniform. That, of course, meant something fairly revealing because.... why the hell else would you buy a Maitreya Lara mesh body? ;)
Sadly though, after a lot of searching, including looking for a specific size of gacha item at various gacha resale markets, nothing could be found. So Mistress decided to custom-make a uniform for me. We ended up with a full-perm mesh template that said it was Maitreya compatible and Mistress made just the perfect texture for it. The final result looked like this:
The problem with it, however, was that it didn't really fit that well. Despite saying it was Maitreya compatible my body was clipping out of it all over the place; with all possible alpha cuts turned alpha it still wasn't right and no amount of shape-changing really solved the problem. We were still seeing the problem even with the "standard" Maitreya shapes. It was going to be no good for dancing.
So Mistress then suggested that she make a glitch applier for it. Normally if an item of mesh clothing doesn't fit I'll bin the demo and not bother; with this however it was a case of wanting to make the right look for a two hour dance so a compromise using a glitch layer made sense.
The plan seemed sound, but how could Mistress get it made without too much faff? To start with I quickly made an applier version (using the dev kit that Maitreya provide in their main store) of the famous "Robin (Sojourner) Wood UV Suit" and put that on so Mistress stood a chance of working out where to place textures.
That was a start, but it was still going to mean a bit of faff uploading textures and trying them out. What she really needed was to be able to live-edit the texture; but to make that happen she'd need to be able to use a local texture as an applied texture on the mesh body and there's no direct way to do that.
I did realise, however, that there was an indirect way.
So, first thing I did for her was write this simple script and pass it to her:
She then dropped that in a cube she rezzed in-world and then textured the cube with a local texture version of the glitch layer. After that she touched the cube and it gave her the UUID of the local texture.
So far so good.
Next I got her to rez another cube and drop the "Maitreya Applier Script - V2 0.10" script from the Maitreya dev kit inside it. This was now the applier prim.
Now for the final step. I had Mistress make a copy of the "Maitreya Texture Loader - Body Overlay V2" notecard and edit it to apply the UUID of the local texture to the top of the mesh body:
All she had to do then was drop the notecard inside the applier prim, let it read it, touch it, apply the texture to the relevant layer and.... done! At that point she had the local texture applied to her body and any change she made was reflected almost instantly on her Maitreya Lara body.
A bit of image editing later and Mistress had the glitch layer sorted; she passed me the texture, I made an applier for it and I was sorted:
At this point I could wear the dress and not worry (too much) about bits of my body clipping through because they were the same colour.
It is, of course, kind of amusing that we had to make glitch pants of old for a nice new mesh body and mesh dress, but it got the outfit sorted and worked a treat. Mistress had fun making a thing and I had fun cobbling together a method that let her live-edit an applier layer.
While nothing I came up with is especially clever or new -- I'm sure others have figured this out before -- I thought it might be handy writing it up here in case anyone else went looking for a way to do this.
Sadly though, after a lot of searching, including looking for a specific size of gacha item at various gacha resale markets, nothing could be found. So Mistress decided to custom-make a uniform for me. We ended up with a full-perm mesh template that said it was Maitreya compatible and Mistress made just the perfect texture for it. The final result looked like this:
The problem with it, however, was that it didn't really fit that well. Despite saying it was Maitreya compatible my body was clipping out of it all over the place; with all possible alpha cuts turned alpha it still wasn't right and no amount of shape-changing really solved the problem. We were still seeing the problem even with the "standard" Maitreya shapes. It was going to be no good for dancing.
So Mistress then suggested that she make a glitch applier for it. Normally if an item of mesh clothing doesn't fit I'll bin the demo and not bother; with this however it was a case of wanting to make the right look for a two hour dance so a compromise using a glitch layer made sense.
The plan seemed sound, but how could Mistress get it made without too much faff? To start with I quickly made an applier version (using the dev kit that Maitreya provide in their main store) of the famous "Robin (Sojourner) Wood UV Suit" and put that on so Mistress stood a chance of working out where to place textures.
That was a start, but it was still going to mean a bit of faff uploading textures and trying them out. What she really needed was to be able to live-edit the texture; but to make that happen she'd need to be able to use a local texture as an applied texture on the mesh body and there's no direct way to do that.
I did realise, however, that there was an indirect way.
So, first thing I did for her was write this simple script and pass it to her:
She then dropped that in a cube she rezzed in-world and then textured the cube with a local texture version of the glitch layer. After that she touched the cube and it gave her the UUID of the local texture.
So far so good.
Next I got her to rez another cube and drop the "Maitreya Applier Script - V2 0.10" script from the Maitreya dev kit inside it. This was now the applier prim.
Now for the final step. I had Mistress make a copy of the "Maitreya Texture Loader - Body Overlay V2" notecard and edit it to apply the UUID of the local texture to the top of the mesh body:
All she had to do then was drop the notecard inside the applier prim, let it read it, touch it, apply the texture to the relevant layer and.... done! At that point she had the local texture applied to her body and any change she made was reflected almost instantly on her Maitreya Lara body.
A bit of image editing later and Mistress had the glitch layer sorted; she passed me the texture, I made an applier for it and I was sorted:
At this point I could wear the dress and not worry (too much) about bits of my body clipping through because they were the same colour.
It is, of course, kind of amusing that we had to make glitch pants of old for a nice new mesh body and mesh dress, but it got the outfit sorted and worked a treat. Mistress had fun making a thing and I had fun cobbling together a method that let her live-edit an applier layer.
While nothing I came up with is especially clever or new -- I'm sure others have figured this out before -- I thought it might be handy writing it up here in case anyone else went looking for a way to do this.
2015-10-28
The Scarecrow
There's actually a bit of a story behind 2 of the 3 gifts made available by Z&A in The Femdom Hunt VI. One of them is intended for subs and is one of Z&A's 2 gifts. The other is intended for Dommes (or subs -- subs can own things to get locked on, or so I'm told) and is the Raven Park gift. Their design is inspired by a picture I've known for a long time and which Mistress has loved since she first saw it back in July.
Given that there's a fair bit of work goes into planning TFH I try and decide and make the Z&A and Raven Park gifts as early as possible. This year I wasn't quite sure what to do. But when Mistress fell in love with an image from Xrenderer, called Scarecrow, I had an idea: I'd make it for her, in SL, and it would then be one of the gifts.
As well as making the actual device I also made what appear to be the nipple bells the sub is wearing in the image.
She was, and is, delighted.
Last night we finally got around to doing something we've being meaning to do since I got to work on the build: recreate the scene, in our own way, in Second Life. Here's the result:
It's not a perfect one-for-one; it's not really intended to be. It is us, with things we made and gathered, and together we created our own version. It's not a perfect one-for-one, but it was perfectly fun to do.
And now a version of it is above the fireplace of the new house (which I should write about at some point).
Given that there's a fair bit of work goes into planning TFH I try and decide and make the Z&A and Raven Park gifts as early as possible. This year I wasn't quite sure what to do. But when Mistress fell in love with an image from Xrenderer, called Scarecrow, I had an idea: I'd make it for her, in SL, and it would then be one of the gifts.
As well as making the actual device I also made what appear to be the nipple bells the sub is wearing in the image.
She was, and is, delighted.
Last night we finally got around to doing something we've being meaning to do since I got to work on the build: recreate the scene, in our own way, in Second Life. Here's the result:
It's not a perfect one-for-one; it's not really intended to be. It is us, with things we made and gathered, and together we created our own version. It's not a perfect one-for-one, but it was perfectly fun to do.
And now a version of it is above the fireplace of the new house (which I should write about at some point).
2015-04-29
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.
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.
2015-04-04
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.
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.
2015-04-03
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.
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.
2015-04-02
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.
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.
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.
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.
2015-03-27
Quick steps maker
While contemplating an upcoming build the other day the idea for this script popped into my head and, having thought of it, I had to knock it together quickly. Like a few other scripts I've put on here this stems from my use of Mesh Studio, where I'll make mesh objects in-world from lots of prims. This time around I wanted to make some simple stairs.
I've done this before and it's easy enough: rez and size a prim, copy it, move it to the next spot, copy, move to the next spot, and so on. But it'd be easier done with a script, right?
So the Z&A Quick Steps Maker was born. With this you simply rez out as many cubes as you want steps:
Link all the cubes and drop the script into the root prim. When you do so it'll texture the "top" face of the root so you know what direction the stairs will build in.
Next, size the root prim to the size of a step.
Once you're happy with it, touch the linkset and...
...the steps build themselves. If it doesn't quite look right all you need to do is resize the root prim to taste...
...and touch again to have the stairs rebuild:
Of course, a far more sophisticated system could be made where an object rezzes other objects out, building the stairs for you dynamically (could be something like that even exists -- I've not bothered to look), but that wasn't the point of this script. The point here was to knock up something that works quickly and easily for those times where you know what it is you're doing but you just want to save some fingerwork. It also means that there's no need to consider things like the grey-goo fence as it's you making all the prims up front.
Anyway, on the off chance that it's useful to anyone else, here's the script:
I've done this before and it's easy enough: rez and size a prim, copy it, move it to the next spot, copy, move to the next spot, and so on. But it'd be easier done with a script, right?
So the Z&A Quick Steps Maker was born. With this you simply rez out as many cubes as you want steps:
Link all the cubes and drop the script into the root prim. When you do so it'll texture the "top" face of the root so you know what direction the stairs will build in.
Next, size the root prim to the size of a step.
Once you're happy with it, touch the linkset and...
...the steps build themselves. If it doesn't quite look right all you need to do is resize the root prim to taste...
...and touch again to have the stairs rebuild:
Of course, a far more sophisticated system could be made where an object rezzes other objects out, building the stairs for you dynamically (could be something like that even exists -- I've not bothered to look), but that wasn't the point of this script. The point here was to knock up something that works quickly and easily for those times where you know what it is you're doing but you just want to save some fingerwork. It also means that there's no need to consider things like the grey-goo fence as it's you making all the prims up front.
Anyway, on the off chance that it's useful to anyone else, here's the script:
2015-03-09
RLV REPL
This script is being filed under "why the heck didn't I think of this before?" as well as "surely someone else has done this, I wonder why I've never seen it before?"
A little earlier today I found myself needing to quickly test a handful of different RLV commands. Now, as I have done over the past 5 years, I could have made a script, ran it, changed it, ran it again, changed it some more, run it again, etc... Really though, that gets rather tedious. And then it hit me! What I really need is a RLV REPL.
What I came up with isn't a REPL in the strictest sense but it more or less does the job. Rez a cube, throw the script inside and then touch it to turn it on (it'll be obvious when it's on and off). In the on state it listens to all local chat by the object owner and, if the text starts with an @, it repeats it via llOwnerSay. Instant quick and dirty RLV command line/REPL thing!
This should save me a bit of faffing about the next time I want to test something.
A little earlier today I found myself needing to quickly test a handful of different RLV commands. Now, as I have done over the past 5 years, I could have made a script, ran it, changed it, ran it again, changed it some more, run it again, etc... Really though, that gets rather tedious. And then it hit me! What I really need is a RLV REPL.
What I came up with isn't a REPL in the strictest sense but it more or less does the job. Rez a cube, throw the script inside and then touch it to turn it on (it'll be obvious when it's on and off). In the on state it listens to all local chat by the object owner and, if the text starts with an @, it repeats it via llOwnerSay. Instant quick and dirty RLV command line/REPL thing!
This should save me a bit of faffing about the next time I want to test something.
2015-02-19
Show face numbers
This is a script that actually started out life as a set of textures, which got made while I was exploring the workings of "Smart Objects" in Photoshop.
The idea behind the script is pretty simple: drop it in a prim or the root of a linkset and it'll texture every face with a number to show the face number. Nothing clever. Nothing you'd want to do to an item where you didn't want to destroy the existing textures. Nothing you can't really do in a reasonable viewer (most of the time -- this does help solve the problem of getting at mesh faces that are almost impossible to touch). On the other hand, sometimes, when you're coding, having a nice big visual reminder on the screen in front of you isn't such a bad thing.
The script itself doesn't self-delete, but it does refresh the textures if the prim changes or more items are linked to it.
Here's the script:
The idea behind the script is pretty simple: drop it in a prim or the root of a linkset and it'll texture every face with a number to show the face number. Nothing clever. Nothing you'd want to do to an item where you didn't want to destroy the existing textures. Nothing you can't really do in a reasonable viewer (most of the time -- this does help solve the problem of getting at mesh faces that are almost impossible to touch). On the other hand, sometimes, when you're coding, having a nice big visual reminder on the screen in front of you isn't such a bad thing.
The script itself doesn't self-delete, but it does refresh the textures if the prim changes or more items are linked to it.
Here's the script:
2015-02-16
A little bit of building
After a weekend of not seeing each other Mistress and I met up in-world for a short while earlier today. One reason was so that I could give her back the keys to my ankle cuffs.
The reason why I had them at all is that, over the weekend, there was a mishap that involved a bug in Firestorm (in which my favourite thing -- Project Interesting -- is implicated) which in turn meant my ankle cuffs got knocked off, which in turn meant they acquired the "he's tried to escape!" alarm hover text that RR cuffs do by default (normally it's turned off but I'd recently upgraded the cuffs and all settings got reverted), which in turn meant I needed to do a RealKey dance with my stunt double to clear the message (something Mistress was happy with me doing).
Having explained all of that to her we did a little bit more work on our background build project. It was just a quick bit of building but it's set me up to be able to get to work on my part of the project.
I'm not sure when I'll get to it during this week, but I hope to make a start. This week will mostly be taken up with planning for Saturday's event.
Because in-world time was in short supply today Mistress also decided to not collect on any of my allowance payments. The list stays rather long, for now.
The reason why I had them at all is that, over the weekend, there was a mishap that involved a bug in Firestorm (in which my favourite thing -- Project Interesting -- is implicated) which in turn meant my ankle cuffs got knocked off, which in turn meant they acquired the "he's tried to escape!" alarm hover text that RR cuffs do by default (normally it's turned off but I'd recently upgraded the cuffs and all settings got reverted), which in turn meant I needed to do a RealKey dance with my stunt double to clear the message (something Mistress was happy with me doing).
Having explained all of that to her we did a little bit more work on our background build project. It was just a quick bit of building but it's set me up to be able to get to work on my part of the project.
I'm not sure when I'll get to it during this week, but I hope to make a start. This week will mostly be taken up with planning for Saturday's event.
Because in-world time was in short supply today Mistress also decided to not collect on any of my allowance payments. The list stays rather long, for now.
2015-02-09
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):
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.
When I'm making something with Mesh Studio I have this approach (with appropriate resolution tweaks along the way):
- Make and texture the source linkset that's exactly how the final mesh will look.
- Shift copy it, remove any faces that I can afford to lose for the next LOD level down.
- Shift copy #2 and start to remove more faces and even whole prims.
- 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).
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.
2015-02-06
Updates
Last night, after I finally got out of the mittens, I set about a job I've being meaning to do for some time now. I set about updating my collar:
While, these days, most of Mistress' general RLV needs are served by the Z&A SubHUD, we still use OpenCollar scripts in the collar because it's handy to have another device that can apply some restrictions (my tattoo layers are perma-locked by the collar, for example) and, generally, the OC relay has served me well. On top of this I find the posing system in the collar very handy and it's where the kneel I made for Mistress lives.
I don't think I've updated my collar in the (just over) 2 years I've being wearing it and a lot has changed with OC code in that time. So, rather than try and do an update with the updater, I took a copy of the collar, grabbed a collar from an OC vendor and pulled all the scripts over and redid all the settings (which was kind of vital given that the names of settings in the defaultsettings notecard appear to have changed).
After passing a copy to my "stunt double" avatar to check that the position and size was still fine and that the kneel position was good, while also checking that the relay was behaving, etc, I tucked this new version away in my inventory for today.
Earlier today, when Mistress and I met in world, we went into her office and I knelt before her so she could unlock the collar...
...and put the new version in place. The nice thing about this new version is that, supposedly, it can be updated in place, while wearing it, without the need to even unlock it. If that works that'll make a very nice change from the old days of having to unlock it, remove it, rez it on the ground and then update it.
Once locked we also took the time to update my copy of the Z&A SubHUD too. We released v1.6 a week ago and my v1.5 was still locked on me.
So, as of now, I'm all sorted with an up-to-date collar and an up-to-date SubHUD.
While, these days, most of Mistress' general RLV needs are served by the Z&A SubHUD, we still use OpenCollar scripts in the collar because it's handy to have another device that can apply some restrictions (my tattoo layers are perma-locked by the collar, for example) and, generally, the OC relay has served me well. On top of this I find the posing system in the collar very handy and it's where the kneel I made for Mistress lives.
I don't think I've updated my collar in the (just over) 2 years I've being wearing it and a lot has changed with OC code in that time. So, rather than try and do an update with the updater, I took a copy of the collar, grabbed a collar from an OC vendor and pulled all the scripts over and redid all the settings (which was kind of vital given that the names of settings in the defaultsettings notecard appear to have changed).
After passing a copy to my "stunt double" avatar to check that the position and size was still fine and that the kneel position was good, while also checking that the relay was behaving, etc, I tucked this new version away in my inventory for today.
Earlier today, when Mistress and I met in world, we went into her office and I knelt before her so she could unlock the collar...
...and put the new version in place. The nice thing about this new version is that, supposedly, it can be updated in place, while wearing it, without the need to even unlock it. If that works that'll make a very nice change from the old days of having to unlock it, remove it, rez it on the ground and then update it.
Once locked we also took the time to update my copy of the Z&A SubHUD too. We released v1.6 a week ago and my v1.5 was still locked on me.
So, as of now, I'm all sorted with an up-to-date collar and an up-to-date SubHUD.
2015-01-30
Before I was unlocked...
I think I got use to the environment of the tkISO suit much quicker this time when compared to last time. Although I did feel rather restrained by it last night I did manage to get a fair bit of building and scripting done on a (non-RLV) pet project that I'm working on at the moment. I had to leave some final texture decisions until I was unlocked, but I got things done.
Waking up in-world this morning was actually rather enjoyable though. There's something about the combination of ALM and the environment of the suit that makes SL look kind of awesome.
As of the time of writing though I'm out of the suit.
Mistress and I got to spend quite a bit of time together today, working on our background join pet project. It's coming along really nicely and, as normally happens, is heading off in a totally different direction than we'd first planned. Which is what makes it all the more fun. There's nothing I enjoy more, nothing that makes me feel more proud to be hers, than when we both riff off each other and see where our heads take us.
Waking up in-world this morning was actually rather enjoyable though. There's something about the combination of ALM and the environment of the suit that makes SL look kind of awesome.
As of the time of writing though I'm out of the suit.
Mistress and I got to spend quite a bit of time together today, working on our background join pet project. It's coming along really nicely and, as normally happens, is heading off in a totally different direction than we'd first planned. Which is what makes it all the more fun. There's nothing I enjoy more, nothing that makes me feel more proud to be hers, than when we both riff off each other and see where our heads take us.
2015-01-21
Out of the boots
Today, a couple of days later than originally planned, because Mistress seemed to rather enjoy seeing me stumble around the place, I was finally released from the ballet boots.
Once unlocked I slipped them off, alone with the stockings, gloves and pants.
Mistress, being the caring person that she is, was concerned that over a week in the ballet boots might have hurt my feet. Seems she had just the solution too.
So that's spending a RL day locked in a hogtie knocked off the allowance payment list.
Once all that was sorted we embarked on something we've not done for quite a while...
Plans are being planned and prims are being rezzed. A big build project is now under way! This will likely be a slow and steady project but one that should be fun and very worthwhile.
Once unlocked I slipped them off, alone with the stockings, gloves and pants.
Mistress, being the caring person that she is, was concerned that over a week in the ballet boots might have hurt my feet. Seems she had just the solution too.
So that's spending a RL day locked in a hogtie knocked off the allowance payment list.
Once all that was sorted we embarked on something we've not done for quite a while...
Plans are being planned and prims are being rezzed. A big build project is now under way! This will likely be a slow and steady project but one that should be fun and very worthwhile.
2015-01-06
More prim/FS/PI oddness
A little earlier I was setting up this week's releases in the shop. As usual we normally set the boards up in the workshop (or, in this case, out on the build platform in front of the workshop seeing as how there was rather a lot of them this time) and then, when I'm ready to move them to the shop, I pick a point in the shop and paste the coordinates into each of the boards to send them down.
Keep in mind the workshop is a couple of km above the shop.
So I send all 8 boards down and then take the TP pad down to the shop. They're not there! I go back up to the workshop and they're still up there! So I send them down again, go down after them and... they're not there! This time I head back up to the workshop and also log the shop alt in on the last version of Firestorm that doesn't have Project Interesting as part of it.
Here's what I see in Firestorm 4.6.9:
Keep in mind that it's the bottom row I'd sent down, yet they appeared to be still up on the build platform. Now, the same scene as seen at the same time by the shop alt you can see in the picture above:
And, sure enough, when I sent him down to the shop the boards I'd sent down were down there, for him.
I relogged to find the boards in the shop too.
I give in...
Keep in mind the workshop is a couple of km above the shop.
So I send all 8 boards down and then take the TP pad down to the shop. They're not there! I go back up to the workshop and they're still up there! So I send them down again, go down after them and... they're not there! This time I head back up to the workshop and also log the shop alt in on the last version of Firestorm that doesn't have Project Interesting as part of it.
Here's what I see in Firestorm 4.6.9:
Keep in mind that it's the bottom row I'd sent down, yet they appeared to be still up on the build platform. Now, the same scene as seen at the same time by the shop alt you can see in the picture above:
And, sure enough, when I sent him down to the shop the boards I'd sent down were down there, for him.
I relogged to find the boards in the shop too.
I give in...
2015-01-02
Firestorm, Interesting and a RLV(a) issue?
I'll start out by making it very clear that this is nothing more than me jotting down something I found and noting my internal speculation about the causes. What I'm thinking (and this post is just me thinking out loud) could be (likely is) completely wrong; but I think it's worth noting down anyway.
At the moment I'm working away on building the new range of Z&A RLV cells while retiring the old ones. Given that they all contain the same script engine there's not a lot of scripting to be doing with that. Sure, there's the odd cell-specific plugin to write here and there but generally nothing I'd call "fun". The bulk of the work is prim-flinging and meshing, something I really enjoy, but it's not scripting, which I really enjoy.
A few days back, when I suddenly couldn't fling prims around so well, I did what I often do in that situation: I rezzed out a cube, got cosy with it and started scripting. This time the idea was to finally do a complete re-write of another early Z&A product to make it better and different. One of the RLV API features it makes use of is the @sit command. While working on that bit of code I decided to have a play and see just how far away (on a region) an object can be before the force sit fails.
[Caution, vague non-technical terms follow]
Keep in mind, at this point, that objects exist in two places in SL. They exist on the server and so exist as things that can be seen by scripts (because scripts live and run server-side). They also exist client-side in the sense that there's a list of "stuff" your viewer knows exists at any given time. Hence the reason why it's always suggested that people have sensible draw distances otherwise you end up potentially wasting a lot of memory and bandwidth loading up lots of objects and textures and the like that you can't really "see".
In the script I was toying with I check that any given object that is a potential sit target actually exists. Of course, the object my script is in and the object I'm verifying might be a few thousand meters apart but the script can still get information about it. RLV, on the other hand, being a body of code that exists only in the viewer, can presumably only ever deal with objects known to the viewer at any given time. Given these facts I sort of assumed that @sit might fail for objects not in draw distance.
Turns out it's a little more complex than that.
Having satisfied my curiosity that things near (the avatar/camera) can be @sit targets and things a long way away can't be (in my case a handful of things in the workshop, where I was stood, vs a chair in Mistress' house, which is about 2km away from the workshop) I got on with writing the code.
Yesterday, while doing some testing, I noticed a very curious thing. One of the target objects, which was near me (and well within my draw distance, about 33m away from where I'd have been stood when the @sit request was sent), just wasn't working. Or, more to the point, the @sit request was coming back as "ok" from my relay but I wasn't being sat.
After double-checking the code I then turned on RLVa debug messages in Firestorm and saw messages like this:
This is the point at which I started to suspect that it might be related to Project Interesting. I won't claim to know anything about how PI works other than what has been mentioned at a high level, but one thing I seem to recall reading is that it tries to do a good job of only loading/holding details of objects you can actually see. So an unobscured object in a scene, that's on the very edge of your draw distance, will be known to the viewer. On the other hand an object close by but obscured by other things won't be.
I guess you can see where my thinking was going at this point: like I said, the problem object, although only 33m away, was obscured by a floor and a wall from my location.
So, to test this idea (that it was about things being obscured, not that it's PI directly to blame), I made a little test rig on the platform outside the workshop. First I made a 3-prim object like this:
The blue bar is the root and is called "Force Sit". The two arrows are named with the UUID of two objects 23m either side of the object. Inside the root is the following code:
The idea is simple: stand at the arrows and click an arrow to be force sat on the object that's in that direction. The difference between the two objects is that one of them is in the clear while the other is obscured:
by two hollowed out cubes, one inside the other:
Initial testing never had a failure. But, I'm guessing, my viewer would "know" about the target object even when obscured and wouldn't bother dumping the data when it was fairly close by. Even heading down to the ground, walking about, and coming back up didn't make a difference. It all still just worked.
So I decided to leave it alone, all sat outside the workshop, and test it again the next time I logged in. Which I did this morning.
I got into the workshop, walked out onto the platform, detached my camera from my avatar using flycam so that my camera would stay about 38m from the arrows and about 45m from each of the target objects, and did the test.
First I touched the green arrow, which would attempt to force sit me on the object that I could see. That worked just fine.
Next I touched the red arrow, which would attempt to force sit me on the object that I couldn't see as it was inside the boxes. Nothing. I didn't move. One again I turned on RLVa debug messages and, sure enough...
It still failed. I then raised and tilted a little more until just one corner of the object was visible:
...and this time the test worked. I was force sat on the object inside the box.
That seemed to pretty clearly demonstrate it: object distance from your avatar, or your camera position, isn't the only thing that will affect how a @sit works -- it's also about if the object in question is obscured.
Keep in mind too, as mentioned above, that a relay will still reply that the operation worked "ok", but the avatar won't be sat and internally the sit will be seen as a failure (something that can of course be overcome by use of @getsitid).
The point of all of this? Well, like I said at the start, there's no actual conclusion to this; I just felt the need to document a curious problem that I'd run into and how I looked into it and what I found. It feels like it's something related to what Project Interesting has done although, of course, I'm not sure. I've also not tested this (so far) with any viewer other than Firestorm 4.6.9.
What I do know is that, if and when this code becomes a released product, this effect is something I might need to note in the documentation. People might see the product work fine on some victims but not on others and there'll be no obvious reason why this is the case.
At the moment I'm working away on building the new range of Z&A RLV cells while retiring the old ones. Given that they all contain the same script engine there's not a lot of scripting to be doing with that. Sure, there's the odd cell-specific plugin to write here and there but generally nothing I'd call "fun". The bulk of the work is prim-flinging and meshing, something I really enjoy, but it's not scripting, which I really enjoy.
A few days back, when I suddenly couldn't fling prims around so well, I did what I often do in that situation: I rezzed out a cube, got cosy with it and started scripting. This time the idea was to finally do a complete re-write of another early Z&A product to make it better and different. One of the RLV API features it makes use of is the @sit command. While working on that bit of code I decided to have a play and see just how far away (on a region) an object can be before the force sit fails.
[Caution, vague non-technical terms follow]
Keep in mind, at this point, that objects exist in two places in SL. They exist on the server and so exist as things that can be seen by scripts (because scripts live and run server-side). They also exist client-side in the sense that there's a list of "stuff" your viewer knows exists at any given time. Hence the reason why it's always suggested that people have sensible draw distances otherwise you end up potentially wasting a lot of memory and bandwidth loading up lots of objects and textures and the like that you can't really "see".
In the script I was toying with I check that any given object that is a potential sit target actually exists. Of course, the object my script is in and the object I'm verifying might be a few thousand meters apart but the script can still get information about it. RLV, on the other hand, being a body of code that exists only in the viewer, can presumably only ever deal with objects known to the viewer at any given time. Given these facts I sort of assumed that @sit might fail for objects not in draw distance.
Turns out it's a little more complex than that.
Having satisfied my curiosity that things near (the avatar/camera) can be @sit targets and things a long way away can't be (in my case a handful of things in the workshop, where I was stood, vs a chair in Mistress' house, which is about 2km away from the workshop) I got on with writing the code.
Yesterday, while doing some testing, I noticed a very curious thing. One of the target objects, which was near me (and well within my draw distance, about 33m away from where I'd have been stood when the @sit request was sent), just wasn't working. Or, more to the point, the @sit request was coming back as "ok" from my relay but I wasn't being sat.
After double-checking the code I then turned on RLVa debug messages in Firestorm and saw messages like this:
Antony's Collar: failed: @sit:{uuid}=force (invalid option)(where {uuid} was the UUID of the object, of course). Now, the object in question wasn't in my direct line of sight; it was obscured by a floor and a wall. But, like I say, it was just 33m away from me. Unsure what was going on I cammed out to it, grabbed the UUID of it again and double-checked and, sure enough, it was the right UUID. I tested again and it worked without me having changed anything in the code!
This is the point at which I started to suspect that it might be related to Project Interesting. I won't claim to know anything about how PI works other than what has been mentioned at a high level, but one thing I seem to recall reading is that it tries to do a good job of only loading/holding details of objects you can actually see. So an unobscured object in a scene, that's on the very edge of your draw distance, will be known to the viewer. On the other hand an object close by but obscured by other things won't be.
I guess you can see where my thinking was going at this point: like I said, the problem object, although only 33m away, was obscured by a floor and a wall from my location.
So, to test this idea (that it was about things being obscured, not that it's PI directly to blame), I made a little test rig on the platform outside the workshop. First I made a 3-prim object like this:
The blue bar is the root and is called "Force Sit". The two arrows are named with the UUID of two objects 23m either side of the object. Inside the root is the following code:
The idea is simple: stand at the arrows and click an arrow to be force sat on the object that's in that direction. The difference between the two objects is that one of them is in the clear while the other is obscured:
by two hollowed out cubes, one inside the other:
Initial testing never had a failure. But, I'm guessing, my viewer would "know" about the target object even when obscured and wouldn't bother dumping the data when it was fairly close by. Even heading down to the ground, walking about, and coming back up didn't make a difference. It all still just worked.
So I decided to leave it alone, all sat outside the workshop, and test it again the next time I logged in. Which I did this morning.
I got into the workshop, walked out onto the platform, detached my camera from my avatar using flycam so that my camera would stay about 38m from the arrows and about 45m from each of the target objects, and did the test.
First I touched the green arrow, which would attempt to force sit me on the object that I could see. That worked just fine.
Next I touched the red arrow, which would attempt to force sit me on the object that I couldn't see as it was inside the boxes. Nothing. I didn't move. One again I turned on RLVa debug messages and, sure enough...
Antony's Collar: failed: @sit:{uuid}=force (invalid option)I then raised my camera and tilted it down a little until I could almost, but not quite, see the target object:
It still failed. I then raised and tilted a little more until just one corner of the object was visible:
...and this time the test worked. I was force sat on the object inside the box.
That seemed to pretty clearly demonstrate it: object distance from your avatar, or your camera position, isn't the only thing that will affect how a @sit works -- it's also about if the object in question is obscured.
Keep in mind too, as mentioned above, that a relay will still reply that the operation worked "ok", but the avatar won't be sat and internally the sit will be seen as a failure (something that can of course be overcome by use of @getsitid).
The point of all of this? Well, like I said at the start, there's no actual conclusion to this; I just felt the need to document a curious problem that I'd run into and how I looked into it and what I found. It feels like it's something related to what Project Interesting has done although, of course, I'm not sure. I've also not tested this (so far) with any viewer other than Firestorm 4.6.9.
What I do know is that, if and when this code becomes a released product, this effect is something I might need to note in the documentation. People might see the product work fine on some victims but not on others and there'll be no obvious reason why this is the case.
Subscribe to:
Posts (Atom)