While the Hubs are overdue for an update, I've been working on a new feature for the Mesmerizer that will probably see the light of day even before the Hubs do. That feature is Outfits. The Mesmerizer's outfits are based on the design used by OpenCollar, and are compatible with an OpenCollar folder structure. However, Mesmerizer outfits provide some extra features to address some limitations with OpenCollar's outfits.
OpenCollar has had outfit support for a while, and it's a nice feature. The intent is to allow your owner to change your complete look, much like regular inventory outfits let you change your own clothes and body in one go. The RLV commands around wearing items from the #RLV folder are much more focused on things that you might add or remove from an outfit (e.g. a set of cuffs), than they are on changing everything you're wearing, so OpenCollar has had to define some conventions to separate "complete outfits" from "items that can be added", so that it can handle them differently.
The way it achieves this separation is by making use of the feature of the #RLV folder that folders whose names begin with a period (".") are not reported back to a RLV user. This means that folders that begin with periods are essentially invisible to RLV queries, although they are still accessible by RLV commands (or at least RLVa commands - see footnote). For example, if you have a folder under #RLV called folder and inside that a second folder called .hidden, then asking RLV for the names of sub-folders of folder (e.g. the Mesmerizer command getinv /folder) would show no such sub-folders, but performing a recursive attach operation on folder (e.g. the Mesmerizer command wearoverall /folder) would cause the contents of both folder and the .hidden subfolder to be added.
OpenCollar uses this behavior for two things. First, it defines a convention that a hidden folder called .Outfits, immediately beneath the #RLV folder, shall be the 'root' folder for all outfits. The fact that .Outfits begins with a period means that it won't show up in RLV queries, so RLV users won't be tempted to see what happens if you 'add' an outfit to what you're already wearing.
OpenCollar also uses this behavior to define .Core folders, which I'll come back to in a moment. But before we get into that added complexity, the basic idea of outfits is simple - they are folders that exist underneath #RLV/.Outfits, but unlike "regular" #RLV folders, they are expected to contain a complete avatar - clothes, shape, hair, skin, any HUDs, collars and other gadgets or toys you usually wear, plus body, hands, feet and full-body alpha layer if you use a mesh avatar. The commands to change outfits will remove everything you're currently wearing before putting on the new outfit. You can create a folder hierarchy beneath .Outfits - for example, you might want to divide your outfits into "Gowns", "Casual", "Lingerie", etc, and use these as first-level folders beneath .Outfits, and create the actual outfits as subfolders of the appropriate first-level folder. OpenCollar would show you these first-level folders when you go to the Outfits menu, and clicking on any of them would go into the folder and show the actual outfit folders inside, letting you choose one to wear.
OpenCollar thinks of an outfit as a combination of a "core look" and some clothes. A core look is basically your avatar - shape, skin, makeup, hair, plus HUDs and other attachments you always wear. Typically, the same core look might be shared between several outfits, although it doesn't have to be. The convention for OpenCollar is that, when you ask it to change to an outfit, it will first look for the "core look" associated with that outfit, wear that, and then add the contents of the actual outfit folder.
The way it finds a "core look" is fairly simple. It assumes that a core look will be specified in a folder called .Core, and it will look for such a folder first in the folder containing the outfit you're trying to wear, and if it doesn't find one there, it will look in the parent folder, and so on until it gets to the .Outfits folder.
This method of locating a core look, separately from the actual outfit, matches some common use-cases well. For example, if you are a role-player with several characters, you might use those characters as your first-level folders - a folder for every character, each with its own core look - and then different clothes for the character in subfolders. Or you might use the top-level folders to simply define different looks for a single avatar - perhaps one with hair in an up-do and evening makeup with which you'd wear formal outfits, and another top-level folder for a more casual look, etc. The advantage of splitting the .Core folders from the actual outfits is that it allows you to modify a core look (perhaps by changing the hairstyle) and have that change immediately appear in all outfits that share that same core look.
This is a neat way of doing things - it allows a "core look" to be shared across multiple outfits, but doesn't require that you do that - you're free to define a different core look as part of each outfit, or at any level in the folder hierarchy you create beneath #RLV/.Outfits.
So what are the limitations of this scheme? The main one is that, if you're sharing a core look among several outfits and you want to change any part of that core look for just one outfit, you have to make a complete new .Core folder for that outfit, with its own copies of every object in the core look, with just the one change you want to make. Let's assume that you have a look you're very fond of, and so you put the objects that make up that look into #RLV/.Outfits/.Core so that it becomes the default "look" to be used by any of your outfits. But then you find that you want to use a different hair with one specific outfit. Your only options are to either remove the hair from the core look and instead put it into every single outfit, or to create a complete .Core folder in the one outfit with which you want to use the different hair, effectively giving that outfit its own core look. If you create a .Core folder inside the outfit folder, then whenever you want to change your core look (for example, use a different skin), then you have to remember to update the skins in all the .Core folders. It's possible to use the viewer's "Find All Links" feature to help, but ideally, you'd want to be able to define a .Core folder for the outfit that contained just the new hair, and somehow took everything else for your core look from the 'standard' .Core folder.
The Mesmerizer's extensions to OpenCollar outfits makes this possible. With the Mesmerizer, any .Core folder that contains things to wear will behave just as it does in OpenCollar. However, a .Core folder that just contains subfolders behaves differently. For a .Core folder that contains nothing but subfolders, each subfolder is considered to contain a named group of items to wear, with the name of the group being the folder name. When building a core look, if the Mesmerizer finds such a folder, it will wear the contents of the subfolders, remember their names, and then continue to the parent's .Core folder. But it will only wear items from a given named group the first time it encounters it.
Let's look at how this would solve the issue described above, of wanting a different hair in just one outfit. Assuming you have your favorite core look in the top-level #RLV/.Outfits/.Core folder, but you want to use just a different hair for an outfit that's in #RLV/.Outfits/Casual/Jeans&TShirt. To do this, you'd create a .Core subfolder inside the Jeans&TShirt outfit folder, and inside that folder, create a subfolder called Hair. You can call the subfolder whatever you like, but you should pick a descriptive name for it. Inside #RLV/.Outfits/Casual/Jeans&TShirt/.Core/Hair you'd place the hair that you want to use with this outfit. Then, in the top-level #RLV/.Outfits/.Core folder, you'd create a similarly-named subfolder called #RLV/.Outfits/.Core/Hair and move the hair from #RLV/.Outfits/.Core down into #RLV/.Outfits/.Core./Hair. Then, when building a core look for the Jeans&TShirt outfit, the Mesmerizer would first look in #RLV/.Outfits/Casual/Jeans&TShirt/.Core, and see that it contains a subfolder called Hair. So it would add the contents of that subfolder (the hair for this outfit) to the core look, and remember that it's added the "Hair" group. Since #RLV/.Outfits/Casual/Jeans&TShirt/.Core contains no wearables (just subfolders), it would look in the outfit's parent folder, #RLV/.Outfits/Casual and then in #RLV/.Outfits for a .Core folder. Finding #RLV/.Outfits/.Core, it would see that it contains a subfolder called Hair, but since it knows that it already has a "Hair" group, it will ignore that subfolder, but will wear any other subfolders, as well as all the wearables in the .Core folder itself.
The end result of this is that the "Hair" group in the outfit overrides the "Hair" group in the default outfit, but everything else in the core look for the Jeans&TShirt outfit is taken from the top-level default core look, which is exactly what we wanted. When wearing an outfit that doesn't have a "Hair" group in its .Core folder (or doesn't have a .Core folder at all), the Mesmerizer would use the Hair subfolder from #RLV/.Outfits/.Core.
You can use this technique to override any part of your core look at any level in your outfit hierarchy. It's particularly useful if you use a mesh body, or even mesh body-parts. My exposure to mesh bodies is mostly to the Maitreya Lara body, but I believe that what I'm about to say is applicable to other bodies too.
Maitreya Lara comes with hands and feet as separate mesh objects that you can choose to wear (or not) with the body. You'd want to wear them in an outfit if they would be visible in that outfit, but if the outfit includes mesh gloves, there's probably not much point in wearing mesh hands. Similarly, an outfit that contains mesh knee-boots probably wouldn't need to include feet. These "tweaks" can easily be done with the Mesmerizer's outfit support by putting the Maitreya hands and feet in subfolders (called "Hands" and "Feet") of the top-level .Core folder. Then any outfit that doesn't want to include hands or feet can include an empty .Core/Hands or .Core/Feet folder. When building the core look, the Mesmerizer doesn't care that these folders are empty - upon encountering them it will remember that it has already worn "Hands" and/or "Feet" and therefore will not wear them from any higher-level .Core folders it visits.
With mesh bodies, clothing falls into two basic types - mesh and applier. Some clothing items may actually contain objects of both types, but for the purposes of this discussion, such "hybrid" clothes will be considered to be appliers.
From the point of view of assembling an outfit, mesh clothing is simplest, since you wear it by simply adding it to your outfit, and you remove it by just detaching it. Some mesh clothing may need the body's alpha regions to be adjusted on wearing/unwearing, but much clothing does this automatically. With Lara, at least, there is a free kit that allows you to add this feature to mesh clothing that doesn't already have it. For best use with Outfits, you will want to enable this "auto-hiding" on any clothes you use as part of an outfit.
Applier-based clothes are very different. An applier is in some ways similar to system clothing - it's a texture that's applied to a mesh layer defined by the body. Unlike system clothing, however, there's no standard way to automatically "remove" an applier layer from a mesh body. With Lara, you can do this via the Maitreya HUD, but I'm not aware of an existing way to do it "automatically", via inventory operations.
Since appliers effectively modify the body (by loading a texture onto one of the body's clothing layers), they can cause problems if you share a single copy of the body between multiple outfits, since the effect of using an applier in one outfit will be seen in other outfits that subsequently use the same body.
Non-applier clothing has a similar issue with the auto-hiding mentioned above. Switching outfits involves first removing everything that's not locked, and then wearing the new outfit. If the original outfit included clothes that automatically hide parts of the avatar (for example a pair of boots that hide the lower legs), then normally if you took off the boots, you'd expect them to un-hide the parts that they had hidden. However, detaching all worn items in preparation for an outfits change might easily remove the body before the boots, which would mean that when you next wore the body (possibly as part of the outfit you're about to change into) the lower legs will still be hidden.
The two issues are both cases where the setting for one outfit "leaks" into another outfit because they share a single instance of the body. This doesn't happen with the SL avatar, because both alpha layers and system clothing can be removed, with the expected effects. Mesh bodies don't in general provide anything that works in quite the same way.
What's wanted is a way to put the body into a known state - with no clothing layers applied and all body-parts visible - when it's first worn, as part of a core look, so that subsequently an outfit can add applier layers, or hide body parts if necessary. This is possible with some but not all mesh bodies today.
As an example, the Maitreya Lara body supports the creation of an "auto-hide object" that can hide a set of body regions on wearing, and un-hide them upon removal. This can be used to create a "show all" object that will simply unhide the entire body, by having it first hide everything, and then detach itself. This sort of object can be put into your top-level .Core folder, so that your default look has all body parts visible. Individual outfit folders can contain objects with their own auto-hides (or clothing with auto-hide functionality built-in).
For this to work, some careful sequencing is required, so that the core look body is worn first, then the auto-hide object from the core look, which must be given time to detach itself, and then clothing and auto-hide objects from the outfit folder. The way the Mesmerizer allows for this sequencing is that, for each .Core folder it visits while building the core look it will first wear objects from the .Core folder itself, then it will visit each subfolder of the .Core folder (each of which defines a group) and wear items from those folders, but won't yet wear items in any sub-folders of the group folders. Then it will pause for a second or two before adding the sub-folders of the group folders. This allows you to place, for example, a mesh body in a "body" group, and a "show all" object in a sub-folder, with the pause allowing the mesh body to be worn and initialized before the "show all" object is added. Once the core look is worn, the Mesmerizer will pause again to give any "show all" objects time to work and detach before it adds the contents of the outfit folder.
A similar pattern will work with objects that clear applier layers. Such objects can be created with the Omega system. However, they don't work well with the Maitreya body, since Lara insists on prompting for approval before accepting an applier layer change request, and multiple such changes will get dropped. The Omega people have asked Maitreya to make this work; hopefully Maitreya is listening.
There are two new commands to handle Outfits: listoutfits and wearoutfit.
| Command | Parameters | Description |
|---|---|---|
| listoutfits | 1 | Show the outfits available below folder <p1> |
| wearoutfit | 1 | Wear outfit <p1> |
Both commands take a path, which behaves very similarly to the path given to the wear and getinv commands, except that the root "/" of the outfit paths is #RLV/.Outfits, rather than #RLV as it is for the wear and getinv commands. Like wear and getinv, the new outfit commands can handle either absolute pathnames (starting with a "/" character) or relative pathnames, which are treated as relative to the last valid outfit path given. And similar to the find command, listoutfits sets a variable "outfits" to a list containing the outfit folders it displayed, so that to wear for instance the second outfit returned by listoutfits, you can simply say wearoutfit "$outfits.2"
Along with outfits, the Mesmerizer update, tentatively named V1.1, will include some extra spirals, as well as improved support for adding your own textures as either frame-based or rotating animations. This has always been possible, but there were some limitations in the feature that 1.0 made available, and I never documented it. The setspiral command lets you choose from one of the provided spirals if you invoke it with a small integer, e.g. setspiral 5. The integer specifies which built-in spiral you want (1 to 7 in v1.0, 1 to at least 14 in v1.1). You can use a negative number to run the spiral backwards.
To use your own texture, specify the texture's key instead of the small integer. The texture can be animated either by rotating it, or it can be treated as a series of frames which are displayed as an animation. This is specified via the setspiral parameter as follows:
| Example | Description |
|---|---|
| setspiral 684e2d18‑ae40‑42e5‑af3d‑9e652018e2ea | Rotate the given texture at default speed |
| setspiral "684e2d18‑ae40‑42e5‑af3d‑9e652018e2ea:2.0" | Rotate the given texture at 2 radians per second |
| setspiral "684e2d18‑ae40‑42e5‑af3d‑9e652018e2ea:2:3" | The texture is an array of 3 rows of 2 frames each. Animate at default speed. |
| setspiral "684e2d18‑ae40‑42e5‑af3d‑9e652018e2ea:4:2:8.0" | The texture is an array of 2 rows of 4 frames each. Animate at 8 frames per second. |
Note how when the parameter contains special punctuation such as ".", it must be placed in double-quotes to keep it as a single parameter. You can put a "-" sign in front of the texture key to cause it to be rotated or animated in reverse. And if an animation texture contains fewer frames than the product of rows and frames-per-row you can specify the actual number of frames in square brackets after the texture key, for example:
setspiral "-684e2d18-ae40-42e5-af3d-9e652018e2ea[5]:2:3"
This says that the texture is arranged as a 2x3 array of frames, but only the first 5 frames should be displayed. The "-" sign at the front says that the five frames should be animated in reverse.
No comments:
Post a Comment