[sldev] 1.23.4 released in a hurry ? NO.

[Ann Otoole]

raise debug setting renderMaxNodeSize above 4096 (default). I use 8192 without any discernible difference on my nVidia 8500GT on 4GB ram/Vista64/quad core.

Your system configuration will determine if you can have an acceptable experience with increased vertices. In addition it seems to only kick in and matter when zoomed on my machine. I do wonder if the widespread reports of avatars no longer rendering are related. But I have seen that in some regions for over a year so how could it be related to this new tiny code addition?

Sheet Spotter is the person that found the change:
--------------------
Sheet Spotter commented on VWR-13868:
-------------------------------------

There are 173 prims in the necklace placed at
secondlife://Hippotropolis/238/28/23 and most of the prims are
detailed, high resolution sculpties. The large number of highly
detailed sculpties has exceeded a recently added limit on the maximum
number of vertices that the rendering engine will process. When the
limit is exceeded, the renderer stops rendering any later vertices. The
skip vertices could be from the same object or any other object in the
scene.

Aside: vertices are the "corners" of all the prims we normally talk
about. High resolution sculpties have more vertices than most other
prim types, so the issue may be more noticeable with sculpties.

The workaround for this problem is to reduce the number of high
resolution scrulpties, or to adjust one of the debug settings
"renderMaxNodeSize". The default value of 4096 for renderMaxNodeSize
causes some portions of the necklace to disappear when zoomed.
Incresing this value above 6000 displayed all the elements of the
necklace. (You might have to wait up to 30 seconds after adjusting the
value to see any effect. Be patient.)

Referring to the source code for the viewer...The following lines were
added to the "LLVolumeGeometryManager::rebuildGeom" method in the
"indra/newview/llvovolume.cpp" source file between revision 1760 and
1817.
if (cur_total > max_total)
{
facep->mVertexBuffer = NULL;
facep->mLastVertexBuffer = NULL;
continue;
}
When the limit set by renderMaxNodeSize is exceeded these statements
cause the renderer to skip the processing of any later prims. The
skipped prims could be from the same object or any other object within
the scene.
----------------------

On to tangentally related observations:

More worrisome is how the public nightly build shows texture 8b8ee746-d658-1a93-065a-3ed78bc20961 8 * 8 pixels black) as a 1024*1024 semi transparent texture. How does one viewer show an asset as 8*8 black and another viewer show the exact same asset as a 1024*1024 semi transparent texture? This sort of defect seems to be capable of catastphic damages. I specifically use this 8*8 to reduce rendering overhead on the majority of faces in a build. To see the most efficient texture asset possible get changed to the worst possible resolution with alpha is absolutely astounding.

Anyway I'm happy Q thinks they improved their processes. We all know and have complained loudly about the apparent lack of methodologies and procedures at LL so if they are improving that aspect it can only lead to good down the road.

One step forward at a time.





________________________________
From: Harleen Gretzky <gretzky.harleen at gmail.com>
To: Ann Otoole <missannotoole at yahoo.com>
Cc: sldev at lists.secondlife.com
Sent: Wednesday, June 17, 2009 10:18:37 AM
Subject: Re: [sldev] 1.23.4 released in a hurry ? NO.

How do you override them?


On Wed, Jun 17, 2009 at 10:01 AM, Ann Otoole <missannotoole at yahoo.com> wrote:

I'm surprised protests are being tolerated in this mailing list.

As for the rendering limits that were put in you can override them as an option. If your frame rate suffers because of your system configuration then it is your choice. Frankly I don't even consider frame rates in the SL viewer to even matter since you are not getting server frame rates above 45 anyway. In order to record cinema quality video the SL frame rate would have to be above 60 FPS to accommodate the recording overhead to get to the ~30 FPS needed.

If people want to dispute the release then they need to apply pressure to the executive level of Linden Research Inc. Not the SLDEV mailing list. IMHO anyway.




________________________________
From: Kent Quirk (Q Linden) <q at lindenlab.com>
To: Latif Khalifa <latifer at streamgrid.net>
Cc: sldev <sldev at lists.secondlife.com>
Sent: Wednesday, June 17, 2009 9:35:48 AM
Subject: Re: [sldev] 1.23.4 released in a hurry ? NO.



On Jun 17, 2009, at 7:48 AM, Latif Khalifa wrote:

> On Tue, Jun 16, 2009 at 7:19 PM, Brad Kittenbrink (Brad
> Linden)<brad at lindenlab.com> wrote:
>> I'm not sure I understand what your complaint is.  There's nothing
>> blocking 1.22 viewers from logging in.  Our policy for deprecating  
>> older
>> viewers is described here:
>> https://blogs.secondlife.com/community/technology/blog/2009/03/09/supported-viewer-versions
>>
>> Quite frankly if you're looking for "Some kind of clue" that a new
>> viewer is going to be released, then IMHO you should treat our  
>> release
>> of RC0 as that clue.  We've been bad in previous releases by calling
>> things that weren't even close to releasable quality "RC" viewers,  
>> but
>> the 1.23 RC process is what we've been aiming for ever since we  
>> started
>> doing Release Candidates.  We're sorry if you've gotten used to us
>> sucking, but this is one case where I'm glad to disappoint you. ;)
>
> It really takes a brave man to claim 1.23RC4 and now production 1.24.4
> "releasable quality". Is that why comments were closed after a few
> dozen or so on the blog post announcing the new viewer?


I absolutely claim that 1.23 is not only of releasable quality, but  
the best viewer we've ever shipped. It met its design goals on RC1.  
The bugs that were found and fixed in the next 3 RCs were minimal. On  
a global statistics level, the crash rates are lower than they've ever  
been, even when you include crashes caused by specific video cards.

There are some individuals who are upset about some of the design  
decisions, like the redesign of pie menus. That's not a quality issue.  
There are other individuals who are upset about some of the technical  
decisions, such as the imposition of rendering limits where we never  
had them before. That's not a quality issue either. And there are  
people who don't like the new Adult-Only stuff. That's also not a  
quality issue.

The definition of quality is meeting the specification. We executed on  
this viewer better than we've ever done it before, and I'm pretty  
proud of our team for doing it.

By the way, contrary to the implication in the subject line, we  
released 1.23.4 almost exactly according to the schedule I announced  
internally in February. The internal decision to ship was based on  
quality. As every professional software organization does, for every  
open issue we balance the risk of shipping a product with that issue  
against the risk of trying to fix it. When all the risks of shipping  
are lower than the risks of fixing, we ship it. Which is what we did  
with RC4.

    Q
_______________________________________________
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/SLDev
Please read the policies before posting to keep unmoderated posting privileges


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


      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090617/8be8e60b/attachment-0001.htm