[opensource-dev] Open Development project: extending avatar wearables

Glen Canaday gcanaday at gmail.com
Wed Mar 24 19:57:45 PDT 2010


That's actually what I would like to avoid, specifically. That forces 
the creator to continue to dictate whether your underwear goes on top of 
your pants or not. There's no added flexibility for the resident in that.

Here's why I'll be an advocate of just a few extra numbered layers on 
top of the existing system (until someone blows me away with a simpler 
to implement, more flexible solution):

Creator: no change. "Hmm... undie, pants, undershirt, shirt, jacket."
Creator A: "... it puts the pants on pants layer...."

Wearer: "I got a pants layer from Creator A! ... but my tights are 
pants, too... Oh, ok. Tights on Pants1, pants from Creator A on Pants 2. 
That'll do it.."

No change for the creator - none. Not a thing. The user gets a "bump up" 
or "bump down" item in the current "wear" submenu.. that's all. Max 3 or 
so, and they act like layers in Photoshop or Gimp, which is essentially 
what they are now.

Totally minimal UI change, no change in permissions, and just a few 
extra layers to bake - half of which will usually be empty anyway until 
people discover the coolness of wearing 3 pairs of pants at once. (last 
part's a joke, but you get my meaning.)

lower layer list:
*skin
*alpha
*tattoo
*underwear 1
*underwear 2
*underwear 3
*pants 1
*pants 2
*pants 3
(*jacket 1 lower)
(*jacket 2 lower)
(*jacket 3 lower)

uppers:
*skin
*alpha
*tattoo
*undershirt 1
*undershirt 2
*undershirt 3
*shirt 1
*shirt 2
*shirt 3
*jacket 1 upper
*jacket 2 upper
*jacket 3 upper

Would also be nice to have a few facial layers, too. The current tattoo 
layer in 2.0 is full-body, one layer only. That doesn't work for people 
who like to mix-n-match, but that in combination with the above list does.

I'm still open to be convinced - I'm just starting the discussion off!

--GC

On 03/24/2010 10:58 PM, Dzonatas Sol wrote:
> An easier way may just to have  list without ordinals. Example:
>
> Outfit:
> * Upper-body
> ** Jacket
> ** Shirt
> ** Undershirt
> ** upper-tattoos
> ** custom-upper-body-skin
> ** another-custom-upper-body-skin
> * Lower-body
> ** Pants
> ** Underpants
> ** lower-tattoos
> ** custom-lower-body-skin
> ** another-custom-lower-body-skin
>
> etc
>
> We can just use a hierarchal like list when any number of subelements. 
> The items near the top of the list appear above the other layers. This 
> way specific layer numbers aren't needed (or the viewer can 
> automatically compute them for you).
>
> Just insert an item into the list and move it up and down in layer 
> appearance priority.
>
> Glen Canaday wrote:
>> Actually, I don't mind "undies, shirt, and jacket." What I'm really 
>> referring to is maybe 3 undies layers numbered 1,2,3. Creators can 
>> still specify which of those three as they do now, but the user would 
>> choose the 1, 2, 3 bit. The creator doesn't lose the ability to 
>> choose which of the three upper layers (or two lower), so they can 
>> still specify on which layer the items would look as intended... but 
>> the user doesn't have to stick to "gee, do I wear the garter, the 
>> undies, or the tattoos? But I still want to wear the glitchpants that 
>> came with the skirt..."
>>
>> I think 1,2,3 is probably fine.. that gives 9 uppers and 6 lowers. 
>> There should be a limit to keep the code simple, it's just a way 
>> bigger limit!
>>
>> There are content creators that give transfer on items.. and I like 
>> it that way. There are some (ok, one that I can name) that doesn't 
>> give multiple layers because she gives them xfer, which I can 
>> understand. It all comes down to smart permissions for the next 
>> person. But that's a key issue for the creators I think.
>>
>> However, they'd still get to choose that their pants go on the pants 
>> layer - just not choose WHICH pants layer. The user would get that, 
>> and that might curb some people's bitching at the creators! Kind of a 
>> win-win imo...
>>
>> --GC
>>
>> On 03/24/2010 09:48 PM, Brent Tubbs wrote:
>>> I like this idea a lot. �While we're talking about about increasing 
>>> flexibility though, why have a low hardcoded limit to the number of 
>>> layers? �The new tattoo and alpha layers are great, but what comes 
>>> next, and how long do we keep hardcoding more specific layers? �If 
>>> someone wants to layer on ten tattoos at once, let's let them! �At 
>>> some point it makes sense to throw away the pre-defined layers and 
>>> just call them 1 through n.
>>>
>>> On the other hand, some content creators sell items in separate 
>>> under-layer and tattoo friendly over-layer packs. �I imagine some of 
>>> them would be pretty upset if the layer restrictions on all the 
>>> products they've sold were suddenly removed.
>>>
>>> Brent
>>>
>>> On Wed, Mar 24, 2010 at 6:21 PM, Glen Canaday <gcanaday at gmail.com 
>>> <mailto:gcanaday at gmail.com>> wrote:
>>>
>>>     Nyx,
>>>
>>>     Oh, I actually do have one functionality idea / request: rather
>>>     than allowing the creator to dictate the clothing layer of a
>>>     wearable, can we allow the wearer themselves choose where it
>>>     goes? I can't tell you how many times I've had to not wear
>>>     something because the original creator did not have the foresight
>>>     to put it on a layer that makes sense for that wearable, nor
>>>     include a copy that goes onto the desired layer.
>>>
>>>     We might have a tattoo layer now, but most places are not
>>>     offering that, nor are very many people using 2.0. It would be
>>>     nice to be able to choose that a tattoo goes *under* the
>>>     underpants since most people sell tats on the unders layer and
>>>     will until 2.1 or 2.2 is widely used. If we get to choose which
>>>     of which multiple-wearable goes on top at /wear/ time and not
>>>     /creation/ time, it allows for far more flexibility in
>>>     customizing an avatar's look.
>>>
>>>     Just my $0.02, but it's hard to justify having multiple layers in
>>>     my mind without doing it this way.
>>>
>>>
>>>     --GC
>>>
>>>     On 03/23/2010 12:58 PM, Nyx Linden wrote:
>>>>       The current iteration of the appearance floater needs to go 
>>>> away. The     current implementation has been held together with 
>>>> chicken wire, bubble     gum, and duct tape. It works for now, but 
>>>> it won't hold up to the     addition of multiple wearables of a 
>>>> given type. The currently designed     plan is to extend the 
>>>> appearance sidebar to pick up the extra     functionality of 
>>>> editing a saved outfit and editing of individual     wearables. I 
>>>> think the flow between the different stages (selecting your     
>>>> outfit, editing your outfit, editing a wearable item) should be 
>>>> pretty     useful and intuitive. I'll be posting our initial design 
>>>> thoughts once     we get the appropriate channels set up (forums 
>>>> most likely).
>>>>
>>>>     I will remind you, however, that this project is specifically 
>>>> about     extending the avatar functionality. Yes there is a UI 
>>>> element here, and     I'm open to discussion of various ways of 
>>>> presenting the UI for these     specific features, given that the 
>>>> ideas are 1) easy to use and intuitive     and 2) still able to be 
>>>> done within the given timeframe.
>>>>
>>>>     It sounds, however that you're asking for the ability to "tear 
>>>> off" any     of the sidepanels into independent floaters. This is 
>>>> good feedback, and     a perspective that a number of residents 
>>>> share, but this project is not     the one that is capable of doing 
>>>> that. We have a design team and a     "Viewer interactive" team 
>>>> that is in charge of the overall design and     GUI implementation 
>>>> of the major elements of the viewer. I'm pretty sure     that 
>>>> they're already aware of this feedback, but I'll send it their way 
>>>>     again.
>>>>
>>>>     Let's keep discussion of the multi-wearables functionality 
>>>> on-target,     please :)
>>>>
>>>>     -Nyx
>>>>
>>>>     Bryon Ruxton wrote:
>>>>>     Could you please stop putting everything into that sidebar as 
>>>>> the only     way to access stuff. You�ve kept wanting to make this 
>>>>> �communicator     window � before into a single un-detachable 
>>>>> block. And despite many of     use hating it and asking for you to 
>>>>> make separate floaters, (or at     least give us that option), you 
>>>>> keep attaching everything all together     again in that sidebar. 
>>>>> This is an ill conceived approach for many of     us, who are used 
>>>>> to identify specific panels at a specific position of     our 
>>>>> choice on the screen just like . Blending it all together makes it 
>>>>>     harder in that sense.
>>>>>
>>>>>     I recall LL hiring a guy who worked on the Tivo interface 
>>>>> which is a     great one for its purpose. But the viewer is a much 
>>>>> more complex     interface. I see too much of the Tivo formula 
>>>>> into this �drawer�. The     worse part is that the sidebar buttons 
>>>>> are stuck on the left side and     actual move with the sidebar 
>>>>> panel itself. That seems wrong. Button     should stay at the same 
>>>>> place on the right in an Adobe fashion for     distinction purpose.
>>>>>
>>>>>     I wish you had studied and adopted the approach of the Adobe 
>>>>> UIs with     stackable and detachable panels and buttons on the 
>>>>> right side (which     always stay there). Their approach is a much 
>>>>> better solution in my     view that this drawer type, which is a 
>>>>> huge waste of space right now     and adding to the required 
>>>>> amount of clicks to get somewhere.
>>>>>
>>>>>     In short, please reserve an option for detachable floaters as 
>>>>> much as     possible, and please
>>>>>     consider the Adobe approach for a more flexible and 
>>>>> customizable     sidebar(s) for Version 2.x.x
>>>>>
>>>>>     Thank you
>>>>>
>>>>>     On 3/22/10 8:06 PM, "Nyx Linden" <nyx at lindenlab.com> 
>>>>> <mailto:nyx at lindenlab.com> wrote:
>>>>>
>>>>>         Good question! There is still a lot of detail left out of 
>>>>> these
>>>>>         descriptions, but we are planning on moving the UI in the
>>>>>         appearance editor into the sidebar, along with creating a new
>>>>>         outfit editor UI. You will still see the results of the 
>>>>> changes
>>>>>         you are making on your avatar in-world in real time. There 
>>>>> will
>>>>>         still be an "editing appearance" mode as you have now, it 
>>>>> will
>>>>>         just be accompanied by a panel in the sidebar instead of a
>>>>>         separate floater.
>>>>>
>>>>>         - Nyx
>>>>>
>>>>>         On Mon, Mar 22, 2010 at 6:56 PM, Argent Stonecutter
>>>>> <secret.argent at gmail.com> <mailto:secret.argent at gmail.com> wrote:
>>>>>
>>>>>
>>>>>             On 2010-03-22, at 12:45, Nyx Linden wrote:
>>>>>
>>>>>                 1) A new panel to edit what is stored in your 
>>>>> saved outfit
>>>>>                 without
>>>>>                 creating a new one.
>>>>>                 This will include both an inventory view and a 
>>>>> view of
>>>>>                 your outfit
>>>>>                 itself, so you can drag items from your inventory 
>>>>> to your
>>>>>                 outfit without
>>>>>                 having an extra floater open
>>>>>                 2) Editing of wearable items (body parts and/or 
>>>>> clothing
>>>>>                 objects) in the
>>>>>                 sidebar, selectable from the outfit editor
>>>>>                 3) Removal of the appearance floater
>>>>>
>>>>>
>>>>>             I have a concern about this, where it comes to editing 
>>>>> outfits
>>>>>             containing prim parts. You have to see them in world, you
>>>>>             can't just edit them in a sidebar window, because you 
>>>>> may need
>>>>>             to edit them with reference to objects in world.
>>>>>
>>>>>             If I'm mistaken about what "removal of the appearance 
>>>>> floater"
>>>>>             means, in the context of a UI designed to allow you to 
>>>>> edit
>>>>>             outfits without having to wear them, then I'll be 
>>>>> happy to be
>>>>>             corrected.
>>>>>
>>>>>
>>>>>
>>>>>         
>>>>> ------------------------------------------------------------------------ 
>>>>>
>>>>>         _______________________________________________
>>>>>         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
>>>
>>>
>>>     _______________________________________________
>>>     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