Re: [opensource-dev] storm-34

[Erin Mallory]

I thought the whole point of storm-34 was to give you your favorites during the 
login under the start at location so you could login to your favorite locations?

Subject: Re: [opensource-dev] storm-34
From: q...@lindenlab.com
Date: Sun, 9 Jan 2011 13:59:36 -0500
CC: opensource-dev@lists.secondlife.com
To: angel_of_crim...@hotmail.com



You can't see the private favorites before login, so you shouldn't expect to 
see the "favorite landmarks" setting during login. You can only see it after 
login. This is because you don't have a private prefs available until after 
login.
Q
On Jan 7, 2011, at 8:35 PM, Erin Mallory wrote:I've been testing the storm 34 
viewer on windows 7 and on windows xp.  Ive noticed its not properly keeping 
the preferences between when youre logged in and logged out and that the 
favorites therefor are not properly showing up for me. this started occuring 
after i changed the account from my cummere to erinyse then back.  now no 
matter what i cant get it to show the favorites for either account at log in 
even though both accounts have that box checked  

before i jira this, can anyone else repo?
___
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] storm-34

[Opensource Obscure]

What about a list of non-private, non-asset SLURLs that users can set
while logged off? They would be shown *before* login, so that users
can directly go there - avoiding additional in-world teleports.

On shared computers, this could be disabled. Actually, in some cases
people using the same shared computer could still enable it, and
arrange a list of commons locations to show.


It could work like this:

1a. while still logged off, go to Preferences and enable the feature.
1b. paste SLURLs in a dedicated field.

2. at next login, those SLURLs are parsed and shown in the current
drop-down, in addition to the existing locations (home & last location)

3. choose a location and log in


A completely different approach could be: embed SL map in the login
screen and let people use it to choose a location where to log in.
But I digress.

Opensource Obscure

On Sun, Jan 9, 2011 at 19:59, Kent Quirk (Q Linden)  wrote:
> You can't see the private favorites before login, so you shouldn't expect to
> see the "favorite landmarks" setting during login. You can only see it after
> login. This is because you don't have a private prefs available until after
> login.
>     Q
> On Jan 7, 2011, at 8:35 PM, Erin Mallory wrote:
>
> I've been testing the storm 34 viewer on windows 7 and on windows xp.  Ive
> noticed its not properly keeping the preferences between when youre logged
> in and logged out and that the favorites therefor are not properly showing
> up for me. this started occuring after i changed the account from my cummere
> to erinyse then back.  now no matter what i cant get it to show the
> favorites for either account at log in even though both accounts have that
> box checked
>
> before i jira this, can anyone else repo?
>  one.JPG>___
> 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 Obscure

Twitter [EN] - Twitter [IT] - Blog [IT] - YouTube - Photos - Second Life
___
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] storm-34

[Andrew Dyukov]

Yes, it was the point of the task and it works this way - you can see
the list of your favorites in login screen if you allowed them to be
shown beforehand (while being logged in). You can't change the
preference before login because viewer wouldn't know whose preferences
to change in this case, and even if it could it would be bad from
privacy perspective.

2011/1/10 Erin Mallory :
> I thought the whole point of storm-34 was to give you your favorites during
> the login under the start at location so you could login to your favorite
> locations?
>
> 
> Subject: Re: [opensource-dev] storm-34
> From: q...@lindenlab.com
> Date: Sun, 9 Jan 2011 13:59:36 -0500
> CC: opensource-dev@lists.secondlife.com
> To: angel_of_crim...@hotmail.com
>
> You can't see the private favorites before login, so you shouldn't expect to
> see the "favorite landmarks" setting during login. You can only see it after
> login. This is because you don't have a private prefs available until after
> login.
>     Q
> On Jan 7, 2011, at 8:35 PM, Erin Mallory wrote:
>
> I've been testing the storm 34 viewer on windows 7 and on windows xp.  Ive
> noticed its not properly keeping the preferences between when youre logged
> in and logged out and that the favorites therefor are not properly showing
> up for me. this started occuring after i changed the account from my cummere
> to erinyse then back.  now no matter what i cant get it to show the
> favorites for either account at log in even though both accounts have that
> box checked
>
> before i jira this, can anyone else repo?
>  one.JPG>___
> 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] storm-34

[Lance Corrimal]

> 1a. while still logged off, go to Preferences and enable the feature.
> 1b. paste SLURLs in a dedicated field.
> 
> 2. at next login, those SLURLs are parsed and shown in the current
> drop-down, in addition to the existing locations (home & last location)
> 
> 3. choose a location and log in


voted.


it could even be two lists, one in the global app_settings folder that could 
be populated (and read-only), and for example on the official LL client it 
would have slurls to infohubs or orientation islands, while a TPV dev could 
populate that with slurls to places that might be of special interest for 
users of that TPV... in case of my dolphin viewer i'd put slurls to vehicle 
rez areas in it, for example.

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

Re: [opensource-dev] storm-34

[Erin Mallory]

The point is I did NOT change the preferences before hand.  I logged in set the 
prefrences and logged out, and STILL do not see them showing up the way they 
should. 

> Date: Mon, 10 Jan 2011 16:39:32 +0200
> Subject: Re: [opensource-dev] storm-34
> From: adyu...@productengine.com
> To: angel_of_crim...@hotmail.com
> CC: q...@lindenlab.com; opensource-dev@lists.secondlife.com
> 
> Yes, it was the point of the task and it works this way - you can see
> the list of your favorites in login screen if you allowed them to be
> shown beforehand (while being logged in). You can't change the
> preference before login because viewer wouldn't know whose preferences
> to change in this case, and even if it could it would be bad from
> privacy perspective.
> 
> 2011/1/10 Erin Mallory :
> > I thought the whole point of storm-34 was to give you your favorites during
> > the login under the start at location so you could login to your favorite
> > locations?
> >
> > 
> > Subject: Re: [opensource-dev] storm-34
> > From: q...@lindenlab.com
> > Date: Sun, 9 Jan 2011 13:59:36 -0500
> > CC: opensource-dev@lists.secondlife.com
> > To: angel_of_crim...@hotmail.com
> >
> > You can't see the private favorites before login, so you shouldn't expect to
> > see the "favorite landmarks" setting during login. You can only see it after
> > login. This is because you don't have a private prefs available until after
> > login.
> > Q
> > On Jan 7, 2011, at 8:35 PM, Erin Mallory wrote:
> >
> > I've been testing the storm 34 viewer on windows 7 and on windows xp.  Ive
> > noticed its not properly keeping the preferences between when youre logged
> > in and logged out and that the favorites therefor are not properly showing
> > up for me. this started occuring after i changed the account from my cummere
> > to erinyse then back.  now no matter what i cant get it to show the
> > favorites for either account at log in even though both accounts have that
> > box checked
> >
> > before i jira this, can anyone else repo?
> >  > one.JPG>___
> > 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] storm-34

[Andrew Dyukov]

If you enabled the preference for your account after login, and quit
viewer correctly (i.e. it didn't crash), favorites should show up in
"Start at" when your username is entered. Please write more detailed
the steps to reproduce the problem.

2011/1/10 Erin Mallory :
> The point is I did NOT change the preferences before hand.  I logged in set
> the prefrences and logged out, and STILL do not see them showing up the way
> they should.
>
>> Date: Mon, 10 Jan 2011 16:39:32 +0200
>> Subject: Re: [opensource-dev] storm-34
>> From: adyu...@productengine.com
>> To: angel_of_crim...@hotmail.com
>> CC: q...@lindenlab.com; opensource-dev@lists.secondlife.com
>>
>> Yes, it was the point of the task and it works this way - you can see
>> the list of your favorites in login screen if you allowed them to be
>> shown beforehand (while being logged in). You can't change the
>> preference before login because viewer wouldn't know whose preferences
>> to change in this case, and even if it could it would be bad from
>> privacy perspective.
>>
>> 2011/1/10 Erin Mallory :
>> > I thought the whole point of storm-34 was to give you your favorites
>> > during
>> > the login under the start at location so you could login to your
>> > favorite
>> > locations?
>> >
>> > 
>> > Subject: Re: [opensource-dev] storm-34
>> > From: q...@lindenlab.com
>> > Date: Sun, 9 Jan 2011 13:59:36 -0500
>> > CC: opensource-dev@lists.secondlife.com
>> > To: angel_of_crim...@hotmail.com
>> >
>> > You can't see the private favorites before login, so you shouldn't
>> > expect to
>> > see the "favorite landmarks" setting during login. You can only see it
>> > after
>> > login. This is because you don't have a private prefs available until
>> > after
>> > login.
>> >     Q
>> > On Jan 7, 2011, at 8:35 PM, Erin Mallory wrote:
>> >
>> > I've been testing the storm 34 viewer on windows 7 and on windows xp.
>> > Ive
>> > noticed its not properly keeping the preferences between when youre
>> > logged
>> > in and logged out and that the favorites therefor are not properly
>> > showing
>> > up for me. this started occuring after i changed the account from my
>> > cummere
>> > to erinyse then back.  now no matter what i cant get it to show the
>> > favorites for either account at log in even though both accounts have
>> > that
>> > box checked
>> >
>> > before i jira this, can anyone else repo?
>> > > > one.JPG>___
>> > 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] Review Request: VWR-24420: PNG images which specify "background color" lose alpha layer when imported.

[Ponzu]

A common cause of z-buffer problems in SL is textures that do not *need* an
alpha channel that contain one anyway.  Lots of content in SL is created by
rank amateurs (me for example).

What if the upload dialog had a check box?

[ ] This texture should have an alpha channel.

If the box is not checked, the alpha channel is removed.  If it is checked,
it is retained, unless it is not there, in which case the user gets an error
message.

Just thinking out loud.

ponzu

On Sun, Jan 9, 2011 at 9:59 AM, Thickbrick Sleaford <
thickbrick.sleaf...@gmail.com> wrote:

>This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/74/
>   Review request for Viewer.
> By Thickbrick Sleaford.
> Description
>
> Current code composites RGBA PNG images that contain a bKGD chunk down to 
> RGB, discarding the alpha channel. This patch removes that code, since it 
> contradicts purpose of the bKGD chunk as described in the PNG spec and as 
> commonly used.
>
>   Testing
>
> Tested uploading the 2 images attached to VWR-24420 with and without the 
> patch. Before patch, "bad alpha.png" was uploaded as RGB, after patch, both 
> images were uploaded as RGBA.
>
>   *Bugs: * VWR-24420 
> Diffs
>
>- doc/contributions.txt (UNKNOWN)
>- indra/llimage/llpngwrapper.h (UNKNOWN)
>- indra/llimage/llpngwrapper.cpp (UNKNOWN)
>
> View Diff 
>
> ___
> 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] storm-34

[Erin Mallory]

what happened to get the issue to occur for me.  I installed the storm-34 
developer viewer.  logged in with cummere mayo.  set the option to show the 
favorites.  logged out.   started the viewer.  it worked as expected. logged 
out.  back in. still worked as expected.  logged out. 
changed account to erinyse planer.   logged in.  logged back out.   started 
viewer.   favorites were not there (as expected)  changed account back to 
cummere mayo.  logged in.  made sure preference was still on.  (it was) logged 
out. restarted the viewer: favorites no longer show up. 

have tried reseeting the preference while logged in multiple times.  didnt fix 
it. have tried reinstalling the viewer.  worked great till i logged in an 
account and didnt set the preferences.   NOTE: even enabling the preference on 
the erinyse account and logging out then switching logging in cummere mayo and 
logging off still doesnt allow it to work.  Im not sure if soemthing is 
corrupting the prefences file or what...  which is why im asking if others can 
repo this?
  ___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] storm-34

[Andrew Dyukov]

The preference is per-account, .i.e. you should turn it on separately
for each user whose favorites you want to be shown in login screen. So
to get favorites for both cummere and erinyse you should:

1. log in with cummere mayo.  set the option to show the favorites.  log out.
2. start the viewer. log in with erinyse planer.  set the option to
show the favorites.  log out.

On the next start of the viewer favorites will be available for both users.

2011/1/10 Erin Mallory :
> what happened to get the issue to occur for me.  I installed the storm-34
> developer viewer.  logged in with cummere mayo.  set the option to show the
> favorites.  logged out.   started the viewer.  it worked as expected. logged
> out.  back in. still worked as expected.  logged out.
> changed account to erinyse planer.   logged in.  logged back out.   started
> viewer.   favorites were not there (as expected)  changed account back to
> cummere mayo.  logged in.  made sure preference was still on.  (it was)
> logged out. restarted the viewer: favorites no longer show up.
>
> have tried reseeting the preference while logged in multiple times.  didnt
> fix it. have tried reinstalling the viewer.  worked great till i logged in
> an account and didnt set the preferences.   NOTE: even enabling the
> preference on the erinyse account and logging out then switching logging in
> cummere mayo and logging off still doesnt allow it to work.  Im not sure if
> soemthing is corrupting the prefences file or what...  which is why im
> asking if others can repo this?
>
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Review Request: VWR-24420: PNG images which specify "background color" lose alpha layer when imported.

[Dave Booth]

Thats a pretty good bit of thinking out loud there, Ponzu

Personally I'd say thats a "clean" fix for this. However it all depends 
on how things are stored server-side - if the asset server code 
automatically assumes that every texture has an alpha channel and 
supplies a "solid" one for those where the upload doesnt provide one, 
any benefit of specifying at upload time is moot.

On 1/10/2011 10:34, Ponzu wrote:
> A common cause of z-buffer problems in SL is textures that do not 
> *need* an alpha channel that contain one anyway.  Lots of content in 
> SL is created by rank amateurs (me for example).
>
> What if the upload dialog had a check box?
>
> [ ] This texture should have an alpha channel.
>
> If the box is not checked, the alpha channel is removed.  If it is 
> checked, it is retained, unless it is not there, in which case the 
> user gets an error message.
>
> Just thinking out loud.
>
> ponzu
>
> On Sun, Jan 9, 2011 at 9:59 AM, Thickbrick Sleaford 
> mailto:thickbrick.sleaf...@gmail.com>> 
> wrote:
>
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/74/
>
>
> Review request for Viewer.
> By Thickbrick Sleaford.
>
>
>   Description
>
> Current code composites RGBA PNG images that contain a bKGD chunk down to 
> RGB, discarding the alpha channel. This patch removes that code, since it 
> contradicts purpose of the bKGD chunk as described in the PNG spec and as 
> commonly used.
>
>
>   Testing
>
> Tested uploading the 2 images attached to VWR-24420 with and without the 
> patch. Before patch, "bad alpha.png" was uploaded as RGB, after patch, both 
> images were uploaded as RGBA.
>
> *Bugs: * VWR-24420 
>
>
>   Diffs
>
> * doc/contributions.txt (UNKNOWN)
> * indra/llimage/llpngwrapper.h (UNKNOWN)
> * indra/llimage/llpngwrapper.cpp (UNKNOWN)
>
> View Diff 
>
>
> ___
> 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] storm-34

[Erin Mallory]

I knwo it should be... but its not! 

> Date: Mon, 10 Jan 2011 18:56:13 +0200
> Subject: Re: [opensource-dev] storm-34
> From: adyu...@productengine.com
> To: angel_of_crim...@hotmail.com
> CC: q...@lindenlab.com; opensource-dev@lists.secondlife.com
> 
> The preference is per-account, .i.e. you should turn it on separately
> for each user whose favorites you want to be shown in login screen. So
> to get favorites for both cummere and erinyse you should:
> 
> 1. log in with cummere mayo.  set the option to show the favorites.  log out.
> 2. start the viewer. log in with erinyse planer.  set the option to
> show the favorites.  log out.
> 
> On the next start of the viewer favorites will be available for both users.
> 
> 2011/1/10 Erin Mallory :
> > what happened to get the issue to occur for me.  I installed the storm-34
> > developer viewer.  logged in with cummere mayo.  set the option to show the
> > favorites.  logged out.   started the viewer.  it worked as expected. logged
> > out.  back in. still worked as expected.  logged out.
> > changed account to erinyse planer.   logged in.  logged back out.   started
> > viewer.   favorites were not there (as expected)  changed account back to
> > cummere mayo.  logged in.  made sure preference was still on.  (it was)
> > logged out. restarted the viewer: favorites no longer show up.
> >
> > have tried reseeting the preference while logged in multiple times.  didnt
> > fix it. have tried reinstalling the viewer.  worked great till i logged in
> > an account and didnt set the preferences.   NOTE: even enabling the
> > preference on the erinyse account and logging out then switching logging in
> > cummere mayo and logging off still doesnt allow it to work.  Im not sure if
> > soemthing is corrupting the prefences file or what...  which is why im
> > asking if others can repo this?
> >
  ___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

[opensource-dev] Review Request: Show TOS (and other login dialogs) if --login is specified

[Joshua Linden]

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

Review request for Viewer.


Summary
---

This simply removes the mUserInteraction logic from LLLoginInstance, which is 
not used other than in this behavior. Internal discussion indicates that the 
current behavior is undesirable and is not being relied upon by test 
automation, and in fact interferes with test automation.

Prior to this change, if the viewer is launched with:

SecondLife.exe --login FIRST LAST PASSWORD

... and if the login response is that a TOS, Critical Message, or Update must 
be acknowledged, the viewer simply returns to the credentials screen (login 
panel) but does not indicate why. 

After this change, the viewer will display the appropriate follow-on UI even if 
--login is used. If necessary, an additional option could be specified to 
inhibit showing these UI elements for test automation scenarios (e.g. 
auto-accepting or exiting the viewer, as appropriate).

(the bulk of the raw diff is whitespace changes due to re-indentation)


This addresses bug VWR-24401.
http://jira.secondlife.com/browse/VWR-24401


Diffs
-

  indra/newview/lllogininstance.h 78fae8ca1b36 
  indra/newview/lllogininstance.cpp 78fae8ca1b36 
  indra/newview/llstartup.cpp 78fae8ca1b36 

Diff: http://codereview.secondlife.com/r/76/diff


Testing
---

Launched viewer normally (with "normal" account), entered credentials, logged 
in successfully.
Launched viewer via --login (with "normal" account), logged in successfully.
Launched viewer via --login with account needing to accept TOS update; viewer 
displayed TOS dialog; accepted and logged in successfully.


Thanks,

Joshua

___
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: VWR-24420: PNG images which specify "background color" lose alpha layer when imported.

[Joshua Bell]

On Mon, Jan 10, 2011 at 8:34 AM, Ponzu  wrote:

> A common cause of z-buffer problems in SL is textures that do not *need* an
> alpha channel that contain one anyway.  Lots of content in SL is created by
> rank amateurs (me for example).
>
>
That seems like a good point, and might explain the existence of the code
(although I'm just responding to the thread here, not as a domain expert).


> What if the upload dialog had a check box?
>
> [ ] This texture should have an alpha channel.
>
> If the box is not checked, the alpha channel is removed.  If it is checked,
> it is retained, unless it is not there, in which case the user gets an error
> message.
>
>
Without digging more deeply into the issue, but putting on my UI design hat,
if it's necessary to ask the user I'd suggest the wording:

[x] Preserve transparency (alpha channel)

The wording "This texture should have an alpha channel" seems like it could
lead to users thinking "hey, sure, why not, sounds like a good idea" and
checking it.

If the image does not have an alpha channel, remove or disable the checkbox
from the UI.

Then there's the question of whether or not the box should be checked by
default or not. Ponzu's point is compelling that the current behavior is
implicitly desired by many content creators to avoid problems ("I uploaded a
new texture and it's rendering differently than the textures I uploaded last
week! SL sucks!"). Which would mean that this could default to unchecked
(i.e. current behavior) but be exposed for users who know what's going on
and would let them toggle it live with the preview.

(Again, just speculating here as well, I haven't dug into the code.)

-- Josh
___
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: VWR-24420: PNG images which specify "background color" lose alpha layer when imported.

[Zi Ree]

Am Montag 10 Januar 2011 17:34:08 schrieb Ponzu:

> What if the upload dialog had a check box?
> 
> [ ] This texture should have an alpha channel.

Would it be possible to do this on a per-face basis rather than on texture 
upload? So people could use the same texture as alpha texture and as non-alpha 
as well?

Edit Texture
[x] Use Alpha

Thinking out loud ...
Zi
___
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: VWR-24420: PNG images which specify "background color" lose alpha layer when imported.

[Joshua Bell]

On Mon, Jan 10, 2011 at 9:28 AM, Dave Booth  wrote:

> Thats a pretty good bit of thinking out loud there, Ponzu
>
> Personally I'd say thats a "clean" fix for this. However it all depends
> on how things are stored server-side - if the asset server code
> automatically assumes that every texture has an alpha channel and
> supplies a "solid" one for those where the upload doesnt provide one,
> any benefit of specifying at upload time is moot.


The asset upload/storage system handles 3, 4 or 5 channel JPEG2000 textures
and doesn't tinker with the channel data. The bulk of the textures in the
asset system are 3-channel (RGB).

(Excellent question, BTW.)
___
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-830 Volume slider isn't properly remembered if set to zero

[Kent Quirk]

> On Jan. 6, 2011, 5:37 p.m., Aleric Inglewood wrote:
> > This is really not how you want to deal with this bug :/.  It's a known 
> > fact that audio mixers are very bad with low volumes. Setting a volume to 0 
> > (or something really small) can put a very high load on the CPU for the 
> > audio mixer, which causes severe problems. See 
> > https://jira.secondlife.com/browse/VWR-14914
> > 
> > So, on the contrary (as VWR-14914 fixed a horrible bug that made FPS drop 
> > drastically): when the volume is set to 0 (or even close to zero) the audio 
> > channel has to be muted and not mixed, ever. Assuming that VWR-14914 is in 
> > Viewer 2, and wasn't broken in the meantime, a volume of 0 would cause the 
> > channel to be muted, but setting it to 0.01 will not cause it to be 
> > muted, but result in a high CPU load.
> >
> 
> Aleric Inglewood wrote:
> After discussion on IRC Jonathan explained to me what this is all about. 
> The patch is correct.
> Nevertheless, I was confused about the fact that this value of 0.01 
> is never going to be USED.
> Perhaps a different value and comment can avoid that in the future when 
> other coders look at it.
> mInternalGain is only ever compared with, and the whole point of this 
> patch is to make sure
> that the first comparison fails (I now understand). A common value used 
> to make sure that
> a first comparison fails is a value outside the valid range of that 
> variable. The valid
> range being [0, 1], I'd suggest using -1 and adding a comment in the 
> lines of:
> 
> // Make sure that the first call to setMasterGain will cause 
> setInternalGain to be called.
> mInternalGain = -1.f;
>

Aleric is correct, and if the approach is technically possible it would be 
preferred to use an out-of-range value. It appears to me that his suggested fix 
will work, but I haven't tried it myself. Jonathan, can you try it, please?


- Kent


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


On Jan. 6, 2011, 2:37 p.m., Jonathan Yap wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/72/
> ---
> 
> (Updated Jan. 6, 2011, 2:37 p.m.)
> 
> 
> Review request for Viewer.
> 
> 
> Summary
> ---
> 
> There is an edge case in setMasterGain during startup which prevents 
> setInternalGain from being called if the master volume setting and 
> mInternalGain both equal 0.
> 
> Setting mInternalGain to a very low but non-zero value fixes this issue.
> 
> 
> This addresses bug STORM-830.
> http://jira.secondlife.com/browse/STORM-830
> 
> 
> Diffs
> -
> 
>   indra/llaudio/llaudioengine.cpp 6d44f0d85a80 
> 
> Diff: http://codereview.secondlife.com/r/72/diff
> 
> 
> Testing
> ---
> 
> In Preferences / Sound & Media tested:
> Buttons
> Ambient
> Sound Effects
> Stream Music
> Media
> Voice Chat
> 
> 
> Thanks,
> 
> Jonathan
> 
>

___
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] 5 Channel JPEG2000

[Ricky]

Question: what, if anything, is the 5th channel currently used for?
Could it be used for normal maps if it is currently unused?

If so, then we could do this entirely clientside, assuming 5 channel
textures can be uploaded.  Of course there would still need to be a
way to disable the alpha channel during upload while preserving the
normal map channel.

Ricky
Cron Stardust

On Monday, January 10, 2011, Joshua Bell  wrote:
> On Mon, Jan 10, 2011 at 9:28 AM, Dave Booth  wrote:
>
> Thats a pretty good bit of thinking out loud there, Ponzu
>
> Personally I'd say thats a "clean" fix for this. However it all depends
> on how things are stored server-side - if the asset server code
> automatically assumes that every texture has an alpha channel and
> supplies a "solid" one for those where the upload doesnt provide one,
> any benefit of specifying at upload time is moot.
> The asset upload/storage system handles 3, 4 or 5 channel JPEG2000 textures 
> and doesn't tinker with the channel data. The bulk of the textures in the 
> asset system are 3-channel (RGB).
>
> (Excellent question, BTW.)
>
>
___
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] Daily Scrum Summary - Monday, January 10, 2011

[Anya Kanevsky]

 Monday, January 10, 2011 General Notes
--

   - Reminder to devs. If a ticket doesn't pass Review and is rejected, it
   will move back to the To Do column in GH, if you do more work or clarify
   questions, it should be moved back through In Progress and then to In
   Review.
   - MMOTD: Merov
   - PE was on holiday Friday.

Team Status
--
 Merov Linden
--

*PAST*

   - STORM-526 : Log out failure during Login causes loss of pending offers,
   including inventory : Look at that code, can't repro but pointed at
   potential issues, commented in JIRA
   - Cleaned-up sprint 9 stuff

*FUTURE*

   - sprint planning
   - STORM-745 : Produce comprehensive perf baseline: Complete that work.

*IMPEDIMENTS*

   - None

Oz Linden
--

*PAST*

   - Merge Monkey (up to 2.5.0-start tag), handed off to Merov
   - More looking at old VWR patches
   - Tracking down viewer dependencies
   - OH

*FUTURE*

   - Sprint planning
   - More VWR mining

*IMPEDIMENTS*

   - none

Q Linden
--

*PAST*

   - LL Planning meeting
   - STORM-34
   - STORM-777
   - SOCIAL-437 / VWR-24440
   - STORM-830
   - Blog post

*FUTURE*

   - STORM-830
   - Sprint planning
   - Triage

*IMPEDIMENTS*

   - none

Esbee Linden
--

*PAST*

   - HR stuff
   - Meetings, Email
   - Wrote Viewer 2.5 Beta 1 blog post
   - Played with Beta

*FUTURE*

   - Meetings
   - Sprint Planning
   - Rev Viewer 2.5 Beta 1 Blog post
   - Review Snowstorm Team product backlog and bug log
   - PO reviews for open tickets
   - Finish going through the list of VWRs assigned to PE (finally)
   - Plan update for system requirements
   - Look at VWR-18435 and VWR-24357 for Jonathan
   - Add instructions for STORM-236 for Wolfpup
   - Look at STORM-383, -797, -28, -447

*IMPEDIMENTS*

   - none

Paul ProductEngine
--

*PAST*

   - STORM-370 (Human-readable name of region disappears from Location Bar
   after pressing ESC)
  - Fixed and sent for review

*FUTURE*

   - STORM-387 (Part of the table is hidden after increasing firsts column
   width in the floater and then dock it to the SP)
   - STORM-554 (NL - text overlapping in Build tools)
   -
___
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] 5 Channel JPEG2000

[Joshua Bell]

On Mon, Jan 10, 2011 at 11:47 AM, Ricky  wrote:

> Question: what, if anything, is the 5th channel currently used for?
>

Bump maps in baked textures. IIRC, only the avatar pipeline
produces/consumes that channel. Also, IIRC, the logic is entirely
client-side at the moment.


> Could it be used for normal maps if it is currently unused?
> If so, then we could do this entirely clientside, assuming 5 channel
> textures can be uploaded.  Of course there would still need to be a
> way to disable the alpha channel during upload while preserving the
> normal map channel.
>

That would technically be possible. The asset system does do verification
and modification of various asset types on upload (including textures), but
- again, technically - this would probably work, possibly requiring some
minor changes to the asset verifier.

However...

The biggest challenge is the lack of support for multiple channels in
JPEG2000-producing/consuming tools. Many tools only work with 3-channel
images, and complain about 4. Combined with the lack of tools for authoring
JPEG2000 images in the first place, I'm not sure you'd want add another 3
channels to the image for the normal map. It would also mean you couldn't
re-use a normal map with two textures, e.g. to allow color variants on a
base mesh.

Avoiding two separate texture asset fetches (colors and normals) per face
might be a significant win, but I'd want to see the numbers to prove it
first.

(For comparison, the 13-channel RAW data used for uploading/downloading
region terrain and parcel data is pretty pesky to work with. Sure, it works
with PhotoShop, and is a technically simple single file backup format, but
putting all of that data into a single image is fragile that you expect
users to edit is not particularly user-friendly.)


> Ricky
> Cron Stardust
>
> On Monday, January 10, 2011, Joshua Bell  wrote:
> > On Mon, Jan 10, 2011 at 9:28 AM, Dave Booth 
> wrote:
> >
> > Thats a pretty good bit of thinking out loud there, Ponzu
> >
> > Personally I'd say thats a "clean" fix for this. However it all depends
> > on how things are stored server-side - if the asset server code
> > automatically assumes that every texture has an alpha channel and
> > supplies a "solid" one for those where the upload doesnt provide one,
> > any benefit of specifying at upload time is moot.
> > The asset upload/storage system handles 3, 4 or 5 channel JPEG2000
> textures and doesn't tinker with the channel data. The bulk of the textures
> in the asset system are 3-channel (RGB).
> >
> > (Excellent question, BTW.)
> >
> >
> ___
> 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-830 Volume slider isn't properly remembered if set to zero

[Jonathan Yap]

> On Jan. 6, 2011, 5:37 p.m., Aleric Inglewood wrote:
> > This is really not how you want to deal with this bug :/.  It's a known 
> > fact that audio mixers are very bad with low volumes. Setting a volume to 0 
> > (or something really small) can put a very high load on the CPU for the 
> > audio mixer, which causes severe problems. See 
> > https://jira.secondlife.com/browse/VWR-14914
> > 
> > So, on the contrary (as VWR-14914 fixed a horrible bug that made FPS drop 
> > drastically): when the volume is set to 0 (or even close to zero) the audio 
> > channel has to be muted and not mixed, ever. Assuming that VWR-14914 is in 
> > Viewer 2, and wasn't broken in the meantime, a volume of 0 would cause the 
> > channel to be muted, but setting it to 0.01 will not cause it to be 
> > muted, but result in a high CPU load.
> >
> 
> Aleric Inglewood wrote:
> After discussion on IRC Jonathan explained to me what this is all about. 
> The patch is correct.
> Nevertheless, I was confused about the fact that this value of 0.01 
> is never going to be USED.
> Perhaps a different value and comment can avoid that in the future when 
> other coders look at it.
> mInternalGain is only ever compared with, and the whole point of this 
> patch is to make sure
> that the first comparison fails (I now understand). A common value used 
> to make sure that
> a first comparison fails is a value outside the valid range of that 
> variable. The valid
> range being [0, 1], I'd suggest using -1 and adding a comment in the 
> lines of:
> 
> // Make sure that the first call to setMasterGain will cause 
> setInternalGain to be called.
> mInternalGain = -1.f;
>
> 
> Kent Quirk wrote:
> Aleric is correct, and if the approach is technically possible it would 
> be preferred to use an out-of-range value. It appears to me that his 
> suggested fix will work, but I haven't tried it myself. Jonathan, can you try 
> it, please?
>

I changed the initial value of mInternalGain to -1, did a quick test with key 
clicks, and saw that that fixes the problem, too.


- Jonathan


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


On Jan. 6, 2011, 2:37 p.m., Jonathan Yap wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/72/
> ---
> 
> (Updated Jan. 6, 2011, 2:37 p.m.)
> 
> 
> Review request for Viewer.
> 
> 
> Summary
> ---
> 
> There is an edge case in setMasterGain during startup which prevents 
> setInternalGain from being called if the master volume setting and 
> mInternalGain both equal 0.
> 
> Setting mInternalGain to a very low but non-zero value fixes this issue.
> 
> 
> This addresses bug STORM-830.
> http://jira.secondlife.com/browse/STORM-830
> 
> 
> Diffs
> -
> 
>   indra/llaudio/llaudioengine.cpp 6d44f0d85a80 
> 
> Diff: http://codereview.secondlife.com/r/72/diff
> 
> 
> Testing
> ---
> 
> In Preferences / Sound & Media tested:
> Buttons
> Ambient
> Sound Effects
> Stream Music
> Media
> Voice Chat
> 
> 
> Thanks,
> 
> Jonathan
> 
>

___
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-830 Volume slider isn't properly remembered if set to zero

[Kent Quirk]

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

Ship it!


Looks good now.

- Kent


On Jan. 6, 2011, 2:37 p.m., Jonathan Yap wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/72/
> ---
> 
> (Updated Jan. 6, 2011, 2:37 p.m.)
> 
> 
> Review request for Viewer.
> 
> 
> Summary
> ---
> 
> There is an edge case in setMasterGain during startup which prevents 
> setInternalGain from being called if the master volume setting and 
> mInternalGain both equal 0.
> 
> Setting mInternalGain to a very low but non-zero value fixes this issue.
> 
> 
> This addresses bug STORM-830.
> http://jira.secondlife.com/browse/STORM-830
> 
> 
> Diffs
> -
> 
>   indra/llaudio/llaudioengine.cpp 6d44f0d85a80 
> 
> Diff: http://codereview.secondlife.com/r/72/diff
> 
> 
> Testing
> ---
> 
> In Preferences / Sound & Media tested:
> Buttons
> Ambient
> Sound Effects
> Stream Music
> Media
> Voice Chat
> 
> 
> Thanks,
> 
> Jonathan
> 
>

___
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: Update returnability of objects based on new encroachment rules

[Merov Linden]

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

(Updated Jan. 10, 2011, 3:36 p.m.)


Review request for Viewer and Andrew Meadows.


Changes
---

Latest diff from most recent andrew_linden repo


Summary
---

The object-vs-parcel overlap test is done by building axis-aligned bounding 
boxes (AABB) about each prim of the selected objects and then checking for 
overlap between those boxes and self- and group-owned parcels. 


This addresses bug STORM-807.
http://jira.secondlife.com/browse/STORM-807


Diffs (updated)
-

  indra/llmath/llbbox.h bceb13778d1d 
  indra/llmath/llbbox.cpp bceb13778d1d 
  indra/llmessage/llregionflags.h bceb13778d1d 
  indra/newview/llviewermenu.cpp bceb13778d1d 
  indra/newview/llviewerobject.h bceb13778d1d 
  indra/newview/llviewerobject.cpp bceb13778d1d 
  indra/newview/llviewerparceloverlay.h bceb13778d1d 
  indra/newview/llviewerparceloverlay.cpp bceb13778d1d 
  indra/newview/llviewerregion.h bceb13778d1d 
  indra/newview/llviewerregion.cpp bceb13778d1d 
  indra/newview/llvoavatar.cpp bceb13778d1d 
  indra/newview/skins/default/xui/en/menu_viewer.xml bceb13778d1d 

Diff: http://codereview.secondlife.com/r/56/diff


Testing
---


Thanks,

Merov

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

Re: [opensource-dev] Review Request: Update returnability of objects based on new encroachment rules

[Merov Linden]

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

Ship it!


Good! Only minor typos and code style issues (see review details). About lines 
commented out, please prefer deletion unless there's a good reason for it which 
then should be mentioned in comments.


indra/llmath/llbbox.cpp


Typo : change "rotiation" to "rotation"



indra/llmessage/llregionflags.h


Suppress legacy code, don't leave it commented out



indra/llmessage/llregionflags.h


Suppress old code, don't leave it commented out



indra/llmessage/llregionflags.h


Please suppress (though it was already commented out...)



indra/llmessage/llregionflags.h


Suppress etc...



indra/llmessage/llregionflags.h


Suppress etc...



indra/newview/llviewerobject.h


Typo: one "it" too many



indra/newview/llviewerparceloverlay.cpp


Code style:
- use "{ }" for each for nested loop and each if statement
- use "()" in "||" statement


- Merov


On Jan. 10, 2011, 3:36 p.m., Merov Linden wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/56/
> ---
> 
> (Updated Jan. 10, 2011, 3:36 p.m.)
> 
> 
> Review request for Viewer and Andrew Meadows.
> 
> 
> Summary
> ---
> 
> The object-vs-parcel overlap test is done by building axis-aligned bounding 
> boxes (AABB) about each prim of the selected objects and then checking for 
> overlap between those boxes and self- and group-owned parcels. 
> 
> 
> This addresses bug STORM-807.
> http://jira.secondlife.com/browse/STORM-807
> 
> 
> Diffs
> -
> 
>   indra/llmath/llbbox.h bceb13778d1d 
>   indra/llmath/llbbox.cpp bceb13778d1d 
>   indra/llmessage/llregionflags.h bceb13778d1d 
>   indra/newview/llviewermenu.cpp bceb13778d1d 
>   indra/newview/llviewerobject.h bceb13778d1d 
>   indra/newview/llviewerobject.cpp bceb13778d1d 
>   indra/newview/llviewerparceloverlay.h bceb13778d1d 
>   indra/newview/llviewerparceloverlay.cpp bceb13778d1d 
>   indra/newview/llviewerregion.h bceb13778d1d 
>   indra/newview/llviewerregion.cpp bceb13778d1d 
>   indra/newview/llvoavatar.cpp bceb13778d1d 
>   indra/newview/skins/default/xui/en/menu_viewer.xml bceb13778d1d 
> 
> Diff: http://codereview.secondlife.com/r/56/diff
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Merov
> 
>

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