Tuesday, September 20, 2016

Little Shop of Kink is gone

Hi,

It seems that the parcel where the famous Little Shop of Kink in Lineside has recently been abandoned by her owner, Tess Whitcroft, an old friend of mine, and Governor Linden returned all the prims from it today, including my vendors and updater, and now owns the parcel.

I'm sad because the Little Shop of Kink was where I had my very first vendor, before my vendors were networked, before I even bought Pak as my First Land, almost... 10 years ago... *gulp*

So that's a little bit of my history that goes away today.

What it means for you, as a customer, is that the updater in Lineside is obviously no longer available, but there is one at Roper's place and another one at Chorazin's sim. And of course the one at my shop in Pak.

Thank you Tess for having me there for so long, and actually helping me start my business back then. I hope you'll be met with success in your future endeavors.

Marine

Monday, September 5, 2016

RLV 2.9.20

Hi,

Here is the latest version of the RLV, including all those commands that were in RLVa for several years and that I never took the time to include in the API (because of time constraints, reviewing to do and all that), resulting in two implementations (RLV and RLVa) progressively diverging apart. It happens sometimes, I add commands first and Kitty Barnett adds them in her RLVa later, or the other way around. This time there was a pretty big backlog on my part so here they are, new commands for the RLV and for you to enjoy !

There is a problem with the version though. Kitty added commands but did not finish the vision restriction ones yet (they're rather tricky because the renderer is so sensitive, it'll need some more time I guess). So if I followed the usual logic, this new version should be 2.10, as new commands are added, but as RLVa still lacks some of the 2.9 commands, it would confuse scripts big time. So this version will be 2.9.20 instead, and we will switch to 2.10 when more commands are added and both implementations converge again.

Without further ado, here is the list of the new commands, you will find a better formalization of them in the RLV API :

added : @findfolders (find several folders at the same time)
added : @touchhud (prevent from touching any HUD)
added : @interact (prevent touching anything in-world as well as editing and sitting)
added : @getdebug RestrainedLoveForbidGiveToRLV, RestrainedLoveNoSetEnv, WindLightUseAtmosShaders
added : @tprequest (prevent from sending a TP request to someone else)
added : @accepttprequest (force send a TP offer to whoever requests one)
added : @sharedwear, @sharedunwear (counterparts of @unsharedwear and @unsharedunwear)
added : @touchfar, @fartouch with max distance parameter
added : @sittp with max distance parameter
added : @tplocal with max distance parameter
added : @sendchannel_except (prevent from using one particular chat channel)
added : @detachthis:uuid, detachallthis:uuid
added : @remattach:uuid (force detach an attachment by its UUID)
added : @shownames:uuid (hide the names of everyone around except one particular avatar)
added : @tpto:region/x/y/z (lookat doesn't work yet) (user-friendlier variant of @tpto)
added : @setcam_avdistmin (synonym to @camdistmin)
added : @setcam_avdistmax (synonym to @camdistmax)
added : @setcam_unlock (synonym to @camunlock)
added : @setcam_fov (force the FoV in radians)
added : @setcam_fovmin (set the minimum FoV)
added : @setcam_fovmax (set the maximum FoV)
added : @setcam_textures:uuid (synonym to @camtextures, + replace the grey texture by a custom one)
added : @getcam_textures (get the specified UUID)
added : @getcam_XXX, XXX being avdistmin, avdistmax, fovmin, fovmax, zoommin, zoommax, zoom, fov

I forgot to add in the release notes (and the file is uploading as I am writing these lines, so I guess it will be for next time) : there was a bug that would not hide emotes coming from an attachment when it took the same name as its wearer (for example, a gag), while under @shownames and @recvemotes AND "Show ..." was active. Specific bug ! Thank you Katinka Teardrop and Isabel Schulze for the heads-up.

ETA : Two commands I forgot to mention here : @sendgesture and @setcam_textures. I just added them to the API now.

You can grab the RLV for Windows here :

www.erestraints.com/realrestraint

Direct download :
www.erestraints.com/realrestraint/RestrainedLoveSetup.exe

And the MD5 hash for the executable is
7974336c3ca0d857442d1b9e4f1b3225
613ea57f20843569c686aafe2cf08348

Have fun !

Marine

PS : It is now  v2.9.20.1 because there was a crash with @camtextures:uuid. This was due to a file I had rolled back while I shouldn't have, after testing @camtextures but before committing the changes. Bad me. Thanks to Chloe1982 Constantine for the report.

Thursday, July 28, 2016

RealRestraint update to v1.29

Hi !

As promised in this post, here is an update to all the restraints in the RealRestraint brand to v1.29 !

The highlight of this update is the ability to detach items that are not necessary for a particular lock, and to reattach them later even after the lock has changed. That's what I call "late-detaching" and "late-attaching", in other words "detach after locked" and "attach after locked" respectively. The purpose is double. It is about decreasing the rendering cost of what your avatar by letting you detach what is not needed, and sparing attachment slots at the same time. You can wear 38 attachments at any given time and mesh bodies tend to take a lot of those slots (one for the body, one for the HUD, usually two for the feet and two more for the hands, add one for the head and one for its HUD if you use a mesh head, that's a total of 8 slots just to look good). So any way to spare slots is welcome, especially when wearing full sets of restraints that can take more than 10 slots for some.

For example, if you wear the Vixen cuffs and lock them in "U-binder", like this :


... you do not need to wear the chain parts nor the left wrist as they're not used by this lock. You can see these parts in "highlight invisible" (Ctrl Alt T), in red :

The chain parts are the little spheres around the waist and over the crotch.

You can also see the left wrist cuff in red around the left wrist, partly hidden by the u-binder part.

Those parts can be detached even though the cuffs are locked.

After having detached those unnecessary parts, that's at least 3 attachment slots freed !

Now suppose you have indeed detached those parts and changed the texture from the default black to a mix of pink and white :


Then you get locked into another pose, let's say ""H+E front", which features chains around the torso and you are not wearing them, plus the left wrist cuff that you are not wearing either. There's no chain, the left cuff is missing, it is a mess :

 
No back chain, no crotch chain...

... and no left wrist cuff.

All you have to do is wear those missing parts (and you can detach the u-binder part since it is not used by this lock), the missing cuffs automatically appear, change texture to become white and pink like the rest, and the chains appear, without you having to do anything. And now everything looks fine again :

All fixed !

To obtain this result, however, a full replacement of each set is required. Of course this update is not mandatory, and of course any new product bought after the update is live will already be updated. I am very aware of how annoying it is to resize all the parts of a set, which is why I have made the copy/paste shape scripts.

Please note that it is not because a part is invisible that it can be detached. Some parts are invisible and yet necessary for the current lock. For example, the right wrist part of most of the RR sets is where the main scripts are located, so of course this part is always required and therefore RLV-locked. A few other parts are always needed too, such as the light harness and crotchrope of the Siren set, because those two parts may be made visible at any time, regardless of the lock.

Conversely, it is not because a part is visible that it cannot be detached. For example, there has been a popular request for the Vixen and Elegance sets to let the elbow parts show while locked without a pose. I had considered making a Style plugin for them, but this would have been useful only for one particular lock, not very efficient. Instead, I have made it so the elbow parts are visible while on the "Lock" lock, but not RLV-locked. That way you have the choice to wear them or not.


There is another new feature included in this update : the ability for any third-party plugin to register itself to Vulnerable, and be given access to whoever clicks on the restraint while not being the keyholder. Until now only the *Leash, *Outfit and *Sit plugins could be accessed, but now if your third-party plugin has one of its parameters set to "vuln" (case unimportant), then Vulnerable will show it on its menu. Only the name of the plugin will be displayed, not its parameters. For example, if your third-party plugin is named "*MyThirdPartyPlugin.param1.param2.vuln", then Vulnerable will show "MyThirdPartyPlugin" on its menu. I realize as I am writing these lines that there is no "..." after the name to indicate that it opens another menu, but it's ok, that doesn't keep it from working. I'll add the ellipsis in a future update, it is only a cosmetic issue.


Aside from the "late-detaching" and "late-attaching" and the addition to Vulnerable, the update includes a few other changes and fixes, so let me write the whole list of changes here :

* Late-detaching, late-attaching
- Ability to detach any item that is not necessary for the current lock.
- Attaching items that were not worn but necessary for the current lock will automatically synchronize themselves for the textures, tints, leashes and particle chains as soon as they are worn.
- Known issues : The "Pet" pose in Mummy Legs and Deluxe Straps Legs re-locks the arms in "Pony" whenever rezzed (not a real issue, but can be surprising);  Mummy plays a lock sound when rezzed, once again harmless but can be surprising. I will work on those issues later and see if I can fix them, as they area a side-effect of the feature above.

* Vixen and Elegance sets
- Elbow cuffs are now visible on "Lock", but can be detached manually.

* Vixen set
- There was a script error when struggling in "Hogtie Tight", a missing animation (thanks JimHC Lykin)
- The "Black+silver" button in the "Saves" menu of the VixenTex plugin was oddly placed (cosmetic change, but it was annoying).

* Vulnerable plugin
- Any third-party plugin that has "vuln" as one of its parameters (the part between "." in the name, if any) will be on the Vulnerable menu like *Leash, *Outfit and *Sit.

* Deluxe Gag & Blindfold
- Removed the "bridge" script that made textures be changed on both items at the same time, as it would cause issues when applying a preset (the item the preset is applied to would look fine, but the other one would look only partly textured, due to SL throttling the messages, as there are so many).

* Siren & Shibari ropes
- Replaced the original colors with the ones used in the Latex catsuits, socks & gloves, Highbinder, Deluxe Straps, Body Harness, Deluxe Gag and Pretty Mummy.

* Deluxe Straps legs
- For some reason the waist part was no-mod. I'm surprised nobody called me about it. Of course if your waist strap is no-mod and you don't want to update just for that, send me an IM and I will give you a mod one.


Please note : The following products do not benefit from this update as they either do not have secondary items or their secondary items are always used. So no need to update these if you don't want to.

Armbinder
Scarf Blindfold
Body Harness
Isolation Hood & Blindfold
Jammer
Serious Shackles
Slave Crate
Tape Gag & Blindfold

I repeat, this update is in no way mandatory, it is just a convenience for you if you need to free some attachment slots when you are heavily bound, or if you are concerned with your own avatar rendering cost.


You can find an updater at the following places in-world :

My little shop

The Little Shop of Kink

Roper's Dark Playground

Chorazin's main store

It looks like an orb floating above a pedestal, just click on it and follow the instructions.


Have fun !

Marine




Monday, July 25, 2016

RLV 2.9.19.2

Hi !

This version of the RLV only contains a hotfix for a very recent bug, making it so you couldn't touch anything when under the @edit restriction. D'oh !

Anyway it's fixed in 2.9.19.2, sorry for the inconvenience !

You can grab the RLV for Windows here :

www.erestraints.com/realrestraint

Direct download :
www.erestraints.com/realrestraint/RestrainedLoveSetup.exe

And the MD5 hash for the executable is
4f61031d7bc18fd07bc1629516ccb2be

Have fun !

Marine

Thursday, July 21, 2016

ARC and what to do about it

Hello again,

Lately Linden Lab added a new feature to the SL viewer that would automatically simplify the rendering of all avatars which rendering cost is above a threshold that you set in your preferences. Every avatar above that threshold is rendered without its attachments, save for their rigged ones, and without any texture. Instead the look like gummy bears, or jelly dolls, or whatever the term is. Although the calculation of the rendering cost is rather old (5 years old at the time of this writing), it had always been purely informative. Now the viewer automatically acts upon the result of this calculation.

This is all good and well as it lightens the load on the rendering part of your viewer, meaning more FPS for you. Very useful in clubs, it helps trimming down the costly attachments that you might not be aware of, and motivates content creators to optimize their stuff (I'm talking about future products, of course, it is very difficult to optimize what has already been made and released since you must make the customers update, when at all possible).


The formula and invisible surfaces

Only, the formula used for the calculation gives alpha-blended textures a high weight. I understand the reasoning behind this, as alpha-blended textures (aka 32-bit textures, textures with a 8-bit alpha channel so they can be partly transparent, as opposed to 24-bit textures that can only be opaque) are very heavy on the rendering, and not only on the SL rendering engine. If you've played a game with explosions that are rendered with sprites of fire and smoke, your computer would likely slow down when you were close enough. This is because of a high number of partly transparent textures stacked upon each other, which makes the renderer suffer, even worse as they are close to your camera.

What I find weird is that completely invisible surfaces (i.e. surfaces which alpha is 0, or "Transparency 100" in the viewer, regardless of whether the actual texture is 24 or 32 bits) are also rendered. Why ? No clue. Why render what you can't see in the first place, right ? But it doesn't matter, the formula punishes invisible surfaces the same as partly transparent ones.

Now, I'm not saying that invisible surfaces should not be counted in the formula at all, because even if they are not rendered, they are still managed by the viewer every frame. It has to decompose the scene into objects, objects into prims, prims into surfaces, group surfaces into pools, and only then can it check whether a surface is invisible or not. The rendering is only a part of the computation cost of a surface. So to me invisible surfaces should be counted in the formula, but not as high as partly transparent ones.

This has a direct impact on some of my products like the Deluxe Straps and the Deluxe Gag. These are the two products with the most invisible surfaces, simply because they morph a lot (they are the products offering you the most customization). Their rendering cost, according to the formula, is rather high : individual attachments in this set are worth 34k average. This is not due to a poor design though, I have optimized the topology of the deluxe straps prior to release, knowing that there would be a LOT of straps. There could certainly be fewer triangles but not a lot fewer or the straps would look blocky. So why the high cost ? Because most surfaces are invisible, so they are taken as transparent surfaces, regardless of whether their textures are opaque or not.

But there is no reason to render these surfaces at all unless they are actually visible, right ? Yet they are rendered anyway and this makes people think those items are badly optimized because it sounds like there are many times more triangles to render than there really are. And it makes other people around you derender you automatically if their threshold is set too low. It is detrimental to my work in the long run.

I am not the only creator to be harmed by that formula. Any item that has options (for example weapons) have parts that hide and show themselves, most use transparency to do that, very few actually shrink prims and move them inside the bulk of the object. Some do, but it isn't always possible for technical and usability reasons.


So what to do about it ?


Update of my products

I mentioned a way to mitigate that in this post. In short, I said that I was thinking of a way to let the user detach the items that are not used in the current lock. For example, when you are locked in "Arms tight" in the Deluxe Straps, you do not need to actually wear the chest part, so this would let you remove it. Problem is, what if you got yourself locked in "Box" afterwards ? Well, you'd be able to re-attach the chest part after being locked, it would become visible and what's more, its textures would synchronize if the colors were changed in the meantime. And you'd be able to remove the upper arm part afterwards since it would not be locked anymore, always allowing you to wear only the required attachments but not necessarily the whole set all the time. This has the added benefit of sparing some attachment slots for you to use otherwise.

This works well now, after days of coding and testing, I have yet to release that update to all my products, it will take a few more days because there are a few other things to do first. The downside is that it will require full replacements, including the secondary items. I know it is a pain, and I'm afraid there is no way around that since the "slave" script of every single secondary item needs an update. And since they are no-mod and their names contain their parameters, I cannot not give away a template script for you to replace the old ones with. Of course that update will not be mandatory, it's just for convenience. Another downside is that this trick does not help the Deluxe Gag at all since it is in one piece. A third downside is that it doesn't help other creators, since it is an update to my products only.

I had been suggested to transform my "set alpha to 0 when unlocked" to "set texture to transparent and alpha blend mode to alpha mask when unlocked". While this is a good idea because fully alpha masked textures are not rendered (not even with "highlight invisible", which is also beyond me), this requires me to make a script that retains all the textures to set when the item is locked again. After giving it much thought, I decided not to do it, because it would make the products a lot more fragile. It would be very difficult to resit a reset, a relink or a texture change with such a feature. Possible, but very costly and error-prone, and would not allow you to customize with your own textures anymore (some people like to do that and I hope they continue).


Update of the RLV

I have just released a new version of the RLV that does not render invisible surfaces at all, i.e. surfaces which alpha is 0, or "transparency" is 100 in the viewer. Well, except when "highlight invisible" is active (that's Ctrl-Alt-T, to see invisible surfaces in red). Really, it is as simple as that. I have detailed the change here with a patch file that is very small, and to my knowledge, without any side-effects. I have run benchmarks and they do demonstrate that invisible surfaces are indeed not rendered. I have also tested that it doesn't interfere with the ability to touch such a surface. It makes sense not to render invisible surfaces anyway, because invisible surfaces on rigged mesh attachments are already not rendered and therefore do not have as high a weight in the ARC formula.

Please note that if a surface does not have its transparency set to 100 but bears a fully invisible texture (such as the "*Default transparent texture" one in the Library), it WILL be rendered even if you won't see it. The change only checks the alpha, not the actual data of the texture, it would be too slow and defeat the purpose. This makes sense, also, because such a texture may be useful when you want to render clear plastic. The texture itself is invisible but may shine in the light.

I understand what modifying this formula means though. There is at least one LSL function that uses it (llGetObjectDetails with OBJECT_RENDER_WEIGHT), so suddenly it would return different results... So if LL decided to make that change to the formula, they would have to modify the viewer and possibly the sim software at the same time, after thinking hard about the consequences on the values fed to the scripts. I have also no idea how much lighter invisible surfaces are on the viewer when you include my modification, all I have is some FPS benchmarks which are a bit extreme (more than 100 surfaces stacked upon each other, you don't see that in public places unless someone wants to grief you). Which means tests have to be made and it takes time and money.

Of course, I will be the first to admit that the modification I made is pretty basic, if LL decided to implement this change they would certainly not do it the same way. But they know the rendering engine well, I don't. I know other parts but the rendering engine is like black magic to me. I didn't really pay much attention during my OpenGL classes, I admit.



So, to recapitulate :

- My whole RealRestraint line of products will get a full update in the near future. This update won't be mandatory (no update is), but if you want the ability to lower the number of attachments in a set, and by extension your rendering cost, this is the way to go. The update is not available yet, I will send a notice and write a blog post when it is.

- The RLV no longer renders invisible surfaces unless you highlight them. It may increase your FPS a little, depending on the amount of invisible surfaces around you. Frankly, I did not see a difference unless I had a hundred surfaces stacked upon each other, but I'm pretty sure it will help in clubs. Unlike my products, the update of the RLV is available already so have at it (you can download it here).


Have fun !

Marine


Wednesday, July 20, 2016

RLV 2.9.19.1

Heya,

Despite my many tests, it just so happens that the rendering fix I introduced in RLV 2.9.19 had a little (but annoying) bug in some special circumstances. So special that I could barely reproduce them, let alone see them occur during the tests in the first place as those special circumstances did not occur in my sim. Namely, some transparent but non-invisible surfaces could vanish from the view depending on the angle of your view. But not all surfaces, they had to be part of an object with transparent, opaque and invisible surfaces, all of them at the same time. The best example of that would be mesh windows, but then again, not all of them (and seemingly not the ones in my region).

So I had to completely redo the fix, switching back to the first technique I used in the JIRA ticket, with an addition to make sure the surfaces update themselves when necessary (it has to be done when you activate and deactivate "highlight invisible", and in a way that doesn't freeze the viewer even though it requires a visual update of all the prims around). And even as of now, I have no clue why my former fix didn't work in all cases, as it was pretty much a copy/paste of some LL code with very little change. At least it works now. Let's just hope I will not discover some silly bug like "transparent surfaces will not show when you are higher than 1024 m, facing West, at night, on a Sunday, wearing black shoes". I kid but the bug in RLV 2.9.19 was almost that specific !

There is another bug I stumbled upon and that I fixed in this version : apparently you couldn't alt-click to focus in world through a HUD anymore. Slightly puzzling but it's fixed now.

So, to recap :

You can grab the RLV for Windows here :

www.erestraints.com/realrestraint

Direct download :
www.erestraints.com/realrestraint/RestrainedLoveSetup.exe

And the MD5 hash for the executable is
e78889251652dcb4353fcc0c5b7bb7cf

Have fun !

Marine

Tuesday, July 19, 2016

RLV 2.9.19

Hi !

Here is the latest version of the RLV with a few interesting changes, including the one I discussed lately. I will not go into details about the rendering change here, I prefer to write a full blog post about it later, because it goes hand in hand with a change in my own products. Even though both changes are, actually, independent. I know, I'm being vague, don't worry everything will become clear soon, I just don't want to dwell on this in these release notes. In short, the change is about not rendering surfaces which alpha is 0.0, to avoid rendering things that we cannot see anyway, making the viewer a bit faster. This change is related to the new Avatar Rendering Complexity changes that came to the SL viewer.

Apart from the small (but important) rendering optimization that will be discussed in a later post, there are a couple additions to the list of IM commands the viewer responds to. You already know that if the other party types "@version" in an IM to you, they get the version of your RLV. Likewise, if they type "@getblacklist", they get the list of RLV commands you have blacklisted (it is empty by default).

Starting from this version, if they type "@list" in the IM window they get the list of RLV restrictions you are currently under (as if you had clicked on the RLV > List Restrictions menu item), and if they type "@stopim", your IM window will automatically close, but only if you are under the "@startim" restriction at that moment (wouldn't make sense otherwise). That way they control when the conversation ends, and not you.

I want to point out that these IM commands are not part of the RLV API specification like script commands, but recommended. I will add such a note to the API soon. They're there for convenience, but since they do not change how the viewer responds to RLV commands coming from scripts, they are not mandatory.

And if you don't want to have to remember all those commands, I have added shortcuts to them to the small menu of the IM window :


Of course these menu entries (and the commands that go with them) are available only in P2P conversations. Not group chat, not conferences and not nearby chat, where they are greyed out. Thanks Angelina Sinclair for suggesting to add those menu entries.


Here is the list of changes :

- added : If someone types "@list" in an IM with you, they get the list of RLV restrictions you are currently under (exactly like the "List RLV restrictions" menu item in the RLV menu).

- added : If someone types "@stopim" in an IM with you and you are under the "@startim" RLV restriction (preventing you from starting IMs), your IM window is closed automatically and both of you get feedback. If you are not under a "@startim" restriction, then the other party gets feedback too to show that it didn't work.

- added : 4 menu items in the small menu button for each IM window, to automatically send "@version", "@getblacklist", "@list" and "@stopim" in IM so you don't have to remember them and type them manually.

- improved : The viewer no longer renders surfaces which alpha is 0.0 except when "highlight invisible" is active. See BUG-20168 for details.

- fixed : @touchme did not allow you to touch the object issuing this command when you were under @touchall (thanks Kyrah Abattoir for the heads-up).

- fixed : Prevent click-dragging when @edit is active.


You can grab the RLV for Windows here :

www.erestraints.com/realrestraint

Direct download :
www.erestraints.com/realrestraint/RestrainedLoveSetup.exe

And the MD5 hash for the executable is
5ce1ccdf5cb36a949b6254dba012edfa

Have fun !

Marine