Re: [opensource-dev] Open Development project: extendingavatar wearables
> 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.."
I can't speak for Nyx obviously :p.
>From what I've seen from coming across code in LLAgentWearables is that you
are currently - at least code-wise - able to arbitrarily "stack" wearables
in a user-defined order.
So if you currently have a pair of pants on the pants layer and a pair of
tights where one part is on the pants layer as well then you can choose to
wear the tights "pants" *underneath* the pants "pants".
I went a *little* bit crazy once I realized it was simple to nudge the
official beta into letting you wear multiple items per wearable type and
wore three tattoos on the underpants layer and then had fun stacking three
different colours of tights on the underpants layer on top of them to see
how the colours would blend to create different shades and it worked out
just fine :).
Personally what I would like best would be:
...
Wear (= "Wearable Wear", replaces all items on
the type)
Wear Add / (wear top) (= "Wearable Add" on the top of the stack)
Name of worn item 1 (= "Wearable Replace" on item 1)
(wear between) (= "Wearable Add" in between two others)
Name of worn item 2
(wear bottom) (= "Wearable Add" on the bottom of the
stack)
If it's the underpants layer then item 2 could be a tattoo (worn underneath
anything else) and item 1 could be panties. If you want to add tights you'd
pick the empty slot at the top and they'll render on top of the other two,
if you want to add garters you'd pick the empty slot in the middle and
they'll render in between the other two. If you want to wear a different
tattoo, panties, ... then you just pick the option that corresponds to what
you want to have replaced.
There will probably be a need for a more fancy ("user-friendly") panel with
up and down click button arrows to allow rearranging the items around but
for just getting dressed I'd far prefer having the option of how to stack
right on the context menu for the inventory item so getting dressed doesn't
involve constant back-and-forth side-trips in the side bar.
Kitty
___
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
[opensource-dev] licenses and the "chain of command"
Hmm... something came up on SLU... on the bottom of the pile is the GPL, because every piece of source code for the viewer says "licensed under GPL v2". on top of that is the TPV, because linden labs think they can say so. ...regarding "connecting to Second Life" they actually can. ...regarding imposing liabilities on developers they can NOT, but they refuse to see that, but that is besides the point anyways. BUT: there is nothing in the TPV that forbids you to put another "clickwrap" license around your third party viewer, that the user has to explicitely accept, which puts you back in the GPLed "no liabilities" state. and legal practice in the last years has been that "clickwrap" licenses (accept at installation/first start) have precedence over anything "shrinkwrapped" (on websites or boxes) ... and in case LL changes the TPV to say that you cannot add additional licensing terms, that would be in clear violation of the GPL v2 unless they completely relicense the whole source which they cannot do retroactively, and it would also be proof that anybody who had been claiming that the TPV doesn't "mean" that devs take all responsibility was simply lying through his teeth. ___ 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
Re: [opensource-dev] Third party viewer policy: commencement date
It's obvious the TPV is directed at sources and distributors that do not conform to specifications as implemented/documented by the GPL code in Snowglobe. If you implement a third-party network protocol, it probably would be of benefit to you to to publish how your version of the network protocol conforms to the implementation in Snowglobe. Look at python's own regression test: http://docs.python.org/library/test.html . With such a test, you could help guarantee to people, that use your software, that you took steps to handle their valuable assets without error as much as possible. That level of regression tests isn't being asked for in compliance, nor does LL seem to desire to become one to oversee such effort, but instead they offer the TPV. More specifically then 'as the only people complaining are "non contributors"' is the appearance that those that have complained the most about the TPV and any suggestion that may have the question of the TPV at hand is those against the GPL. To say one cannot look at or use GPL code as reference documentation is like to say one cannot look at or use information from wikipedia. Instead of a GFDL/CCSA based docs, Snowglobe has the documentation/implementation under GPL. The practice to GPL code as a reference is not unique to Linden Lab. If a third-party network protocol is intended in any way to be compatible with SL grid, yet the authors never compared their work to a reference platform like Snowglobe that has been made available, then users have a right to question the reliability and authenticity of the network protocol itself, especially if they spend their money on valuable assets. Your proposed solution was to disable Naali's attempts to connect to SL grid, as noted here: http://groups.google.com/group/realxtend/browse_thread/thread/a950a62ba97c14a4 LibOMV (OpenSim) has many developers and users that have been told to never look at GPL code (like Snowglobe). Therefore, we can assume that LibOMV has never done any regression tests for compliance with the network protocol as documented by Snowglobe. Users should be aware of this fact, so they are not mistaken that LibOMV (OpenSim and any viewer built from LibOMV) developers have never guaranteed on any level of such mere compliance that steps have been taken to handle their valuable assets reliably. At around US$50 million dollars a month in user transactions, is such compatibility and regression tests worth it? It is very questionable why would a developer or user choose to use a network protocol that is has stated: "The library maintains compatibility with the Second Life protocol and can be used for creating clients and automatons in Second Life, OpenSim or other virtual worlds which use the Second Life Protocol." ( http://www.openmetaverse.org/projects/libopenmetaverse ) ... yet never thought it was worth to simply reference the published source as a measure to ensure to it's users it is compatible. How else would they ensure compatibility is maintained? It's OpenSim's sims policy to state "We cannot accept virally licensed code unless there is a specific F/OSS exemption for BSD-licensed projects." Therefore, we can assume OpenSim uses LibOMV under a guarantee to have never been referenced or derived from the code publish in Snowglobe. Maybe LibOMV (OpenSim and viewers) should state the fact that in order them to have never looked at the GPL code that their documentation misrepresented compatibility with the above except. It should state something to the fact that the process to create LibOMV reversed engineered the SL grid network protocol (in order to avoid GPL?) and that it cannot guarantee direct compatibility with SL Grid, and that users of it's protocol are not guaranteed to have their assets handled reliably due to the fact LibOMV developers simply never looked at published referenced documentation. Ryan McDougall wrote: > I think it's pretty clear LL will broach no more discussion on this > matter, as the only people complaining are "non contributors" -- as > clear a statement yet that realXtend and OpenSim are not considered > contributions to SL. > > As far as I'm concerned, this is a complete FUD own-goal, and > realXtend now has a policy that developers cannot use our own viewer > to connect to SL for any reason -- to protect us from this > ill-conceived policy. > > The only people who have nothing to fear from TPV are malicious > developers, as they were always operating outside various laws any > way. > > Cheers, > > On Wed, Mar 24, 2010 at 6:10 PM, Morgaine > wrote: > >> On Wed, Mar 24, 2010 at 2:57 AM, Joe Linden wrote: >> >>> There is no "catch 22" here.� No "overstepping", and no rocket science. >>> The terms of the GPL are clear and well understood.� The arguments around >>> clauses 11 and 12 of the GPL are completely baseless. >>> >> Here are GPLv2 clauses 11 and 12, Joe.� Which arguments around these clauses >>
Re: [opensource-dev] licenses and the "chain of command"
While this may protect a viewer developer from direct responsibility towards a user, it does not provide any protection against LL. Assuming I have to clickwrap-accept TPV by 30 April before I'm allowed to connect to the SecondLife grid, I still accept universal guilt towards LL. Example: A content creator sues LL for copyright infringement and LL comes as boomerang back to the dev who may not have done anything wrong, just someone else exploited a vulnerability LL put in the code in the first place. Who is guilty? The weakest link who said yes to TPV in the first place. User <-x-> Dev <--- LL |^ Nice try, but does not help. > Date: Thu, 25 Mar 2010 10:26:23 +0100 > From: Lance Corrimal > Subject: [opensource-dev] licenses and the "chain of command" > To: opensource-dev@lists.secondlife.com > Message-ID: <201003251026.24709.lance.corri...@eregion.de> > Content-Type: text/plain; charset="us-ascii" > > Hmm... something came up on SLU... > > > on the bottom of the pile is the GPL, because every piece of source code > for > the viewer says "licensed under GPL v2". > > on top of that is the TPV, because linden labs think they can say so. > > ...regarding "connecting to Second Life" they actually can. > ...regarding imposing liabilities on developers they can NOT, but they > refuse > to see that, but that is besides the point anyways. > > BUT: > > there is nothing in the TPV that forbids you to put another "clickwrap" > license around your third party viewer, that the user has to explicitely > accept, which puts you back in the GPLed "no liabilities" state. > > > and legal practice in the last years has been that "clickwrap" licenses > (accept at installation/first start) have precedence over anything > "shrinkwrapped" (on websites or boxes) > > ... and in case LL changes the TPV to say that you cannot add additional > licensing terms, that would be in clear violation of the GPL v2 unless > they > completely relicense the whole source which they cannot do retroactively, > and > it would also be proof that anybody who had been claiming that the TPV > doesn't > "mean" that devs take all responsibility was simply lying through his > teeth. ___ 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
Re: [opensource-dev] Open Development project: extending avatar wearables
On an equal note, it's extremely annoying that the priority of animations is determined at creation time. Why can't I, as user, determine in what order I want animations to take precedence? On Wed, Mar 24, 2010 at 10:20:19PM -0400, 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 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 y
Re: [opensource-dev] Open Development project: extending avatar wearables
On Wed, Mar 24, 2010 at 10:57:45PM -0400, Glen Canaday wrote: > 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. The problem with this might be that if you give that outfit, entirely existing of freebies say, to another, then you would like that user-defined ordering to prevail. Thus, the difference between a creator and a user defined ordering is that the protocol has to be changed as well. -- Carlo Wood ___ 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
Re: [opensource-dev] Open Development project: extending avatar wearables
+1 Carlo, the specific priority on animations has caused confusion of when to set them to 1, 2, 3, or 4. If it is not set correctly, then it could mess up the other animations. I would like to see that confusion avoided with outfits. Carlo Wood wrote: > On an equal note, it's extremely annoying that the priority > of animations is determined at creation time. > > Why can't I, as user, determine in what order I want animations > to take precedence? > > On Wed, Mar 24, 2010 at 10:20:19PM -0400, 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 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 >>
Re: [opensource-dev] Open Development project: extending avatar wearables
Ah yes, using the descriptions would avoid the need for extra protocol changes. I'd suggest to use the keywords "skin", "tatoo", "underwear", "shirt", "jacket", but also allow "shirt 2", "shirt 3", etc to put things inbetween shirt and jacket. On the downside, no-mod wearables would disallow reordering them. I'm greatly in favor to create bits for wearables and objects that stay user changable even for no-mods. Normally when I think about that, I assume that such bits are stored on the viewer only, and uploaded to the sim like the bake textures (sim-local only thus). Combine that, you arrive the logical conclusion that we can use unused pixels in the uploaded baked textures to communicate avatar related bits (wearables and attachments) with other avatars around us. What is needed is to define a list of things we want to be able to change even on no-mods, and then assign corresponding meanings to pixels in the baked textures. On Wed, Mar 24, 2010 at 08:32:07PM -0700, Dzonatas Sol wrote: > There was a suggestion (from Nyx?) to use the individual item's > description to help with the order. Maybe something like "outer" > "middle" "inner" "skin" could be keywords left in the description to > give a default order without a outfit list. When you add an item to the > list, it would check for such keyword, and place it in a default order > based on such keyword. -- Carlo Wood ___ 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
Re: [opensource-dev] Open Development project: extending avatar wearables
I said: I want to be able to change the priority of (no-mod) animations regardless, as user. I definitely also want to be able to change the order in which a wearable is layered, as opposed to that the creator does that for me. If I go to shop in real life, it's also ME who decides in what order I put clothes on, not the creator of the clothes. On Thu, Mar 25, 2010 at 05:41:02AM -0700, Dzonatas Sol wrote: > +1 Carlo, the specific priority on animations has caused confusion > of when to set them to 1, 2, 3, or 4. If it is not set correctly, > then it could mess up the other animations. > > I would like to see that confusion avoided with outfits. I don't know how you mean this, but you make it sound as if priorities are a bad thing. The problem is NOT confusion imho. The problem is that the creator of animations think that their animation is the most important of all and should be priority 4 "of course", while in reality *I* am the one that has to live with it. It should be me (the user) that decides what priority they want an animation to be. Thus, again, editable values on no-mod items. -- Carlo Wood ___ 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
Re: [opensource-dev] [solved?] Re: SLPlugin lagging my viewer like crazy, maybe it was a bad idea from the start?
Thanks! I just upgraded to the 10.4 beta, I'll give it a try. I was having problems on a similar setup with x64 Fedora but that issue may have been related to the 64bit distro. Mike On Wed, 2010-03-24 at 23:26 +, Opensource Obscure wrote: > On Wed, 24 Mar 2010 18:11:03 -0500, Michael Dickson > wrote: > > On Wed, 2010-03-24 at 22:58 +, Tayra Dagostino wrote: > >> On Mon, 8 Mar 2010 09:39:00 +0100 > >> Lance Corrimal wrote: > >> > >> > Anyways, shouldn't SLPlugin exit when it is done doing what it > >> > thought it should be doing? > >> > >> installed and configured Pulseaudio > >> now only ONE SLPlugin thread executed, with very low processor > >> usage. > > Can you provide a bit more details on what you mean by installed and > > configured? I'm running the same config (pulseaudio through openal) and > > I definitely get extra SLPlugin processes. > > if this can help, SLPugin works fine here with the default > ubuntu 10.04 alpha setup, and I think it worked fine > on ubuntu 9.10 as well > > libopenal1 version is 1.11.753-0ubuntu1 > pulseaudio is 0.9.22~0.9.21 > > bye > opensource obscure ___ 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
Re: [opensource-dev] Open Development project: extending avatar wearables
Am Donnerstag, 25. März 2010 13:38:28 schrieb Carlo Wood: > If I go to shop in real life, it's also ME who decides > in what order I put clothes on, not the creator of the > clothes. oh? try wearing your briefs on top of your pants in public... ___ 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
Re: [opensource-dev] [solved?] Re: SLPlugin lagging my viewer like crazy, maybe it was a bad idea from the start?
I begin to think about libraries bundled with viewer Maybe LL should check again the versions... I still have glibc segfault on SL2 on font loading (libxft?) -- Sent by iPhone Il giorno 25/mar/2010, alle ore 13.52, Michael Dickson ha scritto: > Thanks! I just upgraded to the 10.4 beta, I'll give it a try. I was > having problems on a similar setup with x64 Fedora but that issue may > have been related to the 64bit distro. > > Mike > > On Wed, 2010-03-24 at 23:26 +, Opensource Obscure wrote: >> On Wed, 24 Mar 2010 18:11:03 -0500, Michael Dickson > > >> wrote: >>> On Wed, 2010-03-24 at 22:58 +, Tayra Dagostino wrote: On Mon, 8 Mar 2010 09:39:00 +0100 Lance Corrimal wrote: > Anyways, shouldn't SLPlugin exit when it is done doing what it > thought it should be doing? installed and configured Pulseaudio now only ONE SLPlugin thread executed, with very low processor usage. >>> Can you provide a bit more details on what you mean by installed and >>> configured? I'm running the same config (pulseaudio through >>> openal) and >>> I definitely get extra SLPlugin processes. >> >> if this can help, SLPugin works fine here with the default >> ubuntu 10.04 alpha setup, and I think it worked fine >> on ubuntu 9.10 as well >> >> libopenal1 version is 1.11.753-0ubuntu1 >> pulseaudio is 0.9.22~0.9.21 >> >> bye >> opensource obscure > > ___ 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
Re: [opensource-dev] Open Development project: extending avatar wearables
> I'm greatly in favor to create bits for wearables and objects > that stay user changable even for no-mods. General agreement. Needs some thought to make sure that it's not too easy to change them accidentally and lose the creator-intended settings forever (maybe save the original settings and have a "revert" button?), but seems like a very good idea that would enable useful new things. (Will also require thought to make sure that it doesn't open holes that would let people modify nomod objects in undesirable ways!) Note that there's already a very small amount of this, in that (obviously) if you rez something inworld, you can go into edit and change its position and rotation even if it's nomod. David Chess/Dale Innis ___ 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
Re: [opensource-dev] Open Development project: extendingavatar wearables
> Ah yes, using the descriptions would avoid the need for extra > protocol changes. > > I'd suggest to use the keywords "skin", "tatoo", "underwear", > "shirt", "jacket", but also allow "shirt 2", "shirt 3", etc > to put things inbetween shirt and jacket. Doesn't most of the confusion stem from the fact that clothing layers don't really map to clothing *items*? A full top would be undershirt/shirt plus underpants layer High-waist pants would be undershirt/shirt plus pants layer A catsuit would be undershirt/shirt plus underpants/pants plus socks If there's simply a new wearable type that includes all layers then most of the "being able to specify the order" goes away (aside from legacy items). 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. --- Ideally there would just be a new "container" asset type where you simply group wearables or attachments together which makes things even easier still and would be usable with all existing content as well... Along those lines: I'm curious about the actual purpose of "ensembles"? I can make a few guesses from the code and it would seem to tie in somewhere along those lines but in a very limited way? (The "allowed" XML option is throwing me off :p) --- Kitty ___ 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
Re: [opensource-dev] Open Development project: extendingavatar wearables
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
[opensource-dev] multimedia puzzle on linux (opensuse 11.2)
...yes i know this is not the support hotline... But chances are high that there's someone around on this list who could point me at the one right library dependency in five minutes, whereas a support ticket would take several weeks, and then be closed with spurious reasons but no actual solution. On tuesday streaming music and video still worked just fine with snowglobe 1.4, snowglobe 2.0 and SL 2.0... Since then there were several updated packages for opensuse, including but not limited to gstreamer and kde 4.4.1... and since then, my self-compiled viewers (snowglobe 1.4 and 2.0) don't play streaming media anymore, a stock LL-provided SL 2.0 crashes right after login, and the ll-provided snowglobe 1.4 from http://secondlife.com/developers/opensource/downloads/2010/trunk/3229/Snowglobe- i686-1.4.0.3229.tar.bz2 doesn't play streaming media anymore either... the original 1.23 client, and henris cool viewer 1.23.0.13, still work fine with streaming media... anyone got a pointer for me? or a hint along what to look out for while stracing the running SLPlugin exe? bye, LC ___ 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
Re: [opensource-dev] multimedia puzzle on linux (opensuse 11.2)
solved... "unset http_proxy https_proxy no_proxy" at the start of the launch script, because gstreamer suddenly lost the ability to stream thru a proxy. ___ 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
Re: [opensource-dev] Open Development project: extendingavatar wearables
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.
>
>
> _
Re: [opensource-dev] Open Development project: extendingavatar wearables
On 2010-03-25, at 11:08, Nyx Linden wrote: > 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. OK, here's the one little problem (and it is a little problem) I see with this. We currently have designers who are doing things like putting shirts on underwear layers or jacket layers, or jackets on shirt layer + pants layer, because they're trying to give you workarounds for the current limited situation. For some designers who give you options on all layers (usually on copy-no-transfer items) you're good to go, but for designers who were selling no-copy-transfer items and only gave you one item (cos that's what you bought... fair enough)... let's see what happens... Say I have a vest on a shirt layer (because it came with a jacket), and a shirt on a jacket layer (because it's "untucked"). In the brave new world I should be able to wear my shirt under my vest, now I can wear multiple wearables. But because the jacket layer is over the shirt layer, I don't get to use this combo. Now, you could go "you're still able to do everything you can right now" and you'd be right, but while you're loading extra awesome into the client how about turning it up to 11? ___ 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
Re: [opensource-dev] Open Developmentproject: extendingavatar wearables
If its extra awesome we are after...any chance of eliminating the need for half the prim skirts and capes by adding a flexi-layer mode to the layer...So the clothes can flutter and maybe stretch in the wind? Jonathan Bishop ___ 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
Re: [opensource-dev] Open Development project: extendingavatar wearables
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 lis
Re: [opensource-dev] Open Development project: extendingavatar wearables
Argent Stonecutter wrote: > > On 2010-03-25, at 11:08, Nyx Linden wrote: >> 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. > > OK, here's the one little problem (and it is a little problem) I see > with this. We currently have designers who are doing things like > putting shirts on underwear layers or jacket layers, or jackets on > shirt layer + pants layer, because they're trying to give you > workarounds for the current limited situation. For some designers who > give you options on all layers (usually on copy-no-transfer items) > you're good to go, but for designers who were selling no-copy-transfer > items and only gave you one item (cos that's what you bought... fair > enough)... let's see what happens... > > Say I have a vest on a shirt layer (because it came with a jacket), > and a shirt on a jacket layer (because it's "untucked"). In the brave > new world I should be able to wear my shirt under my vest, now I can > wear multiple wearables. But because the jacket layer is over the > shirt layer, I don't get to use this combo. > > Now, you could go "you're still able to do everything you can right > now" and you'd be right, but while you're loading extra awesome into > the client how about turning it up to 11? That would actually be turning it up to about 15, as far as a code architecture standpoint is concerned :) I'm certainly open to suggestions on how to do this, but the current architecture is very much directed towards a specific rendering order of drawing all tattoos under all undershirts under all shirts under all jackets (where 'jackets' are WT_JACKET wearable types, regardless of what the creator intended them to appear to be). 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. Feel free to contact me for more details if you'd like, but I'd prefer to save the full debate for when we get the forums up, as not everyone subscribes / tracks this list. Hopefully this will be up soon. Alternative proposals for handling this situation: adding a lower body texture to WT_SHIRT? developing a way to convert one wearable type to another (assuming the wearable is mod-able, which I realize is asking a lot)? -Nyx ___ 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
Re: [opensource-dev] Open Developmentproject: extendingavatar wearables
OMG yes! Especially if THAT flexi doesn't "pass through" the avatar! How great wouldn't it be to have flexies (which are client side) that respect other things around them, like avatars, ground, and even other prims, and won't pass through them but rather fold around them! (You could make this a custom Graphics settings that is only on in "Ultra" for all I care, it would just be great if it existed!) On Fri, Mar 26, 2010 at 04:47:47AM +1100, Jonathan Bishop wrote: > If its extra awesome we are after...any chance of eliminating the need for > half the prim skirts and capes by adding a flexi-layer mode to the > layer...So the clothes can flutter and maybe stretch in the wind? -- Carlo Wood ___ 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
Re: [opensource-dev] Open Developmentproject: extendingavatar wearables
There is the "avatar cloth" graphics setting in preferences (if you enable advanced preferences). Though the effect appears to be subtle and not used for terribly much. There is certainly the possibility to extend this functionality to be more explicit and improve it to be better, but I believe its primarily making "loose" clothing flutter in the wind a bit. Causing clothing to react to objects outside the avatar itself (attachments, ground, objects in the world) is a *much* more complex problem however. This is a good feature request, and directly related to avatars, but my todo list is quickly growing beyond what I think I can reasonably accomplish. If any open source devs want to take this on as a project, I'd be happy to provide what support I can, but this will go on my "nice to have someday" list for now. -Nyx Carlo Wood wrote: > OMG yes! Especially if THAT flexi doesn't "pass through" the avatar! > > How great wouldn't it be to have flexies (which are client side) > that respect other things around them, like avatars, ground, > and even other prims, and won't pass through them but rather > fold around them! (You could make this a custom Graphics settings > that is only on in "Ultra" for all I care, it would just be > great if it existed!) > > On Fri, Mar 26, 2010 at 04:47:47AM +1100, Jonathan Bishop wrote: > >> If its extra awesome we are after...any chance of eliminating the need for >> half the prim skirts and capes by adding a flexi-layer mode to the >> layer...So the clothes can flutter and maybe stretch in the wind? >> > > ___ 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
Re: [opensource-dev] Open Development project: extendingavatar wearables
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 out
Re: [opensource-dev] Open Development project: extendingavatar wearables
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. -- Carlo Wood ___ 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
Re: [opensource-dev] Open Development project: extendingavatar wearables
Interesting topic. Thought I'd share some thoughts. 1. I like the idea of wearables being in folders allowing the user to drag and drop the article in different folders to taste. This allows the user to choose where the wearable goes. 2. Adding to that, we can create limits on the object-level that the creator can set. Similar to permissions, the content creator can choose where the object can actually go. (i.e. underwear can be pants and underwear), shirts can be jackets or vice versa. 3. On the avatar, we can keep the render order the same, but tie those areas to meta folders. I think the impact would be minimal, but a neat system to use. 4. Flexi clothing articles would be awesome. I can only imagine the first female avatar doing the classic Marilyn Monroe pose over an air duct. :) Please, keep up the discussion. This is interesting. Jonathan Irvin On Thu, Mar 25, 2010 at 13:12, 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. > > -- > Carlo Wood > ___ > 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
Re: [opensource-dev] Open Development project: extendingavatar wearables
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+s
Re: [opensource-dev] Open Development project: extending avatar wearables
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 unless the briefs are indecent, around here i don't think anyone would directly complain (they might talk about it being unusual with other people, but i don't think anyone would be forbidden to enter a store, restaurant etc just because of an slightly unusual fashion style On 25/3/2010 10:13, Lance Corrimal wrote: > Am Donnerstag, 25. März 2010 13:38:28 schrieb Carlo Wood: > >> If I go to shop in real life, it's also ME who decides >> in what order I put clothes on, not the creator of the >> clothes. > > > oh? try wearing your briefs on top of your pants in public... > ___ > 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/ iEYEARECAAYFAkurtcQACgkQ8ZFfSrFHsmUKTQCfZ8EO79mpZcI2PVj62V2PZfgl gmoAnR9fzgSEUa9k0gUPdbnWbfshKJd0 =E5mT -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
Re: [opensource-dev] Open Development project: extendingavatar wearables
On Thu, Mar 25, 2010 at 7:55 PM, Nyx Linden wrote: [snip] > 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. [snip] I think getting ability to wear arbitrary number of same type clothing will solve 99% of the problems, and since it is a features that can be done in a reasonable time frame, I agree that we should focus on getting it out as the priority. You can always make superhero underwear on the pants layer after all :P Latif ___ 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
Re: [opensource-dev] Open Development project: extendingavatarwearables
> 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.
Could inventory links be used as a modifier for wearables rather than the
current pass-through?
I.e. an item on the shirt layer
User right-clicks and picks "Wear as undershirt" which generates an
inventory link in COF just as it does now, but with the lower two bytes of
its item flags set to WT_UNDERSHIRT.
The "onWearableArrived" would examine the inventory link to the wearable in
COF, note the discrepancy on what it's being passed and convert the
LLWearable to match the type specified in the link and everything else just
works more or less the way it does now?
It's not an ideal solution ("downgrading" jackets might get troublesome
since they have two textures) but would allow arbitrary reordering of
existing layers and since it's all handled by links "no modify" or "no copy"
on the original wouldn't even come into it.
Kitty
___
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
Re: [opensource-dev] Open Development project: extendingavatarwearables
Interesting proposal, and one probably worthy of further investigation.
My concern with this plan is that the conversion from one wearable type
to another is very much non-trivial. The wearable parameters (sleeve
length, etc) have no relation to each other between wearables. For
example, "sleeve length" for undershirts is visual parameter #603, which
"drives" parameters 1042 and 1043. For shirts, it is parameter #800
which "drives" 600, 1013, 1029, and 900.
You'd fundamentally be taking an existing wearable, and creating an
entirely new wearable of a different type based on that wearable.
Whether or not you save it back to your inventory as a different item,
you are essentially both copying it and modifying the wearable. What
happens if it is mod-able but no-copy? If you make changes to the
converted (undershirt) version and hit save, do you have to
back-translate those parameters back to the original (shirt)? I'd think
we'd need to create a new asset/inventory item of the converted type to
implement this idea, at which point permissions on the original are very
much a factor.
Could you do the math to do the conversion? probably. Would the result
be of acceptable quality? possibly. Would it be lossy in some cases?
definitely. Do I want to implement a conversion function that will
convert a wearable type to any other wearable type, including figuring
out (by examining all parameters in avatar_lad.xml) what parameters line
up with what other parameters for each possible conversion operation and
then translate those conversions into code? no, I'd *really* rather not.
But perhaps I'm overcomplicating the implementation of this idea somehow?
-Nyx
Kitty wrote:
>> 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.
>>
>
> Could inventory links be used as a modifier for wearables rather than the
> current pass-through?
>
> I.e. an item on the shirt layer
>
> User right-clicks and picks "Wear as undershirt" which generates an
> inventory link in COF just as it does now, but with the lower two bytes of
> its item flags set to WT_UNDERSHIRT.
>
> The "onWearableArrived" would examine the inventory link to the wearable in
> COF, note the discrepancy on what it's being passed and convert the
> LLWearable to match the type specified in the link and everything else just
> works more or less the way it does now?
>
> It's not an ideal solution ("downgrading" jackets might get troublesome
> since they have two textures) but would allow arbitrary reordering of
> existing layers and since it's all handled by links "no modify" or "no copy"
> on the original wouldn't even come into it.
>
> Kitty
>
>
___
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
Re: [opensource-dev] Open Development project: extendingavatar wearables
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)
Re: [opensource-dev] Open Developmentproject: extendingavatar wearables
Avatar cloth doesn't just make clothing wave in the breeze. Just turning it on and flying. It makes your butt wave in the breeze, too. --GC On 03/25/2010 01:55 PM, Nyx Linden wrote: > There is the "avatar cloth" graphics setting in preferences (if you > enable advanced preferences). Though the effect appears to be subtle and > not used for terribly much. There is certainly the possibility to extend > this functionality to be more explicit and improve it to be better, but > I believe its primarily making "loose" clothing flutter in the wind a > bit. Causing clothing to react to objects outside the avatar itself > (attachments, ground, objects in the world) is a *much* more complex > problem however. > > This is a good feature request, and directly related to avatars, but > my todo list is quickly growing beyond what I think I can reasonably > accomplish. If any open source devs want to take this on as a project, > I'd be happy to provide what support I can, but this will go on my "nice > to have someday" list for now. > > -Nyx > > Carlo Wood wrote: > >> OMG yes! Especially if THAT flexi doesn't "pass through" the avatar! >> >> How great wouldn't it be to have flexies (which are client side) >> that respect other things around them, like avatars, ground, >> and even other prims, and won't pass through them but rather >> fold around them! (You could make this a custom Graphics settings >> that is only on in "Ultra" for all I care, it would just be >> great if it existed!) >> >> On Fri, Mar 26, 2010 at 04:47:47AM +1100, Jonathan Bishop wrote: >> >> >>> If its extra awesome we are after...any chance of eliminating the need for >>> half the prim skirts and capes by adding a flexi-layer mode to the >>> layer...So the clothes can flutter and maybe stretch in the wind? >>> >>> >> >> > ___ > 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
Re: [opensource-dev] Open Development project: extendingavatar wearables
On 2010-03-25, at 12:48, 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. OK, I can live with the awesome knob set back to 6 or 8, no problem. ___ 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
Re: [opensource-dev] Open Development project: extendingavatar wearables
On 2010-03-25, at 13:55, 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. How about this? For clothes that are modify, add an option "change wearable type", between compatible types. Obvious objection: if you change the wearable type from jacket to shirt you lose the lower body texture. 1. Don't make those compatible types. 2. Keep the lower body texture in the asset, but don't show it. 3. Warn the user "you may damage this wearable, do you really want to do this?" ___ 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
Re: [opensource-dev] Open Development project: extendingavatarwearables
On 2010-03-25, at 15:07, Nyx Linden wrote: > Interesting proposal, and one probably worthy of further > investigation. > My concern with this plan is that the conversion from one wearable > type > to another is very much non-trivial. The wearable parameters (sleeve > length, etc) have no relation to each other between wearables. For > example, "sleeve length" for undershirts is visual parameter #603, > which > "drives" parameters 1042 and 1043. For shirts, it is parameter #800 > which "drives" 600, 1013, 1029, and 900. Using my idea of making a non-volatile change to wearable type... Change parameters back to default when you change wearable type? No weirder than changing body type male to female. ___ 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
Re: [opensource-dev] Open Development project: extendingavatarwearables
I'd argue that's an insufficient solution. Parameters such as sleeve length and color have fairly dramatic impacts on how a wearable appears. Converting only the textures would result in a fairly disappointing result, I think. -Nyx Argent Stonecutter wrote: > > On 2010-03-25, at 15:07, Nyx Linden wrote: > >> Interesting proposal, and one probably worthy of further investigation. >> My concern with this plan is that the conversion from one wearable type >> to another is very much non-trivial. The wearable parameters (sleeve >> length, etc) have no relation to each other between wearables. For >> example, "sleeve length" for undershirts is visual parameter #603, which >> "drives" parameters 1042 and 1043. For shirts, it is parameter #800 >> which "drives" 600, 1013, 1029, and 900. > > Using my idea of making a non-volatile change to wearable type... > > Change parameters back to default when you change wearable type? No > weirder than changing body type male to female. > ___ 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
Re: [opensource-dev] Open Development project: extendingavatarwearables
Not to mention that some span over more than one bake, like jacket, tattoo and alpha. I don't think changing wearable type is feasible. On Thu, Mar 25, 2010 at 9:44 PM, Nyx Linden wrote: > I'd argue that's an insufficient solution. Parameters such as sleeve > length and color have fairly dramatic impacts on how a wearable appears. > Converting only the textures would result in a fairly disappointing > result, I think. > > -Nyx > > Argent Stonecutter wrote: >> >> On 2010-03-25, at 15:07, Nyx Linden wrote: >> >>> Interesting proposal, and one probably worthy of further investigation. >>> My concern with this plan is that the conversion from one wearable type >>> to another is very much non-trivial. The wearable parameters (sleeve >>> length, etc) have no relation to each other between wearables. For >>> example, "sleeve length" for undershirts is visual parameter #603, which >>> "drives" parameters 1042 and 1043. For shirts, it is parameter #800 >>> which "drives" 600, 1013, 1029, and 900. >> >> Using my idea of making a non-volatile change to wearable type... >> >> Change parameters back to default when you change wearable type? No >> weirder than changing body type male to female. >> > > ___ > 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
Re: [opensource-dev] Open Development project: extendingavatarwearables
On 2010-03-25, at 15:44, Nyx Linden wrote: > I'd argue that's an insufficient solution. Parameters such as sleeve > length and color have fairly dramatic impacts on how a wearable > appears. Converting only the textures would result in a fairly > disappointing result, I think. As a user, I would be happy to re-do the sleeve length and color if necessary. It's not hard. This is no scarier than the "breast" and "gravity" sliders. ___ 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
Re: [opensource-dev] Open Development project: extendingavatarwearables
On 2010-03-25, at 16:48, Latif Khalifa wrote: > Not to mention that some span over more than one bake, like jacket, > tattoo and alpha. Yes, I explicitly noted that already in my previous message: >> For clothes that are modify, add an option "change wearable type", >> between compatible types. This ->= >> >> Obvious objection: if you change the wearable type from jacket to >> shirt you lose the lower body texture. >> >> 1. Don't make those compatible types. >> >> 2. Keep the lower body texture in the asset, but don't show it. >> >> 3. Warn the user "you may damage this wearable, do you really want to >> do this?" > I don't think changing wearable type is feasible. > > On Thu, Mar 25, 2010 at 9:44 PM, Nyx Linden wrote: >> I'd argue that's an insufficient solution. Parameters such as sleeve >> length and color have fairly dramatic impacts on how a wearable >> appears. >> Converting only the textures would result in a fairly disappointing >> result, I think. >> >> -Nyx >> >> Argent Stonecutter wrote: >>> >>> On 2010-03-25, at 15:07, Nyx Linden wrote: >>> Interesting proposal, and one probably worthy of further investigation. My concern with this plan is that the conversion from one wearable type to another is very much non-trivial. The wearable parameters (sleeve length, etc) have no relation to each other between wearables. For example, "sleeve length" for undershirts is visual parameter #603, which "drives" parameters 1042 and 1043. For shirts, it is parameter #800 which "drives" 600, 1013, 1029, and 900. >>> >>> Using my idea of making a non-volatile change to wearable type... >>> >>> Change parameters back to default when you change wearable type? No >>> weirder than changing body type male to female. >>> >> >> ___ >> 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 >> "Welcome back, Anonymous, we're glad to see you again!" ___ 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
Re: [opensource-dev] Open Development project: extendingavatarwearables
Nyx Linden wrote: > Interesting proposal, and one probably worthy of further investigation. > My concern with this plan is that the conversion from one wearable type > to another is very much non-trivial. The wearable parameters (sleeve > length, etc) have no relation to each other between wearables. Having looked at the code, I understand what you mean. Although they may appear the same, they are defined with different underlying code. The easiest way to change the overlay order is to change the rendering order. That would require additional parameters in the appearance vector, but there's still a lot of room for extra parameters there (although I'd really like to see that utilized for additional morphs). Mike ___ 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
Re: [opensource-dev] Open Development project: extendingavatarwearables
Argent Stonecutter wrote: > On 2010-03-25, at 15:44, Nyx Linden wrote: >> I'd argue that's an insufficient solution. Parameters such as sleeve >> length and color have fairly dramatic impacts on how a wearable >> appears. Converting only the textures would result in a fairly >> disappointing result, I think. > > As a user, I would be happy to re-do the sleeve length and color if > necessary. It's not hard. This is no scarier than the "breast" and > "gravity" sliders. Its more than two sliders. Quite frankly I don't believe this is an acceptable solution to ship in our main client for this particular issue - a user would expect "wear as undershirt" to "just work". I'll note further that such a system would only be effective for wearables you have copy + mod permissions for. No worries for your own creation, but few sold clothing pieces are so liberal to my understanding. However, if you'd like to code up a conversion routine for snowglobe or a third party viewer, please do so! Let me know if you need any information about our wearables system to do so. -Nyx ___ 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
Re: [opensource-dev] Open Development project: extendingavatarwearables
It would also require completely de-constructing the current layers system, and rebuilding it based on the added parameters (I'd actually argue making the parameters part of the links used to create an outfit, not the wearables themselves but that's a side note). -Nyx Mike Monkowski wrote: > Nyx Linden wrote: >> Interesting proposal, and one probably worthy of further >> investigation. My concern with this plan is that the conversion from >> one wearable type to another is very much non-trivial. The wearable >> parameters (sleeve length, etc) have no relation to each other >> between wearables. > > Having looked at the code, I understand what you mean. Although they > may appear the same, they are defined with different underlying code. > > The easiest way to change the overlay order is to change the rendering > order. That would require additional parameters in the appearance > vector, but there's still a lot of room for extra parameters there > (although I'd really like to see that utilized for additional morphs). > > Mike ___ 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
Re: [opensource-dev] Wiki posting: Open Source Repository Strategy
Hi, Thanks Robin for the summary of the Hippo discussion. It's consistent with Q's schema and the point of the discussion was to avoid Merov becoming the bottleneck for merges in Snowglobe trunk... Another thing we said this week was that the export (from viewer-public to viewer-external, process B in Q's schema) will be frequent (ideally for each commit in viewer-public, practically for each successful build of viewer-public which should happen several times a day), completely automatic (viewer-external is a "read-only" repo, i.e. no one but the automatic export process commit to that branch) and will keep history (i.e. the various hg commit messages are collated and used as commit message during the export). Cheers, - Merov On Mon, Mar 22, 2010 at 7:43 AM, Robin Cornelius wrote: > On Mon, Mar 22, 2010 at 1:59 PM, Kent Quirk (Q Linden) > wrote: > > > The merge to Snowglobe isn't automatic -- it probably requires > intelligent > > merging. So if that includes leaving things out, so be it. The right way > to > > do it will probably be to undo the changesets so that it doesn't become a > > fork that requires constant maintenance. > > Merov specificaly talked about this point at last Thursdays snowglobe > meeting. Although we were running short of time and there may be need > for some fine details. The consensus of those present was to manually > merge from vendor branch about once a week. A manual merge is probably > vital here as snowglobe will be adding its own features and fixes and > any of these could be damaged by incomming code based of a slightly > different code base. Hopefully a great deal of snowglobe patches will > make there way back to the main viewer code anyway and this type of > conflict will not happen too often. The other thing Merov said is if a > vendor imported patch breaks/conflicts with snowglobe then just revert > that patch and flag up the situation. The final idea was the help of a > "merge monkey" someone who could assist with the merging from vendor > to snowglobe so that its not always merov, this could be multiple > people taking it in turns etc, this was all up in the air and just > ideas banded around at the meeting. > > Robin > ___ > 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
Re: [opensource-dev] [META] Communication tools (was: Request for clarification on mailing list guidelines)
Hi, We discussed this subject again at the Hippo meeting today. Forums didn't have much takers though I'll try to spend time there and see for myself how the dynamic works. The extra IW meeting was better received. Tuesday seemed to work but we couldn't decide on a time, 2pm PST works for those present at the meeting but the point, precisely, is to get a time that works for those who can't make it at 2pm PST So, if you think you'll come to this new meeting, please propose a time range here and I'll collate the results. I'll give more weight to those who can't make it to the Thursday meeting. Hope we'll find a time that works. Cheers, - Merov ___ 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
