Ref:
http://jira.secondlife.com/browse/VWR-13868
http://jira.secondlife.com/browse/VWR-14049 (watch that youtube video. It is remarkable)
Dear Mr. Klingdon,
Your developers have elected to destroy most of the content in Second Life and the backlash is beginning. This is likely to become ugly and you are the one who is going to look like you have no authority over your software developers.
Last time I checked it was customers that create the requirements not people whose salary is paid by the customers.
In this case your coders are calling most of Second Life griefers because of our art and builds.
You should be embarrassed and your software development team needs to be reconfigured as professional corporate software engineers that code to requirements and do not make decisions outside of what is the best way to write code to meet requirements on a hard delivery schedule.
As it stands your company has done nothing in the last year except to add crippleware code to the viewer and servers. Whatever happened to advancing the technology?
I hope you decide to take control of your software developers and put them on a track that forces them to find ways to code so Second Life can be better than it is with every release instead of the nonsense of your developers that can only code limits instead of more efficient code that renders more with less latency.
As for frame rates? Second Life frame rates are a joke because they are limited to 45 FPS maximum. You need to give up on frame rates as an excuse. If we cared about frame rates that much we would have never built Second Life into what it is.
Frame rate has zero to do with scaling the system to one million concurrency.
And make no mistake it is we who built Second Life not you nor your coders. You people need to get a clue as to who is the people responsible for the success of Second Life because it is us that built it despite the constant obstacles your coders put in our way.
Regards,
Ann Otoole
Re: [sldev] Rendering Limits
…
Ann Otoole
…
Thursday, June 18, 2009 11:18:01 AM
To:Soft ; Harleen Gretzky
Cc:sldev
Soft,
It is your opinion you are expressing as to what is overkill.
Which is why we need Linden Lab to be converted to a standard corporation where software developers are relegated to coding to customer requirements and do not make any decisions whatsoever.
You are going to experience a severe backlash over your decision to destroy most of second life.
That being said as long as you do not disable the customer’s ability to opverride your unqualified decision that was not based on customer requyirements then it is all good. Because everyone is just going to up rendermaxnodesize to get the viewer back to where it was operating perfectly well.
Also you should be embarrassed for categorizing as and calling most of the content creators and artists in Second Life griefers.
We made this world. You would not even have this job if SL did not look good because of our work.
We pay your salary.
From: Soft
To: Harleen Gretzky
Cc: sldev
Sent: Thursday, June 18, 2009 10:45:30 AM
Subject: Re: [sldev] Rendering Limits
I’ll attach the diff. It addresses cases where baddies were creating
attachments tuned to lag out viewers with wild vertex counts. With the
necklace for VWR-13868, view it in wireframe mode or turn on
render->info displays->sculpt to see why it’s a really unusual asset:
at the typical resolution and view distance, it’s going to have like
30 faces per pixel. It’s literally got more polygons than both teams
in a typical console basketball game.
If anyone is really attached to affected assets and wants to
contribute an alternative patch, it might be possible to do something
like dropping LOD on sculpts and tori when a set is wildly expensive.
I think more time didn’t go into that because the few non-griefer
assets we were given were overkill for a space the size of a room, let
alone as an attachment. There are many more tasks requiring graphics
dev time, which affect more resis.
On Wed, Jun 17, 2009 at 9:02 AM, Harleen
Gretzky wrote:
> Can you elaborate on what the new rendering limits are?
>
>
> On Wed, Jun 17, 2009 at 9:35 AM, Kent Quirk (Q Linden)
> wrote:
>>
>> rendering limits where we never had them before