Kathrine Jansma

The N4020 actually has a 2.7 Ghz boost, so its not abysmally bad. Just bad.

Both AMD E-300 und the Intel Celeron N series are pretty low powered, but it is an improvement, according to some benchmarks. https://cpu.userbenchmark.com/Compare/Intel-Celeron-N4020-vs-AMD-E-300-APU/m1134763vsm2468 https://askgeek.io/en/cpus/vs/Intel_Celeron-N4020-vs-AMD_E-300 I would still consider it a pretty low end/entry level system. You might see a small improvement, but the constraints on memory and iGPU are still pretty tight. Just comparing the GPUs recommended by Henri in this thread with the iGPU UHD600 is quite a difference (https://askgeek.io/en/gpus/vs/Intel_UHD-Graphics-600-vs-NVIDIA_GeForce-GTX-1050-Notebook) like 15x slower or so. But faster things with dedicated graphics cards are in a different budget class as well, even refurbished ones with dedicated graphics are in the 500$ range.

"Not responding" is either a sign of a really bad application that blocks the application main loop, but typically it is some crappy system environment slowing down system calls that should be rapid. The SL viewer has very few spots during startup that could do that, but once you are logged in, it should not happen, as Coffee said above. Typical reasons in a system: Failing harddisk/SSD that takes forever to respond to trivial requests Crappy network, especially DNS resolution or background CRL checks AV/Endpoint protection solutions that misbehave randomly, especially the kind that injects code into other programs for security Broken network or graphics drivers (but any driver, especially filesystem or network filter drivers can do that really) Most of those should be ruled out by switching internet connectivity and hardware. But the advice to try one of the TPV viewers for comparision isn't a bad one either, most offer some improvements over the offical client.

URLs were never meant to point to unique objects that do not change. Especially if the standards forget to add any meaningful cryptographic signature of the contents. The Web3 stuff seems to just sign the URL which is utterly useless. Just read about the prank done by Moxie Marlinspike about his NFT that looks different depending on which client you use: https://moxie.org/2022/01/07/web3-first-impressions.html

The easy way to get the cache on Windows would be either a docker container or Windows Subsystem For Linux. No idea if it is worth the trouble though.

There are some generic virtual desktop services that offer similar things that would allow installing a SL Viewer. Googling finds some of those, for example https://shadow.tech There are probably a lot of alternatives around, that offer virtual desktop services.

Yes, the older versions of the offical viewer had Pie menus. But as usual options sometimes survive such minor transitions, when the Goddess of grepping isn't favourable that day.

Average users do not own VR headsets. So you are totally right that SL isn't setup for a smooth experience for the masses. And it is not something to advertise aggressively as "working". However, this does not prevent VR to work good enough for a minority. Even with the broken SL rendering engine, content, etc. The OPs message is evidence to that effect. So why inflict the wrath of the majority onto the happy few that are okay with the current state of things? SL has some significantly different usage profile to an AAA game, so glitches in framerate might be totally not a problem, when you just sit in a club and do not move around all that much. And with just 1-2 avatars around, a framerate of mostly 100 fps might be doable with moderate settings and in some places.

If you want to optimize, measure first is surely good advice. But Nirvan has a point that sometimes usecases seem not to be clear, due to lack of using the product by developers. So often the metrics record and track the wrong numbers (see ARC...) or incentivize the wrong behaviour (LOD vs LI). Regarding the number of bytes vs. number of requests. Once LL deployed HTTP/2 or HTTP/3 instead of the a bit old fashioned HTTP/1.1+Pipelining with all its problems, the difference would probably tend to just look at the bytes sent, at least for anything thats not purely latency bound. With pipelining the overhead for more requests tends to be a little higher and the effects worse as well. Modern I/O subsystems and even network links in the 50-1000 Mbit/s region can deliver a substantial amount of data in the background, if you let them. So yes, maybe it would be a waste to load everything at max resolution/LOD, instead of range requests. Especially when at 512m draw distance..., but if there is bandwidth and cores left to handle that, why not give it a try. But some simple math discourages the "load at max resolution", just looking at my caches. Large textures seem to be at 512kB/Texture, so 1000 Mbit/s just allow me to fetch 250 textures a second. Large assets and objects tick in at around 2000kB/Asset or more, so i can just fetch around 50-60 per second. Flying over mainland i see like 500-1000 active texture fetches in parallel (at 512m draw distance with 14 texture decode threads at work). So guess i tend to be bandwidth limited in many cases and reducing bandwidth usage might be a good thing. For a small club with 64m or less draw distance, sure, grab all the content at once, cannot be THAT bad, but most small clubs feel like rezzing textures near instantly, only meshes float around a bit and stream in slower. Might be worth another round of optimizations. And then stop bottlenecked on the legacy Open GL render pipeline.

Sure, the true hardware costs alone are probably very small. But one could spin a plausible sales story, why offering "part time" sims is in some way cheaper, without directly cannibalizing the full sim rent and cashflow. LL probably does not have infinite deep pockets, so keeping a stable cashflow from land is essential for survival.

I did some live action role playing, so i know it can work even for role-playing. But for paragraph style roleplay it might be detrimental, sure. But on the other hand, its just the difference between wearing a mesh head and not today. If you do not wear one, you do not have the expressive face either. It just makes it easier to use the expressiveness the mesh head already offers, just avoiding the clumsy HUDs and gestures needed now. Voice and voice morphing instead opens a whole new parallel communications channel that does not mix well with parallel chat based roleplay. You use one or the other, and struggle with accents, mumbling and all kinds of background noises and technical issues. Not to mention the fact that people might be uncomfortable using voice for a million other reasons like gender identity, no nice sounding voice or voice not matching the character they want to play. Voice morphing only goes so far. I see the cheering of my business colleagues about gestures and facial expressions using comic style VR headset systems to do sales talks or just sitting around the fireplace and talking with people in a very stripped down VR environment. It really makes a world of difference to them. But those are the same people that insist on voice or even video chat instead of just dropping emails or chat notices or tickets for trivial stuff. Or wanting a video as explanation for everything, because they hate reading textual instructions. Just totally different type of people.

Not quite. Currently when you buy a private island, you have it online and processing scripts, being visible for visitors etc. 24/7. This means LL has to fire up the server and have it run, used or not, even if no one is around. So LL must charge high land prices, as the property is available 24/7 and creates costs to LL 24/7. But now LL moved the system to the cloud, which offers spot prices for computing resources. Now land has at least two significant parts: 1) Persistance of what you build there, e.g. things look the same when you return the next time. 2) Being accessible 24/7 for everyone to look at/visit. If LL limited the 2) part, it could shave off a lot of the costs. The costs of running a region are probably in part CPU costs of the simulator and some costs for the shared inventory database and traffic. If one keeps the persistence, the costs for shared inventory stay the same. But the costs for CPU/outgoing network traffic is billed by minutes used by AWS, so LL could offer a private island that was just around temporarily and reduce the costs. Obviously this would only work well for private islands, not so much for mainland/partial regions. So one could imagine a scheme, where you buy a full region for 175$/month, on top of your premium account. But you select a "weekends only, Fr-Su" option, and the costs drops to maybe 80$/month, as LL has less infrastructure costs to pay and could pass on the savings.

I mostly agree with Henri, even if i see the use of a camera for more expressiveness (e.g. control of mesh head facial expressions) as a good idea, much nicer than gestures and clumsy HUDs, and unlike voice morphing, which needs the will to use voice as prerequisite. But the vast marketplace and inworld content is a real plus. Like i wanna decorate my house, and i am 90% certain i will find everything i need in acceptable quality. A bit like going to Amazon and having the same expectation. Okay, marketplace search could use a few person years of engineering and tuning to be top notch, but the vastness is already there. Just imagine Amazon wants to start over and excised 99% of its existing content to focus on high quality. Would that work? Probably not. But of course, you can improve on the top to make older content obsolete. Like older prim, sculpty stuff. It kind of still works, mostly. But looks bad, so people usually move to more modern mesh things anyway. Add incentives like LI calculations that favour more modern things, and the old crap will fade out over time. So improve at the top, do not throw out the base. Decent, easy to use build tools are a great way to attract and keep users. Just watch the joy of building stuff. Thats kind of 99% of Minecrafts glory. The entry level tools in the viewer should be good enough for satisfying results for average users. Sure, having power tools like Blender etc, and the steep learning curve attached is a must for good content, but a vast amount of mediocre content beats singular great items by lightyears. At least in the eyes of users. Even if it makes developers and artists cry... I could also imagine, that a lot of people would like "temporary land" options, and with the cloud and getting servers on demand, it could even work out. Like imagine you only really have some time at hand at the weekend. So you would love to have your magical island appear on friday afternoons and vanish monday early morning but when the land returns next friday, the builds are as the last weekend. Great to build stuff, enjoy it etc. Offer it for 1/4 a homestead and you would get a lot of people interested i guess. That would allow more people to have some great building options, without the rather high cost of permanent land. The render engine must be good enough to let people with average notebook devices (iGPUs) or mobile GPUs to enter the world and enjoy it. It would be cool if it could scale up to provide VR headset ready fps, but thats a stretch goal. Nice to have, but not essential.

You could try to experiment with the texture decode concurrency. It is set to 0 = auto, which is usually good, as it uses the CPU cores you have available and really helps with decoding lots and lots of textures you load when flying around with large draw distances. But it might cause some side effects of slowing other things a little. You CPU has 8 cores/16 threads, so try to set it to 1 for testing if it fixes your freezes. And if it does, try rising the concurrency a bit too, like 2, 4, etc.

Really impressed by the script performance improvements. It feels like at least half a magnitude better than before (mostly in 50% percentile latency for some stuff) for a script i used that does some script heavy stuff before and usually was too slow. Now it gets very acceptable performance for my usecase. It is a kind of radar script that collided with a monte carlo simulation, and i added latency measurement before. In the old world of less than 100% scripts run it suffered quite a bit. But now it gets in the realm of being useable.

Probably some broken CSS formatting? It looks like the Language dropdown overlaps with the logo for you. Try resizing your browser window, it might fix it. Could also be a ad blocker that runs wild and removed the wrong thing.

This has probably nothing to do with the SL viewer. It looks more like a windows or device driver error. But that might be triggered by some function the SL viewer calls. Microsoft list the following for the errors you mentioned: https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/bug-check-0x154--unexpected-store-exception https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/bug-check-0xef--critical-process-died https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/bug-check-0xc000021a--winlogin-fatal-error You could try the troubleshooting tips listed there. It sounds a bit like memory issues or a problem with the login process, e.g. could be drivers like fingerprint readers or similar devices.

I wondered if there is anything like Teleparty which synchronizes viewing streaming services like Netflix, HBO etc, between multiple people via a chrome extension. https://www.teleparty.com/ Would be a fun metaversy thing to have inside SL to watch such synced-streams with a group of people and chat/talk about it inworld. Did anyone experiment with it or see something like that working in SL?

Probably not all that much. If you google around you find a few comparisions, for example the graph here: https://www.cpuagent.com/article/ram-size-speed-gaming-impact The second RAM module is more important, the actual speed is only a big concern if you used a non dedicated GPU or try to get to really high FPS.

A second and maybe a little faster RAM module would be good. 16GB is fine, 8 GB can be limiting. The CPU supports two memory channels, so you want two RAM modules to use the memory bandwidth. In addition, the CPU supports RAM speeds of 3200Mhz, so 2666 Mhz is a bit on the slow side.

In viewers with concurrent texture decode threads (Firestorm & Cool VL Viewer) it might also depend on the concurrency level and CPU count chosen. Try the texture fetch/decode boost after TP/movement in the Cool VL Viewer, it massively improves the time for textures to show up. Meshes still take quite some time to materialize, but i get close to zero grey textures with it even moving.

TextureTest2 looks useful for tuning the pipeline. But guess i need a bigger network pipe (as it can saturate my 100MBit/s link but not the CPU when running with 16 texture decode threads in CoolVL Viewer and forcing full size texture loads).

The hard part with benchmarks is usually to come up with useful metrics AND make the measurment halfway reliable and repeatable. With around 500 functions, which one do you care about? Sometimes performance is a little suprising. E.g. i tried to script some system to detect objects based on proximity and wind etc. (basically a primitive smell simulation with a bit of monte carlo sampling thrown in). I assumed it would be much faster to detect statically named objects in range via llSensor() as thats basically a trivial geometry query with a static condition, which should be super fast if backed by any kind of database with spatial index (e.g. https://en.wikipedia.org/wiki/SpatiaLite ). Turns out llSensor(fixed_name, ...) is so high on latency that it is around 10x more efficient (for latency) to drop a script with a listener in every single target instead and send out static pings and listen for the echos. Which is sad, script spamming for no good reason. Other parts of the code create random numbers for a Monte Carlo simulation and get starved on the llFrand() performance (and would love a CSPRNG like /dev/urandom) so would see improvements there. Another part does vector manipulation and distance calculations for many objects, which would really benefit from SIMD optimizations. So if the server JITed those loops to use AVX it would be awesome. But totally different performance metric again. I'm surprised the script works at all, but it is super lag/script performance sensitive.

TextureTest2 seems unaccessible. TextureTest works, MeshTest2 also, but could not TP to the TextureTest2 region on the Beta grid.

No shadows = Faster. Enable Vertex Buffer Objects is on for all. Disabling it makes things slower. That is with just my AV in sight. The 9/20fps max are with a club with around 20 AVIs with lots of rigged mesh attachments.