Wulfie Reanimator

You're about 11 pages late. The Lindens are working on it and actively reassessing L$. https://community.secondlife.com/forums/topic/436499-linden-dollar-assessment/

In all seriousness: Unless I missed something, nobody suggested that graphics settings should be closed off and only adjusted automatically, which would take away control. Adding a feature to enable auto-adjusting is adding convenience without taking control. Other games have features like this, the easiest of which to implement is lowering the render resolution dynamically when FPS drops below a certain threshold. Same for shadow and max texture resolution.

"Infantalizing" the end-user with convenience is absolutely a good thing. Political tribalism is absolutely not. I'm a sith btw.

Psst... Firestorm has a setting to limit its own performance when the window isn't in focus... If you turn it off, you get 100% identical performance.

Why not? What kind of error do you get?

How did you even FIND this thread?

And the part people refer to as "SL" is actually the viewer, which is open-source that anyone could modify (and do). The problem that "SL doesn't properly utilize hardware" is a fixable problem that doesn't rely on LL.

Occlusion exists in SL, you can even watch it via Developer > Render Metadata and you can read more about the specifics here. That page hasn't been updated since 2011 so it doesn't mention how mesh is handled. Do they occlude based on visible tris, bounding box, or what? It seems to be visible tris, at least partially, but I'm not 100%. It's also easy to test. Go to mainland, max out your draw distance, and put your camera inside of a solid room with no gap or transparent window outside. Your FPS will increase significantly. For example, in a "busy" area I go from ~10 FPS to ~20 if I'm in a dubious mesh hut. About ~25 if I cover my camera with a prim cube.

I might agree on account of SL not having very complex shaders that could be used in other games to get even more detail onto the screen from textures alone. Parallax mapping and cel shading especially come to mind, but any custom shader (for pixel, vertex, or geometry) would be great. I still disagree with the argument that using textures for detail would cause more lag. Only if the textures are many or unnecessarily large and the detail isn't substantial. Don't worry, that's not what I'm saying. I'm currently studying and writing my own (basic) renderers in C so I have a particularly good grasp on the concept that "nothing is free." Generally speaking you should be able to cache those calculations so that you don't have to literally go over the whole mesh all over again, especially the "relevant" faces so you wouldn't even check the shadow-side of an avatar for example, so the subsequent passes over the same mesh/object should be significantly cheaper. I don't know if viewers do this, though.

While I agree that you're more likely to get the "best" result by hand (and I've even made threads demonstrating how easy it is), it's not inherently bad to use a "magic button that does it all." From the video above, you can see that the plugin produces very clean topology for hard-surface models (the gun), but organic shapes (the skull/helmet) are handled very poorly if (and only if) the goal would be to rig it. It's very much about context and trade-offs. As you know, time spent is an important factor when working to a professional capacity. If you can just press a button to get a clean model in 5 minutes instead of spending 20-60 minutes on it, why wouldn't you do it? Same applies for all areas of the entire workflow. Not doing everything by hand doesn't reduce the value of the final product.

I strongly and respectfully disagree. Obviously the first thing is that Second Life is a game as far as any sort of tech talk is considered, there's no way around that regardless of your beliefs of the platform in general. For online games, bandwidth is the #1 priority over anything else. It doesn't matter how good the game looks if you're rubber-banding, stuck running in place, or dying in safety because you weren't safe on someone else's screen. Players will get upset over ping before anything else. In SL, interaction isn't very time-critical and that has been normalized over its entire existence. Textures are a big performance cost in real-time rendering in general. Not just loading them into memory, but drawing them from memory onto the screen as well. I don't think there's anything special about how LL has "optimized" textures, besides using a weird format that allows for "texture LODs" while bloating the total download size. I think @NiranV Dean has talked about that in the past. The way creators use textures isn't anything resembling performance-concerned development. I don't think I need to bang the drum about 1024sq textures, but generally speaking you should treat textures just like geometry. "Average pixel density" per area should be a goal just like for triangles. The problem is of course that there is no quality control or an enforceable standard. Triangles are relatively cheap. The difference between SL and other games is that SL scenes tend to be fairly static. As in, new objects/resources being created is fairly low. There are exceptions, like sandboxes or combat sims, but your average mall/club/hangout area tends to stay the same. That's why most games need to optimize more heavily -- to account for more things appearing into the world. The main exception is avatars, which are by far the worst offenders in terms of performance. They're like walking bombs, ready to destroy your framerate with all the excess everything. In games, even avatars are created with resource budgets in mind. There's some upper limit of characters that will be in a scene and all of them have to work for that limit. In SL, that limit basically doesn't exist. You can have up to (38 * 256 * 174752) triangles attached to your avatar. That's a "limit" of over a billion. Per avatar. More realistically I have seen multiple avatars in the same location with over a million visible tris, never mind all the other avatars and the world itself. TLDR: If people would develop content for SL exactly as a game developer would, we would see a significant positive change. That's neat.

Like Dessi explained, scripts cannot be copied. It's simply impossible because the "code" is never communicated to the viewer. They only exist on LL's servers, we can only observe their effect on the world. The same goes for all object contents. An otherwise "flawless" copy is as easy as it has ever been. It's easy because the viewer has all the information about the visual appearance of the object, including rigging data. If the viewer didn't have that, it couldn't display it. You can't copy an object from inside of another object because the viewer has no knowledge of what the object is, other than the fact that it's an object with a name. Similarly, it's theoretically impossible to create new objects with someone else as the creator, because object creation is handled completely by LL's servers. The only way to get around that would be if LL's servers trusted any of the data it was receiving from a viewer requesting to create a new object, which could "trick" LL's server into thinking the object was actually created by someone else. That's highly unlikely. A simple way to "hide" the fake creator is to get a transferable object from the real creator (such as a prim) and make that the root of the copied linkset. That way they can mask the name if you only select the whole object, but if you select any other link in the linkset or right-click>inspect, you'll see the actual (fake) creator. Considering the amount of people just in this thread reporting that they've lost rare gachas, I don't think there's any real reason to think there's anything being copied. If the fraud is as wide-spread as it seems from this little thread, it's not hard to imagine there being a large supply of rares just waiting to be sold later.

The device that logs into SL is not your desktop/tablet/phone/fridge. The "device" is within Speedlight itself. No matter which device(s) you use to view the webpage at any (or the same) time, only one "device" is constantly logged in.. and it's none of the ones you're touching. It's "seamless" because there literally isn't a seam that could exist. The webpage is there only to display the data received by the viewer, but the viewer doesn't depend on the webpage to stay open or even exist.

I believe the notification OP is talking about was the built-in "Your HUD has many textures, this may negatively impact performance." warning. This is normal when the viewer is taking its time to download all the data about the mesh. What you saw was the mesh without rigging. It only looks correct after the rigging data is applied.

Although you may have bought your own item back, there's no way to create new copies of an item with the real creator's name. There's nothing in what you described that would let us conclude that anything was copied. Edit: Oh wait, woosh. You bought from someone else and you were still the last owner. I got it, weird. Of course they won't. That'd be a really dumb thing to do. Offer it as an option and incentivise its use, but don't force it. Did you miss the Tilia kerfuffle? You didn't even have to sign the Tilia agreement. (P.S. I would use 2FA.)

But they don't have to be inworld to make the purchase, even if some are.

I was so confused until the halfway point...

Are you concerned about the performance of browser-based rendering at all (low FPS for the user)? Or does it not matter since it isn't using your resources?

Ah yes, a witch hunt. Very classy and guaranteed to work.

This is still false. A rezzed mesh object that has less textures, VRAM, links, and triangles can have higher complexity than other objectively worse items.

Bit annoying when people keep saying just "lag" without describing it when there are many kinds with totally unrelated causes. Framerate? Reduce mesh/textures. Unresponsive scripts? It's complicated. Hard to move? Possibly physics / agent updates. And that's not all.

Just to clarify in case this detail isn't clear (and to anyone reading to explain the drop): Script time is an average over the past (up to) 30 minutes, or since the script's last rez or restart.

Yeah, from the second link: That's a pretty scary content-destroying bug. If the viewer fails to resolve a texture UUID, it goes "whoops, dunno what that was, but it's this now." That looks to be exactly what happened, based on Chic's screenshots and the fact that she has modify rights to the plant.

When I say "normal" I mean "the viewer is specifically programmed to unload textures from memory when they aren't needed (in view)." It should be your normal, unless you are using a viewer that isn't LL's, Firestorm, or Black Dragon and it does things differently. The textures aren't unloaded immediately, but pretty quickly. (Like 5-20 seconds?) I believe you when you say "it's not your normal" but to me that sounds like there's more going on than your basic description of what happened.

It's not nesting. It's one line, that's it. Nothing needs to go "inside" of it. There's no Else or Else-If either. Also the griefing doesn't have to be targeted for you (general you) to be affected, if I did what I explained earlier, I'm almost guaranteed to break products from many creators at the same time. I just like plugging security holes, sue me. 😜