Toothless Draegonne

Haha no. If that were the case, you'd use a free account, buy the minimum number of linden dollars to upload your assets, throw stuff on the MP and have zero "land" whatsoever.

This is not a one-time issue. Avatars appearing literally brains-first, followed by head, followed by body, followed by clothing, is a thing that has happened for years. Regions being low-FPS messes once a couple of dozen people are in a crowd has been a problem for years. This is a solution to these problems. Some people do not want a solution to these problems. I stand by my words.

De-linking or making certain faces transparent is a two minute job that can be done on a copy of the body before descripting. Attachments are a two second job. I stand by my words.

As much as this is very much a Lab problem, I've always recommended making an outfit that is Barbie and Ken levels of nothing when nude, or outright has everything under the clothes detached or invisible. It's not only leaner on your and everyone else's GPUs, easier on the servers and just better by so many metrics, but it also prevents stupidity like this. You want to do the naughties, that's what outfit changes are for. It takes like, two seconds. Of course some people are just weird, but I'm talking to the relatively sane people out there.

I currently run a publically-available sandbox. Do I pay a fee for people knocking together random bits of kit? That sandbox has landscape items that were placed there by someone else. Since then I've bought my own copies of these items in case I want or need to do some remodelling. I wouldn't have bought matching items from that creator if I didn't like the results. What happens in the case of a shared region? I'm probably in the minority of people who actually own one or more entire regions. Many are group-owned. Some are mainland collectives putting their tier together. Does everyone have to buy a copy of everything used because they're visible to more than just the person who bought and rezzed it? If I buy a drill, do I have to pay Hilti for every hole I drill with it?

Unity tried something very similar to this with the now-infamous attempt at levying a run-time fee. Look how well that worked out for them. No. It is a non-problem. Being upset at making some money instead of all the money is something that needs a solution, but not a solution that changing how Second Life's permissions system works can solve.

Because this is a platform with an above-average number of absolute psychotic psychopaths, where few are to be trusted any further than you can throw them, and where anybody can make an alt with almost zero effort.

Only the KV store is grid scope. The permissions side of experiences is still land-scope. This means you have a way for scripts across the grid to access the same pool of memory for whatever they need it for, without having to open URLs and talk with servers. (Or at least that's how it was last time I checked. Any change to that is extremely recent.)

In-world building. You can just download a viewer and use it. You can be "deaf and mute" and still enjoy it. No Steam. No EGS. No Facebook goggles. No worries. Now they just need to make those server prices more sane, and they might attract more people. Yes I said server prices, because regardless of what goes on in the simulator back-end to make a region go, Joe Normal is going to ask how much a server is so they don't have to deal with someone else's bull***** on their server, scream, and run.

It's a part of how the viewer now copes with displaying HDR content on non-HDR displays. You now basically have a virtual camera iris that closes or opens, depending on the brightness of what you are looking at. You might want to consider filing a feature request to have a fixed iris available in the Phototools window. However be aware that if such a thing existed, you'd have to be careful when using it so that stuff doesn't get blown out in the daylight, or damn near impossible to see in dim areas.

That's a known issue with vivox and occurs on teleports within the same region. The workaround is to uncheck/recheck voice in the viewer's volume sliders to give SLVoice a kick. The voice indicator on your Nearby Chat window should turn from yellow to green after a few seconds to indicate that voice is available again. I'm not sure it will be fixed, given vivox is on life support as-is.

Guess I should put away my coin gun and stop doing drive-by shootings? Nah really though, some people just like to throw lindens around for funsies. And others just use scripted objects that make it look like they're giving you lindens. It's just a Thing That Happens. Welcome to Second Life. People are crazy here.

Note that using the existing megapack has other advantages. If you're using the same materials as everyone else, the asset servers don't have to work as hard, the assets stick around in the fastest parts of AWS for longer, generally SL runs better. I'd be surprised if the Lab hasn't considered folding them into the stock library.

You already kinda-can with a script, and there are already systems that will boot people over a certain render weight (along with script count, script memory and such), though render weight is uh, notoriously not a brilliant metric.

Use static probes and the probe only has to bake the image once. You don't need to use probes everywhere. Especially in wide-open areas at ground level, you can just rely on the autoprobe. Probes can be spherical or cubical. Spherical probes as far as I'm aware are cylinder-mapped, like sky-spheres. I couldn't tell you exactly how the cube maps for cubical probes are stored, but I would be surprised if it's just a straight-up horizontal cross. And again if you are VRAM-constrained, turn your reflections down or off. Use compressed textures. Use 512px max textures if you really must. These are all things you can do to run modern viewers on old machines, and have always been the things that matter much more than "turn ALM off" in prior viewers.

If you don't need to use the emissive map in a material, you don't use the emissive map in the material. It is then a material with three textures, not four, and three is the same as three.

I'm not sure how you missed all the other times I've mentioned that there was some kind of regression between earlier betas and the release of PBR viewers to the public, but I'll say again that I have ran PBR viewers on iGPUs in a medium to high detail level. I was the first to point out in the Discord that you love to hate, that hardware like Steamdeck and Ally needs to be a supported use, even if you shouldn't expect to be able to run full ultra on those platforms. If someone doesn't know how to disable reflections, mirrors, point lighting and shadows, to drop their graphical settings down to something that their PC can handle, limiting textures to 512px if necessary, then no amount of sticking with less efficient and objectively worse rendering pipelines is going to help.

When you can have emissive be a part of the material, rather than have to use the diffuse alpha channel as an emissive mask, and possibly double up with an onion layer, then yes, four is less than quite possibly six, plus extra geometry.

It's one of those advantages of materials as an asset. You don't have to care about what textures and tweakable parameters are required for each face of each link in every object you make. You make a cube, you drop "concrete" in the slot, you now have a concrete cube. If you want that to be "concrete, no normals", well, just don't include the normal map.

The pack isn't just a bunch of materials. There's some boxes-in-boxes but it's mostly nicely sorted as categorized and rezzable galleries where you can pick materials from a preview as needed while you build. Pretty nicely done.

Another thing to consider is that the pack is full perm. Those marketplace results probably don't include people just giving each other the box.

It really isn't. There might be some extremely over-textured, over-polygonned godawful frame-gobblers that drag the performance of even the best machines down to nothing, but that in my eye at least, is not "better". You know what I see as better? Having a rendering pipeline that actually offloads stuff to the GPU, has more advanced shaders that can do more with less, that have the ability to make stuff look good without pre-baking everything so it only looks "right" when viewed at sunset during a simulated Autumn evening at 52 degrees latitude on planet Earth with moderate cloud cover, or whatever the creator recommends. What I see as "better" is only having to put all the texture maps and tweaks to make a material look like a thing into an object once. To actually have a "material" asset that can then be applied to objects all in one go instead of having to re-do the same steps multiple times for every tan leather item that you want to look like "tan leather". Despite whatever happened between the more performant PBR betas and release to make the initial release slower, you know what's going to achieve all that? Oh I think you know what my answer is going to be. The PBR update is so much more than "shiny things be shiny", and it's only the first step in proposed updates to uplift the entire system to something more approaching a mid-2010s standard rather than late 90s. Personally I'm hoping the rest of the gltf spec gets implemented in a useful way and we get to have scenegraphs and shapekeys... like every other 3D chat room out there (that were all built from the ground up using physically based rendering).

Something like that was already in (pre-PBR) viewer code and is why Intel Xe96EU chips did far worse than they should have, with VRAM limited to 512MB on a system that has a unified memory architecture. "If Intel Then Potato" is not robust code, and isn't even true (these days).

A long while before PBR was even a pipe-dream, most of the people I spoke to who "couldn't use ALM", were actually "couldn't run with shadows". Turning ALM off also turned shadows and projectors off, so of course, that translated into higher FPS. Now there was some odd regression with performance that happened during PBR's development which I'm sure the Lab is poking around with. I know the ROG Ally certainly used to be able to run the pre-release PBR viewers at a medium to high setting, and that's an iGPU, albeit a more modern one. It still can, but it'll probably splutter and die in really busy areas. And you can still disable a bunch of the more demanding things that PBR enables. It's just that now, you get to find out that you were always a chrome-dome with an extra-shiny head, regardless of settings. If the performance regression gets dealt with, hopefully the whole low-end-computers issue can be finally put to bed.

Now that the experience KV store is grid-wide and doesn't require the experience to be added to the region/parcel, there are other ways of checking on script status grid-wide without using HTTP. How many new scripts are using experience KV stores for that is another matter.