Tuesday, June 7, 2022


 Hi !

This is my first post in over a year... I'm still taken by this RL project which is why I'm quiet these days, but I'm not gone, just quiet and very busy.

In the meantime, it seems that LL hasn't been idle either and released a new viewer that kind of breaks some system libraries which makes the previous RLV unusable, so here is a new version based on LL's v6.5 codebase that should work again.

It doesn't contain bug fixes or improvements, it is just meant to stay up-to-date with LL's latest viewer. Actually, at the time of this writing, the latest SL viewer is 6.6 and I have a working RLV based on that one, except it breaks invisiprims. I know, invisiprims are evil, ugly, they're a hack and so on, and the SLV and FS only support them in forward rendering, but I'd like to keep supporting them in deferred rendering as well as long as we don't have another way of dynamically hiding rigged mesh parts with scripts. Not everyone uses BoM and not every mesh body has alpha cuts. Like it or not, invisiprims still have some usefulness so the RLV based on 6.6 is not ready yet. This one here is okay, though.


You can download the Windows version from http://www.erestraints.com/realrestraint/

The MD5 hash for the Windows version is :

The Linux and Mac versions are proposed by Chorazin at this address :

Have fun !


Wednesday, May 19, 2021


 Hi !

First of all, apologies for being quiet for so long, all my time is taken by an RL project these days. It might be tied to SL actually but I won't comment on it yet. All I can say is that it's big so it's taking all my time for now. But no worries, there's a lot of work on my plate in SL as well, for example Xuxu needs a bit of love because there are bugs that still need to be fixed. So I'll get to that when I can.

Here is the latest version of the RLV with a few bug fixes and the latest code from LL. This RLV has been ready for release for a month already and I... kind of forgot to ship it. Sorryyy !



- fixed : couldn't @attach an item located inside a temporary RLV folder (thank you Jenna Huntsman for the heads-up)

- fixed : #RLV/~a/b/c became #RLV/~a/b/c at the next login

- fixed : declining #RLV/~a/b/c created the folders anyway


You can download the Windows version from http://www.erestraints.com/realrestraint/

The MD5 hash for the Windows version is :

The Linux and Mac versions are proposed by Chorazin at this address :

Have fun !


Friday, March 19, 2021

Update for all the RR blindfolds

Hi there,

Following the recent addition of @setsphere to the RLV (in v2.9.30), I have updated all the RR blindfolds to add the ability to choose between three methods of blinding, in their "Blindfold" plugin :

- HUD : This is the old-school pre-RLV method, a big prim takes all your view and has only a tiny hole in the middle to let you click through it. It obscures all your view, including your avatar.

- CamDraw : This is the RLV 2.9 vision restriction spheres that you already know.

- SetSphere : This is the RLV 2.9.30 and RLVa 3.4.3 vision restriction sphere that was recently introduced.

The way it works is simple. You choose your preferred method (even while blindfolded, you can change on-the-fly) and the plugin decides which method to use according to the version of your RLV. If the version or your RLV actually supports the method you chose, no problem, the plugin will use it. Otherwise, it chooses another method like this :

- If you chose CamDraw and are not using a RLV 2.9 but are on a RLVa version 3.4.3 or above (in Firestorm or otherwise), then it will choose Setsphere.

- If you chose SetSphere and you are using a RLV 2.9 but not 2.9.30 or above (in which case what are you waiting for, grab the latest version !), then it will choose CamDraw.

- Otherwise it will choose HUD.


If you wonder, the blindfolds in the RR line are :

- Scarf Blindfold

- Deluxe Blindfold

- Tape Blindfold

- Iso Blindfold

- Mummy Blindfold

- Remvision

Note : If you are reading this and are a creator of RLV blindfolds yourself, let me help by recapitulating all the versions and what they mean for you when you get a response to your @versionnum request : 

< 2090000 : No camdraw, no setsphere available (that's before RLV 2.9).

< 2093000 : Camdraw only, no setsphere (that's RLV 2.9 but before 2.9.30).

< 3000000 : Camdraw and setsphere are available (that's RLV 2.9.30 and above).

< 3040300 : No camdraw, no setsphere available (that's RLVa prior to 3.4.3).

Other numbers : Setsphere only, no camdraw available (that's RLVa 3.4.3 and above).

I hear often that this update makes your vision spheres white. This is not a bug but a feature actually, the vision spheres take the same color as the root prim of your blindfold. To change that, simply edit your blindfold, check "edit linked" on the edit window, select only the root prim (that's the one highlighted yellow) and set its color to whatever you prefer, the vision spheres will follow. It's a nice hidden little feature if you're tired of the black.

As an extra, there is also an update to the Vixen legs cuffs : their D-rings would not hide when selecting the Invisible style while unlocked. You need a replacement to benefit from this update though.

If you don't want to replace your Vixen cuffs (which I understand, they're a pain to resize), you can fix the bug yourself by following this procedure :

1. Edit the right ankle cuff and check "edit linked" on the edit window.

2. Click on the main part of the cuff only (the one with the strap and rings) so it selects only this part.

3. It should have a weird name. Replace the weird name with another weird name such as this :

$2%Lw:1/0 $3%Lw:1/0 $4%!Lw:1/0 $1567%w:1/0 $0%Lkw:1/0

4. Do the same with the left ankle cuff.

No need to reset or anything, this fixes the bug once and for all.

To update, simply go to any of the following locations :

My Little Shop
Chorazin's store
Roper's Dark Playground
Dark Wishes

Once there, click on the updater and follow the instructions. You do not need to choose "REPLACE" for this one as the Blindfold plugin is the only thing that changes and is a single script, so a simple "UPDATE" is fine. You do need to replace your Vixen legs cuffs though.



Have fun !


Monday, March 15, 2021

RLV 2.9.30

Hi !

Here is a new version of the RLV which is dedicated to taking a couple features from RLVa, namely "@setsphere" and the ability to create sub-folders when giving a folder to #RLV directly.

I said in my last post that this was the last time I integrated proofs of concept RLVa commands that make their way into Firestorm without filter. But that was without taking into account Kitty Barnett's new "@setsphere" commands which she worked on for a long time and that are now going to go into Firestorm, once again without any filter.

But I know that users have been eagerly waiting for years for an equivalent of the @cam commands to simulate blindfolds and other vision restrictions that are present in the RLV and Kokua viewers but not in Firestorm which is by far the most popular viewer. It was frustrating for them so I expect scripters will jump on the opportunity to use these commands as soon as they are released. That's why I can't just ignore this new set of commands since they will become popular in no time. Problem is, they are not in the RLV API so if they start using them and I don't do anything, there might be a significant difference once they actually make it to the API and it will be too late then.

So this version (2.9.30) includes Kitty's "@setsphere" commands, working the same way as in RLVa with two key differences that I will explain below.

The second feature is being able to create sub-folders when a script gives a folder to the user's #RLV folder. For example, before this version, giving a folder named "#RLV/~A/B/C" would create a folder "~A/B/C" and put it under #RLV, just like that. Not very handy especially since RLVa would actually create folders "~A", "B" and "C", and organize them the way you'd expect. Since this version here, RLV does the same now which is :

- Create a folder C (in all cases, the last folder in the path is created so we don't pollute an existing folder with new items).

- Create the other folders in turn and organize them, but only if they don't already exist. For example, if your inventory already contains "~A" and "B" inside "~A", it won't create them but it will reuse them, placing the new folder "C" under the existing folder "B" (regardless of the fact that there might already be a folder "C" there since, like I said, the last folder in the path is always created, never reused).

That way, RLV functions exactly like RLVa on these features from version 2.9.30.

Here is the change list :

- Added : Support for @setsphere like in RLVa (with a significant difference : "=force" commands become "=n" commands).

- Changed : Giving a folder to #RLV will now create nested sub-folders if the name of the folder contains slashes ("/").

- Fixed : Defensive fix against a potential crash when using @camtextures (thanks Henri Beauchamp for the heads-up).

You can download the Windows version from http://www.erestraints.com/realrestraint/

The MD5 hash for the Windows version is :

The Linux and Mac versions are proposed by Chorazin at this address :


Now, you might have noticed the "significant difference" part in the change list about @setsphere. Read on if you want to know more.

All the "=force" commands designed by Kitty are turned into "=n" commands (*). The reason for this is the way the parameters must be mixed when two or more objects issue identical "@setsphere_mode" commands but with different parameters. In RLVa the result is random, whoever comes last wins or something like that. In RLV they are properly mixed to retain the most restrictive parameters.

For example, if two objects issue "@setsphere_mode:0=n" (that's "restrict the vision with a plain color gradually becoming more opaque over the distance) then one issues "@setsphere_distmax:3=n" and the other @setsphere_distmax:10=n" afterwards, the second command will be retained like the first one but the actual distmax parameter that will be applied will be "3" because it is more restrictive.

(*) Actually the RLV accepts both because there might be scripts already using @setsphere the way Kitty designed it, but the RLV API will only specify "=n", not "=force" because the latter is bound to cause issues and is not consistent with the way the RLV works.

The "force" commands are not retained in the main RLV map, they are forgotten as soon as they are executed, so they cannot be consulted afterwards by scripts. Those "force" commands are "one-shot" commands that are meant to force the avatar to do something, like sit somewhere or teleport, but not configure a command that itself sticks around.

Another difference is the separators in the "@setsphere_param" command. The API will specify that ";" is needed but RLVa takes "/" for the time being. However, "/" is more reserved for folders than actual separators than for multiple parameters (I know, "@tpto" seems to be an exception, it was done this way to facilitate turning an slurl into an actual RLV command, it sounded like a good idea at the time) so ";" it is.


Also, it is too soon to add anything to the RLV API about @setsphere. I don't know yet if it is a good idea, for example there are issues with alpha-blending which I am not sure Kitty will be able to solve. I would also like @camdraw commands to be replicated in RLVa, at least becoming synonyms for @setsphere commands. In short, "@setsphere" is still more or less a command in testing.

However Kitty raised an issue with @camdraw commands in RLV : the view seems darkened far before the actual outer limit. There is a reason for this, the spheres are alpha-blended and stack one after the other in a linear way (that's 40 concentric spheres between @camdistmin and @camdistmax).

Problem is, when two alpha-blended surfaces overlap each other, the resulting transparency is a multiplication of both transparencies. As a result, the concentric spheres blend in an exponential way, resulting in an apparent darkness occurring a lot closer than it should. The spheres are placed correctly though and the initial requirement was to make it so @camdrawalpha commands were exact. If you specify that the outer alpha should be 75% (hence 25% transparent), then any white fullbright surface beyond that distance should appear 75% grey, and it works. The reason for this apparent bug is that the spheres are placed linearly. I could place them differently (logarithmically for example) but then this would break existing products using those commands. Adding new @camdraw commands would require to think long and hard on how to mix them.

Anyway, this is the reason why @setsphere is a different set of commands from @camdraw but it would be great to find a way to set a bridge between them, after all they both do the same thing.


Have fun !


Monday, February 1, 2021

RLV 2.9.29

Hi there,

Here is a new version of the RLV, this one is a big one because it includes many new RLV commands on top of a few bug fixes and changes.

Normally it should have been 2.10 but none of the new RLV commands is a real game changer like the vision restriction spheres in 2.9 so it stays a 2.9. It's not really important anyway.

Here is my personal take on the matter of most of the new commands included in 2.9.29. The technical stuff and the actual release notes follow after the part in italics.

Most of the new commands were actually already present in Catznip and I've added them to the RLV for consistency concerns. They're mostly about EEP and how to keep controlling the environment settings with EEP the same way we used to with Windlight, without having to rewrite any script. Problem is, RLVa 2.3 brought in commands with a different syntax than those in the RLV API 2.9.27.

As a result, RLVa was forking even further from RLV and for the sake of the scripters (and their sanity), it is not good to have two nearly but not entirely identical APIs. On top of it, RLVa goes straight into Firestorm (without filter as far as I know, but I'd love to be corrected on that) which is by far the most popular viewer so when a command is added to RLVa, some people assume they are in the RLV as well. This is why most of the new RLV commands in 2.9.29 are taken from RLVa.

There is one simple rule though : if a command is not in the RLV API, it is not an RLV command and scripts should not assume they are.

This is the last time I do this. In order to keep RLV a single API which scripters can rely on for its consistency, all the people working on different implementations of the RLV API must understand that forking is not the most sensible thing to do. Having different implementations that interpret the API differently, or even having commands that are part only of some implementations only confuses users (scripters and end users alike) and increases everybody's workload.

I do understand that when someone wants to add a new command to the RLV API, they have to ask me and I'm the one to do the work on the specification and first implementation (because it has to be tested, right ?), which is not always possible. I consider every suggestion carefully and I say no more times than I say yes, provided I have time at all. So I do understand that other viewers implement their own "test" commands on their side as proofs of concept. I have no problem with that as long as they stay test commands and proofs of concept, but injecting them into popular viewers without getting back to me first is bound to cause issues because suddenly the proofs of concept become mainstream commands without being in the API. That's when things become ugly for scripters and end users.

This applies to Catznip because that's the one that I know about, but there are perhaps others. Of course, if the test commands in Catznip are not transferred into Firestorm when the latter publishes a release, then this whole rant personal take is moot and to be ignored.

Alright, on to the interesting stuff.

- added : A slew of new "setenv" and "getenv" RLV commands, some of them to match the new ones in Catznip : asset, cloudtexture, sunscale, suntexture, sunazimuth, sunelevation, moonazimuth, moonelevation, moonbrightness, moonscale, moontexture.

- added : Support for vectors in the following "setenv/getenv" commands : ambient, bluedensity, bluehorizon, cloudcolor, cloud, clouddetail, cloudscroll, sunlightcolor. Attention : although ";" and "/" are acceptable as separators in the "setenv" command, the "getenv" command will separate the numbers with ";" only to remain consistent with other RLV commands ("/" is supposed to be for folders, it is not a separator).

- added : Show "Typing" above the head of the avatar even when its chat is redirected (this brings a new debug setting named "RestrainedLoveShowRedirectChatTyping").

- added : New RLV command @shownearby (thank you Chorazin Allen for the code).

- added : New RLV command @touchattachother:UUID to prevent from touching a specific avatar's attachments.

- added : New RLV command @share (with its _sec variant as well as share:UUID exceptions) to prevent the user from giving anything to anyone, with exceptions.

- added : New RLV command @sitground to force the avatar to sit on the ground where it stands (in fact it will just sit where it is, even if it is flying, it's not necessarily going to sit on the ground below).

- added : New RLV command @editworld to prevent the user from editing objects rezzed in-world but not their own attachments (no exceptions).

- added : New RLV command @editattach to prevent the user from editing their own attachments but not objects rezzed in-world (no exceptions).

- added : New notification when sitting and unsitting on/from an object or the ground : the viewer says "/sat object legally", "/unsat ground legally" etc.

- added : New RLV command @sendim:<group_name> to add exceptions to @sendim by group. If <group_name> is "allgroups", then all the groups are exceptions.

- added : New RLV command @recvim:<group_name> to add exceptions to @recvim by group. If <group_name> is "allgroups", then all the groups are exceptions.

- added : New RLV command @sendimto:<group_name> to prevent from sending IMs to a specific group. If <group_name> is "allgroups", then all the groups are restricted.

- added : New RLV command @recvimfrom:<group_name> to prevent from receiving IMs from a specific group. If <group_name> is "allgroups", then all the groups are restricted.

- changed : When we press the Esc key, the camera returns to its default position without moving the avatar (this was the case in the past but since EEP it would move the avatar to match the camera instead). To move the avatar to match the camera, simply press one of the arrow keys, like before.

- fixed : Receving a "#RLV/~" folder no longer created the folder under RLV (thank you Sabrina Dumont for the heads-up).

- fixed : Since EEP, the shine was too bright when the camera was outside the light radius (https://jira.secondlife.com/browse/BUG-229436). This is an SL viewer bug, I'm just applying Sovereign Engineer's fix minus the materialF.glsl file because that one makes the shine way too weak.

- fixed : Looking at the Experiences window would show the slurls even when under @showloc

- fixed : Sometimes, moving the camera at certain angles while not rendering the avatar would not render the vision spheres either.

- fixed : @edit should not block spin and grab (thank you Chorazin Allen for the fix).

- fixed : The white flash over the icon of a user in the Communication is now a faded orange, much more readable (thank you Chorazin Allen for the fix).

- fixed : An SL bug blocking the loading of landmarks under certain conditions : https://jira.secondlife.com/browse/BUG-230139. Thank you Chorazin Allen for the fix.

A word about the EEP shine fix. The initial bug arose after some LL fixes about the shine on any surface, namely the shine was now way too bright when you moved your camera outside the light radius (see https://jira.secondlife.com/browse/BUG-229436 for details).

Sovereign Engineer brought a fix for this new bug that fixed it beautifully... except that the shine was now way too low specifically on alpha-blended surfaces, on parts of the surface where the specular map was not completely white. It does not sound like much but it breaks a lot of content that relies on precise materials such as sweat appliers. Suddenly the background shine of the skin became invisible.

To fix this was easy, I could just ignore the materialF.glsl file in Sovereign's commit and all was well. Problem is, Sovereign's commit was also taken by LL, materialF.glsl included, which means soon the SL viewer will show a very weak shine on alpha-blended surfaces, breaking content. After discussing with Sovereign about it, I know that the calculation of the shine after the fix is correct and it was incorrect before, but it has been incorrect since 2015, when materials were introduced in SL, and a lot of content was developed using this flawed specular curve. In my opinion it is too late to go back now. Keeping the fix the way it is now in the SL viewer is bound to make a lot of people, creators and customers alike (who paid for those products) very angry.

For now the RLV keeps the shine the way it always was, even though it is not consistent with how the SL viewer will render it in one of its next iterations. I have yet to decide what I'll do if LL keeps it like this. I'm certainly not going to rework nearly all my products to match the new calculation.

You can download the Windows version from http://www.erestraints.com/realrestraint/

The MD5 hash for the Windows version is :

The Linux and Mac versions are proposed by Chorazin at this address :

Have fun !


Monday, November 9, 2020




Here is a new version of the RLV that fixes two very annoying bugs contained in the recent versions. See for yourself :

- fixed : Sometimes all the attachments (except the locked ones) would be kicked off upon login for no apparent reason.

- fixed : Included the fix for https://jira.secondlife.com/browse/BUG-229428 (clicking on something in the Places window would scroll it down and make you click on another landmark by mistake).

Please note that the second fix is not my own, LL had it fixed months ago but the fix hasn't reached the official code yet, so I'm including it in advance. I don't really like to do that but this bug was sooo annoying.

You can download the Windows version from http://www.erestraints.com/realrestraint/

The MD5 hash for the Windows version is :

The Linux and Mac versions are proposed by Chorazin at this address :

Have fun !


Friday, November 6, 2020

MdlM Latex Outfits : BoM support

Hi !

Here is a big update to the MdlM Latex Catsuits, Bodysuits and Socks & Gloves to add support for BoM ("Bakes On Mesh") !

In a nutshell

To use the BoM version of the Catsuits, Bodysuits or Socks and Gloves, you need to wear one of the provided Tattoo wearables, and to apply one of the skin shine appliers from the provided HUD, preferably the one that corresponds to the Tattoo you wore.


Bakes On Mesh

Before I explain what's in the update, let me try to explain a few things about Bakes On Mesh first, so you understand what you'll get and how to use it, because it is not obvious at first glance. If you already know what Bakes On Mesh is and how to use it, you can skip the part in italics.

Bakes On Mesh ("BoM"), in principle, is a set of special textures that the viewer renders differently from the usual ones. A BoM texture, when applied to a surface of an attachment, renders a part of your system body including its skin and all its wearables at the time. For example, if you apply the "upper body" BoM texture to your Maitreya upper body skin layer, then you will see your system skin top body part, plus all the wearable items you are wearing on the upper body at the time (I mean actual wearable items, not mesh objects, so for example a tattoo, an undershirt item etc). If you add or remove a wearable or change skin, the texture on the mesh body updates accordingly without you having to do anything. Think of it as a dynamic texture that the sim recalculates every time your appearance changes and that projects your system avatar onto your mesh body (and/or head) as if your mesh body was your actual avatar. A little like "media-on-a-prim" in fact.

Bakes On Mesh works well for wearables, unfortunately it does not support materials (that's the normal texture, the specular texture and the shine values). In plain English, there is no slot in an Undershirt wearable for the material textures, for example, there's only one texture (that we call "diffuse" in 3D design) and that's the one BoM manages and lets the viewer render. Normal and specular textures, however, can still be applied onto your mesh body skin layer while still keeping it BoM-active and that's the point of this update.

As the MdlM latex outfits use materials and BoM does not support materials, the solution here is to provide you with additional appliers that will replace your skin shine (but not your skin textures, which are supposed to be the Upper and Lower body BoM textures), and many Tattoo wearables that contain the diffuse textures of each latex outfit (that's 129 tattoos for the Catsuits, 129 for the Bodysuits and 252 for the Socks & Gloves, yes that's a bit much but that's what it takes).


What's in the update

The update contains, for each product, a new HUD called "something something skin shine appliers for BoM something something" (for example "MdlM Latex Catsuits skin shine appliers for BoM OPAQUE" for the opaque catsuits) and a bunch of Tattoo wearables, one per color. All those new wearables are contained in boxes because the Latex Outfits can be updated either with a Marketplace redelivery or with the provided updater which gives you the new product from a server in-world, and you can't include sub-folders in a box unlike in pure Marketplace products. In some cases, like the Latex Socks & Gloves Fatpack, that makes quite a lot of new boxes.

How to use

Wear one of the wearables provided in this update and the corresponding Skin Shine HUD. Click on the button of your choice to apply the corresponding shine, and if you chose the correct button the shine will match your tattoo and you will look like you are wearing the latex outfit you wanted. Easy, right ?

Wait I'll give you an example. Firstly, and most importantly, make sure your mesh body is set to "Bakes On Mesh" (on Maitreya Lara V5 that's the big "Bakes On Mesh" button in the "Skin" tab of your HUD). Notice that I'm wearing the Proud Girls, in BoM mode too (that's a switch in its Options menu) to show that they work seamlessly with the rest.

Then wear the "Catsuit Opaque - Black" Tattoo (provided you own the Opaque Catsuits, if not, replace with whatever variant and color you prefer).

This is what you see :

It's not really a catsuit yet, but we'll get there. Now wear the "MdlM Latex Catsuits skin shine appliers for BoM OPAQUE" HUD, it looks like this :

(there's a reason why there is so much empty space, as you'll see below)

Click on the rightmost button and you get this :

Aha, you can now distinguish the seams and creases, the catsuit shine is still dull though. All you have to do is manipulate the shine of your skin, and most likely the shine of your Proud Girls too. I'll do both here, setting the Glossiness and Intensity to max on my Maitreya Lara mesh body, as well as its Environment to 30 (that's three clicks on the right of the "+" button next to the "Environment" slider on the Advanced Skin Panel of the Maitreya HUD). Same for my Proud Girls, that I set to "255 30" to match (open the Proud Girls menu, go to "Layers", then "Skin shine", then write "255 30" in the text box and click "Submit") :

And now we have it, and no layer is necessary since it is all directly on the skin. Notice though that the catsuit is very sticky, it is like painted on your skin. Depending on your mesh body, you may or may not have some "BoM parts" to loosen the fit. Maitreya provides such parts, no need to demonstrate them here though, I have written a full blog post that explains a lot of things about Maitreya, including BoM and BoM parts at the end.

So, what really happened ? You have noticed that wearing the BoM version of the catsuit is done in two steps. Wear the Tattoo wearable and apply the skin shine, not necessarily in that order. And you don't have to do both if you don't want to. For example, if you only apply the skin shine without wearing the Tattoo (or you unwear the Tattoo), you will look like you are wearing a clear latex catsuit, like this :

This is, actually, almost exactly the same thing as wearing the Clear Latex Catsuit with the regular appliers, on the Tattoo layer. With the notable difference that unlike the applier version, the BoM version lets you see reflections (there's an Env Box in the room I'm in) for a more realistic look, while the applier version cannot do that because it is alpha-blended (i.e. transparent).

The skin shine

So, now that you see what it does and how to use it, let's get into the nitty-gritty stuff. It is important because you will see that this update does not merely port existing appliers to BoM, but also offers you a few new features that you can use to your advantage.

In a nutshell, every applier you see on the HUD is a stripped down version of the corresponding latex outfit applier, meaning it only applies the bump and shine to your Skin layer, but not the texture itself -- you have to do it manually by wearing the Tattoo layer of your choice. The part in bold has notable consequences.

Since it applies the latex shine to your skin layer, it replaces whatever shine was applied to it before. Usually, the factory shine (for Maitreya, that's one of the three "Material Presets Skin" buttons on the Advanced Skin Panel).

Attention : If your skin shine is custom, make sure you know how to re-apply it after you're done wearing your latex suit, because the HUD cannot do it for you.

This is not really an issue when you wear Latex Catsuits because they cover the whole body, but what about Latex Bodysuits which don't cover the legs ? Or Latex Socks or Gloves ? What happens to the exposed skin when you apply these ?

The answer is : instead of making the exposed skin dull and without shine, it replaces its existing shine with a subtle sheen. The key part is that although the shine values (glossiness, environment and shine color) are the same as the latex since it is on the same layer, the exposed skin shine is toned down a lot. In other words, when you put some environment on your latex to reflect your surroundings (if you have a reflection box or an env box around), your skin won't reflect it at all unless you crank the value to the max. Likewise, your skin will shine in a subtle way, a lot less than your latex.

Here is an example :

Medium skin shine (gloss about 200, intensity about 75%, environment 10), you see no shine on the skin, only on the latex.

Max skin shine (gloss max, intensity max, environment 30), you see a subtle shine, and even a little environment reflection on the skin, while the latex shines brightly.


Since there are cases where you may want to wear only a part of the latex outfit and not cover the whole body, for example when you wear only the nipple or pussy pasties in the Transparent Catsuits, or just gloves or just socks, I have included appliers to only apply the skin shine, either on your body or on your head, or both.

This allows you to have a matching skin shine over your whole body (mesh body, mesh head, Proud Girls if you want) in a seamless way. In the Socks & Gloves BoM HUD, you can even apply skin shine only to the upper or the lower body part, to match the skin shine applied by the socks or by the gloves, respectively.

I quite like this skin shine because it's subtle and allows for a slight environmental reflection (as if you were slightly wet or oiled), even on my Lelutka Origins mesh head which normally does not provide any control for environment shine. See for yourself with the Glossiness and Intensity to the max, and Environment set to 30 :

With this update, you can therefore give your skin (body and head) this new custom shine without even using the latex suits.


As you know, the Catsuits, Bodysuits and Socks & Gloves come in 4 variants : Opaque, Sheer, Transparent and Clear, each containing around 30 colors and/or patterns. The Socks & Gloves are actually double that since you can apply the gloves and the socks separately. This is why there are a lot of Tattoos included in this update.

The Fatpack HUD contains all the buttons while the other HUDs only contain some of them, which is why some HUDs have very few buttons and a lot of empty space.

Each button contains a Maitreya applier for your skin (unlike regular Maitreya appliers, you won't get a menu asking you where to apply since it goes to your skin directly, no need to ask), and triggers the corresponding Omega applier as well, plus modifies your accessories (neck piece and shoes) if you are wearing them, except when you apply the naked skin shine. That way, clicking on a button applies to your Maitreya body if you wear one, to your Omega body if you wear one, and to your Proud Girls if you wear them and if they are set to execute Omega appliers. This HUD does not send Lolas appliers at all, since Lolas and Omega conflict for the breasts.

One thing that is important to keep in mind though is this. Unlike the Maitreya appliers that only replace the skin shine without touching the skin texture (which means you can actually use them even while not in BoM mode, if you want), the Omega appliers require to set a texture, which is the BoM one in this case. In practice, this means that when you apply to your mesh body (not Maitreya), your skin will be replaced by the BoM "textures", if not already done.

The small head button on the left applies the naked skin shine to your head through an Omega applier (obviously not a Maitreya one since Maitreya Lara has no head) so make sure your mesh head is Omega-compatible. The remark in bold above applies here too : clicking on this button will de facto turn your head BoM since it will set the head BoM texture.

Attention : I noticed that applying the skin shine to the head resets the tint of the head skin to white, at least on my Lelutka Origins (Simone 2.0). It might be a quirk with Omega or with Lelutka. I don't know if it does that on other mesh heads but that's a thing to be aware of. If you don't want to lose your skin tint, save it somewhere first.

Here is what each button does on the Catsuit and Bodysuit HUDs :


And here is what each button does on the Socks & Gloves HUD, which doubles the number of appliers since you have separate ones for the upper body and for the lower body. This is why each button has a separator to split it in two parts. Notice it has the head naked skin shine applier too.

Notice the two "plain" buttons (that's four appliers). The one on the left is for the opaque socks and gloves because it contains a crease near the top edge, while the one on the right is for all the non-opaque socks and gloves, not having a crease near the top edge. Of course feel free to use the one you like, just be aware of the difference between the two.

Note : The socks and gloves have a subtle shadow outside the edges to give the illusion that they are tight enough to press the skin inwards. It works quite well on the appliers, also quite well on BoM, but with BoM there is a better way to do it, by adding normals to make the surface of the skin near the edges reflect the light in a more realistic way. I tried, the effect looks better than the painted shadow, I really like it. However, the tattoos also have the painted shadow, which makes the edge doubly as dark so it doesn't look good when wearing the tattoo plus the skin shine. To remove the painted shadow from all the socks and gloves tattoos represents too much work, there are hundreds of them. So maybe one day I will, but for now the socks and gloves skin shines do not include that additional edge normal, even though I wish it did.

Tinting your suits

Since you can tint your regular suit appliers with your mesh body HUD (Maitreya V5 also offers this option, it didn't in V4), it is normal that you can tint your tattoos as well. For this reason, all the Tattoo wearables in the BoM suits are modifiable.

Using your accessories

As you know, the latex catsuits come with a neck piece and shoes, the bodysuits come with the neck piece and the socks come with the shoes. Those are also impacted by the BoM appliers (yes, I know "BoM applier" is an oxymoron but I have no better word for them) but since they are not BoM themselves, they are applied an invisible texture, and the shine to match your skin. I recommend you do not set an environment value on them though, since they are transparent they would not reflect the environment like your skin would. And it they did, it would make the reflection twice as bright anyway.

The advantages of BoM

So, now that you know how to use it and how it works, why would you want to use the BoM suits at all, you might wonder ? I'll be fair with you, I've been wondering that myself for a long time, not really seeing a point. However, it was a popular request, I kept getting messages from customers asking me why there were no BoM versions of my catsuits, and when I would make them. My answer was invariably "BoM does not support materials so there is no point". Well that's not entirely true, there are a few good points to using BoM, but only one of them really decided me to go ahead and make them, regardless of how much work it represents (and when you see the number of tattoos, you understand). So what are they ?

It makes layers unnecessary

Obviously, if you want to use a BoM catsuit, that would be primarily to dispense yourself from using additional layers. With Maitreya V5 in particular, you can then avoid wearing a layer just for the latex outfit you want to wear, since its texture and shine are on your skin instead of on a layer. This allows you to save one attachment slot (other mesh bodies may not provide that option but Maitreya now does), and to lower your complexity count.


It saves a layer for more latex

Well, yes, by extension you can wear more appliers since your latex suit does not take one.

It solves alpha-blending conflicts

This is a big advantage of BoM. Since the latex suit is applied to an opaque surface (your skin), there is no alpha blending conflict with other layers or with your hair anymore, even if the suit is transparent !

See for yourself :

Wearing alpha-blended rigged hair, it completely hides the applied catsuit !

Same hair but BoM catsuit, no conflict detected.

Transparent suits reflect environment

This is the one that really decided me to go ahead and make the BoM suits. If you wear an Env Box or any reflection box, you know that you can see the reflections only on an opaque catsuit or on a masked latex suit (which is not always possible to begin with), but not on an alpha-blended layer, which means the sheer, transparent and clear catsuits could not reflect your env boxes, sadly.

With BoM it is different since the shine is applied to your skin layer, which is always opaque (or at least masked) ! This means that you can finally get the dynamic reflections on your transparent catsuits !

Look at this glorious polish.

You can mix materials and textures

This is a side effect of the fact that you wear a BoM catsuit in two manual steps instead of one. You can for example wear a black fishnet catsuit and the plain catsuit applier instead of the fishnet applier. Nothing keeps you from doing that and the result you get is something you can't get with the transparent catsuit applier :

Black Net with plain catsuit shine.

Likewise, you can wear a catsuit with holes for your tits, but with a plain latex suit applier, covering your tits too but not hiding them :

Sheer Black Holes with plain catsuit shine.

Or you can even wear several tattoos :

Transparent Yellow under Black Clear.

You can't do any of these with regular appliers, although you could do the third one if you set the clear black layer to mask mode. But then you would need two layers anyway while with BoM you need zero.

The disadvantages of BoM

BoM is not the applier killer some would like it to be, there are several drawbacks that make the regular appliers still useful, and sometimes necessary depending on what you want to achieve.

It does not cover the whole neck

Obviously, the mesh body does not go as high as the neck piece, which means that if you want your catsuit or bodysuit to go as high as your jaw, you still need to wear the neck piece. Which is a problem sometimes, because as pointed above, transparent latex on the neck won't reflect the environment (because it is alpha-blended and all that). So you see your neck under it, and only half of it can reflect the environment. There is no real solution to this problem, at least not at the moment.

Painted on the skin

BoM makes the outfits (not only these latex suits) painted on your skin, that's even the whole point. This is not always desirable though, you are wearing a catsuit, not latex paint, so you might want some looseness. Typically, the latex goes under your fingernails and toenails, and you certainly don't want that. Depending on your mesh body, you can hide your nails or not (Maitreya lets you hide the fingernails but not the toenails). And depending on your mesh body, you may or may not have additional "BoM parts" that let you loosen the fit a bit. Maitreya V5 offers that capability. Of course, having to wear BoM parts kind of defeats the "save one attachment slot" advantage but at least BoM parts are not as complex as full layers.

It replaces the skin shine

Well, yeah, that's even the whole point. If you've read the whole post you already know that and what it does instead. But you may or may not like the skin shine included in the bodysuits and socks. If you don't like it, lower the glossiness but that makes your latex less shiny.

You can't combine bodysuits and socks

Since the BoM skin shine appliers apply to the skin, and since the bodysuits and the socks are different products, I could not merge the bodysuits and socks in the same applier. That option is not entirely close though, I might make some at some point but I don't know how to distribute them at the moment. So if you want to wear stockings and a bodysuit, one of them has to be a regular applier.

The skin tint also tints the suits

Since the Tattoo is part of the skin, it is also tinted the same way if your skin tint is not fully white. So keep this in mind if you want to wear a white catsuit but your avatar skin is made darker by a custom tint you've set, the white catsuit will not be so white.

How to update

Simple. Either rez the updater contained in your folder (the one that was delivered to you by the Marketplace the day you bought it) and you will get your update automatically, or request a redelivery on the Marketplace website.

Have fun !