Polymath Snuggler

LL has to make money somehow. The business model for SL needs to evolve as people aren't really interested in owning land all that much, but constantly shop. It's been 15 years, I'd say some updates are needed. I'm not pleased about shouldering more of the 'keep the lights on' bill, but servers don't run for free. It's a bit of a squeeze, but really, if it's THAT much of a problem, like any other business out there you can just raise your prices 9% and offset it to the customer. It's not great. But that's how economies work. At least as a business, you have that option.

Yes, that's always been a functionality ~ but that doesn't invalidate the fact that that is mandatory for groups that are 5000 + .

I'm mostly okay with the state of things. LL has been declaring the intent to switch revenue from land sales > microtransaction taxes for years. I'm not pleased with it, but at the same time it's still better than every other platform available at the moment, so. I'll pay my taxes and not grumble about it... for now. If there's another fee hike and I'll start to grind my teeth a bit.

Actually that limitation only exists for groups in excess of 5000 members. For the same reasons that they wanted to reduce the number of group slots ~ they also needed to limit groups with >5000 people from having interactions for the same "this is breaking SL" reasons.

Woo ! Thank you for listening, and staying up till midnight reading forum posts from angry people! It's amazing to have people who care about the platform, it's also amazing to have Lindens who are willing to stay up until midnight dealing with angry customers just to listen to us. Thank you again !

https://jira.secondlife.com/browse/BUG-227067 I already recommended this change / fix.

90,000 people * 7 groups per person = 630,000 group memberships * the average group size of dunno ... 400? Is 242 Billion connections that would be saved. Seems reasonable to me.

That was more or less what I was implying~ without stating specifically.

Because some people don't want to have people who were a part of their SL~ but aren't anymore.... removed from their groups, even if it is for expediency ~ that sentimental value is sometimes more important.

I'm not so sure about the accuracy of that statement. At least on Firestorm , I'm pretty sure they only load on demand. ( IE you look at the chat list itself )

Well, think about a group like Firestorm Support English ~ it's the most popular viewer out there and there's 24/7 support for it~ a decent fraction of the entire SL population has joined that group at some point or another ~ most haven't left it.

I'm just going to point out for everyone here who says "The Lindens don't care and just want your money" ~ that Grumpity is apparently up at Midnight reading and replying to this forum thread. Also @Grumpity Linden should I make a feature request JIRA for my +1 Group Slot / Rez Day idea or is that sort of thing actually impractical?

You made an alt to troll people, so I don't really know why I'm wasting my breath refuting your obvious troll. But it's late, and I might as well. Actually SL IS a necessity for many peoples lives. It IS needed for them to exist in the world. They live in remote parts of the world, or they've got no other means of income, or they're disabled, they're bedridden, etc~ and so without SL they have nothing. No money, no food, no social life, no normalcy, no nothing. The fact may be that the majority of SL residents don't fall into these categories, but some do, and coming here pretending to speak 'truth' to all of the 'entitled' whiners is what makes discussions like this devolve into unproductive flaming instead of providing valued feedback. People are rightfully concerned because as human beings we're afraid of change~ changes to what we know and love ~ cause worry that it will end that normalcy that they have grown to expect. That's no more a sense of 'entitlement' than the average worker feels each day ~ a feeling that they're entitled to go in to work each morning and still have the same job at the same desk that they had yesterday. Are these changes by themselves going to be the end of SL? Heavens no! But the underlying ~ unwritten, nagging question at the back of everyone's mind is that gnawing cynical feeling of "if the Lab is this desperate for money ~ where is SL going to be in 3 years ~ in 5 years?" No one has an answer for that. While some have argued that this is due to the failure of Sansar, it could also just as easily be argued that the landscape of the entire world has changed and SL needs to adapt. That the steps that are being taken are a good sign for the longevity of the platform. I don't know which it is ~ but I sure hope it's the latter. Too many good things come from SL for it to vanish quietly into the crevices of the forgotten parts of the internet.

Okay ~ so, over the years, I've slowly become familiar with the issues of running SecondLife ~ both the technical ones ( all those balls of group data getting dragged around with avatars, bogging down sims as they try and connect from one to another ) and the social ones ~ of managing a store, and friends and, trying to not let people fall through the cracks. So I've been thinking rather long and hard about my reply here, and while there's many things I find frustrating about the news, there's really only one thing stands out as problematic and worth planting a pitchfork and lighting a torch of my own over. Reducing basic account activity feels both punitive and disrespectful to your legacy users. People who have been faithful members of the community for a decade or more shouldn't be treated on equal grounds as someone who has just signed up. Grandfather in the 42 group cap and old IM limit for accounts that were created prior to June 4th. OR Alternatively, I'd suggest raising all caps by one each year the account remains active. Kind of a 'thank you for being here' reward. ( so a basic account that's 13 years old gets 48 [35+13] groups and 28 [15+13] offline IM's ) People love inventory expansions in games, and they love birthday presents, and all the data that's needed is already tracked to implement this. Happy Rez Day! Here's a group slot ! I've been premium for almost the entire time I've been on SL ~ so while the changes to the basic account levels shouldn't affect me directly, I still find them insulting and problematic. My management accounts aren't premium, so lower IM caps will cause them to be difficult to use. There are thousands of people who are emotionally invested in SL and offer their time and energy into making it a better place that don't deserve to be punished for not handing over money. Don't alienate your long-term user base please. Thank you for listening @Grumpity Linden -- Liz

I'm far less of an expert from Beq on this topic, so I will defer to her "informed ignorance". I just wanted to point out that Prims appearing before everything else in a scene has nothing to do with their render-impact, but rather the fact that they're constructs of the viewer itself. However, people tend to think that means they're more efficient since they just poof appear. From what I understand about the viewer is that you don't have to download a prim mesh every time you want to look at one, rather you're just getting info from the server "prim box, these inputs". As such they appear in the scene before everything else. Which, as Beq noted ~ doesn't mean that they induce less GPU lag than say a similarly constructed box that someone uploaded.

Getting a dino to look good shouldn't take more than 1-2 1024 maps if you use symmetry and UV Pack well. If you UV Stack the left and right sides on top of each other and you split it into two 1024 x 1024 maps you should be able to get a good normal map resolution with minimal seam distortion down the back and underbelly. Additionally, along the top of the back, that specific ridge you can add extra ( non-normal map ) based geometry to help your silhouette. It'll help distract from the natural normal map defects you get from ( relatively ) smaller normal map sizes. As a general rule I'd avoid making super-tiny spines like the ones you have along the neck, but defer to something a little bit courser and built to help the silhouette will hide the normal map seam, especially if it goes from neck-to-tail-tip. You can put these spines on their own UV islands that break symmetry and sprinkle them into the crevices of your existing UV maps to maximize space utility and keep the symmetry from being too stark. ~Cheers! -Liz Edit! :: A dino like that can be well executed with a triangle count of roughly 25-55K triangles ( no subdivisions needed ). Just got to break some edge loops up near the spines and head and do your topology right !

When exporting a file from 3ds max ~ if the 3ds max scene is set to cm ~ and upon export, the file is set to convert cm to meters. That item will appear in world at it's appropriately converted scale. However, the rigging data will be incorrect~ as it won't have been converted properly. If you look in the DAE file, the values are all off. ( I think? .. it's a vague recollection I have of this ).

Based on my testing on all this sort of stuff awhile ago ( and my memory is a bit hazy on all of it ~ ) this is how stuff works ( I think? )~ so please correct me if any of this tests out to be incorrect. In world avatar BB (bounding box) size altered based on the SL dimensions of the rigged asset and where it is attached to ~ despite how it visually looks. That is to say the same formula for altering an avatar's bounding box is used regardless of the worn items rigged status. The alterations to the avatar bounding box are based on the worn position and scale of the unrigged parameters of the worn item, regardless of whether rigging data is present for that item, or if it's simply just a giant box-prim~ The same calculation is used. It's the same issue I originally dredged up when assessing the validity of the ARC calculations with respect to rigged assets. Rigged mesh assets have a bounding box size based on what their unrigged scale is. IE if a rig a 0.5 m (per side) 6 sided box to my head bone~ and upload it. The bounding box size of the rigged item ( and also the effect that wearing it has upon my overall avatar bounding box ) is based solely upon what size that object is in SL when it's placed on the ground. If I place it on the floor and scale it down to 0.01 m ~ then it's associated bounding box on the avatar when worn ~ will be that size.... however visually it will appear as a 0.5 m rigged mesh box, overtop the avatar head, because it's vertex data dictates that's where it will appear. The ARC costs will be calculated as if I was wearing an unrigged asset that size ~ and the overall avatar bounding box does not grow. If I scale that same box up to 64 m per side and wear it ~ it will now affect the avatar's overall bounding box to be absolutely ginormous, and it's effective ARC cost for the box alone, is raised. However the associated ARC costs for all the other worn attachments that have now had their LOD swap rate changed by the fact that I'm wearing a 64 meter box~ (thus making my avatar bounding box absolutely gigantic ) ~ is not. Which is probably not intended behavior either. It's important to keep in mind that in both of these cases the box appears as a 0.5 m cube on the avatar's head at all times. It's just "under the hood" it's different. This however has nothing to do with how rigged assets are stored and rendered by SL~ which I think was the original question! All vertex data are stored as having an offset from the avatar skeleton. The offset of these vertices is stored in a rather generic system unit ~ which based on what Beq tells me is an integer distance that's divided into and interpreted as meters ~ effectively making your vertex distances from your avatar skeleton stored as measurements that are ~ for the sake of argument: meters. This offset position is multiplied at render time by all of the skeleton bone scale modifiers with the skeleton ~ IE joint sliders, or ~ in the cases of giant avatars and tinies alike ~ a scale applied directly to the mPelvis bone ( which I confess I'm still not entirely certain how this scale modifier actually makes it in world and is applied ! I've just seen it in action enough times to know that it works. ) This vector based offset position is updated with skeleton deformations etc and that's how our rigged content moves. However. If you export from your scene from your external 3D app in cm without doing the proper conversion to meters, such that your vertex data is measured in cm, SL will still interpret those values as if they were in meters. This will effectively set every vertex offset from its parent bone to be different from your intended value by a factor of 100. It's got internal limits to cap these values and you'll wind up with a giant puffy avatar that's just a near-spherical blob of vertices, each following their respective bone~ jiggling about like some sort of terrifying vaguely humanoid kooshball. This behavior however ~ will have zero effect on the avatar's ARC cost or bounding box when compared to a correctly scaled and exported avatar that has the same SL object scale ( size on the ground ) . It is worth mentioning as a final aside though ~ that SL will interpret an upload that is 50 cm to a side as a 0.5 meter cube. But at the same time it will translate the vertex data from the object at upload time into meters, creating a 0.5 m large cube in world that has rigged vertex offset data specified at 50 meters away from a bone ( which hits the integer limit for maximum allowable distance from a bone ) and makes things a mess. Note: that this effect is something I've noticed while browsing DAE files, but it's possible that different DAE writing export plugins might do the unit conversion differently such that SL interprets the data correctly, despite doing an export in cm.

Just to add a little addendum to Beq's lovely essay describing physics. The avatar collision skeleton is primarily used for resolving clicks ( left and right ) on an avatar. For example when you want to right click on your friend to see what their profile update is ~ in order for the viewer to "solve" that you've clicked on your friend it uses the collision volumes. These collision volumes are also what allow you to "cam onto" someone and for the camera to stick. The camera uses the Collision Volume to resolve where to point and what to follow around. This is what allows you to "stick" your camera to your friends head to look at their face, or stick it to another region of their body to examine that. I believe that this is slightly different than "bounding box" resolving which is how we bump into things in the world or what responses are given for LLCastRay collision hits from such things as weapons and combat scripts. This means that if your avatar is playing an animation that has your hands extended in front of you like a zombie, the arm collision volumes do not dictate when you bump into the wall, rather the extended avatar bounding box does. As best I can tell the avatar collision bounding box does change based on a number of things including your present height, sitting status, etc, but it does not change based on what animations you are presently in, in fact I'm pretty sure that you can walk your "Collision volumes" completely out of your bounding box via an animation, thus visually being clickable in one location, while your bounding box is in fact in another.

Dohhhh Whirls... what kind of flame fest did you drag me in to... stop baiting me into messes like this, I have more important things to waste my time on, like playing Don't Starve. Feh... fine. @Klytyna - It's not a Linden that came up with the idea to allow the Serverside Baked output textures to be applied to Rigged Mesh Avatars, it was mine. The reason is pretty simple. It's not for reviving millions of system layer clothing assets, ( though that will happen too as a byproduct ), but rather for giving users a reliable way of applying skins, tattoos and stocking/lingerie layers to mesh bodies without the mesh body designers having to use additional polygon shells. Presently all standard mesh bodies contain 3-5 copies of the original body "shelled" or "layered" overtop the basic layer. Each copy of the body is used solely for applying a tattoo layer or a freckle layer or a piece of lingerie/clothing to that mesh body. This means that anyone viewing that avatar has to render four copies of the entire mesh body at all times, This makes that mesh body 4x as laggy. Additionally, on top of the polygon count cost, there's the cost of keeping individual textures in memory~ all at 1024x1024 pixel size. This means for each part of the body~ a fully tattooed mesh avatar with system layer lingerie on will have: 3X 1024 textures for the skin layer ( head, torso and legs ) 3X 1024 textures for the tattoo layer alpha blended overtop that ( head, torso and legs ) 2X 1024 textures for the lingerie layer ( torso and legs ) This leads to a grand total of 8 x 1024 textures stuck in memory. This is before we even get to whatever mesh clothing that's presently being worn on top of that body. Now. Using the serverside baked textures on all body parts eliminates the need for the extra 3 layers of "shelled" copies of the mesh body, making the rez time for the mesh asset 4x faster than it presently is, but it also culls the texture count down from 8x 1024x1024 textures down to just 3x ( baked head , body & legs ), more than doubling the efficiency there as well. This texture efficiency boost doesn't even take into account the massively reduced render complexity differences that come from rendering layered alpha blended textures of tattoos overtop skin layers. But because of the way that the serverside baker operates, it doesn't have to stop at just there. Allowing use of server compounded textures would allow for users to wear multiple tattoo layers, multiple stocking and lingerie layers. A lot of people love to customize every singled detail of their avatar down to single tattoos, single moles, single scars etc. This ability was lost with the arrival of mesh bodies, but would be regained by this feature. The original notion of this thread was that someone lamented the arrival of mesh because of the aberrant load times. This is a very valid concern, one that the Lindens actually take rather seriously. So, this proposal that you're so thoroughly upset about is actually a massive ( 4-5X ) optimization, that would allow him to continue to enjoy SL in a much more ideal way~ as well as make SL events 4-5X less laggy.

This is still on my project list ~ but during the course of Bento, something much more pressing finally stole the majority of my build-time, namely the inability for my native software suite to produce SL related animations / skeletons. That project is finally nearing "Live" status. I'm still VERY interested in establishing this sort of thing. But I haven't the mesh head and saleable content I was hoping to have at this time myself. So, I'm lagged a bit behind on that regard.

Hi~ you seem upset! First off, disconnecting from teleports is nothing to do with Bento~ that's just the servers being finicky, or your internet connection being bad. I'm sure it'll settle out in no time. As for "things looking exactly the same as they did before", that is precisely the point. If the Lindens did their job correctly, all existing content should look exactly the same!! This is an affirmation that things are in fact, working correctly! New content however, will look different ~ and you may enjoy it sometime soon. I hope this makes you less-upset! Have a happy new year!

Thus far physics has only been applied to "Volume" bones, rather than skeletal animation bones. All the new bones are skeletal animation, rather than volumetic. So sadly physics can't really be applied to them directly, however something like a "dragging tail" can be faked with animations. Alternatively there are prim ray-cast script solutions that can mimic the behavior you're requesting, but it's a tad bit late in the Bento project to be adding collision physics. Edit: Also, it's worth mentioning that making things move with the physics engine drastically reduces the number of alternative uses that a bone can be repurposed for ~ as it's suddenly being influenced by the environment.

Okay, so it turns out twist is a special case~ because bone orientation is specified by everything but the axis twist of a bone. Think about a look at constraint, it never spins the camera on it's "look at" axis. I'm guessing something about SL labels this as a special case it seems.

If you parent your current bone skeleton ~ instead of from one bone to another in proper skeletal heirarchy ~ but instead you parent them to another copy of the skeleton, then their local transforms relative to the parent node is still going to be [1,0,0] [0,1,0] [0,0,1] [0,0,0] but it will be in correct position in world space~ as defined by it's parent heirarchy. Then you can move them around without altering their identity transform [1,0,0] [0,1,0] [0,0,1] [0,0,0] definition. I dunno!! ~ it works in 3ds max this way ~ but again, I haven't tried that twist case. Which is still going to generate horrid topology once the limb is reoriented to fit the SL TPose.