my furry looks bad at night...again :o

Same thing I'm seeing, Ingrid.

I'm not sure what to say besides that many other people are seeing this, too.

Ingrid - did you bug report it? I know it sound kinda useless but... doing so may get some of the folks at LL to look at the problem more seriously. Especially if people besides "furries" are complaining.

No, but I will tonight. Bug reports work especially well en masse.

Do send bug reports.

To help them even further, try to get the UUID of the hair that's looking funny then include that in the report. That way LL will have an easier time replicating the problem because they will be using the same hair that you reported the problem with.

Same goes for the furries with attachment problems. Send those UUIDs.

i think most of the lusk avs demonstrate the problem quite nicely, and lindens know where to go for those.

bug report sent

I think I'll drop by Lusk later and see if I can fiddle with my settings to recreate the problem.

[edit]

Visited Lusk and saw several furries there. All of them look perfectly fine on my system whether avatar vertex is on or off. I even checked one that was away and bathed her in intense green light. The color effects were all as predicted.

Looks like we're not dealing with a problem in the rendering engine per se.

As I write this I have Adrienne Belvedere and Max Dapto on my screen. Both have colored furry avs and they look ok. The other two avs on my screen are black/blackish so not good samples for checking.

you should totally sell those tie-dyed prim boobs aodhan!

ROTFLMAO

No sorry, I don't wish to impose my bad taste in boobs to the community at large. We're insane enough as it is.

I'm not really a tie-dye fan (I prefer greys and low-sat colors for my RL clothing) but I still have to admit the tie-dye texture supplied by LL looks really good.


To topic:
The problem that you guys are encountering is worrisome. Just because it doesn't happen to me doesn't mean I don't worry, because it just might happen to me eventually. I don't like the fact that it can't be repeated reliably.

Another line to investigate:

When you got the new client (1.10.1) did you just install over or did you uninstall the previous client (1.10.0.34) first?

I cannot do any tests for this because I deleted all my older client installers. I normally just install over the old client, but this one time I uninstalled the old client before installing the new one.

i installed over the old.

i notice torley has consolidated our hotline posts and is inquiring within yay!

I installed over the old as well, but I'm not encountering the problem that was mentioned. The local lighting looks really great on prims and body, or at least on my machine. But then theres the fact that I don't really wear prims as body parts, however the robots and furries I've seen seem to look correct.

Ok. I think we can scratch the install method line.

This is crazy. The only thing that I can figure is wrong is that individual clients are messing up the transmission of prim parameters to the video cards. Which is very strange because we're getting different results from same-brand cards that all use the same driver. Theoretically that shouldn't be happening.

Worst part is Fa Nyak saying the error isn't even consistent. Makes it harder to find.

I hope this is not a problem related to inconsistent OpenGL support.

Aodhan -- I'd like you to come by some time when I'm around if possible so that we can compare notes (and screenshots) -- I mean, you've seen the images I've posted in Answers... ---

what's troubling is if it *is* "hit or miss", then Linden Lab may not see it, either....

But it really shouldn't be. As per the OpenGL Support, it could be a driver issue, (ogl 2.0 vs 1.5) .. maybe we should compare those...

Yes I have seen the images.

"hit or miss" ... that's what's also troubling me. The longer LL takes to find the problem, the more the next update will be delayed because whatever problem exists now will likely be in the newer version too.

When a problem is universal I'm less concerned because it's usually easy to replicate it. The one that's scary is the one that isn't consistent, and that's exactly what we have here. Similar systems (Pentium4s + NVIDIA gpus) and *different* results is certainly disturbing.

Would like to come by and take a look. Give me a time (include time zone) and I'll try to logon then. Lusk?

heh, for what it's worth, i think i slightly overstated the difficulty of reproduction. i tried at a friends place and the effect was barely noticeable, though there could be several factors and angles i didn't take into account. i can reproduce it at my place where i took the original screenshots.

OK folks, first let me reassure you that we have identified the problem and are working on a fix. It should be available in the next week or two.

In the meantime, you can turn off "Avatar Vertex Program" in "Preferences -> Graphics Detail" and the lighting should match. This should only have a minor performance impact and only in areas with many avatars.

Here's the problem in a nutshell (kind of technical):

When we created the new lighting model, we wanted to limit the range of local lights for a number of reasons, primarly to reduce the artifacts when only a limited number of lights are being used. In order to do this, we had to put the lighting in GLSL shaders (the OpenGL lighting model uses a 'realistic' but very long falloff). Unfortunately, due to driver issues we decided to postpone introducing GLSL shaders for object rendering. We did include them for avatar rendering, but neglected to modify the lighting to match the default OpenGL lighting. Thus the descrepency.

We did do a shader update in 1.10.1 which fixed a different shader lighting bug which was generating some harsh lighting effects on avatar faces. Apparantly this fix exaggerated the discrepency. This was not in any way deliberate, it is just that the attachment discrepency hadn't hit our radar yet (remember, at any given time there are dozens of issues like this in the forums, and hundreds of other little things on our plates, not to mention the big things).

Now, some of you might be asking "won't the lighting change again when you introduce GLSL for objects?" The answer is "yes", however, the discrepency between avatar lighting and object lighting is what is noticable here, and we will make sure that when you enable GLSL it will affect both objects and avatars, and the lighting will match.

Thank you for your patience,
-Steve

Well I guess making a full body furry isn´t an option is it?

Steve -- While I understand the mismatch issue (vertex on vs off) --- note that attachments are still *too blown out* in common daylight after the 1.10.1 fix...

I am hoping that lighting is changed to match what is seen in Vertex Program vs what is seen without it -- yes, they'll match with it off.... but essentially if there is ANY nearby light, the entire avatar's brightness is at 255. (fullbright).

So in a nutshell, I -really- believe, that after 1.10.1, falloff is FAR, far too long.

Can we get any input as to whether or not we'll see a middle ground on falloff?

I've posted a follow-up to Steve's response in Answers here

Hokay. We can relax. Relief.

Yes, it's falloff. Was able to reproduce the problem. The reason why it would look ok in some areas and bad in other areas was distance from the light source. The discrepancy appears only if the avatar has stepped out of the set range of the light source.

@Michi
Saying falloff is far too long is somewhat an understatement. With the avatar vertex off we do get consistent lighting once again however the lighting radius parameter of our light sources is effectively ignored.

With the avatar vertex on the light is completely "off" to an avatar once he steps out of its range. Now what we have is realistic falloff however this means we now have no way of stopping light from going through walls and lighting up avatars on the other side.