[opensource-dev] Open Development project: extendingavatar wearables

Glen Canaday gcanaday at gmail.com
Thu Mar 25 13:11:02 PDT 2010


All,

If layers are to be truly arbitrary, then we would need to go all the 
way with it so that items can be sold as only 1 item and not on multiple 
layers w/ xfer. Argent's got the idea partly in one of his posts.

Of course, multiple wearables of the same type at once kind of wrecks 
the argument and it looks like everyone's got the same idea but just 
phrased it differently.

;P

--GC

On 03/25/2010 02:55 PM, Nyx Linden wrote:
> Specifying an arbitrary order in inventory that is unrelated to wearable
> type is absolutely trivial.
> The difficult part comes when you go to render your baked textures.
>
> Currently each baked texture is specified by a "layerset" which is a
> vector of texture layers in rendering order. So the upper body layerset
> is a list of layers somewhat along the lines of:
> "skin color, upper skin texture, upper tattoo, undershirt texture,
> gloves texture, shirt texture, jacket texture, upper alpha mask texture"
> which are rendered in order on top of one another to result in the baked
> texture you see on screen. Note: there are actually a *lot* more layers
> than I've listed, if you look at avatar_lad.xml for examples. Many
> texture layers have shadow layers, etc.
>
>      This gets more complicated when you allow someone to wear multiple
> shirts. I did a rather large chunk of the required refactoring last
> year, but the feature was too complicated to ship with viewer 2.0, given
> all of our other needs. The "straightforward" way to re-architect this
> layer system is to allow the "shirt" texture layer to be a meta-layer
> that contains references to all the shirt textures, in order of their
> drawing. Layer order right now is completely data-driven by the contents
> of avatar_lad.xml. The resulting code changes you can see in the
> released viewer-2 source code - look for the classes
> LLTexLayerInterface, LLTexLayerTemplate, and LLTexLayer. Each
> user-modifyable layer is replaced with a LLTexLayerTemplate which
> contains a list of LLTexLayer objects for that layer. Currently its
> limited to one LLTexLayer per LLTexLayerTemplate, but this is what the
> multiwearables project will extend.
>
>      In order to allow you to arbitrarily re-order layers, this structure
> completely breaks. Layers would need to be grouped by wearable that they
> effect, rather than what actual layer order is sepcified in
> avatar_lad.xml. The user interface also gets significantly more
> complicated, or at the very least, less intuitive.
>
>      As I stated previously, I'm not completely stuck on the current
> structure, its just one that I know I can finish and ship in the given
> timeframe. I can think of ways to re-re-architect the structure yet
> again to enable this requested functionality, but I'm not convinced to
> do so because:
>
> 1) The ultimate user interface becomes less intuitive (I'll go into more
> depth on this later)
> 2) We simply do not currently have the time to re-architect and test the
> new structure yet again.
>
> Again, if any open source developer wants to look at the code
> architecture and draw up a plan for how this can be done in a reasonable
> amount of time, I'm all ears. My current ideas on how to implement this
> would push us well out of the timeframe that we were hoping to ship this
> set of features.
>
>   -Nyx
>
>
> Carlo Wood wrote:
>    
>> On Thu, Mar 25, 2010 at 01:48:39PM -0400, Nyx Linden wrote:
>>
>>      
>>> My initial answer to that request is "we don't have time to implement
>>> that right now", but I'd be happy to have a more in-depth technical
>>> discussion as to how that could be implemented in the future. If the
>>> community is able to come up with a proposed implementation where layer
>>> order is truly arbitrary, regardless of wearable type, without damaging
>>> the intuitiveness of the user interface or expanding required
>>> development time too far, I'd love to go over such a proposal.
>>>
>>>        
>> This seems rather trivial... just allow one to explicitely
>> drop a wearable in any folder (ie, a shirt in a jacket folder),
>> after which you can move it up and down "as usual" (what you
>> implement right now).
>>
>> How have a new problem however: Why not allow to tuck jackets in?
>> That means: a jacket having an abitrary order related to shirts
>> and other jackets is fine, but even if it goes over all other
>> jackets, you might still want to put it below the pants.
>>
>> Since a jacket is currently the only wearable that extends over
>> two textures (apart from the new "tatoo" containing three textures,
>> and the skin, both of which kinda make sense to always be on
>> the bottom), it make sense to have, or NEED, an ordering relative
>> to pants too! After all, both pants and jackets have a lower-texture!
>>
>> For example (top layer on top):
>>
>> * jacket Y (not tucked in)
>> * jacket X (tucked in)
>>
>> Just means for the LOWER texture, this ordering:
>>
>> * jacket Y (not tucked in)
>> * pants
>> * jacket X (tucked in)
>>
>> There should be an ordering between jackets and pants
>> as well thus, which is entirely missing in your current proposal.
>>
>> Perhaps a solution is to add a pseudo item in the "jackets"
>> category that appears as a horizontal line, and where things
>> below the line are tucked in, and above it are not:
>>
>> shirts:
>>      * shirt
>>
>> jackets:
>>       * jacket Y
>>       ----tucked in-----
>>       * jacket X
>>
>> pants:
>>       * pants
>>
>> Otherwise it is not unlikely that the vendors will (have to)
>> resort to a hack where selling jackets also as pants+shirts,
>> so users can choose to tuck them in or not.
>>
>>
>>      
> _______________________________________________
> 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