Re: [opensource-dev] 1-bit alpha textures

[Stickman]

On Sat, Sep 11, 2010 at 9:04 PM, Frans  wrote:
> I assume you are talking about Avatar Alpha Masks. It's in the viewer 2+,
> and 1.23 has backwards compatibility. It is for avatars, so you can make
> (parts of) the avatar invisible.
>
> http://www.youtube.com/watch?v=O8UDHD2S_-I

I was referring to what's mentioned in this Jira, actually:
http://jira.secondlife.com/browse/VWR-6713

I'm not seeing any promises in the comments, but I could have sworn it
was supposed to be in viewer 2 somewhere. Anyone have information
about what was planned for it that isn't in the Jira?

Stickman
___
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] 1-bit alpha textures

[leliel]

On Sun, Sep 12, 2010 at 1:13 AM, Stickman  wrote:
> I was referring to what's mentioned in this Jira, actually:
> http://jira.secondlife.com/browse/VWR-6713

That issue is unresolved.

> I'm not seeing any promises in the comments, but I could have sworn it
> was supposed to be in viewer 2 somewhere. Anyone have information
> about what was planned for it that isn't in the Jira?

The viewer has had an option for many years now to force all alpha
channels down to 1 bit. This fixes most all the alpha sorting problems
but it also breaks content (mostly hair and particles).

Viewer 1 Advanced -> Render -> Fast Alpha
Viewer 2-2.1 Develop -> Render -> Fast Alpha
Snowglobe 2.1 & viewer-development -> Develop -> Render -> Automatic
Alpha Masking (with separate options for deferred and non deferred)
___
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] Retaining Newbies (Was: The Plan for Snowglobe)

[Boroondas Gupte]

 On 09/11/2010 08:11 PM, Tateru Nino wrote:
>   Well, as far as this mailing list goes, it should largely be kept to 
> viewer features/changes/improvements. Anything that happens beyond the 
> viewer is kind of out-of-scope.
I think the discussion would be very on-topic on the sl-ux mailing list
, so why
not move it there?

cheers,
Boroondas
___
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] Severe water flicker in recent development build

[Oz Linden (Scott Lawrence)]

  I'm seeing what I believe is the same problem described in SNOW-745 in 
our current development viewer.
Second Life 2.1.2 (209297)

I added some detail to the issue description.

It's very irritating.   I think we need to do something about it (might 
we be able to force Atmospheric Shaders to 'on'?  That appears to 
suppress the problem).

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

Re: [opensource-dev] Severe water flicker in recent development build

[Lance Corrimal]

Am Sonntag 12 September 2010 schrieb Oz Linden (Scott Lawrence):
>   I'm seeing what I believe is the same problem described in
> SNOW-745 in our current development viewer.
> Second Life 2.1.2 (209297)
> 
> I added some detail to the issue description.
> 
> It's very irritating.   I think we need to do something about it
> (might we be able to force Atmospheric Shaders to 'on'?  That
> appears to suppress the problem).
>


I think that might be a bad idea... as already discussed here, 90% of 
new residents leave right away because their hardware is just not up 
to it. Forcing athmospheric shaders would raise the bar even higher.


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] 1-bit alpha textures

[Sythos]

On Sun, 12 Sep 2010 02:07:25 -0700
leliel  wrote:

> On Sun, Sep 12, 2010 at 1:13 AM, Stickman  wrote:
> > I was referring to what's mentioned in this Jira, actually:
> > http://jira.secondlife.com/browse/VWR-6713
> 
> That issue is unresolved.
> 
> > I'm not seeing any promises in the comments, but I could have sworn
> > it was supposed to be in viewer 2 somewhere. Anyone have information
> > about what was planned for it that isn't in the Jira?
> 
> The viewer has had an option for many years now to force all alpha
> channels down to 1 bit. This fixes most all the alpha sorting problems
> but it also breaks content (mostly hair and particles).
> 
> Viewer 1 Advanced -> Render -> Fast Alpha
> Viewer 2-2.1 Develop -> Render -> Fast Alpha
> Snowglobe 2.1 & viewer-development -> Develop -> Render -> Automatic
> Alpha Masking (with separate options for deferred and non deferred)

it work fine, enabling both alpha masking i cannot find others issue
with tree, hair or glasses. Dunno how viewer enable it (enabling both i
loss 3-4% of FPS), i usually use "high" and sometime "ultra" (for take
photos), *imho* this issue may be marked fixed since alpha masking (def
and no-def) avaiable
___
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] Severe water flicker in recent development build

[Sythos]

On Sun, 12 Sep 2010 09:22:22 -0400
"Oz Linden (Scott Lawrence)"  wrote:

>   I'm seeing what I believe is the same problem described in SNOW-745

SNOW-745 is about timestamp/chat log... are you sure about numbers? (or
maybe is new jira too weird for me)
___
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] Severe water flicker in recent development build

[Bunny Halberd]

On Sun, Sep 12, 2010 at 8:22 AM, Oz Linden (Scott Lawrence)
 wrote:

> It's very irritating.   I think we need to do something about it (might
> we be able to force Atmospheric Shaders to 'on'?  That appears to
> suppress the problem).

Horrible idea -- turning those off is one of your first lines of
defense when "SL is so laggy I can't type".

- Bunny
___
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] Severe water flicker in recent development build

[Boroondas Gupte]

 On 09/12/2010 03:22 PM, Oz Linden (Scott Lawrence) wrote:
>   I'm seeing what I believe is the same problem described in SNOW-745 in 
> our current development viewer.
> Second Life 2.1.2 (209297)
You probably mean SNOW-7*54* .
> I added some detail to the issue description.
>
> It's very irritating.   I think we need to do something about it
Indeed. Would be helpful if someone can track down the changeset that
introduced this error (e.g. with hg bisect), so we can see what exactly
changed there. Would probably take quite some build cycles, though.
> (might 
> we be able to force Atmospheric Shaders to 'on'?  That appears to 
> suppress the problem).
Not a good idea. This used to work correctly, so there must be another fix.

Cheers,
Boroondas
___
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] Severe water flicker in recent development build

[Sythos]

On Sun, 12 Sep 2010 09:03:35 -0500
Bunny Halberd  wrote:

> On Sun, Sep 12, 2010 at 8:22 AM, Oz Linden (Scott Lawrence)
>  wrote:
> 
> > It's very irritating.   I think we need to do something about it
> > (might we be able to force Atmospheric Shaders to 'on'?  That
> > appears to suppress the problem).
> 
> Horrible idea -- turning those off is one of your first lines of
> defense when "SL is so laggy I can't type".

i think there is somethng to fix in "system requirements" on
secondlife.com, actual viewer run on a pc matched on minimal
requirement with 4-6fps with "low" graphic detail and no other tweaks
on advanced menu neither 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

Re: [opensource-dev] Severe water flicker in recent development build

[Tillie Ariantho]

On 12.09.2010 15:29, Lance Corrimal wrote:

>> It's very irritating.   I think we need to do something about it
>> (might we be able to force Atmospheric Shaders to 'on'?  That
>> appears to suppress the problem).

> I think that might be a bad idea... as already discussed here, 90% of 
> new residents leave right away because their hardware is just not up 
> to it. Forcing athmospheric shaders would raise the bar even higher.

Are there any statistics out there about what kind of hardware people have?

Tillie
___
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] Severe water flicker in recent development build

[Sythos]

On Sun, 12 Sep 2010 16:24:17 +0200
Tillie Ariantho  wrote:

> > I think that might be a bad idea... as already discussed here, 90%
> > of new residents leave right away because their hardware is just
> > not up to it. Forcing athmospheric shaders would raise the bar even
> > higher.
> 
> Are there any statistics out there about what kind of hardware people
> have?

if i'm right latest viewers by LL have some data collector (KDU sure,
seen on changelogs, dunno if other), may be interesting if some other
data collection (anonymous) can be collected (and ask to other viewers
teams to do same, always anonymous), checking to be unique (using uP
serial number as ID for database?)
___
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] Retaining Newbies (Was: The Plan for Snowglobe)

[Sythos]

On Sat, 11 Sep 2010 11:26:27 -0500
Bunny Halberd  wrote:


> 1.) My computer can't handle it. (This is, by far, the #1 reason
> people leave SL after trying it, I'm convinced. Maybe as high as 90%!)

this point have no viewer side solutions :)

> I think a lot of headway could be made if the open source community
> and LL worked together to do two things:
> 
>  - Give newbies a fighting chance with a viewer that degrades
> gracefully.
>  - Provide an easy pathway for newbies to find groups like ours as
> soon as they're first rezzed in. Give them something to do as soon as
> they rezz in. Show them how wonderful the SL *PEOPLE* are, not some
> cold, sterile orientation program.

i wish add an old "solution": menthors

now all viewer can detect language used by resident before he/she
login, in place of a unique help-island may be more interesting create
one each language and ask to old menthors to hangout here

all this isn't related to code, maybe elsewhere will be a better place
where discuss deeper about this topic
___
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] [POLICY] Banning TPV not on the TPV list

[Sythos]

On Fri, 10 Sep 2010 10:50:01 -0400
"Oz Linden (Scott Lawrence)"  wrote:


> >> >  You said "imho*ALL*  non TPV listed viewers should be
> >> > blacklisted"
> 
> All viewers must comply with the Third Party Viewer Policy.
> 
> Viewers in the directory are ones that have certified that they are 
> compliant - viewers not in the directory may or may not be compliant, 
> but it's up to the user to determine that.
> 
> Using a non-compliant viewer or distributing one are both ToS
> violations.
> 
> None of this is really an opensource-dev topic, however.


i think is related to opensource too, a lot of "developers" don't know
the differences between an opensource viewer and a businness ToS, by
the way some "Linden" are here a lot of people believe server's
services provided by LL are "open" too. A missing information (or
missing people skill to RTFM and read ToS) can cause only damage to
OpenSource project like this.

People *MUST* understand this is an opensource project, sponsored by LL
but LLìs services (like the grid) are another pair of shoes.

A lot of developers here (or outside here) don't understand tossing a
patch here isn't "gift code to LL" but is "gift code to
community" (real meaning of opensource). 

My experiences in opensource projects sponsored by company with a own
businness is quite low, i've only worked on Familiar Linux 11-12years
ago (sponsored by COMPAQ, before COMPAQ sold handhelds division to HP).
Developement model and flow was simple but it work (not so far from
this one used here, just a bit more documented). I wish share it here,
maybe may be usefull to tuneup.

Is like a pyramid, on lower slice everybody with rights enabled 
can throw patches, rules to accept patches in this step are easy:
- no warning neither error
- other code don't be broken by a patch (if add feature A, and A work
but broke feature B isn't good)
- base guidelines matching (no features with negative behaviour, viewer
example may be copybot features)

Step after some skilled/old developers review each patch, and fit them
in a controlled way to check aftermath on global code, this step
generate a daily build for a initial check or compiled cource, where
few tester can diagnose what don't work and why) only after a
opensource QA check the patch if match sponsor/hoster requirements
[alpha stage]

If it compile, if no bad aftermath, if no other code reason, the patch
is checked by sponsor/hoster QA, if ok the patch will be slided on "beta
stage", where a wider spread of tester (less skilled, just to detect if
something don't work, with the requirement to diagnose why not work) to
let release run on a wider kind of operating system and hardware


last step before "Release" is like a "release candidate", where all
people, developers, tester and other test the code on a broad-spectrum
variety of OS, hardware, entwork conditions, field applications (busy
sim, lag).

if to last step all work patch drop in release code, witha  very low
requirement of handwork requirement by sponsor/hoster (in THIS case, LL
businness is provide grid and services, not do babysitting to
opensource viewer ;) )

and, obviously... a bug will be discovered after 2 minth of running
code as "release"

if now the workflow already is this ia sk excuse... but maybe better if
somebody add mroe details on wiki/else why not so clear and i believe a
lot of coder/developers/other_viewer_teams don't know/understand how
use all these tools provided with this project to create a better
viewer... especially top steps aren't clear...


___
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] Severe water flicker in recent development build

[WolfPup Lowenhar]

Yes SNOW-754 is the right issue as I was the one that reported it and that
had appeared after a fix for higher altitude water flickering was put into
the code for SG. Also thinking about having Atmospheric Shaders defaulted to
on would severally affect those that are on older systems like my roommate
that are already running at very low FPS now. 

 

From: opensource-dev-boun...@lists.secondlife.com
[mailto:opensource-dev-boun...@lists.secondlife.com] On Behalf Of Boroondas
Gupte
Sent: Sunday, September 12, 2010 10:08 AM
To: opensource-dev@lists.secondlife.com
Subject: Re: [opensource-dev] Severe water flicker in recent development
build

 

On 09/12/2010 03:22 PM, Oz Linden (Scott Lawrence) wrote: 

  I'm seeing what I believe is the same problem described in SNOW-745 in 
our current development viewer.
Second Life 2.1.2 (209297)

You probably mean SNOW-7  54.



 
I added some detail to the issue description.
 
It's very irritating.   I think we need to do something about it

Indeed. Would be helpful if someone can track down the changeset that
introduced this error (e.g. with hg bisect), so we can see what exactly
changed there. Would probably take quite some build cycles, though.



(might 
we be able to force Atmospheric Shaders to 'on'?  That appears to 
suppress the problem).

Not a good idea. This used to work correctly, so there must be another fix.

Cheers,
Boroondas

No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 9.0.851 / Virus Database: 271.1.1/3130 - Release Date: 09/12/10
02:34:00

___
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] Retaining Newbies (Was: The Plan for Snowglobe)

[Lance Corrimal]

Am Sonntag 12 September 2010 schrieb Altair "Sythos" Memo:
> > 1.) My computer can't handle it. (This is, by far, the #1 reason
> > people leave SL after trying it, I'm convinced. Maybe as high as
> > 90%!)
> 
> this point have no viewer side solutions :)


actually it has... "do not add more shinies that raise the hardware 
requirements even higher"...

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] Severe water flicker in recent development build

[Ponzu]

Several years ago, some Linden posted a table that showed the typical
range of FPS for various graphics cards. At the time I thought that
was a very interesting piece of data, and am sad to have never seen it
again (maybe I missed it).

For one thing, you could look at *your* graphic card, and if you were
typical, you could stop whining about low fps.  It could likewise be
helpful for shoppers.

I see fps messages in the logs.  Why not capture those and keep the
data online somewhere.

regards,
lee
___
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] Retaining Newbies (Was: The Plan for Snowglobe)

[leliel]

On Sun, Sep 12, 2010 at 9:01 AM, Lance Corrimal
 wrote:
> Am Sonntag 12 September 2010 schrieb Altair "Sythos" Memo:
>> > 1.) My computer can't handle it. (This is, by far, the #1 reason
>> > people leave SL after trying it, I'm convinced. Maybe as high as
>> > 90%!)
>>
>> this point have no viewer side solutions :)
>
>
> actually it has... "do not add more shinies that raise the hardware
> requirements even higher"...

Most of these people have machines that don't even support the shinies
so that what does it matter if we add them? And adding support for
shinies such as volumetric lighting would get rid of those ugly semi
transparent cones around lights and speed things up for people on low
end machines that have it disabled. See, it's a win win situation, I
get my shinies and they get better performace.
___
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] Retaining Newbies (Was: The Plan for Snowglobe)

[Patnad Babii]

If LL plan to get more people in, they better lower those requirement, make 
a low-definition viewer if it can't be done in the current one. Give them 
minimal tools so they can still connect and enjoy second life. It's true 
that SL doesn't work everywhere, but the web does. This is in most part why 
the web is STILL so popular.

If the 3D web want to get more people interested it have to lower that entry 
bar, people really take a while to upgrade their hardware.

Lots of people having still 5-10 years old computer and we need to get these 
people in too.

Just my taught but im no specialist.

-Message d'origine- 
From: Lance Corrimal
Sent: Sunday, September 12, 2010 12:01 PM
To: opensource-dev@lists.secondlife.com
Subject: Re: [opensource-dev] Retaining Newbies (Was: The Plan for 
Snowglobe)

Am Sonntag 12 September 2010 schrieb Altair "Sythos" Memo:
> > 1.) My computer can't handle it. (This is, by far, the #1 reason
> > people leave SL after trying it, I'm convinced. Maybe as high as
> > 90%!)
>
> this point have no viewer side solutions :)


actually it has... "do not add more shinies that raise the hardware
requirements even higher"...

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] Severe water flicker in recent development build

[Celierra Darling]

On Sun, Sep 12, 2010 at 12:01 PM, Ponzu  wrote:

> Several years ago, some Linden posted a table that showed the typical
> range of FPS for various graphics cards. At the time I thought that
> was a very interesting piece of data, and am sad to have never seen it
> again (maybe I missed it).
>

The chart is still up, but I don't think it's been updated very recently...
http://wiki.secondlife.com/wiki/Typical_Frame_Rate_Performance_by_Graphics_Card/GPU


Celi
___
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] Severe water flicker in recent development build

[Tateru Nino]

On 13/09/2010 3:18 AM, Celierra Darling wrote:
On Sun, Sep 12, 2010 at 12:01 PM, Ponzu > wrote:


Several years ago, some Linden posted a table that showed the typical
range of FPS for various graphics cards. At the time I thought that
was a very interesting piece of data, and am sad to have never seen it
again (maybe I missed it).

The chart is still up, but I don't think it's been updated very 
recently...

http://wiki.secondlife.com/wiki/Typical_Frame_Rate_Performance_by_Graphics_Card/GPU

Another aspect to the numbers there is that (quite often) users will 
crank up visual features until frame-rates become just short of 
intolerable or unusable. That tends to make the results trend downwards. 
They *could* be higher for the same hardware, but many of us will crank 
up our quality and distance settings until the viewer is on the edge of 
shuddering -- and increase our crash-rates in the process.


--
Tateru Nino
http://dwellonit.taterunino.net/

___
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] Severe water flicker in recent development build

[Yoz Grahame]

Might be worth running this past Team Shining, especially since they've
worked on some major speed improvements to water recently. No idea how close
they are to merging.

On 12 September 2010 06:22, Oz Linden (Scott Lawrence) 
wrote:

>  I'm seeing what I believe is the same problem described in SNOW-745 in
> our current development viewer.
> Second Life 2.1.2 (209297)
>
> I added some detail to the issue description.
>
> It's very irritating.   I think we need to do something about it (might
> we be able to force Atmospheric Shaders to 'on'?  That appears to
> suppress the problem).
>
> ___
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/OpenSource-Dev
> Please read the policies before posting to keep unmoderated posting
> privileges
>
___
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] Severe water flicker in recent development build

[Lance Corrimal]

Am Sonntag 12 September 2010 schrieb Celierra Darling:
> On Sun, Sep 12, 2010 at 12:01 PM, Ponzu  wrote:
> > Several years ago, some Linden posted a table that showed the
> > typical range of FPS for various graphics cards. At the time I
> > thought that was a very interesting piece of data, and am sad to
> > have never seen it again (maybe I missed it).
> 
> The chart is still up, but I don't think it's been updated very
> recently...


no kidding, the biggest nvidia card in there is a geforce 8800.
they stopped making these a few years ago.

anyways, I run SL on a geforce 9400 M and i usually get around 15-20 
FPS on "recommended settings".
on the same computer I get roughly 60-70 FPS in unreal tournament 2004 
with all settings maxed out and it looks tremendously better.

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] Severe water flicker in recent development build

[Joel Foner]

I hope... ??? ... that someone doing rendering dev has a typical netbook
class computer to try things on, and actually does it and checks performance
variations from build to build on a few classes of hardware... That would
point the performance issues out quite directly, and cost a mere US $350
each to have on hand.

Netbooks represent common low end machines that are very popular. While I
also have high end hardware, I often run about with a netbook, and have yet
to see it above 8 FPS on any build at any time. Some might be tempted to say
"oh, that's an absurd machine that we're not targeting", however as evidence
I would point to the blog post I did a while back on performance
optimization for low end machines
http://joelfoner.com/2009/12/8-ways-to-make-low-perf-computer-second-life-faster/.
At this point that post has now been retweeted 71 times, is over 5000 unique
page views, and generated lots of email comments that their netbook/cheap
machine from best buy/etc is finally marginally useful with Second Life.

Increasing the base graphics hardware requirements will likely kill off both
netbooks and the class of machines just above it, which is not in my view a
good move.

Hope this helps,

Joel

On Sun, Sep 12, 2010 at 1:43 PM, Yoz Grahame  wrote:

> Might be worth running this past Team Shining, especially since they've
> worked on some major speed improvements to water recently. No idea how close
> they are to merging.
>
>
> On 12 September 2010 06:22, Oz Linden (Scott Lawrence) 
> wrote:
>
>>  I'm seeing what I believe is the same problem described in SNOW-745 in
>> our current development viewer.
>> Second Life 2.1.2 (209297)
>>
>> I added some detail to the issue description.
>>
>> It's very irritating.   I think we need to do something about it (might
>> we be able to force Atmospheric Shaders to 'on'?  That appears to
>> suppress the problem).
>>
>> ___
>> Policies and (un)subscribe information available here:
>> http://wiki.secondlife.com/wiki/OpenSource-Dev
>> Please read the policies before posting to keep unmoderated posting
>> privileges
>>
>
>
> ___
> 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] Severe water flicker in recent development build

[Joel Foner]

Another thought to toss in is that Second Life is fairly CPU dependent for
performance too. Just last night, I upgraded a machine here from an AMD
Athlon 8650 2.6 GHz triple core processor to an AMD Phenom II X4 965 3.4 GHz
quad core. This system has an NVidia 9800GT-based card in it, and that
stayed.

FPS went from 45 FPS to 75-80+ FPS in a scene that I know well. Same
machine. Same graphics card. Same net connection.

Yes, the graphics card matters, but what this says to me is that performance
benchmarking by putting a low performance graphics card in a high
performance machine is invalid, as the results will be significantly better
than experienced in the wild with a low end machine.

Hope this helps,

Joel

On Sun, Sep 12, 2010 at 1:43 PM, Yoz Grahame  wrote:

> Might be worth running this past Team Shining, especially since they've
> worked on some major speed improvements to water recently. No idea how close
> they are to merging.
>
>
> On 12 September 2010 06:22, Oz Linden (Scott Lawrence) 
> wrote:
>
>>  I'm seeing what I believe is the same problem described in SNOW-745 in
>> our current development viewer.
>> Second Life 2.1.2 (209297)
>>
>> I added some detail to the issue description.
>>
>> It's very irritating.   I think we need to do something about it (might
>> we be able to force Atmospheric Shaders to 'on'?  That appears to
>> suppress the problem).
>>
>> ___
>> Policies and (un)subscribe information available here:
>> http://wiki.secondlife.com/wiki/OpenSource-Dev
>> Please read the policies before posting to keep unmoderated posting
>> privileges
>>
>
>
> ___
> 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] Severe water flicker in recent development build

[Zha Ewry]

This reeks of something we could seriously crowdsource. How hard would it be
to pick a base region, a base set of settings (Draw distance etc) and have
100 or 200 of us
take turns getting a simple benchmark? set a bar for network (use speakeasy
to measure to a constant place, for example) and as people to boot, run the
client to attach to the
regoin, take a number of measurements and post them to a table in a wiki
page. I am betting we'd learn a lot in a hurry.

~ Zha


On Sun, Sep 12, 2010 at 2:14 PM, Joel Foner  wrote:

> Another thought to toss in is that Second Life is fairly CPU dependent for
> performance too. Just last night, I upgraded a machine here from an AMD
> Athlon 8650 2.6 GHz triple core processor to an AMD Phenom II X4 965 3.4 GHz
> quad core. This system has an NVidia 9800GT-based card in it, and that
> stayed.
>
> FPS went from 45 FPS to 75-80+ FPS in a scene that I know well. Same
> machine. Same graphics card. Same net connection.
>
> Yes, the graphics card matters, but what this says to me is that
> performance benchmarking by putting a low performance graphics card in a
> high performance machine is invalid, as the results will be significantly
> better than experienced in the wild with a low end machine.
>
> Hope this helps,
>
> Joel
>
> On Sun, Sep 12, 2010 at 1:43 PM, Yoz Grahame  wrote:
>
>> Might be worth running this past Team Shining, especially since they've
>> worked on some major speed improvements to water recently. No idea how close
>> they are to merging.
>>
>>
>> On 12 September 2010 06:22, Oz Linden (Scott Lawrence) 
>> wrote:
>>
>>>  I'm seeing what I believe is the same problem described in SNOW-745 in
>>> our current development viewer.
>>> Second Life 2.1.2 (209297)
>>>
>>> I added some detail to the issue description.
>>>
>>> It's very irritating.   I think we need to do something about it (might
>>> we be able to force Atmospheric Shaders to 'on'?  That appears to
>>> suppress the problem).
>>>
>>> ___
>>> Policies and (un)subscribe information available here:
>>> http://wiki.secondlife.com/wiki/OpenSource-Dev
>>> Please read the policies before posting to keep unmoderated posting
>>> privileges
>>>
>>
>>
>> ___
>> 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] Severe water flicker in recent development build

[Daniel Smith]

On Sun, Sep 12, 2010 at 11:29 AM, Zha Ewry  wrote:

> This reeks of something we could seriously crowdsource. How hard would it
> be to pick a base region, a base set of settings (Draw distance etc) and
> have 100 or 200 of us
> take turns getting a simple benchmark? set a bar for network (use speakeasy
> to measure to a constant place, for example) and as people to boot, run the
> client to attach to the
> regoin, take a number of measurements and post them to a table in a wiki
> page. I am betting we'd learn a lot in a hurry.
>
> ~ Zha
>
>
>
>
> Excellent idea.  The other thing I am wondering these days is:  how come
the Unity3d engine is getting much more
impressive graphics, at high frames, with very complex scenes, compared to
SL?  I wish there were a simple
way to do an apples to apples comparison of the same scene in SL vs
Unity3d.  On my 4 year old Intel iMac,
the difference is absolutely striking.

It's not just the hardware.  There's something in the SL graphics pipeline
that is a big issue.


-- 
Daniel Smith - Sonoma County, California
http://daniel.org/resume
___
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] Severe water flicker in recent development build

[Ann Otoole]

I am not in the fan club of miring Second Life in the past. Another reason 
people don't stay is because all the current video games look so much better. 


However that has nothing to do with something working right on one build and 
then not working right on the next build and then trying to hide the defective 
coding by forcing settings to a higher level. I'm a little taken aback that 
such 
a tactic would be suggested. Why can't someone, specifically whoever made the 
changes, do a diff and look at the changes and come to a comprehension of 
exactly why this behavior commenced? 



(Why when I was a group development manager at the evil empire we had to walk a 
mile in the snow to fetch a pail of electricity to run the build system with 
and nm)



From: Oz Linden (Scott Lawrence) 
To: Esbee Linden (Sarah Hutchinson) ; opensource-dev 

Sent: Sun, September 12, 2010 9:22:22 AM
Subject: [opensource-dev] Severe water flicker in recent development build

  I'm seeing what I believe is the same problem described in SNOW-745 in 
our current development viewer.
Second Life 2.1.2 (209297)

I added some detail to the issue description.

It's very irritating.   I think we need to do something about it (might 
we be able to force Atmospheric Shaders to 'on'?  That appears to 
suppress the problem).

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



  ___
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] Severe water flicker in recent development build

[Zabb65]

It generally isn't fair to compare other engines results with that of
second life, and I don't think it ever will be fair to compare
results, or how it looks.

The fundamental differences are too large. Most graphics engines deal
with optimized static geometry that has specially designed textures
that can be mapped onto them in clever ways, and an optimized
pre-computed tree is formed to occlusion, so that you can obtain very
high framerates and good looking results, even from very very modest
hardware. This however is not the case with second life, where there
is NO static geometry that can be optimized or merged, the textures
cannot be applied in clever ways or mapped efficiently, and those
using them generally do not know how their use of textures slows
everything now. I hope to see a lot of this change with the
introduction of mesh.

Second life current has a trade off between simplicity of data
transfer and polygon count and complexity, by over generating its
geometry for each primitive, it allows for simple building blocks that
can be used for construction. The trade off is that a great number of
them go unused or are never visible, hidden inside intersections of
other prims. Sadly this case cannot be optimized, as the system is
entirely dynamic, where any given primitive or object can change or
move at any time, leaving little room for clever programming to fill
in holes and optimize away pieces that cannot be seen.

Currently the second life system does a fairly good job of creating a
semi decent performance scene out of all this chaos, but I am sure
there are ways it could be further improved. Suggesting a move to
another graphics engine that is developed and designed for use with
static optimized geometry in a controlled environment would provide
poor performance, likely far worse than what is currently offered by
the tuned system that current exists. This is particularly true for
the number of unique textures that are often visible within a scene at
any time. Sometimes counting in the thousands. In most games you have
maybe 200 textures visible at any given moment, and its careful tuned
to stay as low as possible to achieve the good performance you are
used to.

I hope that we can continue to watch the engine used for second life
change and evolve in ways that increase this performance and lower the
bar of entry, but it will never be something that the programmers
alone can do, it takes the coordination of everyone involved, content
creators and users included.
___
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] (no subject)

[Hitomi Tiponi]

>I'm seeing what I believe is the same problem described in SNOW-745 in 
>our current development viewer.
>Second Life 2.1.2 (209297)
>
>I added some detail to the issue description.
>
>It's very irritating.   I think we need to do something about it (might 
>we be able to force Atmospheric Shaders to 'on'?  That appears to 
>suppress the problem).

/me shakes head in disbelief.

How about finding out what caused the problem in the first place - that is 
usually the best approach.  I am sure this issue can be addressed by testing 
likely changes until the cause is found.

Forcing on atmospheric shaders would:
- cause a lot of machines to slow to a crawl.
- cause a number of viewer problems for many users (my own laptop runs sl fine 
until atmospheric shaders are switched on and then gives a weird kaleidoscope 
of 
colours as it can't cope with them).


  ___
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] Client side scripting.

[Brandon Husbands]

Was looking at this it would be really simple and really powerful including
new ui's and stuff.
You could expose what llclass methods you want and create new ones.

Wrap that up into a mono dll that they just use the name space of so they
dont have to bother with any extern code syntax.

http://www.mono-project.com/Embedding_Mono

Would bring a whole new slew of people to the tables with c# skills.

Also allowing for features and ui stuff kinda like LUA and World of Warcraft
where they expose the functions they wish to provide to the user.

You would run in the lowest priv level. And do like a andorid app does when
they install it it says what they are requesting access to do and the user
has to grant that.


Maybe a day or two worths of work to get something going with basic interop.
___
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] Severe water flicker in recent development build

[Stickman]

> Are there any statistics out there about what kind of hardware people have?

I know LL has information on this that they don't readily publish,
though tidbits spill through the cracks sometimes.

This Jira of mine requests more information about users, likely
including information they don't collect yet, using Steam's hardware
and software survey as an example.
http://jira.secondlife.com/browse/WEB-2596

Stickman
___
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] Client side scripting.

[Ricky]

Hehe, client-side scripting has been in the works for a while now.  At
least one dev has a working model, (Dzonatas Sol in SNOW-375 I
believe,) and there has been loads of discussion on the idea on this
very forum.  Just got interrupted by one of the many "big" events
that's happened since mid-March... (Good reading there!  Plenty of
arguments for various methods of implementation.)

>From what I remember, LL had been working on a system as well, but I
don't remember any confirmation..  Oz, is/was such a project in place?
 If so, any idea what it's progress is and what team is working on it?
 According to my mail history, it may have been called "Firefly".

Ricky
Cron Stardust

On Sun, Sep 12, 2010 at 3:45 PM, Brandon Husbands  wrote:
> Was looking at this it would be really simple and really powerful including
> new ui's and stuff.
> You could expose what llclass methods you want and create new ones.
>
> Wrap that up into a mono dll that they just use the name space of so they
> dont have to bother with any extern code syntax.
>
> http://www.mono-project.com/Embedding_Mono
>
> Would bring a whole new slew of people to the tables with c# skills.
>
> Also allowing for features and ui stuff kinda like LUA and World of Warcraft
> where they expose the functions they wish to provide to the user.
>
> You would run in the lowest priv level. And do like a andorid app does when
> they install it it says what they are requesting access to do and the user
> has to grant that.
>
>
> Maybe a day or two worths of work to get something going with basic interop.
>
>
> ___
> 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] Client side scripting.

[Brandon Husbands]

I Am going to put together a test build this week with it and see what it
can do and how well it works.

On Sun, Sep 12, 2010 at 8:39 PM, Ricky  wrote:

> Hehe, client-side scripting has been in the works for a while now.  At
> least one dev has a working model, (Dzonatas Sol in SNOW-375 I
> believe,) and there has been loads of discussion on the idea on this
> very forum.  Just got interrupted by one of the many "big" events
> that's happened since mid-March... (Good reading there!  Plenty of
> arguments for various methods of implementation.)
>
> From what I remember, LL had been working on a system as well, but I
> don't remember any confirmation..  Oz, is/was such a project in place?
>  If so, any idea what it's progress is and what team is working on it?
>  According to my mail history, it may have been called "Firefly".
>
> Ricky
> Cron Stardust
>
> On Sun, Sep 12, 2010 at 3:45 PM, Brandon Husbands 
> wrote:
> > Was looking at this it would be really simple and really powerful
> including
> > new ui's and stuff.
> > You could expose what llclass methods you want and create new ones.
> >
> > Wrap that up into a mono dll that they just use the name space of so they
> > dont have to bother with any extern code syntax.
> >
> > http://www.mono-project.com/Embedding_Mono
> >
> > Would bring a whole new slew of people to the tables with c# skills.
> >
> > Also allowing for features and ui stuff kinda like LUA and World of
> Warcraft
> > where they expose the functions they wish to provide to the user.
> >
> > You would run in the lowest priv level. And do like a andorid app does
> when
> > they install it it says what they are requesting access to do and the
> user
> > has to grant that.
> >
> >
> > Maybe a day or two worths of work to get something going with basic
> interop.
> >
> >
> > ___
> > 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
> >
>



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

Re: [opensource-dev] Severe water flicker in recent development build

[Jamey Fletcher]

Tateru Nino wrote:

> Another aspect to the numbers there is that (quite often) users will
> crank up visual features until frame-rates become just short of
> intolerable or unusable. That tends to make the results trend downwards.
> They *could* be higher for the same hardware, but many of us will crank
> up our quality and distance settings until the viewer is on the edge of
> shuddering -- and increase our crash-rates in the process.

One possibility is if the Lindens set up an island, with an agent limit 
of *1*.  Region forces AV to face a particular direction.  Avatar drops 
in, and waits 5 mins.  During that time, the system records frame rates, 
CPU, and vid card.  AV reports graphics settings (unless that can be 
pulled from the client automatically).  AVs do it with client set to the 
absolute defaults for low, mid, high, and ultra, turning off anistropic 
filtering and antialiasing.  A few weeks of that, and we should have 
some good data - would have to be the stock client, too, though - but 
could record stock 1.23 and stock 2.1, and get good data on whether the 
changes to the rendering engine helped.
___
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] J2C fast decoder

[Sheet Spotter]

Some comments on SNOW-361 (Upgrade to OpenJPEG v2) suggested that changing
to version 2 of OpenJPEG might improve performance, while other comments
suggested it might not support progressive decoding. 

http://jira.secondlife.com/browse/SNOW-361

 

Is an upgrade to OpenJPEG v2 under active development?

 

 

Sheet Spotter

 

  _  

From: opensource-dev-boun...@lists.secondlife.com
[mailto:opensource-dev-boun...@lists.secondlife.com] On Behalf Of Philippe
(Merov) Bossut
Sent: September 9, 2010 10:35 PM
To: Nicky Fullton
Cc: opensource-dev@lists.secondlife.com
Subject: Re: [opensource-dev] J2C fast decoder

 

Hi Nicky,

As it happens, I've been working on instrumenting the code to add metric
gathering for image decompression as part of the Snowstorm sprint.

You may want to use my branch
(https://bitbucket.org/merov_linden/viewer-development-vwr-22761) and create
a baseline for openjpeg then run a test for Jasper. You'll have to sort out
the failing cases certainly and just throw them so we compare what gets
truly decompressed (though, clearly, working in all cases is pretty critical
if we look at Jasper as an alternative).

Here's what I got comparing KDU and OpenJpeg:
Label Metric  KDU(B) OJ2C(T)
Diff(T-B) Percentage(100*T/B)
ImageCompressionTester-1
 TotalBytesInDecompression50486435003370-4527399.1
 TotalBytesOutDecompression 40415336  465928966177560115.29
 TimeTimeDecompression3.74   17.04  13.3
455.39
ImageCompressionTester-2
 TotalBytesInDecompression50007445000144 -600
99.99
 TotalBytesOutDecompression 46440040  44248324   -219171695.28
 TimeTimeDecompression3.64   15.02   11.37
412.02

For that test, I output data every time 5MB of compressed data have been
processed. It's partial but shows that OpenJpeg is roughly 4 times slower
than KDU (at least, the version we're using in the official viewer
currently). Would be nice to have a similar set of numbers for Jasper before
going too far down the implementation path.

I wrote a short (and still incompleted) wiki to explain a bit how the metric
gathering system works:
- https://wiki.secondlife.com/wiki/Performance_Testers

BTW, that's something we should be using more generally for other perf
sensitive areas, especially when starting a perf improvement project.

See http://jira.secondlife.com/browse/VWR-22761 for details.

Cheers,
- Merov

On Fri, Sep 3, 2010 at 9:05 AM, Nicky Fullton  wrote:

Hello,

>> i'm testing in RL office (not or a viewer) JasPer decoder for JPG2000
>> images, after a short test with openjpeg2000 from EPFL we have tested
>> last 3 days JasPer (only a POC apps to do some bench), we must do a lot
>> of work too, but this is a lil question... anybody here around never
>> tried it as alternative to OpenJPEG/KDU in a viewer?

>I'm not aware of anyone publishing results for such a test, but if you
>have the time it would be interesting reading.

You might be interested in:
http://bitbucket.org/NickyD/viewer-development/changeset/027bf44c5582

I made a rather quick hack to try Jasper instead of OpenJpeg to decode
images.

The patch has some very rough edges. In fact is the decoding into the
LLImageRaw buffer not correct.

I did not fix this (yet) because the results so far are not very promising.
Jasper can only decode around 20% of the jpeg, for the other 80% it will
create an error and then my code falls back to OpenJpeg.
This fallback makes the whole decoding rather slow, so it is hard to say
if Jasper would really be any faster.

Right now I am not sure if it would be reasonable to invest more time
looking at Jasper. First the code would need to fixed upstream, so all
images can be properly decoded. As this project looks rather dead, one
with JPEG2000 knowledge might have to step up for this.

On another note, you might like to try:
http://bitbucket.org/NickyD/viewer-development/changeset/e4eff3e2af39

This will at least skip the step of calling OpenJpeg in
LImageJ2COJ::getMetadata (if possible, it will do sanity checks first).

>Some things to keep in
>mind. OpenJpeg has patches floating around on its ML against 1.3 that
>reports have claimed up to 40% speed increase in places due to
>unrolling the inner loops so finding them and testing would be good.

I did not find any of those, but then again maybe I did not look hard
enough.
There is certainly some potential in OpenJpeg.
There are some loops in t1_dec_sigpass and t1_dec_refpass that can be
easily rewritten. But there is some pretty tricky stuff in t1_dec_clnpass
that would need some cleaning and mqc decoder (mqc_decode) burns a lot
of time. But that one is especially hairy as it has side effects on its
input parameter.

I am not sure if anyone without enough deep knowledge of OpenJpeg (and
the dedication to recode a good part of it) would be able to improve
much o

Re: [opensource-dev] J2C fast decoder

[Brandon Husbands]

Phoenix uses a newer openjpeg and its static compiled might want to
check.its source

On Sep 12, 2010 10:58 PM, "Sheet Spotter"  wrote:

 Some comments on SNOW-361 (Upgrade to OpenJPEG v2) suggested that changing
to version 2 of OpenJPEG might improve performance, while other comments
suggested it might not support progressive decoding.

http://jira.secondlife.com/browse/SNOW-361



Is an upgrade to OpenJPEG v2 under active development?





Sheet Spotter


 --

*From:* opensource-dev-boun...@lists.secondlife.com [mailto:
opensource-dev-boun...@lists.secondlife.com] *On Behalf Of *Philippe (Merov)
Bossut
*Sent:* September 9, 2010 10:35 PM
*To:* Nicky Fullton
*Cc:* opensource-dev@lists.secondlife.com
*Subject:* Re: [opensource-dev] J2C fast decoder





Hi Nicky,

As it happens, I've been working on instrumenting the code to add metric
gathering f...

___
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] Severe water flicker in recent development build

[Joel Foner]

>
> One possibility is if the Lindens set up an island, with an agent limit
> of *1*.  Region forces AV to face a particular direction.  Avatar drops
> in, and waits 5 mins.  During that time, the system records frame rates,
> CPU, and vid card.  AV reports graphics settings (unless that can be
> pulled from the client automatically).  AVs do it with client set to the
> absolute defaults for low, mid, high, and ultra, turning off anistropic
> filtering and antialiasing.  A few weeks of that, and we should have
> some good data - would have to be the stock client, too, though - but
> could record stock 1.23 and stock 2.1, and get good data on whether the
> changes to the rendering engine helped.
>
> I've found that graphics cards and machines will reverse performance
ranking sometimes based on the scene they're presented with. The load of
having other avatars around is substantial and sometimes different from card
to card (and on lower end machines occasionally it's seemed that turning off
avatar nametags can make a noticeable difference). Some "less capable" cards
will hold up better in some circumstances, in terms of FPS degradation
percent, than "better" ones, and it's hard to guess based on looking at the
scene. A single scenario will tell something, but it's hard to extrapolate
from it and generalize over the range of scenes found on the grid.

Joel
___
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] J2C fast decoder

[Tateru Nino]

 If we're using HTTP textures, is there actually any need for the JPEG 
2000 format? Since the transfer time of individual textures is vastly 
reduced (from the first byte to the last byte) the intermediate quality 
levels supported by jpg2k would seem to be redundant. Indeed, you could 
argue that transferring the textures in jpg2k format imposes a 
now-redundant workload on the texture-pipeline, and that providing HTTP 
textures in a simpler format that is more tractable to high-speed, 
low-cost decoding would save a whole lot of problems.


Would it be a huge problem, for example, to transfer HTTP textures as 
TGA or PNG and use one of the rather well-optimized decoder libraries 
for those instead? It seems to me that it would be more efficient both 
on the network and on the system - though at the expense of conversion 
of all the textures at the store.


Just thinking out loud.

On 13/09/2010 1:58 PM, Sheet Spotter wrote:


Some comments on SNOW-361 (Upgrade to OpenJPEG v2) suggested that 
changing to version 2 of OpenJPEG might improve performance, while 
other comments suggested it might not support progressive decoding.


http://jira.secondlife.com/browse/SNOW-361

Is an upgrade to OpenJPEG v2 under active development?

Sheet Spotter



*From:* opensource-dev-boun...@lists.secondlife.com 
[mailto:opensource-dev-boun...@lists.secondlife.com] *On Behalf Of 
*Philippe (Merov) Bossut

*Sent:* September 9, 2010 10:35 PM
*To:* Nicky Fullton
*Cc:* opensource-dev@lists.secondlife.com
*Subject:* Re: [opensource-dev] J2C fast decoder

Hi Nicky,

As it happens, I've been working on instrumenting the code to add 
metric gathering for image decompression as part of the Snowstorm sprint.


You may want to use my branch 
(https://bitbucket.org/merov_linden/viewer-development-vwr-22761) and 
create a baseline for openjpeg then run a test for Jasper. You'll have 
to sort out the failing cases certainly and just throw them so we 
compare what gets truly decompressed (though, clearly, working in all 
cases is pretty critical if we look at Jasper as an alternative).


Here's what I got comparing KDU and OpenJpeg:
Label Metric  KDU(B) OJ2C(T)
 Diff(T-B) Percentage(100*T/B)

ImageCompressionTester-1
 TotalBytesInDecompression50486435003370-4527399.1
 TotalBytesOutDecompression 40415336  465928966177560115.29
 TimeTimeDecompression3.74   17.04  
13.3455.39

ImageCompressionTester-2
 TotalBytesInDecompression50007445000144 -600
   99.99

 TotalBytesOutDecompression 46440040  44248324   -219171695.28
 TimeTimeDecompression3.64   15.02   
11.37 412.02


For that test, I output data every time 5MB of compressed data have 
been processed. It's partial but shows that OpenJpeg is roughly 4 
times slower than KDU (at least, the version we're using in the 
official viewer currently). Would be nice to have a similar set of 
numbers for Jasper before going too far down the implementation path.


I wrote a short (and still incompleted) wiki to explain a bit how the 
metric gathering system works:

- https://wiki.secondlife.com/wiki/Performance_Testers

BTW, that's something we should be using more generally for other perf 
sensitive areas, especially when starting a perf improvement project.


See http://jira.secondlife.com/browse/VWR-22761 for details.

Cheers,
- Merov

On Fri, Sep 3, 2010 at 9:05 AM, Nicky Fullton > wrote:


Hello,

>> i'm testing in RL office (not or a viewer) JasPer decoder for JPG2000
>> images, after a short test with openjpeg2000 from EPFL we have tested
>> last 3 days JasPer (only a POC apps to do some bench), we must do a lot
>> of work too, but this is a lil question... anybody here around never
>> tried it as alternative to OpenJPEG/KDU in a viewer?

>I'm not aware of anyone publishing results for such a test, but if you
>have the time it would be interesting reading.

You might be interested in:
http://bitbucket.org/NickyD/viewer-development/changeset/027bf44c5582

I made a rather quick hack to try Jasper instead of OpenJpeg to decode
images.

The patch has some very rough edges. In fact is the decoding into the
LLImageRaw buffer not correct.

I did not fix this (yet) because the results so far are not very 
promising.

Jasper can only decode around 20% of the jpeg, for the other 80% it will
create an error and then my code falls back to OpenJpeg.
This fallback makes the whole decoding rather slow, so it is hard to say
if Jasper would really be any faster.

Right now I am not sure if it would be reasonable to invest more time
looking at Jasper. First the code would need to fixed upstream, so all
images can be properly decoded. As this project looks rather dead, one
with JPEG2000 knowledge might have to step up for this.

Re: [opensource-dev] J2C fast decoder

[leliel]

On Sun, Sep 12, 2010 at 10:40 PM, Tateru Nino  wrote:
> If we're using HTTP textures, is there actually any need for the JPEG 2000
> format?

There is the 500TB asset server full of jpeg2k images. Switching to a
new format would be a massive undertaking.

> Would it be a huge problem, for example, to transfer HTTP textures as TGA or
> PNG and use one of the rather well-optimized decoder libraries for those
> instead?

TGA is uncompressed so it won't work. PNG could work, but its
compression ratio and file overhead isn't that much better than
jpeg2k. So the gains would only be in decode time, which is the
biggest cpu drain in the viewer so it may be worth it.
___
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] J2C fast decoder

[Dahlia Trimble]

Jpeg 2000 discard levels are also used for reducing the resolution of
textures for distant objects which reduces data download requirements. Few
other formats offer comparable compression ratios with the quality that Jpeg
2000 offers. HTTP transfer doesn't magically make data traverse the network
faster; much of the reduced download time is due to offloading the sim from
the task of sending textures as they can come from another server process
(or even another physical server).


On Sun, Sep 12, 2010 at 10:40 PM, Tateru Nino  wrote:

>  If we're using HTTP textures, is there actually any need for the JPEG 2000
> format? Since the transfer time of individual textures is vastly reduced
> (from the first byte to the last byte) the intermediate quality levels
> supported by jpg2k would seem to be redundant. Indeed, you could argue that
> transferring the textures in jpg2k format imposes a now-redundant workload
> on the texture-pipeline, and that providing HTTP textures in a simpler
> format that is more tractable to high-speed, low-cost decoding would save a
> whole lot of problems.
>
> Would it be a huge problem, for example, to transfer HTTP textures as TGA
> or PNG and use one of the rather well-optimized decoder libraries for those
> instead? It seems to me that it would be more efficient both on the network
> and on the system - though at the expense of conversion of all the textures
> at the store.
>
> Just thinking out loud.
>
>
> On 13/09/2010 1:58 PM, Sheet Spotter wrote:
>
>  Some comments on SNOW-361 (Upgrade to OpenJPEG v2) suggested that
> changing to version 2 of OpenJPEG might improve performance, while other
> comments suggested it might not support progressive decoding.
>
> http://jira.secondlife.com/browse/SNOW-361
>
>
>
> Is an upgrade to OpenJPEG v2 under active development?
>
>
>
>
>
> Sheet Spotter
>
>
>  --
>
> *From:* opensource-dev-boun...@lists.secondlife.com [
> mailto:opensource-dev-boun...@lists.secondlife.com]
> *On Behalf Of *Philippe (Merov) Bossut
> *Sent:* September 9, 2010 10:35 PM
> *To:* Nicky Fullton
> *Cc:* opensource-dev@lists.secondlife.com
> *Subject:* Re: [opensource-dev] J2C fast decoder
>
>
>
> Hi Nicky,
>
> As it happens, I've been working on instrumenting the code to add metric
> gathering for image decompression as part of the Snowstorm sprint.
>
> You may want to use my branch (
> https://bitbucket.org/merov_linden/viewer-development-vwr-22761) and
> create a baseline for openjpeg then run a test for Jasper. You'll have to
> sort out the failing cases certainly and just throw them so we compare what
> gets truly decompressed (though, clearly, working in all cases is pretty
> critical if we look at Jasper as an alternative).
>
> Here's what I got comparing KDU and OpenJpeg:
> Label Metric  KDU(B) OJ2C(T)
>  Diff(T-B) Percentage(100*T/B)
> ImageCompressionTester-1
>  TotalBytesInDecompression50486435003370-4527399.1
>  TotalBytesOutDecompression 40415336  465928966177560115.29
>  TimeTimeDecompression3.74   17.04  13.3
> 455.39
> ImageCompressionTester-2
>  TotalBytesInDecompression50007445000144 -600
> 99.99
>  TotalBytesOutDecompression 46440040  44248324   -219171695.28
>  TimeTimeDecompression3.64   15.02   11.37
>  412.02
>
> For that test, I output data every time 5MB of compressed data have been
> processed. It's partial but shows that OpenJpeg is roughly 4 times slower
> than KDU (at least, the version we're using in the official viewer
> currently). Would be nice to have a similar set of numbers for Jasper before
> going too far down the implementation path.
>
> I wrote a short (and still incompleted) wiki to explain a bit how the
> metric gathering system works:
> - https://wiki.secondlife.com/wiki/Performance_Testers
>
> BTW, that's something we should be using more generally for other perf
> sensitive areas, especially when starting a perf improvement project.
>
> See http://jira.secondlife.com/browse/VWR-22761 for details.
>
> Cheers,
> - Merov
>
> On Fri, Sep 3, 2010 at 9:05 AM, Nicky Fullton  wrote:
>
> Hello,
>
> >> i'm testing in RL office (not or a viewer) JasPer decoder for JPG2000
> >> images, after a short test with openjpeg2000 from EPFL we have tested
> >> last 3 days JasPer (only a POC apps to do some bench), we must do a lot
> >> of work too, but this is a lil question... anybody here around never
> >> tried it as alternative to OpenJPEG/KDU in a viewer?
>
> >I'm not aware of anyone publishing results for such a test, but if you
> >have the time it would be interesting reading.
>
> You might be interested in:
> http://bitbucket.org/NickyD/viewer-development/changeset/027bf44c5582
>
> I made a rather quick hack to try Jasper instead of OpenJpeg to decode
> images.
>
> The patch has some very rough edges. In fact is the decoding into th