-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
i'm not sure if i've not suggested this before, what if the wearable
type identified which types of shading, cuts gradients, parameters etc
go along with it, that way the client would be able to know how to
interpret the data, how to cut etc and the order the stuff is baked
wouldn't matter?
On 27/3/2010 22:33, Carlo Wood wrote:
> Yup, makes sense if you can put wearables anywhere.
> Better than having a category called "shirt" and then fill it
> with shirts a jackets.
>
> Bottom line, also Jacek wants to be able to determine the order
> of anything that might give a different result with a different
> order.
>
> On Fri, Mar 26, 2010 at 07:49:29PM -0500, Jacek Antonelli wrote:
>> On Thu, Mar 25, 2010 at 11:08 AM, Nyx Linden <n...@lindenlab.com> wrote:
>>> 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.
>>>
>>> [snip]
>>>
>>> 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
>>
>> I really like this design, for the most part. But I think it would be
>> much better, and would address everyone's wishes for more flexibility
>> in clothing order, if a few things were changed:
>>
>> 1. Instead of having categories for each wearable type (shirts, pants,
>> shoes, etc.), have categories for "layer" (as when getting dressed in
>> RL):
>>
>> * Outer Layer: jacket, gloves, shoes
>> * Inner Layer: shirt, pants, and skirt
>> * Under Layer: underpants, undershirt, and socks
>> * Body Layer: skin, tattoos, and (maybe) alpha
>>
>> This is just an example. I'm not picky about the number of layers, or
>> what they're called, or which types go in which layer. But the idea is
>> that higher layers render on top of lower layers. The same is also
>> true within each category, an Nyx said: higher items render on top of
>> lower items.
>>
>> 2. When a wearable is worn, it goes to the top of the appropriate
>> layer (as above). But the user can open up the outfit editor and drag
>> the wearable to any layer they want, or reorder the items within a
>> layer. I think this would be a good solution, because wearing clothes
>> would "just work", yet users still have total control over the order
>> of layers, with a simple and natural way of modifying the order.
>>
>> - Jacek
>> _______________________________________________
>> 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
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.12 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkuu1YsACgkQ8ZFfSrFHsmUQjwCfXd44YLSqYTbgYS40DpcC0Tvq
AgkAn2XTLJRL8j4OVDGJutEKs5PEqFSO
=WTgz
-----END PGP SIGNATURE-----
_______________________________________________
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
