Re: [opensource-dev] Review Request: STORM-702 Make it possible to wear partial outfits

[Nyx Linden]

---
This is an automatically generated e-mail. To reply, visit:
http://codereview.secondlife.com/r/14/#review59
---


I have no technical objections to the code provided.
And in fact, the code provided *should* change the functionality back to what 
the users are reporting is their expectation of what the behavior should be.

The part that makes me nervous is that this enables an outfit operation for a 
class of folders that we have not allowed with the new outfit system 
previously. Based on other pieces on the code that would get called by this 
operation, I believe that the result will be that of the resident request to 
"revert" behavior (namely remove all clothing, remove body parts that are 
replaced by the new folder, leave old body parts that are necessary to display 
the avatar). 

That being said, we need a more comprehensive review of the role of incomplete 
outfits and how it fits with our technical architecture we've built up in our 
current outfits system. The code here should implement the correct behavior and 
I have no technical issues with it. But I want to make sure that we are aware 
of the risk of edge cases as we have not considered possibly popping up as a 
result of this patch.

- Nyx


On 2010-12-13 07:08:28, Vadim ProductEngine wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/14/
> ---
> 
> (Updated 2010-12-13 07:08:28)
> 
> 
> Review request for Viewer.
> 
> 
> Summary
> ---
> 
> Enabled the "Replace Current Outfit" option for incomplete outfits (i.e. 
> those that don't contain full set of body parts).
> 
> 
> This addresses bug STORM-702.
> http://jira.secondlife.com/browse/STORM-702
> 
> 
> Diffs
> -
> 
>   indra/newview/llappearancemgr.cpp 3d2e71443c58 
>   indra/newview/llinventoryfunctions.cpp 3d2e71443c58 
> 
> Diff: http://codereview.secondlife.com/r/14/diff
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Vadim
> 
>

___
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] Review Request: STORM-702 Make it possible to wear partial outfits

[Nyx Linden]

---
This is an automatically generated e-mail. To reply, visit:
http://codereview.secondlife.com/r/14/#review145
---

Ship it!


Now has design approval. ship it.

- Nyx


On Dec. 13, 2010, 7:08 a.m., Vadim ProductEngine wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/14/
> ---
> 
> (Updated Dec. 13, 2010, 7:08 a.m.)
> 
> 
> Review request for Viewer.
> 
> 
> Summary
> ---
> 
> Enabled the "Replace Current Outfit" option for incomplete outfits (i.e. 
> those that don't contain full set of body parts).
> 
> 
> This addresses bug STORM-702.
> http://jira.secondlife.com/browse/STORM-702
> 
> 
> Diffs
> -
> 
>   indra/newview/llappearancemgr.cpp 3d2e71443c58 
>   indra/newview/llinventoryfunctions.cpp 3d2e71443c58 
> 
> Diff: http://codereview.secondlife.com/r/14/diff
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Vadim
> 
>

___
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] from debug to prefences

[Nyx Linden]

Also keep in mind most debug preferences were written by coders who want 
to provide the functionality to debug features and provide QA with the 
tools to test features. The debug options themselves often are not 
formalized / well tested / well supported.

This would be providing more formal support for untested features. 
Certainly there's an argument that some specific options have been 
around long enough and are stable enough that they should be upgraded to 
supported options. We've moved a few of these into the advanced and 
develop menus.

There are multiple classes of debug options here: some that are stable 
and would do better with bigger visibility, some that are incredibly 
useful but require more debugging and QA time to be upgraded, and some 
that probably aren't useful enough to justify the effort.

  -Nyx

On 01/24/2011 01:05 PM, Jonathan Welch wrote:
> There are approximately 1,100 entries in settings.xml, which is the
> list you see in the Debug Settings floater (perhaps it should be
> renamed to just Settings).  I don't see any practical way of having
> all those available in any kind of sane preferences menu system.
>
> It would be good to generate a list of entries that are in there and
> never used by the code.  Those could be eliminated without much
> discussion.
>
> You can find a pretty recent list here
> http://wiki.secondlife.com/wiki/Debug_Settings
> ___
> 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] Review Request: TestCapabilityProvider build fix.

[Nyx Linden]

---
This is an automatically generated e-mail. To reply, visit:
http://codereview.secondlife.com/r/123/#review256
---

Ship it!


Looks good to me

- Nyx


On Jan. 25, 2011, 1:26 p.m., Seth ProductEngine wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/123/
> ---
> 
> (Updated Jan. 25, 2011, 1:26 p.m.)
> 
> 
> Review request for Viewer and Nyx Linden.
> 
> 
> Summary
> ---
> 
> Fixed TestCapabilityProvider build issue.
> 
> 
> Diffs
> -
> 
>   indra/newview/tests/llcapabilitylistener_test.cpp 26c09ad4293e 
> 
> Diff: http://codereview.secondlife.com/r/123/diff
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Seth
> 
>

___
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] Mesh branch merged to viewer-development

[Nyx Linden]

Already filed as https://jira.secondlife.com/browse/SH-1616. Will 
move to snowstorm once we have a fix. Should be a straightforward fix, 
but I've been swamped today :(


 -Nyx

On 05/20/2011 04:16 PM, Kiptic ‌ wrote:

> > 2011-05-17T21:41:18Z newview/llviewertexturelist.cpp(492) : error
> > 2011-05-17T21:41:18Z ERROR: LLViewerTextureList::addImageToList: 
ASSERT

> > (mInitialized)

> I get another crash on each startup:

> $1 = (struct LLConvexDecomposition *) 0x0

> Apparently, LLConvexDecomposition::getInstance() returns 0;

I have the same problem, and yes, that call does return 0, which is 
then happily dereferenced a few lines further on.


All this in llmeshrepository.cpp, lines 3655-3665 (rev. 18475):


LLConvexDecomposition* decomp = LLConvexDecomposition::getInstance();
decomp->initThread();
mInited = true;

static const LLCDStageData* stages = NULL;
static S32 num_stages = 0;

if (!stages)
{
num_stages = decomp->getStages(&stages);
}


Not sure why getInstance returns 0, it seems it's never initialized 
properly?


/Kip


___
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] Review Request: STORM-1041 Removed clothes come back to haunt me

[Nyx Linden]

---
This is an automatically generated e-mail. To reply, visit:
http://codereview.secondlife.com/r/441/#review981
---

Ship it!


I was skeptical, but after reviewing some of the code from those systems (that 
I hadn't touched in months), the proposed code appears to be correct. Also 
tested the build and it appears functional. Ship it!

- Nyx


On Aug. 15, 2011, 12:26 p.m., Vadim ProductEngine wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/441/
> ---
> 
> (Updated Aug. 15, 2011, 12:26 p.m.)
> 
> 
> Review request for Viewer and Nyx Linden.
> 
> 
> Summary
> ---
> 
> The "Remove all clothes" item of the avatar menu didn't actually remove all 
> clothes.
> 
> I haven't investigated what the problem was, I've just rewritten the 
> (ancient?) removal code
> in the way we take off items in other places, i.e. by removing them from the 
> Current Outfit forder.
> 
> What I'm not sure about is whether we need to call updateAppearanceFromCOF() 
> afterwards. Nyx?
> 
> 
> This addresses bug STORM-1041.
> http://jira.secondlife.com/browse/STORM-1041
> 
> 
> Diffs
> -
> 
>   indra/newview/llagentwearables.h 87fe21031c46 
>   indra/newview/llagentwearables.cpp 87fe21031c46 
>   indra/newview/llinventorybridge.cpp 87fe21031c46 
> 
> Diff: http://codereview.secondlife.com/r/441/diff
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Vadim
> 
>

___
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] ok this may sound dumb but what is the llphysicsextention package

[Nyx Linden]

We use Havok libraries as our implementation of llconvexdecomposition.
The interface to llconvexdecomposition has not changed, only the packaging
of it, as we needed to add more havok functionality to the viewer for
pathfinding.

You should be able to tie in HACD to llphysicsextensions and leave the rest
stubbed out with minimal effort. If anyone has difficulty with porting to
the new structure do let us know, and we'll help how we can.

Separating out the two parts would just result in havok libraries that are
shared between convex decomposition and the pathfinding functionality being
linked in twice for the main viewer.

 -Nyx


On Wed, Aug 8, 2012 at 5:56 AM, Moriz Gupte  wrote:

> Fourthed !
> But am 100% Oz will receive a message from the top regarding this! Bah ..
> moving on. When fear drives things instead of true openness, opensource
> efforts get hurt.
>
>
> On Wed, Aug 8, 2012 at 8:44 AM, Robert Martin wrote:
>
>> Could somebody hit the Jira with this so it can be hopefully properly
>> handled by The Lindens???
>>
>> (in lue of the normal Voting as required by "my" Rules of Order [wolf
>> grin])
>>
>>
>> --
>> Robert L Martin
>> ___
>> 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
>>
>
>
>
> --
> 'Consider how the lilies grow. They do not labor or spin.'
> *Rameshsharma Ramloll* PhD, *Research Associate Professor*, Idaho State
> University, Pocatello, ID 83209 Tel: 208-282-5333
> Blog , 
> LinkedIn
> , Play2Train 
>
>
> ___
> 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

[opensource-dev] Server Side Avatar Appearance pile-on test

[Nyx Linden]

Greetings all,
 In preparation for rolling out server side avatar appearance, we'll be
running a short test tomorrow afternoon. If you are available, or know
someone who is, please come to the server usergroup (
http://wiki.secondlife.com/wiki/Server_Beta_User_Group) with the latest
sunshine viewer (
http://wiki.secondlife.com/wiki/Project_Sunshine-Server_Side_Appearance
version number 270409). We will run the test after the server meeting, for
those able to stick around. You will need several outfits that your avatar
can switch between and will do so both on the old system and the new
system. Also please clear your cache before attending.

   Please use our latest viewer as it has additional statistics gathering
code that will allow us to calculate load patterns and measure the
improvements expected for later releases.

Let me know if there are any questions!

 -Nyx Linden
___
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] Server Side Avatar Appearance pile-on test

[Nyx Linden]

We saw similar errors for some users at the pile-on yesterday, it
appears to be account-specific (some people can reproduce others cannot).
There are a few commits that have not been pushed to sunshine-external yet,
but nothing that should affect the behavior so fundamentally. We're going
to be looking into this issue today, I'll send another email if we think we
have a fix.

Thanks for the report!

 -Nyx

On Fri, Feb 22, 2013 at 4:29 AM, Henri Beauchamp  wrote:

> On Wed, 20 Feb 2013 15:54:42 -0500, Nyx Linden wrote:
>
> > Please use our latest viewer as it has additional statistics gathering
> > code that will allow us to calculate load patterns and measure the
> > improvements expected for later releases.
> >
> > Let me know if there are any questions!
>
> Greetings,
>
> Today, I'm having troubles on Aditi SunshineTest resgions: the
> server-side baking seems broken. Whether I use LL's latest Sunshine
> viewer(*) v3.4.5.270409 or the Cool VL Viewer v1.26.7, which both
> used to work just fine before, I get "bad requests (400)" errors,
> like so:
>
> WARNING: RequestAgentUpdateAppearanceResponder::errorWithContent:
>  appearance update request failed, status: 400 reason: Bad
>  Request
> DEBUG: RequestAgentUpdateAppearanceResponder::errorWithContent:
>content: 
> 
> 
> INFO: RequestAgentUpdateAppearanceResponder::onFailure: retrying
> (SecondLife v3.4.5.270409 for Windows)
>
> or:
> WARNING: RequestAgentUpdateAppearanceResponder::error: Appearance
>  update request failed, status: 400 reason: Bad Request
> INFO: RequestAgentUpdateAppearanceResponder::error: Retrying...
> (Cool VL Viewer v1.26.7.11, either Linux or Windows builds)
>
> Was something changed that is not yet propagated to the
> sunshine-external sources repository (the last commit in it dates
> back from 8 days ago) ?... If the answer is "yes", then please commit
> the necessary changes today...
>
> Regards,
>
> Henri.
>
> (*) The Linux build is still impossible to run for me because it
> requires GLIBCXX_3.4.15: "bin/do-not-directly-run-secondlife-bin:
> /usr/lib/libstdc++.so.6: version `GLIBCXX_3.4.15' not found
> (required by bin/do-not-directly-run-secondlife-bin)"
> when my system got libstdc++.so.5.0.7 (g++ v3.3.6) and
> libstdc++.so.6.0.13 (g++ v4.4.3). Why don't you build the Sunshine
> viewer on the same build system as for the other viewer branches
> (which all run fine on my system) ?...
>
___
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] Serious regression in SSB-enabled regions

[Nyx Linden]

https://bitbucket.org/lindenlab/sunshine-external/commits/108ae1ed56ea38426df239ef3247f57fb63d0806

Added a new parameter to shapes to replace the viewer-side height offset.
Since it is stored in a wearable, the new back end can read and use the
value. Will send an email to third party devs later today to let them know
to pick up the patch.

Marking SUN-38 as resolved.

 -Nyx

On Sun, Feb 24, 2013 at 11:46 PM, Ricky  wrote:

> I know this thread has gotten completely OT, but I feel I should respond
> to the feeling of dissatisfaction.
>
> I contribute to help me.  I know that not everything I contribute will be
> accepted: see https://jira.secondlife.com/browse/VWR-25739 for one I
> created that I suspect that LL will never swallow, but that is already in
> Firestorm's LGPL codebase.  What I've come to understand, and I accept as I
> can see the logic behind it, is that open source is not the same as
> open decision making, nor is it the same as allowing others to make the
> decisions.  It simply means the code is available under a permissive
> license for others - including us - to review, comment on, modify, and
> compile for ourselves.  Let me re-iterate: open source is NOT community
> maintenance.  LL has never implied or pretended that they've set up
> a community maintenance program - and I think they'd have major problems if
> they tried.
>
> My L$2, and I will not continue in this topic on this thread.  If you wish
> to respond to me, please take it off-list.
>
> Ricky
> Cron Stardust
>
>
> On Sun, Feb 24, 2013 at 7:27 PM, Carlo Wood  wrote:
>
>> On Sun, 24 Feb 2013 20:09:19 +0100
>> Henri Beauchamp  wrote:
>>
>> > > I'm unable to comment on SUN issues (or even make them)
>> >
>> > Gotta love the new closed JIRA !... Way to go, LL...
>>
>> I was about to type "fuck you Linden Lab" in my previous post,
>> but assumed they might be assholes enough to then kick me
>> of this list... The phrase "way to go" is inventive. It would
>> never have occurred to me to use that in this context.
>>
>> This whole "open source" HAHAHA project is a pathetic, lame,
>> grrr - I want to SPIT on it. LL should be sued for fucking
>> CALLING this "open" in ANY way. I hate you.
>>
>> A REAL Open Source coder,
>> Carlo Wood 
>>
>> PS I'd add a comment HERE regarding SUN-38, but I learned years
>>ago already that LL doesn't listen to anyone. They are just
>>going to give you the finger Henri (and everyone else in SL)
>>but not going to fix this. I'm not even going to TRY add
>>a (technical) comment. Seriously, why is ANYONE still HELPING
>>them? Why doesn't everyone just leave this list, stop
>>going to their meetings, and stop giving them patches? Are
>>you all stupid or what?
>> ___
>> Policies and (un)subscribe information available here:
>> http://wiki.secondlife.com/wiki/OpenSource-Dev
>> Please read the policies before posting to keep unmoderated posting
>> privileges
>>
>
>
> ___
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/OpenSource-Dev
> Please read the policies before posting to keep unmoderated posting
> privileges
>
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Serious regression in SSB-enabled regions

[Nyx Linden]

SSB does all appearance generation as a centralized service - meaning
your avatar's visual parameters, height, and baked textures are served
without needing the viewer to have downloaded and decoded the wearables.
That's why I'm starting to refer to it as server side appearance, not
server side baking. Height is determined when you calculate your agent's
appearance message which is now generated on the back end.

Adding new wearable parameters is not without precedent - we've done it
before when we added alpha masks, tattoos, avatar physics, etc. The only
change should be a new parameter (id=11001) in the shape's parameter block.
This does not represent a major revision to the wearable or avatar format.

 -Nyx

On Fri, Mar 1, 2013 at 4:43 PM, Darien Caldwell
wrote:

> Well, This is an interesting development. I only understood SSB to be
> handling the baking of textures. But it's centralizing the avatar's shape
> too? Or why does a change in height need to be routed through the back-end?
>
> Adding a new slider to the Avatar appearance is kind of unprecedented.
> Will LL be revving the Shape XML export format?
>
> https://wiki.secondlife.com/wiki/Mesh/Avatar_Shape_XML_Format
>
>    - Dari
>
> On Fri, Mar 1, 2013 at 1:20 PM, Nyx Linden  wrote:
>
>>
>> https://bitbucket.org/lindenlab/sunshine-external/commits/108ae1ed56ea38426df239ef3247f57fb63d0806
>>
>> Added a new parameter to shapes to replace the viewer-side height offset.
>> Since it is stored in a wearable, the new back end can read and use the
>> value. Will send an email to third party devs later today to let them know
>> to pick up the patch.
>>
>> Marking SUN-38 as resolved.
>>
>>  -Nyx
>>
>>
>> On Sun, Feb 24, 2013 at 11:46 PM, Ricky  wrote:
>>
>>> I know this thread has gotten completely OT, but I feel I should respond
>>> to the feeling of dissatisfaction.
>>>
>>> I contribute to help me.  I know that not everything I contribute will
>>> be accepted: see https://jira.secondlife.com/browse/VWR-25739 for one I
>>> created that I suspect that LL will never swallow, but that is already in
>>> Firestorm's LGPL codebase.  What I've come to understand, and I accept as I
>>> can see the logic behind it, is that open source is not the same as
>>> open decision making, nor is it the same as allowing others to make the
>>> decisions.  It simply means the code is available under a permissive
>>> license for others - including us - to review, comment on, modify, and
>>> compile for ourselves.  Let me re-iterate: open source is NOT community
>>> maintenance.  LL has never implied or pretended that they've set up
>>> a community maintenance program - and I think they'd have major problems if
>>> they tried.
>>>
>>> My L$2, and I will not continue in this topic on this thread.  If you
>>> wish to respond to me, please take it off-list.
>>>
>>> Ricky
>>> Cron Stardust
>>>
>>>
>>> On Sun, Feb 24, 2013 at 7:27 PM, Carlo Wood  wrote:
>>>
>>>> On Sun, 24 Feb 2013 20:09:19 +0100
>>>> Henri Beauchamp  wrote:
>>>>
>>>> > > I'm unable to comment on SUN issues (or even make them)
>>>> >
>>>> > Gotta love the new closed JIRA !... Way to go, LL...
>>>>
>>>> I was about to type "fuck you Linden Lab" in my previous post,
>>>> but assumed they might be assholes enough to then kick me
>>>> of this list... The phrase "way to go" is inventive. It would
>>>> never have occurred to me to use that in this context.
>>>>
>>>> This whole "open source" HAHAHA project is a pathetic, lame,
>>>> grrr - I want to SPIT on it. LL should be sued for fucking
>>>> CALLING this "open" in ANY way. I hate you.
>>>>
>>>> A REAL Open Source coder,
>>>> Carlo Wood 
>>>>
>>>> PS I'd add a comment HERE regarding SUN-38, but I learned years
>>>>ago already that LL doesn't listen to anyone. They are just
>>>>going to give you the finger Henri (and everyone else in SL)
>>>>but not going to fix this. I'm not even going to TRY add
>>>>a (technical) comment. Seriously, why is ANYONE still HELPING
>>>>them? Why doesn't everyone just leave this list, stop
>>>>going to their meetings, and stop giving them patches? Ar

[opensource-dev] The Current Outfit Folder and you!

[Nyx Linden]

 clothing items of a
 given type than the Linden release viewer allows


If your viewer does not behave as described above, please let us know ASAP
as it will help us diagnose some of the issues that are being reported. If
you plan on making changes to your viewer to comply with this protocol, let
us know and keep us up to date on your progress. If you feel that there are
parts of this protocol that your viewer does not need to comply with,
please contact us to discuss it. Keep in mind that many users choose to
install and run multiple types of viewers from multiple computers, both on
SSA-enabled and SSA-disabled regions, and your viewer should operate
smoothly under such conditions. As always the final arbiter of the current
protocol is the source code of the latest Linden release viewer. This list
identifies some of the assumptions that our systems make in terms of how
compliant viewers should act. It is not meant to be exhaustive.

With the release of Sunshine (SSA) to the grid, we’re eliminating a lot of
the failure points in appearance resolution we were seeing. However, the
next largest failure point we’ve identified is the inventory system.
Specifically, the current inventory protocol relies on both HTTP and UDP
messages, some of which have failure callbacks and some which the viewer
assumes will complete successfully (not always accurate). If you’ve run
into situations where you have received a COF mismatch error, you have hit
this class of issue (it means that the viewer and server disagree as to
what the version number of the COF currently is).

For our next round of changes after SSA goes grid-wide, we’re working on
updates to the Agent Inventory Services (AIS), that should help alleviate
the most prominent causes of these errors, as well as hopefully reduce the
number of network calls needed to successfully update the COF. If you’ve
been tracking sunshine-internal, you may have seen references to these new
protocols. They’re not ready for release yet, and will require much
testing, but we’d like to start discussing in more detail what it will
involve.

Specifically, we will convert the most error prone operations on the COF
from using the old UDP-based system over to AIS. This includes operations
like creating and deleting links, etc. These new calls should always
resolve, and should throw sensible error codes if any operations fail.
Additionally, we’re adding some new functions that should allow common
appearance operations to resolve with less work on the viewer’s part. There
will be AIS calls for operations such as wearing an outfit from the library
(which will copy items to the user’s inventory), and wearing a complete
outfit from inventory (which will replace the current contents of the COF
with links to the items you pass to it).

We’ve been working on this new system in parallel with the first release of
Server Side Appearance. While we’ve made great progress, it is not yet
complete. Once it is we will let you know and provide more detailed
documentation about the methods involved, and try to stand up regoins on
Aditi to start testing project viewers against. It will require some time
before the code is ready to be in anyone’s release viewer, so keep it out
of your trunk branch for now.

If you have any questions about the release process, the way the current
system works, or the upcoming work around inventory, please let me know.
Thanks, and have a great week all,

-Nyx Linden

-- 
*Neal Orman* | *Senior Software Engineer*
Skype NyxLinden | Second Life Nyx Linden<https://my.secondlife.com/nyx.linden>

Linden Lab | Makers of Shared Creative Spaces <http://lindenlab.com/>
SECOND LIFE <http://secondlife.com/> | PATTERNS <http://buildpatterns.com/>|
CREATORVERSE <http://creatorverse.com/> | DIO <http://dio.com/> |
VERSU<http://versu.com/>
___
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] question on SL/SG 2.0 avatar backend

[Nyx Linden]

I believe you're referring to avatar_lad.xml, which is stored in the 
character subdirectory of your client's install directory.

If you have any specific questions on it, please let me know!

 -Nyx

Robert Martin wrote:
> ive been trying to get somebody to code an editor for SL clothing and
> one of the things ive found is a file deep somewhere in the tree that
> has the parameters of the avatar in a nice neat list.
> The question is since i seem to have dumped the original could
> somebody remind me where this file is in the source tree
> (i would like to see the changes that 2.0 has done to this file).
>
>   

___
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] Open Development project: extending avatar wearables

[Nyx Linden]

Greetings Opensource-dev!

This tiny robot is going to be working over the next few weeks to 
begin working on the next iteration of avatar features, and needs your help!
We're hoping to continue our overhaul of how you manage your appearance. 
Since we're shooting for moving towards quarterly releases, there's a 
lot of work to be done!

I'll be setting up a sub-form for collaboration and discussion of 
designs, as well as working on cleaning up some initial design concepts 
for how the user interface will be presented - I'll follow up on this 
list with links to the documents when they're online.

Some of the features we want to implement:
1) A new panel to edit what is stored in your saved outfit without 
creating a new one.
This will include both an inventory view and a view of your outfit 
itself, so you can drag items from your inventory to your outfit without 
having an extra floater open
2) Editing of wearable items (body parts and/or clothing objects) in the 
sidebar, selectable from the outfit editor
3) Removal of the appearance floater
4) Order-specific outfits with the ability to re-order wearables as desired
5) Ability to wear multiple wearables of the same type (multiple shirts, 
multiple jackets and yes, multiple alpha masks!).

I look forward to working with everyone and getting a lot of feedback 
throughout the development process. I'll be releasing a lot more 
detailed information as I can get it formatted and out the door. There 
are just a handful of things to keep in mind.

First, this is still a featureset developed by Linden Lab, which has a 
few implications. If there is a dispute, we will hold final say on what 
goes into the client we ship. There will not always be perfect consensus 
on every decision made, but I will try to be more transparent about what 
decisions we make and why, where appropriate. Also, since the code for 
this feature will be in the main second-life viewer, we do still require 
a signed CLA before we can integrate your patches into our codebase.

Second, I ask that we all do what we can to keep the discussion civil 
and collaborative. The tiny robot cloning machine still isn't working 
right yet, so there is only one of me and I'll make the time to 
collaborate with everyone who wants to help with creating a more robust 
featureset that will ship in the time we have to develop it. Posts for 
ideas that we don't have the time or resource to implement, rants, or 
non-constructive feedback will receive significantly less attention.

Once the forums are up, I'll post there with details of what 
infrastructure is currently in place, what our initial designs are, and 
how best to give feedback. Once we get our new branch structure in 
place, I'll be doing all of my checkins in the open and will be pulling 
in community contributions on a regular basis. I look forward to working 
with the community on this project and providing a positive examples to 
encourage other internal projects to work more directly with the community!

 -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: extending avatar wearables

[Nyx Linden]

Hi Mike,
I'm already on sl-ux and will keep an eye on it when I have the 
time. I'll defer most discussion and decision making to a central 
location (probably the forums & wiki), but would be happy to come to a 
group meeting if my schedule permits (that's a little late for my 
timezone, but not unreasonably so) to discuss the project. If I'm unable 
to attend, I'll send a mail to the sl-ux list explaining the project and 
where people can go for more info. Let me know if you have any specific 
concerns or requests.

 -Nyx

Mike Monkowski wrote:
> Nyx, would you be willing to come to the User Experience Interest 
> Group meeting, Thursdays from 3-4PM at Hippotropolis ( 
> http://slurl.com/secondlife/Hippotropolis/43/104/25 ), or share your 
> thoughts on the sl-ux mailing list?  Jacek Antonelli (copied here) is 
> the moderator of the UXIG meeting.
>
> (cross posting to sl-ux)
>
> Mike
>
> Nyx Linden wrote:
>> Greetings Opensource-dev!
>>
>> This tiny robot is going to be working over the next few weeks to 
>> begin working on the next iteration of avatar features, and needs 
>> your help!
>> We're hoping to continue our overhaul of how you manage your 
>> appearance. Since we're shooting for moving towards quarterly 
>> releases, there's a lot of work to be done!

___
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

[Nyx Linden]

Good question! There is still a lot of detail left out of these
descriptions, but we are planning on moving the UI in the appearance editor
into the sidebar, along with creating a new outfit editor UI. You will still
see the results of the changes you are making on your avatar in-world in
real time. There will still be an "editing appearance" mode as you have now,
it will just be accompanied by a panel in the sidebar instead of a separate
floater.

 - Nyx

On Mon, Mar 22, 2010 at 6:56 PM, Argent Stonecutter  wrote:

>
> On 2010-03-22, at 12:45, Nyx Linden wrote:
>
>> 1) A new panel to edit what is stored in your saved outfit without
>> creating a new one.
>>   This will include both an inventory view and a view of your outfit
>> itself, so you can drag items from your inventory to your outfit without
>> having an extra floater open
>> 2) Editing of wearable items (body parts and/or clothing objects) in the
>> sidebar, selectable from the outfit editor
>> 3) Removal of the appearance floater
>>
>
> I have a concern about this, where it comes to editing outfits containing
> prim parts. You have to see them in world, you can't just edit them in a
> sidebar window, because you may need to edit them with reference to objects
> in world.
>
> If I'm mistaken about what "removal of the appearance floater" means, in
> the context of a UI designed to allow you to edit outfits without having to
> wear them, then I'll be happy to be corrected.
>
>
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

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

[Nyx Linden]

  The current iteration of the appearance floater needs to go away. The 
current implementation has been held together with chicken wire, bubble 
gum, and duct tape. It works for now, but it won't hold up to the 
addition of multiple wearables of a given type. The currently designed 
plan is to extend the appearance sidebar to pick up the extra 
functionality of editing a saved outfit and editing of individual 
wearables. I think the flow between the different stages (selecting your 
outfit, editing your outfit, editing a wearable item) should be pretty 
useful and intuitive. I'll be posting our initial design thoughts once 
we get the appropriate channels set up (forums most likely).

I will remind you, however, that this project is specifically about 
extending the avatar functionality. Yes there is a UI element here, and 
I'm open to discussion of various ways of presenting the UI for these 
specific features, given that the ideas are 1) easy to use and intuitive 
and 2) still able to be done within the given timeframe.

It sounds, however that you're asking for the ability to "tear off" any 
of the sidepanels into independent floaters. This is good feedback, and 
a perspective that a number of residents share, but this project is not 
the one that is capable of doing that. We have a design team and a 
"Viewer interactive" team that is in charge of the overall design and 
GUI implementation of the major elements of the viewer. I'm pretty sure 
that they're already aware of this feedback, but I'll send it their way 
again.

Let's keep discussion of the multi-wearables functionality on-target, 
please :)

-Nyx

Bryon Ruxton wrote:
> Could you please stop putting everything into that sidebar as the only 
> way to access stuff. You’ve kept wanting to make this “communicator 
> window “ before into a single un-detachable block. And despite many of 
> use hating it and asking for you to make separate floaters, (or at 
> least give us that option), you keep attaching everything all together 
> again in that sidebar. This is an ill conceived approach for many of 
> us, who are used to identify specific panels at a specific position of 
> our choice on the screen just like . Blending it all together makes it 
> harder in that sense.
>
> I recall LL hiring a guy who worked on the Tivo interface which is a 
> great one for its purpose. But the viewer is a much more complex 
> interface. I see too much of the Tivo formula into this “drawer”. The 
> worse part is that the sidebar buttons are stuck on the left side and 
> actual move with the sidebar panel itself. That seems wrong. Button 
> should stay at the same place on the right in an Adobe fashion for 
> distinction purpose.
>
> I wish you had studied and adopted the approach of the Adobe UIs with 
> stackable and detachable panels and buttons on the right side (which 
> always stay there). Their approach is a much better solution in my 
> view that this drawer type, which is a huge waste of space right now 
> and adding to the required amount of clicks to get somewhere.
>
> In short, please reserve an option for detachable floaters as much as 
> possible, and please
> consider the Adobe approach for a more flexible and customizable 
> sidebar(s) for Version 2.x.x
>
> Thank you
>
> On 3/22/10 8:06 PM, "Nyx Linden"  wrote:
>
> Good question! There is still a lot of detail left out of these
> descriptions, but we are planning on moving the UI in the
> appearance editor into the sidebar, along with creating a new
> outfit editor UI. You will still see the results of the changes
> you are making on your avatar in-world in real time. There will
> still be an "editing appearance" mode as you have now, it will
> just be accompanied by a panel in the sidebar instead of a
> separate floater.
>
> - Nyx
>
> On Mon, Mar 22, 2010 at 6:56 PM, Argent Stonecutter
>  wrote:
>
>
> On 2010-03-22, at 12:45, Nyx Linden wrote:
>
> 1) A new panel to edit what is stored in your saved outfit
> without
> creating a new one.
> This will include both an inventory view and a view of
> your outfit
> itself, so you can drag items from your inventory to your
> outfit without
> having an extra floater open
> 2) Editing of wearable items (body parts and/or clothing
> objects) in the
> sidebar, selectable from the outfit editor
> 3) Removal of the appearance floater
>
>
> I have a concern about this, where it comes to editing outfits
> containing prim parts. You have to see them in world, you
> can

Re: [opensource-dev] Open Development project: extendingavatar wearables

[Nyx Linden]

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

[Nyx Linden]

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

[Nyx Linden]

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

[Nyx Linden]

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:
>>

Re: [opensource-dev] Open Development project: extendingavatar wearables

[Nyx Linden]

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 tuc

Re: [opensource-dev] Open Development project: extendingavatarwearables

[Nyx Linden]

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: extendingavatarwearables

[Nyx Linden]

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

[Nyx Linden]

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

[Nyx Linden]

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] Open Development project: extendingavatarwearables

[Nyx Linden]

Carlo,
I've been given the resources (my time, QA, release, and external
development) to do this project in one project cycle, not two. It is yet to
be seen, but it would not be surprising if my time and attention is needed
elsewhere next project cycle, as our list of tasks to do far outweighs our
resources with which to implement them. As such, we need to weigh the
cost/benefit of each feature carefully.

   For this project, we need to ship the ability to wear multiple wearables
of the same type, a new outfit editor, and a new wearable editor (to replace
the appearance editor). That is the minimum work that must be done during
this project cycle, and what we have resources allocated to accomplish. I'm
certainly willing to consider and discuss other potential features or
designs!
Keep in mind, though, that I am just one developer, working on limited
resources (time, other devs, QA, release, etc). I'm already planning on
working on several features above and beyond the minimum, but this work
needs to be considered carefully.

This is still a Linden-developed featureset, so we have some pretty specific
requirements as far as scheduling is concerned. I'm planning on gathering
community feedback throughout the process, but without more developers on
the project I need to be careful what I commit to. External developers are
welcome to join on the project and accelerate development to allow a broader
featureset to be implemented, but for the time being I am only one tiny
robot swimming in a sea of feature requests!

 -Nyx


On Fri, Mar 26, 2010 at 5:18 PM, Carlo Wood  wrote:

> Jonathan,
>
> I have no disrespect at all for Nyx. And yes, it's highly appreciated
> that he asks us for input instead of just implementing it.
>
> Still, if nothing in his original design is going to be changed
> then the effect is almost the same; except if this list is
> convinced that his original design is indeed the best.
>
> Apparently that stands or falls with having time (money) to do
> anything beyond what he already planned to do, and therefore
> explaining that is the only way to make the list understand this.
>
> Hence my question. Not because I think he is wrong, but because
> I want to know (and understand): Why not implement the extra
> requests from this list and then release the whole feature
> three months later? Imho it IS better to delay the feature and
> release a really well-thought-out new feature that will really
> work for a long time, than to be 3 months sooner and have people
> feel frustrated about little shortcomings for the next 3 years.
>
> Specifically to Jonathan: I'm sure this is a misunderstanding
> in the way my post came across. I appologise for that. It's
> sometimes hard to come accross correctly in written emails
> (I'm not even good at it in RL).
>
> On Fri, Mar 26, 2010 at 02:52:39PM -0500, Jonathan Irvin wrote:
> >
> > On Fri, Mar 26, 2010 at 06:56, Carlo Wood  wrote:
> >
> > It bothers me a bit that we (you) would choose to go
> > for an implementation that is not the best or the
> > ideal one, ONLY because you want to push out a new
> > feature "in time".
> >
> >
> > Carlo, it pains me to see you have this attitude towards the
> > Lindens...especially those who are in here trying to communicate with
> us.
> > ***Linden Labs has limited resources*** They can't just magically
> allocate time
> > and money to a feature that would be awesome because you think so.  They
> have
> > time and money constraints.
> >
> >
> > Personally, I'd first design how I'd want it to look
> > from the user point of view (what most of the discussion
> > from the community is about) without taking into account
> > coding arguments. And once we have that, I'd just
> > implement it, no matter the costs or time needed.
> > That is what coders do: they implement what is requested.
> >
> >
> > This is a blind perspective to have.  Coding constraints come into play
> because
> > coding takes time and when you are on a payroll with a budget, time =
> money.
> > You have to sacrifice the really awesome feature that will take a while
> for the
> > ones that are easy, but have an ok benefit.
> >
> > The Lindens aren't tools, my friend.  Perhaps showing more respect for
> them
> > will give you respect in return by getting us new features.  And, keep in
> mind,
> > this is an OpenSource forum.  If you have an idea, make it happen and
> pitch it
> > to us.  Code it yourself and post it to the open forum.  The lindens have
> > enough on their plate as it is which is why they went the opensource
> route to
> > begin with...having the assistance of the community make a better
> product.
> >
> >
> > Thus, since for almost everything we said so far your
> > argument is: we can't do that within the given timeframe;
> > can you defend, or at least make acceptable and understandable
> > that "a" new feature has to be added in 3 months, even if
> > that new feauture is a b

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

[Nyx Linden]

Forums for discussing multi-wearables and related issues can be found 
here: 
https://blogs.secondlife.com/community/forums/open-source/open-development/multi-wearables

Please re-direct all multi-wearables related conversations there - I'd 
like to keep all discussion centralized so everyone knows where to look 
for the latest info!

 -Nyx

Nyx Linden wrote:
> Greetings Opensource-dev!
>
>This tiny robot is going to be working over the next few weeks to 
> begin working on the next iteration of avatar features, and needs your 
> help!
> We're hoping to continue our overhaul of how you manage your 
> appearance. Since we're shooting for moving towards quarterly 
> releases, there's a lot of work to be done!
>
> I'll be setting up a sub-form for collaboration and discussion of 
> designs, as well as working on cleaning up some initial design 
> concepts for how the user interface will be presented - I'll follow up 
> on this list with links to the documents when they're online.
>
> Some of the features we want to implement:
> 1) A new panel to edit what is stored in your saved outfit without 
> creating a new one.
>This will include both an inventory view and a view of your outfit 
> itself, so you can drag items from your inventory to your outfit 
> without having an extra floater open
> 2) Editing of wearable items (body parts and/or clothing objects) in 
> the sidebar, selectable from the outfit editor
> 3) Removal of the appearance floater
> 4) Order-specific outfits with the ability to re-order wearables as 
> desired
> 5) Ability to wear multiple wearables of the same type (multiple 
> shirts, multiple jackets and yes, multiple alpha masks!).
>
> I look forward to working with everyone and getting a lot of feedback 
> throughout the development process. I'll be releasing a lot more 
> detailed information as I can get it formatted and out the door. There 
> are just a handful of things to keep in mind.
>
> First, this is still a featureset developed by Linden Lab, which has a 
> few implications. If there is a dispute, we will hold final say on 
> what goes into the client we ship. There will not always be perfect 
> consensus on every decision made, but I will try to be more 
> transparent about what decisions we make and why, where appropriate. 
> Also, since the code for this feature will be in the main second-life 
> viewer, we do still require a signed CLA before we can integrate your 
> patches into our codebase.
>
> Second, I ask that we all do what we can to keep the discussion civil 
> and collaborative. The tiny robot cloning machine still isn't working 
> right yet, so there is only one of me and I'll make the time to 
> collaborate with everyone who wants to help with creating a more 
> robust featureset that will ship in the time we have to develop it. 
> Posts for ideas that we don't have the time or resource to implement, 
> rants, or non-constructive feedback will receive significantly less 
> attention.
>
> Once the forums are up, I'll post there with details of what 
> infrastructure is currently in place, what our initial designs are, 
> and how best to give feedback. Once we get our new branch structure in 
> place, I'll be doing all of my checkins in the open and will be 
> pulling in community contributions on a regular basis. I look forward 
> to working with the community on this project and providing a positive 
> examples to encourage other internal projects to work more directly 
> with the community!
>
> -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: extending avatar wearables

[Nyx Linden]

Yes, I will be developing in viewer-public.

Nyx

Carlo Wood wrote:
> You mean he'll be developing in viewer-public then?
>
> On Mon, Mar 29, 2010 at 09:44:09PM -0700, Philippe (Merov) Bossut wrote:
>   
>> Nyx stated he wanted to develop this feature "in the open" which means that
>> he'll be developing in viewer-internal which is exported on each successful
>> build (so we avoid those breakage) to viewer-external (see http://
>> wiki.secondlife.com/wiki/Linden_Lab_Repository_Strategy for naming
>> conventions).
>> 
>
>   

___
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

[Nyx Linden]

go to
https://blogs.secondlife.com/community/forums/open-source/open-development/multi-wearables
log in using the login link on the top of the page
click on "all content" to see everything that has been posted so far
click "start a discussion" in the "actions" panel on the side to start a new
thread.

 -Nyx

On Wed, Mar 31, 2010 at 6:43 AM, Carlo Wood  wrote:

> I can't seem to figure out where to start a new thread about
> outfits and inheritance.
>
> How/where should we continue this discussion?
>
> --
> 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] texture problem on avatars

[Nyx Linden]

Chang Liu wrote:
> Hi, all, when we connect a modified version of Second Life Client 
> Viewer to OpenSim, we notice that from time to time, textures on 
> avatars may turn into mosaic and hollow like what's shown in the 
> attached screenshots.  Has anyone seen this before?  Any clues as to 
> what may have gone wrong? Many thanks.
>
> ~Chang
>
What version of the viewer are you using? Viewer-1.23 redefined the 
fourth channel of baked textures to be "alpha mask" instead of "bump 
map". If you load old baked textures that generated a fourth channel 
intending it to be a bump map, and use it as a baked texture for a 1.23+ 
viewer, the viewer will incorrectly interpret the fourth channel as an 
alpha mask, resulting in images like you included in your email.

Were the avatars on the sim a mix of 2.0 and 1.22 (or previous) versions 
by any chance?

 -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

___
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] viewer-external svn r3448: multi-wearables seriously broken?

[Nyx Linden]

Multi-wearables should work fine on Agni, (with the exception that 
outfit order doesn't persist across logins yet).
Multi-attachments will not work on Agni until the Server 1.40 rollout to 
the grid. Its a debug option right now in the viewer (and will remain 
default-off for 2.1).

If you'd like to test multi-attachments, please test it against aditi, 
which is currently running 1.40. We haven't enabled multi-attachments 
yet because we know it will not work against the main grid.

Let me know if there are any other questions!

 -Nyx

Lance Corrimal wrote:
> Heya,
>
> I just gave the new multi-wearables in viewer-external (svn r3448) a try, and 
> i found it to be seriously broken.
> when I logged in, every single attachment, including HUDs, went to some 
> rather 
> weird attachment point somewhere near my right knee, and everything was only 
> "half attached": huds would complain that "you have dropped ... to the 
> ground" 
> if they were scripted to detect that, and none of the stuff showed "worn" in 
> my inventory. And what was even more strange, the prims stayed where they 
> were 
> when I moved, hanging in the air at the very spot where my avatars right knee 
> was when i attached them.
>
> Maybe even more worse was the fact that that attach point then was stored in 
> the asset, and the stuff would attach to the same weird point even with an 
> older viewer (snowglobe 1.4). Took me about 45 minutes to repair the damage 
> to 
> my default outfit 0.o
>
> Anyone else noticed this bug?
> Is there already a jira for it?
>
>
> 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
>   

___
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] food for thought: multiple attachment support versus server-side lag

[Nyx Linden]

Whichever one you "add" last will go on top, then you can reorder the 
clothing you are wearing from the outfit editor. The order you choose 
should persist when you save your outfit or across logins, as it is 
saved as part of the inventory link created in the "current outfit" 
folder or the saved outfit folder.

As for multi-attachments, the total number of attachments you can wear 
at a given time is capped server-side, as stated earlier in the thread 
to ensure that the feature does not increase avatar complexity.

 -Nyx

Marine Kelley wrote:
> Oh you cannot decide on which slot you want to wear a piece of 
> clothing (say, a shirt), you can only "Add" it to what you are wearing 
> and it will go on top. But you can reorder it later by going to the My 
> Outfit tab, and click on the tools button to edit your appearance. 
> Then you will see up and down arrows next to the name of each piece of 
> clothing if you are wearing more than one layer of the same type. For 
> example, you can move a shirt over or below a t-shirt that way.
>
> (PS : sorry for the double mail Lance, I only replied to you the first 
> time)
>
>
> On 16 August 2010 16:19, Lance Corrimal  > wrote:
>
> hi,
>
>
> that's a bit better.
>
> more thought about multiwearables:
>
> let's say i have a tattoo, and a tank top, both on undershirt...
> with viewer
> 2.1 i can wear them both.
> How do i define what goes on top?
>
> by which order i put them on? and what about when i relog?
>
>
> bye,
> LC
>
>
> On Monday 16 August 2010 16:13:49 Marine Kelley wrote:
> > I think that's precisely why LL wanted to keep control of this
> feature
> > server side by deciding how many objects can be worn (possibly
> according to
> > the script memory limits to come), instead of going the
> avatar_lad.txt fake
> > attachments route.
> >
> > On 16 August 2010 15:58, Lance Corrimal
> mailto:lance.corri...@eregion.de>> wrote:
> > >  Hi,
> > >
> > > I just had this thought...
> > >
> > > In recent versions there's support for multiple attachments per
> > > attachment slot.
> > >
> > > In recent SERVER versions, there's a nasty bug that freezes
> whole sims
> > > when an avatar who wears lots of scripted attachments enters
> or leaves
> > > the sim... (SVC4196)
> > >
> > > Now, with multiple attachments per slot, how likely is it that
> john the
> > > mindless noobie will end up wearing lots of invisible, scripted
> > > attachments that are not that obvious, but contain a LOT of
> scripts...?
> > >
> > > Isn't there an obvious conflict of interests here?
> > >
> > >
> > > 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
> ___
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/OpenSource-Dev
> Please read the policies before posting to keep unmoderated
> posting privileges
>
>
> 
>
> ___
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/OpenSource-Dev
> Please read the policies before posting to keep unmoderated posting privileges

___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Removal of the "MultipleAttachments" debug settings ?

[Nyx Linden]

"MultipleAttachments" was a debug setting we were using for testing 
multi-attachments internally because we didn't have sufficient UI for 
specifying what happened when you went to wear an item on your avatar. 
To be clear, the setting "MultipleAttachments" affected the "wear" 
option for attachments as follows:

FALSE:
When set to false, any time you "wear" an attachment, it would 
replace all attachments at that point. If you're wearing three things on 
your head, and you "wear" something on your head, all three will be 
replaced with the new attachment. Result: you're wearing a single 
attachment on your head.

TRUE:
When set to true, any time you "wear" an attachment, it would ignore 
whatever attachments were at that point and "add" the attachment onto 
that point. For example, if you're wearing three attachments on your 
head and you "wear" something new, you will end up with four things on 
your head.

We've removed the debug setting as we've implemented this 
functionality directly in the user interface, making the debug setting 
completely unnecessary. With the latest code if you "wear" an attachment 
on your head, it will act as if MultipleAttachments was set to FALSE - 
it will replace everything else on your head.

We have a new option in the UI which we've labeled "add" - which 
will act as if MultipleAttachments is TRUE - that is it will "add" the 
attachment to the attachment point, without removing the existing 
attachments.

With both of these options being available through the UI, there is 
no need for the debug option anymore. If you don't want to use 
multi-attachments, all you need to do is make sure you use the "wear" 
option instead of the "add" option. If this is not working as I've 
described, then let us know as we have some bugs to fix :)

Let me know if this clarifies things.

 -Nyx


Marine Kelley wrote:
> Hello all,
>
> I am currently working at integrating the RLV code into the latest 
> 2.1.2 viewer in "viewer-development". Some users might have noticed 
> that the "MultipleAttachments" debug setting was set to FALSE by 
> default in order to stay compatible with 1.x, because 1.x users cannot 
> see attachments worn on slots 1 and beyond, only slot 0 is rendered. 
> So the feature is still rather useless because since most of the users 
> are still using 1.x, multiple attachments are to be avoided. However 
> having the option to choose whether to activate it or not was a good 
> idea. I even added a checkbox in the navbar to set it to TRUE or FALSE 
> in one click without having to open the debug settings (but that 
> version is not released).
>
> And now what I'm seeing in the latest version worries me. The 
> MultipleAttachments debug setting is gone ! The viewer behaves as if 
> it were always TRUE. On the paper it makes sense, since 2.x is 
> supposed to handle multiple attachments natively and the sims have 
> been updated to 1.40 (and now 1.42) almost only for this reason. 
> But... this is actually counter-productive because now someone who 
> tries 2.1 will soon discover that most of their attachments are not 
> showing to their friends. And that they require more steps to change 
> an outfit than before, because they now have to explicitely remove 
> attachments before wearing new ones.
>
> For a viewer that has a lot of difficulties being adopted by the user 
> base, isn't this move a little backwards ? Why not set 
> MultipleAttachments to TRUE by default and let the user choose in the 
> preferences or in the navbar as I did ?
>
> I for one would very much like to see the MultipleAttachments debug 
> setting come back and stay !
>
> Marine
> 
>
> ___
> 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] Removal of the "MultipleAttachments" debug settings ?

[Nyx Linden]

Correct, that is what most people will do, and that's why we wanted to 
keep the behavior of double click / "wear" to be consistent with how the 
functionality worked in 1.23.X, as that's what most people are used to 
those functions doing.

Since multi-wearables is a new feature, using the new functionality 
warranted using a new right click menu option.

We'd like to keep things consistent for old users and offer new 
functionality for those who would like to take advantage of it. Its a 
fairly simple implementation for the UI for controlling multiwearables, 
however, so if you have suggestions for better ways of exposing the 
functionality, please do let us know!

 -Nyx

Trilo Byte wrote:
> My mistake, then.  When I performed the same action to wear an item as
> I had in previous builds and got the unexpected/unwanted result, and 
> saw that the debug option was gone, I thought it had broken (like 
> anti-aliasing did in the latest build).
>
> When this viewer gets released. it would be helpful if this change in 
> behavior was blogged and documented.  I think it makes a lot of sense,
> but double-clicking on an item or right-clicking and choosing 'wear' is 
> what I imagine most people would do.
>
> Trilo
>
> On Aug 26, 2010, at 1:24 PM, Nyx Linden wrote:
>
>   
>>"MultipleAttachments" was a debug setting we were using for testing 
>> multi-attachments internally because we didn't have sufficient UI for 
>> specifying what happened when you went to wear an item on your avatar. 
>> To be clear, the setting "MultipleAttachments" affected the "wear" 
>> option for attachments as follows:
>>
>> FALSE:
>>When set to false, any time you "wear" an attachment, it would 
>> replace all attachments at that point. If you're wearing three things on 
>> your head, and you "wear" something on your head, all three will be 
>> replaced with the new attachment. Result: you're wearing a single 
>> attachment on your head.
>>
>> TRUE:
>>When set to true, any time you "wear" an attachment, it would ignore 
>> whatever attachments were at that point and "add" the attachment onto 
>> that point. For example, if you're wearing three attachments on your 
>> head and you "wear" something new, you will end up with four things on 
>> your head.
>>
>>We've removed the debug setting as we've implemented this 
>> functionality directly in the user interface, making the debug setting 
>> completely unnecessary. With the latest code if you "wear" an attachment 
>> on your head, it will act as if MultipleAttachments was set to FALSE - 
>> it will replace everything else on your head.
>>
>>We have a new option in the UI which we've labeled "add" - which 
>> will act as if MultipleAttachments is TRUE - that is it will "add" the 
>> attachment to the attachment point, without removing the existing 
>> attachments.
>>
>>With both of these options being available through the UI, there is 
>> no need for the debug option anymore. If you don't want to use 
>> multi-attachments, all you need to do is make sure you use the "wear" 
>> option instead of the "add" option. If this is not working as I've 
>> described, then let us know as we have some bugs to fix :)
>>
>> Let me know if this clarifies things.
>>
>> -Nyx
>>
>>
>> Marine Kelley wrote:
>> 
>>> Hello all,
>>>
>>> I am currently working at integrating the RLV code into the latest 
>>> 2.1.2 viewer in "viewer-development". Some users might have noticed 
>>> that the "MultipleAttachments" debug setting was set to FALSE by 
>>> default in order to stay compatible with 1.x, because 1.x users cannot 
>>> see attachments worn on slots 1 and beyond, only slot 0 is rendered. 
>>> So the feature is still rather useless because since most of the users 
>>> are still using 1.x, multiple attachments are to be avoided. However 
>>> having the option to choose whether to activate it or not was a good 
>>> idea. I even added a checkbox in the navbar to set it to TRUE or FALSE 
>>> in one click without having to open the debug settings (but that 
>>> version is not released).
>>>
>>> And now what I'm seeing in the latest version worries me. The 
>>> MultipleAttachments debug setting is gone ! The viewer behaves as if 
>>> it were always TRUE. On the paper it makes sense, sin

Re: [opensource-dev] Removal of the "MultipleAttachments" debug settings ?

[Nyx Linden]

Its a bug. We're going to fix it. This isn't the final behavior.

 -Nyx

Trilo Byte wrote:
> I thought that was the whole point of creating outfit folders to begin with.
> Get your avatar looking exactly the way you want, attachments
> and all, then save it to a folder for fast/easy/fun one click
> wardrobe change.  New behavior makes outfit folders decidedly
> less fast/easy/fun to work with.
>
> On Aug 27, 2010, at 1:12 PM, Kadah wrote:
>
>   
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> On 8/27/2010 8:37 AM, Trilo Byte wrote:
>> 
>>> Nyx, I did also notice that if you wear an outfit folder that makes 
>>> use of mutliple attachments in v2.1.2, it no longer works properly.
>>>
>>> Instead of putting on all the items in the user-specified folder, it
>>> only puts on the first attachment the viewer gets to.  Any
>>> additional ones are left un-worn, and must be added to the outfit
>>> manually, one at a time.
>>>   
>> I can verifiy this is the case with 2.1.2.208673. Made a new outfit that
>> has 2 tails, took everything off, did wear-replace with new outfit. Saw
>> the first one pop on for a moment then replaced by the 2nd one a moment
>> later. Wear-add had the same effect.
>>
>> Kinda defeats the purpose of 2's outfits if it don't work together with
>> multi-attach :P
>>
>> Would be nice if I could also put on all items in a folder with
>> multi-attach. Would be nice for those infrequently used collection of
>> items that aren't associated to any one outfit.
>>
>> Its a little confusing now that "add" has different meanings on
>> different items. "Add" on a single item attaches it without replace,
>> "add" on a folder/outfit replaces existing on same points.
>> -BEGIN PGP SIGNATURE-
>> Version: GnuPG v1.4.10 (MingW32)
>> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>>
>> iQEcBAEBAgAGBQJMeBw+AAoJEIdLfPRu7qE2DTMH/iuCUdlibLH4Xt64AaJa3Cnt
>> 8RjXYbtkm3MjtgK/m+a+lV/lngO7regiVshDMUo55mdUbzA0MNgI9bdsEkXJQfzY
>> NJQGr5bcC4ls3clnY9oVOSdZKncuq0N/tU6Smno8Y4M4LzCmIj2WEyjWC77U9sOC
>> bTtmGwHdTnJqEWGVuei1ABvg5QgLaqBymSKTVcXyGr2wVtEC+HxTSYFWKe33tyow
>> 7Uvvw/yO0fn5sXfdgacCpepRdlq73Z6BDHMyOFd2KMZHQ+eRiL15cbua5BLE09ui
>> NeBmu8NMMvFkCKpBvl0cEhnI+DklHmYFxmxNdYpMpOMwCzWdES0luVZ1kyFHkeM=
>> =ZQJu
>> -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
>   

___
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] Removal of the "MultipleAttachments" debug settings ?

[Nyx Linden]

This is fixed internally in the ECC project branch. Once that merges 
into viewer-development (we have the same submission process for merging 
as you guys do!), I'll post here to ask everyone to test out the fix.

Thanks!

 -Nyx

Nyx Linden wrote:
> Its a bug. We're going to fix it. This isn't the final behavior.
>
> -Nyx
>
> Trilo Byte wrote:
>> I thought that was the whole point of creating outfit folders to 
>> begin with.
>> Get your avatar looking exactly the way you want, attachments
>> and all, then save it to a folder for fast/easy/fun one click
>> wardrobe change.  New behavior makes outfit folders decidedly
>> less fast/easy/fun to work with.
>>
>> On Aug 27, 2010, at 1:12 PM, Kadah wrote:
>>
>>  
>>> -BEGIN PGP SIGNED MESSAGE-
>>> Hash: SHA1
>>>
>>> On 8/27/2010 8:37 AM, Trilo Byte wrote:
>>>
>>>> Nyx, I did also notice that if you wear an outfit folder that makes 
>>>> use of mutliple attachments in v2.1.2, it no longer works properly.
>>>>
>>>> Instead of putting on all the items in the user-specified folder, it
>>>> only puts on the first attachment the viewer gets to.  Any
>>>> additional ones are left un-worn, and must be added to the outfit
>>>> manually, one at a time.
>>>>   
>>> I can verifiy this is the case with 2.1.2.208673. Made a new outfit 
>>> that
>>> has 2 tails, took everything off, did wear-replace with new outfit. Saw
>>> the first one pop on for a moment then replaced by the 2nd one a moment
>>> later. Wear-add had the same effect.
>>>
>>> Kinda defeats the purpose of 2's outfits if it don't work together with
>>> multi-attach :P
>>>
>>> Would be nice if I could also put on all items in a folder with
>>> multi-attach. Would be nice for those infrequently used collection of
>>> items that aren't associated to any one outfit.
>>>
>>> Its a little confusing now that "add" has different meanings on
>>> different items. "Add" on a single item attaches it without replace,
>>> "add" on a folder/outfit replaces existing on same points.
>>> -BEGIN PGP SIGNATURE-
>>> Version: GnuPG v1.4.10 (MingW32)
>>> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>>>
>>> iQEcBAEBAgAGBQJMeBw+AAoJEIdLfPRu7qE2DTMH/iuCUdlibLH4Xt64AaJa3Cnt
>>> 8RjXYbtkm3MjtgK/m+a+lV/lngO7regiVshDMUo55mdUbzA0MNgI9bdsEkXJQfzY
>>> NJQGr5bcC4ls3clnY9oVOSdZKncuq0N/tU6Smno8Y4M4LzCmIj2WEyjWC77U9sOC
>>> bTtmGwHdTnJqEWGVuei1ABvg5QgLaqBymSKTVcXyGr2wVtEC+HxTSYFWKe33tyow
>>> 7Uvvw/yO0fn5sXfdgacCpepRdlq73Z6BDHMyOFd2KMZHQ+eRiL15cbua5BLE09ui
>>> NeBmu8NMMvFkCKpBvl0cEhnI+DklHmYFxmxNdYpMpOMwCzWdES0luVZ1kyFHkeM=
>>> =ZQJu
>>> -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
>>   
>

___
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] Mesh?

[Nyx Linden]

We intend on releasing the code when we go to open beta (when we start 
publicly shipping mesh-enabled viewers).
The featureset is not done, and will require more work even in open 
beta, and contributions from the community will be welcome and encouraged.
Currently, we're trying to get the featureset to a base level of stable 
functionality so that it will be useful for non-coders as well as 
developers. We're also brushing up our documentation efforts to ensure 
we have some basic guides as to how to use the features.


You can view our documentation efforts here: 
http://wiki.secondlife.com/wiki/Mesh
We'll be announcing the date of the open beta soon on the blogs: 
http://blogs.secondlife.com/index.jspa


Stay tuned for updates!
I look forward to working with third party developers on this featureset 
during and after the open beta!


 -Nyx

On 09/25/2010 11:21 AM, Brandon Husbands wrote:
I understand the want to be all private and stuff with this but uhh it 
hurts the open source initiative if you hide this code from us.  Are 
we really 2nd rate developers where our skills are not trusted enough 
to help with actual development and nut just hit or miss bugfixers?



--
---
This email is a private and confidential communication. Any use of 
email may be subject to the laws and regulations of the United States. 
You may not Repost, Distribute nor reproduce any content of this message.

---
---


___
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] Project-MESH viewer

[Nyx Linden]

We just pulled from viewer-development yesterday actually, but we had 
already released the initial beta viewer.
We try to stay reasonably up to date, but we don't merge the latest 
changes every day.

Don't worry we will stay synced!

  -Nyx

On 10/15/2010 01:29 PM, Oz Linden (Scott Lawrence) wrote:
>On 2010-10-15 13:07, Ponzu wrote:
>
>> I tried this viewer last night.  As I am sure you Lindens know, it is
>> based on a version of viewer-development that is many days old.  (Some
>> complaint, huh?)
>> Could perhaps someone help the Mesh team pull the most relevant
>> changesets from viewer-dev so their next release lacks the more
>> annoying problems? (such as my personal favorite, SH-173 8-)
>>  
> How frequently a team pulls from viewer-development is up to the team.
> It should not surprise you to hear that in the final days leading up to
> releasing a viewer, this task might take a back seat to putting the
> finishing touches on the feature one is building the Project Viewer to
> test.
>
> It happens that the last few days have also been a busy time in the
> viewer-development repository, with fixes coming back from the
> viewer-beta and yesterday the Display Names project merging in.  I think
> that if I were deciding on when to sync with the latest from
> viewer-development, I too might have decided to wait a bit.
>
> Have no fear... any future mesh project viewers will have pulled more
> from viewer-development, and it will all come together before being in a
> Beta or released Viewer.
>
>
> ___
> 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

[opensource-dev] Mesh viewer source code

[Nyx Linden]

Sorry for the delay, there's been a few build and licensing issues that 
have cropped up recently that have made it difficult to get the source 
code published for the mesh viewer. That being said, the source is now 
public, at the following repository:

http://hg.secondlife.com/mesh-development/

Please note that there are still some build errors on some platforms, 
but there have been a few requests that we release the source even 
before these issues are fixed. I'll be focusing on getting these errors 
fixed tomorrow, so if you encounter specific build issues, please let me 
know.

There are a few new libraries that are linked into the viewer - the 
source code for these will be released soon. The new libraries are:

glod - level of detail library we use for auto-generating different 
levels of detail. Based on this library: 
http://www.cs.jhu.edu/~graphics/GLOD/  We have some tweaks that make it 
work with our system, and will be releasing the source shortly.

collada - we're wrapping the standard collada libs with some code that 
makes it work with our viewer. We'll be releasing the source to our 
modifications shortly.

Convex decomposition stub - We're using havok to decompose meshes into 
multiple convex hulls in our official release. However, to support the 
development of a fully open-source solution, we're releasing the source 
code to the "stub" (non-functional) version of the library we're 
providing to compile the mesh viewer. This stub should have all the 
relevant information necessary to start development of a new convex 
decomposition library. We hope to have the source up shortly.

I'm very interested personally in seeing a fully open-source convex 
decomposition library created to work with our mesh source code, so if 
anyone would like to get started on this, please let me know and I'll do 
what I can to support such an effort!

Please note that the current state of the code isn't fully stable - 
initial builds have reported a linking issue on linux, and a crash on 
windows. I'll be working to resolve these issues ASAP, but if you have 
any specific information on how the build is breaking, please let me 
know! This will be our primary repository, so check back for updates and 
build fixes :)

Thanks everyone for your patience on waiting for the code!

  -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] Mesh viewer source code

[Nyx Linden]

Library source code is now up as well! the repositories are listed below:
http://bitbucket.org/lindenlab/glod
http://bitbucket.org/lindenlab/colladadom
http://bitbucket.org/lindenlab/llconvexdecompositionstub

Let me know if there are any questions!

  -Nyx

On 10/22/2010 11:43 AM, Nyx Linden wrote:
> Sorry for the delay, there's been a few build and licensing issues 
> that have cropped up recently that have made it difficult to get the 
> source code published for the mesh viewer. That being said, the source 
> is now public, at the following repository:
>
> http://hg.secondlife.com/mesh-development/
>
> Please note that there are still some build errors on some platforms, 
> but there have been a few requests that we release the source even 
> before these issues are fixed. I'll be focusing on getting these 
> errors fixed tomorrow, so if you encounter specific build issues, 
> please let me know.
>
> There are a few new libraries that are linked into the viewer - the 
> source code for these will be released soon. The new libraries are:
>
> glod - level of detail library we use for auto-generating different 
> levels of detail. Based on this library: 
> http://www.cs.jhu.edu/~graphics/GLOD/  We have some tweaks that make 
> it work with our system, and will be releasing the source shortly.
>
> collada - we're wrapping the standard collada libs with some code that 
> makes it work with our viewer. We'll be releasing the source to our 
> modifications shortly.
>
> Convex decomposition stub - We're using havok to decompose meshes into 
> multiple convex hulls in our official release. However, to support the 
> development of a fully open-source solution, we're releasing the 
> source code to the "stub" (non-functional) version of the library 
> we're providing to compile the mesh viewer. This stub should have all 
> the relevant information necessary to start development of a new 
> convex decomposition library. We hope to have the source up shortly.
>
> I'm very interested personally in seeing a fully open-source convex 
> decomposition library created to work with our mesh source code, so if 
> anyone would like to get started on this, please let me know and I'll 
> do what I can to support such an effort!
>
> Please note that the current state of the code isn't fully stable - 
> initial builds have reported a linking issue on linux, and a crash on 
> windows. I'll be working to resolve these issues ASAP, but if you have 
> any specific information on how the build is breaking, please let me 
> know! This will be our primary repository, so check back for updates 
> and build fixes :)
>
> Thanks everyone for your patience on waiting for the code!
>
>  -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] (standalone/64-bit) build issues with Mesh viewer source code (and fixes for some of them. Yay!)

[Nyx Linden]

I'm out of the office today and tomorrow, but will definitely be  
looking into these patches and remaining issues on Wednesday. Thanks a  
ton for helping us out!


Nyx

Sent from my iPhone

On Oct 25, 2010, at 10:27 AM, "WolfPup Lowenhar" > wrote:


Just so everyone knows I’m building on Windows 7 32-bit and both if  
the tests that Boroondas mentions are actually memory leaking BADLY( 
test ballons to nearly 1GB of mem usage) on my system just before cr 
ashing or I terminated the process.




From: opensource-dev-boun...@lists.secondlife.com [mailto:opensource- 
dev-boun...@lists.secondlife.com] On Behalf Of Boroondas Gupte

Sent: Monday, October 25, 2010 10:02 AM
To: Nyx Linden
Cc: opensource-dev
Subject: [opensource-dev] (standalone/64-bit) build issues with Mesh  
viewer source code (and fixes for some of them. Yay!)




So ... I've been busy during the weeking poking the mesh viewer  
source code with a stick g++ and can report some results. It seems  
quite some of the issues were (re)introduced by mistakes in merge  
conflict resolution. Some others are new. Here are the one's I've  
filed issues for already:


CTS-314: Fix of VWR-20810 / SNOW-503 (Quote EXE_STAGING_DIR to  
prevent it failing with some paths) lost in merge


VWR-20810 was fixed at b987077e9bbb, but it looks like the fix got  
lost in the merge at 538a49313042.

Re-fixed
Ready for review
CTS-315: -march=pentium4 may not be used for 64bit builds

Started discussion on the mailing list about how to fix this correctly
Until that's decided, work around with
· sed '175 s/-march=pentium4 //' -i indra/cmake/00-Common.cm 
ake

when building 64-bit.

CTS-318: Fix of VWR-20809 / SNOW-504 (Do not depend on  
stage_thirds_party_libs for a standalone build.) lost in merge


VWR-20809 was fixed at c5ddd1e361ae , but it looks like the fix got  
lost in the merge at 538a49313042.

Re-fixed
Ready for review
CTS-319: Fix of VWR-20670 / SNOW-506 (Protection on  
LLInstanceTracker base in LLEventTimer needs to be public for gcc  
>4.1) lost in merge


VWR-20670 was fixed at 20860bbd5cae, but it looks like the fix got  
lost in the merge at ad384ab52275.

Re-fixed
Ready for review
CTS-320: use system zlib for standalone

Fixed, using the same pattern as already used elsewhere in the code
Noticed some mistakes in the fix and corrected those
Ready for review
CTS-323: Don't cast pointers to U32

Fixed by using uintptr_t instead.
This type isn't part of the current C++ standard (might become part  
of the next), but it's already used elsewhere in the code, so I  
assume all of our build platforms support it.

Ready for review


Now I'm stuck at where it won't find the new libraries, even when I  
build and install them. I guess some CMake glue for standalone is  
still missing. (Or maybe I should just wait for auto-build?)


Also, when tests are enabled, one of them errors out. That's right,  
it's not even failing. :-P


Running: /usr/bin/python ${SRC_DIR}/indra/llmessage/tests/ 
test_llsdmessage_peer.py ${BUILD_DIR}/llmessage/ 
INTEGRATION_TEST_llsdmessage

Unit test group_started name=llsdmessage
Failed to catch N11LLEventPump11DupPumpNameE
Failure running: /usr/bin/python ${SRC_DIR}/indra/llmessage/tests/ 
test_llsdmessage_peer.py ${BUILD_DIR}/llmessage/ 
INTEGRATION_TEST_llsdmessage

Error: 245
make[2]: *** [llmessage/INTEGRATION_TEST_llsdmessage] Error 245
make[1]: *** [llmessage/CMakeFiles/INTEGRATION_TEST_llsdmessage.dir/ 
all] Error 2

make: *** [all] Error 2
Wolfpup observed that INTEGRATION_TEST_llcapabilitylistener also has  
runtime issues.


Cheers,
Boroondas

No virus found in this message.
Checked by AVG - www.avg.com
Version: 10.0.1152 / Virus Database: 422/3218 - Release Date: 10/25/10

___
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] Latest Linux Mesh Development build = ~200 MB

[Nyx Linden]

Its known, but not desired. I need to look into what libraries we're 
linking in that are causing the bloat and if we can slim them down.

Created a task for next sprint to investigate.

  -Nyx

On 11/17/2010 09:10 AM, Opensource Obscure wrote:
>   I'm downloading right now the latest Linux Mesh Development build,
>   and it amounts to 198 MB, while Win and Mac versions seem to have
>   'normal' weight (~25 and ~50 MB)
>
>   Is this expected?
>
>   build filename is SecondLife-i686-2.4.0.214802.tar.bz2
>
>
>   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
>

___
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] Upcoming depth-of-field feature

[Nyx Linden]

Depth of Field is a quick feature one of our devs developed while 
looking into anti-aliasing bugs. It didn't take a substantial amount of 
time away from bug-hunting, and should be useful for a variety of 
purposes (photography and machinima for starters).

At this point it should be considered a toy, in that its a feature that 
hasn't yet been formally finished, debugged, qa'd, or had a good 
interface put on top of it. Feedback is appreciated for when we do 
prepare to polish it up of course.

As always, you can see the changes we've made in the mesh branch in our 
public repository:
http://hg.secondlife.com/mesh-development

You can always get the latest successful build of our changes here (link 
is also on the wiki downloads page):
http://automated-builds-secondlife-com.s3.amazonaws.com/hg/repo/mesh-development/latest.html

Feedback is appreciated to be put into jira-form under the mesh beta 
project for specific bug reports and feature requests, or on the forums 
for any topics that could require discussion:
http://blogs.secondlife.com/community/forums/mesh

Thanks for noticing, and thanks for the feedback!

  -Nyx

On 11/25/2010 06:54 PM, Ricky wrote:
> Agreed, DOF is on my long-list not my short-list of things I'd like to
> see done.  However, I expect that SL's deferred rendering system has a
> laundry list of issues. Just look at it's history; it's been little
> more than a pet-project since it's inception.  A pet project with the
> capability to go far, but still just a pet project.  Getting the
> client into a stronger codebase (2.0) and then stabilized with very
> little new features has been the largest pushes in recent history.
>
> In fact, we've (LL and OS devs,) been working stability for so many
> months that it might be time to push for a cool, if small, new
> feature.  However, with the new level of visibility, it won't be as
> much a surprise. I hope.  From my reading here, most people don't like
> surprises! :P  Maybe something nice, like a good UI skinning system...
>   See http://wiki.secondlife.com/wiki/Skinning#Phase_2_-_Switchable_Skins
>   Or maybe a roll-out of meshes, but I suspect that's wishing too hard!
> :P
>
> As to the original question about DoF, here's what is known:
>
> http://www.google.com/search?sourceid=chrome&ie=UTF-8&q=%22depth+of+field%22+OR+DOF+site:secondlife.com
> Which gives the following JIRAs:
> https://jira.secondlife.com/browse/VWR-19244  PROFESSIoNAL TOOL:
> Snapshot: add functions: Dynamic Focus, Depth of field and Blurr
> https://jira.secondlife.com/browse/VWR-3921  photographic tools: DoF
>
> In VWR-3921 Adeon Writer pointed to this build of the mesh viewer:
> http://automated-builds-secondlife-com.s3.amazonaws.com/hg/repo/mesh-development/rev/215482/index.html
>
> Ricky
> Cron Stardust
>
> On Thu, Nov 25, 2010 at 3:11 PM, Geenz Spad  wrote:
>
>> I wonder how awesome it'll run on top of the already awesome deferred
>> renderer that has really awesome performance on really awesome video cards
>> that have really awesome drivers?
>>
>> Honestly, as nifty as DOF is as far as the "pretty" factor is concerned,
>> right now the deferred renderer needs a few more optimizations before any
>> additional features are added to it, and it still needs a few more work
>> arounds for buggy drivers (for example, successfully running the deferred
>> renderer on ATI hardware still tends to vary from person to person,
>> depending on their hardware and driver combination).  On top of that, you
>> still need a pretty powerful video card in order to really take advantage of
>> it, though I think that really has to do with bottle necks within the
>> rendering system as a whole, not just bottle necks presented by the deferred
>> renderer its self (although deferred rendering does have it's own bottle
>> necks, and SL's deferred renderer in particular presents a few interesting
>> ones of its own due to its flexibility).
>>
>> On Thu, Nov 25, 2010 at 4:43 PM, Ricky  wrote:
>>  
>>> Things ARE getting fixed, just look at the daily scrum reports or the
>>> progress tracking in the JIRA.  Also take note that sometimes "adding"
>>> a single feature will often resolve several bugs and feature requests.
>>>   For instance the Deferred rendering channel will add the ability to
>>> have greater than 7 light-sources, solving several issues with
>>> facelights and other lights taking out room lighting.
>>>
>>> As to optimization, things are pretty optimized.  Yes, they CAN get
>>> better, but without a major restructuring of how content is created,
>>> we will never have the high render rates found in the online and
>>> offline games.  Even so, the work being done on upgrading KDU looks
>>> like it is improving load/render rates as it is.
>>>
>>> Don't forget that there are multiple people in multiple teams working
>>> on this program.  Some are better at adding new features, and so are
>>> better utilized in that area.  Some are better testers than coders,
>>> and so t