Beq Janus

tip: profile text and picture issue · August 22, 2023

@Silver Selenium I would be interested to know if you have recently (or ever) changed your name. I read that another person who was having this issue had recently done so, and as this would be a uncommon but not unheard of situation I am wondering if it ties together those of you who are experiencing this problem.

EDIT: I just found an existing JIRA for this. Please add your experience to that. https://jira.secondlife.com/browse/BUG-234248

Posted August 22, 2023 · August 22, 2023

@Asher Isodo out of interest (given new information on another thread here) have you changed your name recently (or ever)? I'm trying to see if there is a pattern behind these.

ETA: I just saw your JIRA (thank you). https://jira.secondlife.com/browse/BUG-234248

I am directing a few others that way. Can you please updateon the JIRA if by some chance you have changed your SL name recently (or undergone any other change that comes to mind)

Profile not Saving changes? · August 22, 2023

On 8/16/2023 at 6:57 PM, Rowan Amore said:

There does seem to be an issue...

@Beq Janusis this a known issue already?

Not one that I am aware of, in the sense that I have only heard of it in the occasional mentions we have seen here. I have not seen anything in terms of a proper bug report.I will double check with our support team. The information here that places the failure in the context of a name change is very interesting.

@Virulent Vortex could you please raise a JIRA at https://jira.secondlife.com . Based on what you have written here, this appears to be a bug in the upstream LL viewer that we have inherited, which also implies that it will affect most other TPVs that have adopted the new profiles, moreover, it may well be a server side issue related to that update mechanism used.

If I understand correctly, this only happened after you changed your name, that is probably/possibly an important detail to record. The simplest way to create the JIRA is to login using the LL viewer and go to the help menu, from there select "report a problem"; that should take you directly to the JIRA system and even pre-fill some of the form for you. When you write the JIRA, be sure to specify the steps that led up to this.

It would be useful to attach you viewer logs to the JIRA, though only if you go through the steps of attempting to do the update, beforehand. Looking at the code I see only limited logging in the profile code but it may be enough to suggest where the issue lies.

Posted August 9, 2023 · August 9, 2023

this is the side effect of merging in the largely retrograde profile updates that were applied when LL moved away from web profiles. We now have "free upload" profile images that you pick directly from disk and which cost nothing, and bypass the normal image upload. The downside of these is that they are then squashed to 256x256. We retrospectively restored the ability to select an inworld texture and upload normally, which leads to this rather awkward situation where you have multiple ways to "update" your profile. It's pretty ugly all round and personally, I think it was far better before the profile changes were made.

July 30, 2023

@Jackson Redstar, back on the original subject a little. I'm sure that you'll have probably looked at this already but do double-check that you have all the correct AV whitelisting in place for BD as well as FS. Assuming that BD is using a separate cache, that would be a good reason why sucking down a scene might take a lot longer. Temporarily disabling any AV might be a quick way to test that theory.

Also, keep in mind that if you are running "side-by-side" comparisons, viewers will (by default) back off and go into low-usage background mode when not the active window. For many viewers (Cool VL Viewer is the exception here, I think - because I haven't yet borrowed Henri's idle/background code, and BD may be the same), the rendering frame rate and the rate at which background stuff is serviced are somewhat correlated. If your viewer is inactive (i.e., you are tabbed out), some aspects of the background workload will run at a lower framerate. Many more things run in separate threads these days than they did in the past, but several aspects of viewer operation are still coordinated from the main thread; when you tab out, and the viewer yields the CPU for other processes, this coordination happens less often, and if you are tabbing out of one viewer and into another then the active viewer will naturally appear to be a lot more snappy and faster.

July 30, 2023

Whitelisting is definitely something to look at.

@Rebecca Crisp mentioned 100% RAM usage but not 100% CPU, unless I misunderstood. I would certainly take a look at the VRAM setting but be careful that if you are running multiple instances this can itself lead to increased instability. I would increase your disk cache too, the current setting at 2GB is very small if you are travelling around more than a couple of simple regions.

To examine the memory usage I'd probably want to look at log files. If none of the advice here helps please raise a JIRA ticket at https://jira.firestormviewer.org and describe as fully as possible what happens, how long it takes for it to happen, and attach your log files.

While it is not what is happening here. It is worth noting , that for good and ill, the viewer will increasingly be demanding more of your PC. It started with the performance updates a few releases back and will continue with PBR. In striving for better performance and higher quality the viewer is moving from something we run on the side while doing other things and not having to worry about the resources it demands and the conflicts with other tools, to being more game-like expecting the whole mahcine and wanting to use it.

July 20, 2023

Just returning here to give a public update. @BondJamesBond contacted me privately, and I've been able to look at the bug splat reports. They do (as @Kathrine Jansma suspected) suggest an OOM exception in the NVidia drivers. The next step will be to review the settings and see if we can tighten them up a bit to allow a dual operation in 4GB VRAM. I've not yet seen any preferences etc so I have no idea what settings are in use, but I thought I'd update here with what we have so far.

@Henri Beauchamp I recall that you've mentioned a couple of times in forum posts in the past about "broken dynamic memory" but I've not seen any details on that. What is the broken behaviour you are alluding to? I can take a look at it if I know what I am looking for. Of course, at this stage, I don't know that we are even using dynamic VRAM here.

As a general note, all viewers that are largely based on the LL viewer are increasingly able to use more of the VRAM more of the time, this is a trend that is going to continue with PBR.

July 20, 2023

15 hours ago, animats said:

I'd like to have LOD enforcement when objects are uploaded to Marketplace. A proposal:

For non-clothing items, once we have glTF mesh uploads:

The Marketplace system should generate a panorama preview of the object. See what you're getting before you buy. This is easy to implement with glTF objects, because how to render them is well-defined by a standard and there are many open source renderers that can display them. If you upload textures with the meshes, you get a textured preview. Otherwise, it's just grey. This encourages uploading textures and mesh together. You can still have other textures, but there should be a primary set. With glTF, you can export textures and meshes as a linkset from Blender/Maya. (In theory you can do this with COLLADA, but it doesn't work right for SL.)

Generate panoramas for each LOD. Find out if it has bad lower LODs before you buy. The Marketplace web site might display a big image for the high LOD, and smaller images for the lower LODs.

Use basic automated image comparison for quality control. Downsize the big panorama to each lower LOD size and run an image compare program. The minimum requirement is that textured outlines must roughly match. Don't even let those go on sale on Marketplace. This rejects lower LODs with holes in them.

Find or implement a mesh reduction algorithm for the uploader that has "silhouette protection". Unreal Engine 5, for example, has that. This means the outline will roughly match for default automated LODs, and they will pass the test above.

Clothing items have a different set of problems. Maybe they could be displayed rendered on something like a dressmaker's dummy.

While I agree that more information can do no harm; indeed, the reason I added the in-viewer LOD preview on FS was to increase the visibility of this issue and enable "look before you buy". None of these tools overcomes the basic problem of consumer indifference and creator time-to-market pressure.

While as users, we may collectively curse the erratic frame rates, the FPS killers and the texture hogs. As individuals, we are all too willing to tolerate a bad item if it serves our needs. I don't think that uncosted bad assets will be halted by pretty pictures and information overload. If the server on upload were able to reject poor assets or, more realistically, if worn assets carried a proper impact cost, that would prevent entry to regions that were already at "capacity", then we'd get appropriate pressure on creators to be economical with render impact in the same way as we see with land impact for non-worn items.

I have written this before here I am sure; right now the market pressures are entirely wrong. Creators are expected to produce new, unique items on a very regular basis if they are to stay at the top of the market. A 1 million poly dress is not going to sell fewer units than a 50K poly dress, but the 50K poly dress takes time, effort and some skill to retopologise properly and so there is no revenue incentive to spending that time, it is a very simple commercial choice to say "screw it, good enough, it'll sell". Many conscientious creators out there will take the extra steps, and we should celebrate those because the reward for them in doing so is higher production costs and possibly lower sales, a sacrifice made to help us keep performance higher. You also have the argument that those who do optimise lose sales because the side-by-side comparison with a ludicrously over-dense dress makes their offering look less appealing visually and looks win the day.

Ultimately we need enforcement, a tangible penalty/cost that incentivises good asset creation, but we also know that this is a pretty tough nut to crack.

July 19, 2023

The derendering when you zoom in close is only slightly related to LOD, it is precisely what @Henri Beauchamp describes.

I get called to investigate such things a couple of times a year on average, the common cause is sports shoes (seriously). People model every last detail on a shoe that nobody is going to look at for more than 5 seconds, and then they set out 20 of them on a stand at an event. The poor merchant in the stall next to them will frequently find that some of their own products are not showing up for some people because, as Henri noted, the cutoff is simply based on how much is stuffed into "this part of the scene", and once it passes a limit everything else is arbitrarily discarded. The issue is ancient, but sadly people are still making over complex items, and I don't expect them to stop any time soon.

Edited to add: Another common cause is table decor, flowers and serving places. Possibly why you found this at a wedding. Here is an example from a few years ago where the creator themselves was confused by the behaviour (https://jira.secondlife.com/browse/BUG-225107)

https://jira.secondlife.com/browse/BUG-1509

The FS default for that setting has been 64MB for as long as I can recall. Runitai notes that the LL default was 64 in 2013 so It does beg the question as to whether a larger default would be better suited in this day and age, perhaps something that scales to the RAM/VRAM available.

Sadly though, we are once again making the viewer compensate for unsociable, irresponsible asset design.

July 19, 2023

I would check that your Anti virus whitelisting is still correctly in place. I don't see a reason why the LL viewer would interfere in that regard but what you are describing sounds like one of the many ways that AV and anit-malware systems can interfere with the viewer

July 19, 2023

On 7/14/2023 at 2:42 AM, MRSCANDIREDBONE said:

CPU: AMD Ryzen 5 4500U with Radeon Graphics (2370.55 MHz)
Memory: 7542 MB
Concurrency: 6
OS Version: Microsoft Windows 11 64-bit (Build 22621.1992)
Graphics Card Vendor: ATI Technologies Inc.
Graphics Card: AMD Radeon(TM) Graphics
Graphics Card Memory: 512 MB

Windows Graphics Driver Version: 30.0.14046.0
OpenGL Version: 4.6.14802 Compatibility Profile Context 21.40.46 30.0.14046.0

RestrainedLove API: RLV v3.4.3 / RLVa v2.4.2.67470
libcurl Version: libcurl/7.54.1 OpenSSL/1.1.1l zlib/1.2.11.zlib-ng nghttp2/1.40.0
J2C Decoder Version: KDU v8.2
Audio Driver Version: FMOD Studio 2.02.07
Dullahan: 1.12.3.202111032221
CEF: 91.1.21+g9dd45fe+chromium-91.0.4472.114
Chromium: 91.0.4472.114
LibVLC Version: 3.0.16
Voice Server Version: Not Connected
Settings mode: Firestorm
Viewer Skin: Firestorm (Grey)
Window size: 1920x991 px
Font Used: Deja Vu (96 dpi)
Font Size Adjustment: 0 pt
UI Scaling: 1
Draw distance: 1024 m
Bandwidth: 500 kbit/s
LOD factor: 4
Render quality: High-Ultra (6/7)
Advanced Lighting Model: Yes
Texture memory: 384 MB (1)
Disk cache: Max size 2048.0 MB (100.0% used)
Built with MSVC version 1916
Packets Lost: 732/369,067 (0.2%)
July 13 2023 18:42:13 SLT

With less than 8GB RAM and very limited VRAM you are unlikely to be able to use this machine for very much longer for SecondLife. The sad reality of life is that things are getting more demanding on hardware and this machine is significantly underpowered for second life use.

There are a few things that you might want to try.

1) As @Gwin LeShelle pointed out, making sure that you have the latest stable driver for you system (this is not always the newest, and with older laptops newer drivers can cause more problems than they solve)

2) Minimise the memory demands as much as possible.

Set you graphics to Low, everything will look awful, but put up with it and see if it stabiliseand does not flicker.

You can help yourself a lot by restricting the texture size. (paste this into chat and click secondlife:///app/openfloater/preferences?search=restrict ) you'll see this preferences window like this

make sure that the restrict max texture resolution is ticked. You'll need to restart.

If you get it stable and not flickering then you can start to increase some of thew quality settings again.

Please note though, that machine is significantly underpowered for modern SL and it is only going to get worse soon, there's nothing we can do about that really.

July 19, 2023

@Island Granville, firstly welcome to Firestorm; I am very pleased to hear that you are enjoying our viewer.

I would advise you to follow Gavin's suggestions and do whatever you can to enable 10.13 updates. Gavin is very knowledgable (far more than I will ever be) on Mac stuff.

Our (Firestorm) next release will also be moving to 10.13, the simple reason for this is that none of the build servers we have access to support anything below 10.13, and as such, we have had to move our minimum level up too.

We will (as usual) have a 3-release policy where we will not block the current release until we have 3 newer ones. so you have probably a year or so left. In the past, we have also left a specific build available if it was "the last working build" for some given platform, but of course, with that accommodation, you do give up any hope of new features. I'm not sure whether we'll do that in this case (that decision comes from elsewhere)

There are a lot of changes coming to SL, not least of which is improved graphical realism (known in the annoying techno-jargon that people seem determined to bamboozle users with as PBR - Physically based rendering); this is going to put a lot more demands on hardware and may well see the death of many older, less capable machines. If this does apply in your case, then, as noted in my previous paragraph, you'll get extended support in FS to a point, but there is a cut-off, so the more that people are aware and prepared less distressing this will be.

July 19, 2023

12 hours ago, Henri Beauchamp said:

However, the caches (which structure and format are often different) are held in different directories than any other viewer.

Henri, in Cool VL Viewer do you get many complaints about this from the entitled users that we all tend to have at least a few of?

I'm curious because I've been planning on making discrete caches and logs for a while, but I keep holding back, wondering whether I end up with another 50/50 situation where half the people think it's good and half the people complain that now their caches are eating all their disk space. The plan would be to have a per-user cache, which would, therefore also avoid the read-only cache issues that we have today for second and subsequent instances.

July 18, 2023

10 hours ago, BondJamesBond said:

The title mostly says it. I'm using the most recent 64 bit version of Firestorm, I'm running a GTX 1050 TI... I can run one viewer for days without a crash, but if I open a second instance and log in another account... it's incredibly unstable. Sometimes it lasts for a few minutes, other times it crashes within seconds of logging in. Only the second account to log in ever crashes. I get the bugsplat crash report window after most of the crashes. After many of the crashes, I get the bug where I log back in at a location I was at several TPs ago, and my avatar never loads (stays the orange cloud forever) until I relog. When this bug occurs... the game is stable! No crash! But if I relog to force my avatar to load, back to crashing every few seconds/minutes.

I've talked to a couple of friends who've had similar problems dual logging. Has anyone had this problem and found a fix?

Can you let me know (private message if you prefer) the name of the alt that was logged in as the second instance when you crashed and submitted the bugsplat(s)? I can sift through them and see if there is an answer.

Can you check if the same issue happens when running the default (LL) viewer. If it does not then I'll probably be asking you to raise a JIRA (jira.firestormviewer.org) so that I can track this.

At the very least I need to know more about the system how much RAM, VRAM, what are your graphics settings etc.

Thanks

Beq

July 16, 2023

On 7/2/2023 at 3:16 PM, Henri Beauchamp said:

The Cool VL Viewer (not CoolVL, please) uses 512MB as the textures memory maximum size when it cannot detect any VRAM and this can be overridden via a debug setting (”VRAMOverride”) for a system with enough RAM to dedicate more than this to the iGPU...

Ahh Cool VL Viewer, I shall try to keep that clear in future. What I meant about 512 is the resolution limits. When FS is run using the 32-bit build, we force the resolution limit of 512x512, forcing all 1024 textures to 512 max. This makes it a lot less memory intensive to visit texture-heavy places. In the 64-bit version we also have that option as a preference but it is not enforced.

July 2, 2023

As Henri says, you might be able to get online with that just barely, but it won't run any sense at all. These days I would say 8GB is the minimum viable DRAM for basic operation, and increasingly I would be pushing people towards 12 and 16 as the realistic minimum. You can improve things a little by running the 32-bit viewer. Firestorm (and possibly other TPVs such as CoolVL) allow you to limit the maximum texture size to 512 (in FS, it is enforced in the 32-bit viewer and optional in the 64-bit). This will greatly reduce the memory demands but not enough to make 4GB viable for anything but the barest minimum.

June 28, 2023

54 minutes ago, Paul Hexem said:

That's... crazy.

I immediately ask myself how that got enabled to begin with, and why it's even an option, and why it doesn't stand out as different than regular chat...

Created more questions for me, but at least we found the problem.

How it got enabled is almost certainly "you clicked it", probably not intentionally, maybe you were trying to click history or something, if there was no muted text on screen then you'd have seen no change except the subtle highlight and forgotten all about it.

As for differentiation, for muted avatars it will be different. See preferences->colours->muted. But in this case, the fact it is an object supercedes the fact it is muted. For all I know there was a previous JIRA a decade ago asking for that.

As to why it is a button at all? I have no idea, I never even knew it was one. It has been there for a long time, though, and this is the first I have ever heard of it causing an issue, so I am going to have trouble arguing that it is a problem 🙂

However, I have made it so that it will not persist, that way the worst case is you'll be confused until you relog. The other option is to add yet another colour and I don't think that is worth the hassle

And, of course, thank you for helping get to the bottom of it. Today we all learned something new 🙂

June 27, 2023

OK problem has been located. You will kick yourselves when you see it. The blocks are working entirely as designed.

You have enabled the "show muted chat" button. In the example below, GreenSpammer is blocked, YellowSpammer is not.

It is remarkably obvious in hindsight, but I've never clicked the button, so learned something new today, too LOL

June 27, 2023

1 minute ago, Paul Hexem said:

Thanks again for the effort on it.

I do have RLV enabled in the viewer itself, but the only RLV stuff I wear is an item I scripted myself to do some teleports via some of my own devices. I can't imagine it's having an impact other than, like you said, some odd combination that triggers a glitch. Next step I suppose is to export my settings into that JIRA.

I have a custom build, but as don't know if you are able to repro like Tessa can it doesn't move us forward

June 27, 2023

1 hour ago, Paul Hexem said:

Are we thinking there's an error reading the list before the llInstantMessage?

Just for chuckles I'm going to wipe my entire list (minus the current problem person) prior to this weekend and see if it makes a difference.

Not necessarily. I've had another person test the same scenario as @Quistess Alpha and I, and like me they block normally and as expected. I am currently building a viewer with some extra logging in it that might help us identify at what point the viewer gives up and says screw it, let it through. There are a lot of checks and conditions for whether a message is allowed through, RLV, friends only, mutelist, etc etc, so now I am wondering if you have some magic combination of settings that is doing this (or I have the magic ones that make it work)

June 27, 2023

1 hour ago, Henri Beauchamp said:

The mute list is only actually received on first request, at login. The rest of the time, the viewer uses its local mute list. Note that the server got no notion whatsoever about what a mute/block is (it's entirely a viewer-side feature) and only stores the mute list as a convenience (so that for each avatar, the same, up to date list is used when you switch to another computer or another viewer).

Thanks Henri,

Yeah, I was expecting to see at least a processMuteListUpdate() for the initial response though. I've not had a chance to walk it through and see where it goes. It might just write to file then load the cache, which would explain what I see, or don't see.

June 27, 2023

5 hours ago, Quistess Alpha said:
Video: https://files.catbox.moe/z5vq6k.mkv

Log: https://files.catbox.moe/a8mf5n.txt (Very big! I turned debugging on, maybe TMI?)

Script in the mystery cube (no that it should matter too much):
default
{
    state_entry()
    {
        llInstantMessage("68686474-391b-44ea-b68f-9b88a566af9f","Spam");
    }

    touch_start(integer total_number)
    {
        llInstantMessage("68686474-391b-44ea-b68f-9b88a566af9f","Spam");
    }
}

Ty,

my test script is essentially the same (I didn't bother with the state_entry completeness).

default
{
    state_entry()
    {
        llSay(0, "Hello, Avatar!");
    }

    touch_start(integer total_number)
    {
        llInstantMessage("c7d8bc3e-3b7d-45a8-94f6-080913a47999", "spam!");
    }
}

The only thing I see that strikes me as odd is that you don't get any update from the remote server when the viewer requests the mute list. It seems to only use the cached version.

I need to do some digging to see if that is "expected".

In the meantime if you have the opportunity to test the same cube setup on a completely different region that'll help remove that variable too.

June 27, 2023

If anyone has information that is anything other than anecdotal please add the logs and any step-by-steps to the JIRA, it may be the hint we need to determine what this missing detail is.

June 27, 2023

47 minutes ago, Paul Hexem said:

I'll update the JIRA with a screenshot of the blocked resident and objects. Thanks for looking into it.

It actually does look like Governance is returning it and the person is just putting out a new one each week, which gives me a new UUID to block, even while the owner is still blocked.

Thanks, it still begs the question of how that evades the user block; we're missing something here, just no idea what yet 🙂

June 27, 2023

10 hours ago, Extrude Ragu said:

I happen to have a high end consumer machine, not bought so much for SL but AI/Rendering.

RTX 4090 TI (24gb VRAM), 64gb of RAM, i9, nVME SSD's

I was at the opening ceremony and was managing about 15-20fps in ultra. For reference it's usually about 250fps in my own sim. There must have been about 200+ people there, but I found that moving the max avatars slider around didn't seem to affect performance, as though it were the mere fact the avatars were present, regardless of if they were being impostered or not, that was lagging me.

There's definitely some truth in that. In the end an object is an object and the viewer has to iterate over them all, all those segmented bodies out there, while now far more heavily optimised in the viewer than was the case a year or so back, are still hundreds of separate parts all of which have to be properly marshalled. Imposters are "more efficient" mostly by virtue of rendering less frequently but still require everything to have been fetched in order to render them.

I went to see my favourite SL musician (Tally Mercury) singing at SL20B and after fiddling was getting around 20fps (3070Ti 8GB VRAM) with Max avatars at around 26, draw distance 288. I was getting about 9 FPS (IIRC) before I reduced the max avatars, so it made "a difference" but not perhaps what we'd expected. As you can see it was "good enough" to get a reasonably smooth flycam, though obviously the imposters switching in and out is not the best.

https://i.gyazo.com/ead815a44353ff8cae7b0a77d75bb0cc.mp4

Forums

Blogs

Knowledge Base

Posts posted by Beq Janus

Linden Lab

Tilia

Second Life

Connect With Us

Partner With Us