Jump to content
  • 0

Second Life Textures Acting Weird - Pixilating


Gwendolynne Constantine
 Share

You are about to reply to a thread that has been inactive for 2195 days.

Please take a moment to consider if this thread is worth bumping.

Question

So earlier yesterday, I popped into SL Viewer (latest), and headed over to a cam sim to shop at Blueberry.  It was packed and took a long time to load graphics / items / avatars.  Graphics were loading in weird places - like avatar skins were loading on prims, avatar profile pictures were loading on vendors... I cleared the cache and rebooted my laptop and it cleared up.  I didn't think much of it; I shopped and left.  However, ever since, any time I log into SL, I'm getting weird issues with textures refusing to load.  Instead of being jumbled and out of place, I'm getting this weird pixilated replacement thing.  It's on random prims, and it's happening every time I log into SL now.

I've checked my graphics card; the driver is updated.

My graphics view on SL is set to "MID"... what else do I need to do?

Edited to add:  I uninstalled and reinstalled SL viewer.  No improvement.  I tried Firestorm and it's not doing it in that browser.

SL Pixilating.jpg

Edited by Gwendolynne Constantine
Link to comment
Share on other sites

1 answer to this question

Recommended Posts

  • 0

I suspect it may be pipelining blowing up.
SL viewers use Http Pipelining to fetch textures & mesh. Pipelining is a little tetchy & if the pipeline gets out of sync you will see those rainbow barf textures shown in your image or a random cached texture displaying on some objects.

On viewers before the Alex Ivy (LL's 64bit implementation), Pipelining was mostly well behaved unless you were using an antivirus or firewall software that was incompatible with pipelining & sadly a lot of them are, most notably Webroot.
Which firewall & antivirus software are you using?

Firestorm has a workaround for this problem - if the viewer detects that the pipeline has got out of sync, it will disable Http Pipelining on the fly for that session.
You said you didn't have this problem on Firestorm, which makes me suspect pipelining is the problem.

Also,  the most recent Firestorm release doesn't have the Alex Ivy code merged in from the LL viewer.
Pipelining is pretty broken on viewers with the Alex Ivy code even if you don't have the problem antivirus or firewall software installed on the system.
There is a bug report filed here on the LL JIRA: BUG-202968 - [Alex Ivy] Pipelining still blows up frequently resulting in corrupted textures & mesh.

You will be able to see if it is indeed pipelining blowing up from the viewer log.

I suggest you file a bug report on the LL JIRA & run a session on the LL viewer where you reproduce the rainbow barf textures problem on a clean cache, log out & then zip up the logs folder & attach them to your JIRA issue.
Instructions on how to find your logs are HERE.


The reason I ask you to reproduce the problem with a clean cache is that if a texture is corrupted by fetching with pipelining, it will be stored in a corrupted state in your cache & you will always see the same textures corrupted in subsequent sessions unless texture cache is purged.
We want the logs to show fresh texture fetches going wrong with pipelining, not just a reload of already corrupted cached textures.

 

 

  • Like 1
Link to comment
Share on other sites

You are about to reply to a thread that has been inactive for 2195 days.

Please take a moment to consider if this thread is worth bumping.

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
 Share

×
×
  • Create New...