Extreme thrashing, or failure to completely rez, of scripted letter/number textures on game boards, Shoutcast boards, and similar items
complete
Anastasia Horngold
This problem started cropping up after the introduction of PBR. We have had many reports of this in Firestorm support, and it does repro on the official SL viewer.
The problem generally involves letter/number displays that are scripted to change. Other parts of the object are not affected.
Typically the scripted item will make its texture change, and the texture will rez, blur, rez, over and over, or simply remain in an unreadable, blurry state.
Right clicking the item or putting it into edit mode will often cause the textures to completely rez. Once the item is deselected, it blurs again.
Log In
Dan Linden
complete
Atlas Linden
tracked
Thanks all for the info! This issue is now being tracked here: https://github.com/secondlife/viewer/issues/3611
Medea Destiny
As Anastasia has pointed out, this looks like the same issue I have reported here: https://feedback.secondlife.com/bug-reports/p/texture-bias-issue-with-texture-atlases-on-forever-fps
In comments in that report I include video showing the textures of a text display coming into focus during zoom in, and another showing a similar effect on an attachment that uses a texture atlas, with another attachment of very similar size that does not use a texture atlas remaining unblurred throughout the zoom.
As per Kirsty Aurelia's comment below my assumption is that this is scaling based on total texture area, which is completely inappropriate for faces that use an atlas. The evidence in my report strongly supports this theory.
Andrey Kleshchev
Medea Destiny
> is that this is scaling based on total texture area
- Visible face area gets calculated. F32 vsize = face->getPixelArea();
- Then scale gets taken into account. vsize = vsize / (min_scale^2);. So if scale is 2 (4 textures per face), value gets reduced, if value is 0.5 (half of a texture visible), value will grow.
- Camera focus and the rest get applied to boosted vsize, not total visible texture area.
- Texture's area gets compared to vsize.
Example:
128x128 pixels are visible of a face, it has a 256x256 texture atlas with 4 items, scale is set to 0.5 so we see only a quarter of a texture.
vsize = 16 384
16 384 / (0,5^2)= 65 536
Now we compare 256x256 = 65 536 texture to vsize, values are identical, full texture sgould be displayed.
But there are limits to how much viewer will prioritize textures based on scale due to low memory efficiency of atlases. Atlases are relatively memory effective for alphabets, the longer the string is the more effective they are memory wise, the bigger the symbol selection the less efficient it becomes. But people often use a fraction of a texture for a single 0.1 scale sub image (like a single gem on a choker from an atlas of 100 gems), that image basically costs one hundred times the memory of a dedicated image, by that point gem-atlas is actively harmful to memory usage.
Note that this is texture specific and works differently for PBR and media textures.
Medea Destiny
Andrey Kleshchev In your example of the gem atlas, if the other 99 gems are also visible while the total number of pixels may be approximately the same there should be considerable savings handling 1 texture rather than a hundred I'd hope! Though if the atlas is being used for texture changing then that could be quite an issue.
In this instance, how is min_scale determined? If it's by the face scale setting, then there's an issue. Consider two situations. In one, you've got a text board where each character has a scale of 0.1, so it's showing only 1/100th of the entire texture area. In the other, the mesh that is displaying the face has been designed so that each face occupies 1/100th of the UV space. Thus the scale will be 1, and that would return the same value as if the entire texture area was being used.
Andrey Kleshchev
Medea Destiny min_scale is smallest value between vertical and horizontal scale. It uses values from face data. I think meshes compensate somehow with pixel area, but might be wrong.
Medea Destiny
Andrey Kleshchev If it does not that could explain why I'm seeing the blurring happening more aggressively for atlased textures than a non-atlased texture at a very similar pixel density right next to it.
ib1ub12 Resident
now i have noticed that other things are not in focus like 2 or 3 versions ago, see poic
ib1ub12 Resident
ib1ub12 Resident
ok this is happening to me on the beta version. I was told it was fixed on this version and to try it. Well its not fixed, it isnt as bad but its still not readable. Hope they can fix this soon as its frustrating to say the least
ib1ub12 Resident
ib1ub12 Resident
this is how clear it is on version 7.1.10 75913
Kristy Aurelia
I'm going to take an educated guess of why this is happening: Latest viewer updates have been tweaking texture loading to try an avoid loading high resolution textures on small objects... which is what you end up having here, the little squares for letters have small surface area, and the texture they're using is used as an atlas, so the maths works out as "way too large texture for said surface area" and downscales it... except the point of a texture atlas is to do exactly that instead of using dozens of individual textures for each letter...
ib1ub12 Resident
Kristy Aurelia i was told its only on scripted things, none scripted is fine which i can attest to
Kristy Aurelia
ib1ub12 Resident Should be easy to test - if you have one of those boards, set bunch of text on it, make a copy, delete the scripts.
ib1ub12 Resident
Kristy Aurelia i dont own the boards but from what i read it is the scripted stuff
SabrinaCooke Resident
I've been getting this a LOT, and it's especially annoying when I'm trying to take snapshots at heavy/fully decorated sims. I can cope with it by right clicking into the Edit menu on the item, but that's hardly a tenable solution.
Ecko Soulstar
SabrinaCooke Resident And if you go OUT of Edit mode it instantly blurs right back up too. I've taken to staying in edit, and hiding the UI just to get clarity when this happens. Infuriating really.
Dan Linden
Please add SLURLs to examples where this happens.
Shawn Dakota
Dan Linden. It's not consistent, not happening all the time, but where I've seen it the most is here at my house: http://maps.secondlife.com/secondlife/Primal%20Fusion/143/215/23 with the crates I have on the wall. Lilke just now when I was getting the SLURL, the crates were perfectly clear and looked fine, but then all of the sudden they went fuzzy as in the attached.
Kira Skydancer
Dan Linden Happens, well, everywhere. Torgon's KittyCats! info boards are pretty consistently doing it to me, including at my lonely piece-of-homestead (not the owner), but all the time, especially during auctions at http://maps.secondlife.com/secondlife/CatTales/140/130/23
Kira Skydancer
I'm still seeing this as well, especially on Torgon's KittyCat! boards, but elsewhere as well. Has been happening for at least a month or more.
very
annoying. I tried all the fixes in the "texture thrashing" wiki for FS,did not fix.Shawn Dakota
Seems to happen to me a lot, mostly on gaming machines like No Devil, but sometimes on other things too.
Load More
→