[opensource-dev] Open Development project: extendingavatar wearables

Nyx Linden nyx at lindenlab.com
Thu Mar 25 10:58:45 PDT 2010


Arbitrary wearable re-ordering (if you want to be a superhero with 
underwear over your pants) is a rather difficult problem. I'll get into 
more detail once the forums are set up, but its probably beyond what I 
can reasonably do for this project cycle. I'm open to ideas from the 
community on how to do this on a very constrained timeframe though.

Good outfit transfer mechanisms (transfer a folder of links, grab the 
originals, respecting transfer/copy permissions, and maintain order) is 
an area we're admittedly lacking right now. I really don't want to store 
order information in the wearable itself, but transferring an outfit 
folder itself along with order information is something that would be 
useful in the future, just beyond the current project cycle I think.

 -Nyx

Carlo Wood wrote:
> The advantages of this:
>
> * Automatic insertion that makes sense
> * No need to edit (no-mod) items
>
> The disadvantage:
>
> * Still can't wear a shirt over a jacket, or
>   a designated "undie" over a "pants".
> * Giving an outfit to someone else might
>   change unexpectedly change the order in
>   which the items were stored (?)
>
> On Thu, Mar 25, 2010 at 12:08:54PM -0400, Nyx Linden wrote:
>   
>> Wow great discussion so far - these are a lot of the issues I've been 
>> thinking on for a good while now, and I'm glad they're being brought up 
>> immediately.
>> I'm still working on getting the forums set up, where this conversation 
>> would ideally take place, but in the meantime, I'll try to respond on-list.
>>
>> We're trying to make the system as flexible as possible. Think of it 
>> this way: you have a bunch of 'categories' or 'slots' - one for each 
>> type of wearable (pants, shirts, jackets). Inside each category, you can 
>> have multiple items up to a reasonable maximum. When you "wear" a shirt, 
>> it gets added to the top of the list of shirts that you are wearing. If 
>> you don't want it to be on top, you can push it down below other shirts.
>>
>> For example, let's say you're using an avatar with the below clothing:
>>
>> shirts:
>>     * blue shirt
>>     * green shirt
>> pants:
>>     blue jeans
>> shoes:
>> socks:
>> jacket:
>>     *winter coat
>> gloves:
>> undershirt:
>>     * White T
>> underpants:
>> skirts:
>> tattoos:
>>     * dragon tattoo
>> alpha masks:
>>     * super leg hider
>>
>> and you click "wear" on an item that is a red shirt. your new appearance 
>> would be:
>>
>> shirts:
>>     * red shirt
>>     * blue shirt
>>     * green shirt
>> pants:
>>     blue jeans
>> shoes:
>> socks:
>> jacket:
>>     *winter coat
>> gloves:
>> undershirt:
>>     * White T
>> underpants:
>> skirts:
>> tattoos:
>>     * dragon tattoo
>> alpha masks:
>>     * super leg hider
>>
>> there is not a concept of a "shirt1" slot, vs "shirt 2" etc - the list 
>> of your shirts can change size according to how many shirts you want to 
>> wear at the time. The order in which you wear your clothing is 
>> completely up to the end-user who is constructing the outfit.
>>
>> a couple things to note with this approach:
>> 1) the listed order of clothing probably will change to something that 
>> makes a bit more sense.
>> 2) the list is wearable-focused, not texture-focused. Hence tattoos 
>> won't be split up into upper/lower/head, as they are a single wearable item.
>> 3) the "order" will be able to be changed frequently and will not 
>> require any change to the item itself - only how it is stored in 
>> inventory. Hence, you don't need mod privs to re-order a shirt.
>>
>> Thus, pants are not inherently set to "pants 3", they're just pants! The 
>> consumer of said pants will determine if there are any other pants above 
>> or below it. This has the other advantage of allowing you to take a 
>> single pair of pants ("blue jeans") and having it be the bottom layer in 
>> one outfit, and the 3rd layer in a different outfit, even if they refer 
>> to the same wearable item!
>>
>> I hope that clarifies the proposed design - I hope to get more detailed 
>> information up in a central location sometime next week. In the 
>> meantime, keep poking at the proposal on-list!
>>
>>  -Nyx
>>
>>
>>
>> Dzonatas Sol wrote:
>>     
>>> Kitty wrote:
>>>   
>>>       
>>>> If someone sells a full-top + high pants combination they wouldn't have to
>>>> struggle with defining which shirt layer goes on top of which other one by
>>>> messing with numbers - since those will still result in conflicts with what
>>>> it's being worn in combination with - but you just leave it up to the user.
>>>> If they want the bottom of the top tucked into the pants then they just
>>>> arrange the top under the pants. Or vice versa.
>>>>
>>>> It also solves the issue where you're limited to what the creator felt like
>>>> providing you with and working with clothing items is much more natural than
>>>> working with clothing layers that only clumsily map to what they represent.
>>>>   
>>>>     
>>>>         
>>> This is where I think a outfit list should be hierarchal  to allows 
>>> someone to wear multiple outfit (lists).
>>>
>>> For example, let's say this outfit list is already being "worn":
>>>
>>> Outfit "Worn":
>>> * Upper-body
>>> ** Shirt
>>> ** Undershirt
>>> * Lower-body
>>> ** Underpants
>>> ** lower-tattoos
>>>
>>> Here is another outfit list (as Kitty suggested):
>>>
>>> Outfit "Kitty's":
>>> * Upper-body
>>> ** full-top
>>> * Lower-body
>>> ** high-pants
>>>
>>>
>>> If we take Kitty's outfit and 'add to' the worn outfit (with default 
>>> order), we get:
>>>
>>> Outfit "Worn":
>>> * Outfit "Kitty's":
>>> ** Upper-body
>>> *** full-top
>>> ** Lower-body
>>> *** high-pants
>>> * Upper-body
>>> ** Shirt
>>> ** Undershirt
>>> * Lower-body
>>> ** Underpants
>>> ** lower-tattoos
>>>
>>> No priority numbers had to be given in the above lists to see that 
>>> layers near the top of the list appear as the outer-most layers to bake. 
>>> With the lists above, *both* the creator of the outfit and the wearer of 
>>> the outfit have full flexibility to change the priority of the layers, 
>>> with mod or no-mod. Keywords, like "Upper-body" slots, can appear 
>>> anywhere in the hierarchies multiple times.
>>>
>>> With the list hierarchy like above, the program that bakes the layers 
>>> only needs to start at the bottom of the list to bake the first layer, 
>>> and step up the list to bake the next layer, until it reaches the top. 
>>> The keywords like "lower-body" and "upper-body" only denote where (or 
>>> how) the textures (in sub-lists from that keyword) are baked onto the 
>>> avatar.
>>>
>>>
>>> _______________________________________________
>>> Policies and (un)subscribe information available here:
>>> http://wiki.secondlife.com/wiki/OpenSource-Dev
>>> Please read the policies before posting to keep unmoderated posting privileges
>>>   
>>>       
>> _______________________________________________
>> Policies and (un)subscribe information available here:
>> http://wiki.secondlife.com/wiki/OpenSource-Dev
>> Please read the policies before posting to keep unmoderated posting privileges
>>     
>
>   



More information about the opensource-dev mailing list