Beatrice Voxel

So, my comment isn't as a developer (I think I managed to compile a few BBS's back in the 90's, that's my sum total of programming experience) but as a server/backend app support person. LL is a client/server system. The viewers are the clients. The good part of this issue is, the clients are actually all capable of presenting the content, they all have access to multithreading CPU's and parallel-processing GPU's, along with good sound and whatever I/O devices you can think up. You think coding a viewer is hard, try coding a streaming-video player with multi-channel sound, alternate sound sources such as descriptive audio, DRM key management, and account caching... and do all that for the Amazon Firestick First Gen, or an old Roku. "I can't get it to play 4k!" well yeah, because the damn thing has networking, processing, AND heat dissipation bottlenecks, it's not gonna happen. The hardware our viewers run on are top-grade, for the most part. And for those that aren't (old Android tablets, iPads, etc) there's stripped down versions like Lumiya that sacrifice world-rendering for the simple ability to connect to the Grid and communicate. The bad part is, we've layers upon layers of onion-skinning. SL is built on a decades-old rendering engine that was originally used for CAD programs in the 90's, for Goddess' sake. And we still have content inworld that was made for those early versions. Backwards compatibility, taken to a ridiculous extreme. Plus we have to deal with content creators (*cough* users) that A) aren't trained on proper optimization methods, B) aren't held to optimization standards, and C) aren't paid to stick around and support their work. So there's a LOT of stuff in SL that is just plain bloated. And since the viewers must at least try to render pretty much everything one could encounter in a given sim, we can't just deprecate flexiprims, or enforce texture sizes on nano objects, because then someone's stuff would break and they'd be upset. Or, maybe we can. The idea of rendering imposters is a good one, especially cross-region. If you're in one region, everything nearby is being rendered by the same SL server instance, but what you see across the border is being handled by a different instance. It doesn't seem to me to be a bad idea to take 'snapshots' from the centerpoint of one region (maybe in series along X, Y, and Z axes) with all of the in-region stuff derendered, and use those to make imposters of what's out of region. That would mean significantly less data to pass to the viewer. Perhaps this would be done for regions further out than 'next door' if you wanted dynamic rendering a little further out, but then again, regions are decently sized to imposter the neighbors. For the inworld texture imbalance, the viewer can determine 'scaling' by distance OR by size, if something is X meters away, or smaller than Y centimeters in size (perhaps both), the viewer would downsample textures that are "too far" or "too small" to render given the viewer's viewport size and camera position. Cache the originals, but also cache the downsample for actual rendering. The same goes for scripting and animation. If someone's avatar is too far away, I don't give a ***** about their facial expressions or finger movements, or their hair blowing about. The fact that I can see them at all is enough. Sure, render the details when the camera view is close enough to benefit, but until that happens, it's wasted processing on the viewer's part. The OTHER elephants in the room are all those "listener" scripts for resizing and retexturing and so on and so forth. The only viewer that they should impact are those of the wearer - push those clientside as much as possible. When they're activated, and a shape changes or a texture updates, relay THAT to everyone else. But forcing the server instance to keep track of everyone's Mama Allpa pregnancy status when no one else is paying attention is just... it's a waste of processing time at the server level. This means a major overhaul to the scripting language - it would need to be broken into two parts, the server-side scripts that allow data to be communicated between avatars, or from sim-placed objects to avatars, and client-side routines that listen for inworld or client queries, and provide updates via HTTPS calls. And yeah, it'd be nice to work out some kind of way to get around the alpha clash issues. Again, SL 'knows' positions of objects relative to the camera on all three axes, so I'm a bit confused on how there's still a problem of stacking order. Given objects with alpha channel textures A and B, and non-alpha backdrop (or world sky) C, if (A closer B closer C), then render from C forwards. I'm sure the issue is a lot more complex than that, probably an OpenGL limitation, but... yeah.

So, first off, I use four mesh bodies "regularly", in order of preference/usage: Slink Hourglass - my 'comfortable' body, one that fits my sense of proportions the closest. Maitreya Lara - when there's clothes I REALLY like, but aren't available for Slink (and I've told designers this, I'm getting to the point where I will stop buying from them if they can't support but more than one or two bodies, I get that they have limited time and resources, but ... I have limited Lindens to spend, too.) Belleza Freya - for SL pregnancies and BBW 'play', it seems to hold the best 'shape' when you expand certain proportions. Not sure why the others go all egg/torpedo, I guess the rigging is a bit off. DEV Nana - a GORGEOUS "fitness"body, not musclebound, but nicely defined. "Muscle" skins that are made for it bring out the UV map really nicely, but normal skins still have a nice toned look to them. THIS BODY NEEDS MORE ATTENTION as an everyday body, seriously. It reshapes well (see above) and exudes a lovely confidence. It comes with its own head, hands, and feet, but these can be swapped for Slink hands/feet decently well (there's a bit of clip) and with a decent neck blender works well with other bento heads. Sadly, you can count the number of clothing makers that support it and not run out of fingers. (This may be due to the body designer being a non-English speaker, and also being the creator/administrator of the SML Fitness mini-game - they do not have a lot of bandwidth for support issues.) Bodies I refuse to buy, either because they're not well supported, because they're not well made, or because they're straight-up too expensive: Kupra - I've tried the demo, it looks nice if you want the latest style of thicc, but frankly, it looks like a slightly toned down SKING Brazilia, and it does not respond to tummy changes hardly at all, why is that? Legacy - I was around during the TMP days. The big gripe was that anything made for TMP (skins, clothing appliers, etc) all had to be uploaded to a third party server and thus give up chain of custody of your work. That, and it's really pricey, and if you want a 'pregnant' version, you pay the same price again for slightly tweaked rigging and a different UV. LoveMomma - As above, it seems a lot of money to pay for a specialized body, and then pay again for an 'egg' to put thru their in-house 'system' to end up with a Zooby. I'd rather just get the Zooby at the end, tbh.

Oh dear... how DO I look today?