Kyrah Abattoir

I'd like to point out that low performance essentially dictates what people do in SL, it's not simply that ALL people want to chat or AFK all day, it's that there isn't much more that they can do without SL turning into a slideshow. Especially if it's something that requires moving.

KeyFramedMotion doors are by far the best movement wise, but they can't be linked to other things and can be tricky to write because of how they use position and rotation steps.

I strongly recommend to use the Viewer URI Namespace whenever possible, example: secondlife:///app/agent/UUID/about secondlife:///app/agent/UUID/displayname secondlife:///app/agent/UUID/username It should work for llDialog (but not the buttons), llSay, llWhisper, llShout, llOwnerSay Won't work for prim names and llSetText tho. The main advantage is that you work strictly with UUIDs and let the user's viewer deal with converting it into the current display name. And as a bonus i think it will also respect their settings if they only want to see usernames instead.

That's beyond the scope of the name change feature. UUIDs are unique and immutable.

I'll precise if this helps anyone else, objects in SL have a minimum size of 0.01m x 0.01m x 0.01m. Mesh size is automatically calculated from their geometry's bounding box.

Baked textures doesn't mean you have to do it blind and without consideration, come on, you're better than that. Building creators tend to be major offenders in this department. They aparently didn't get the memo that we aren't in 2008 anymore. Scaling inconsistencies typically do not matter when we are talking about 50 - 150% difference between maps. Most people won't notice, I usually reduce texture resolution for things like underside, hole caps and lining on my items because it's not important, it only exist to be ignored. Likewise, If i can get away with it i'll slightly enlarge the areas that contain important elements that can benefit from a little more texture area. The whole point of normal maps, realtime ambient occlusion and realtime shadows is so you're not loading the vram with huge, heavily pre-lit textures (since that's the only way you'll be able to achieve an acceptable look without lightmapping). If you want to throw the realism argument, don't use ambient occlusion at all, because the point of AO has never been that it was realistic, it's just eye pleasing. The PROPER way is to use every trick in the book to get a similar (or better) result at a lower cost, not just the ones that are easy or convenient.

I'll quote (a few quotes actually) an old article that Robert Yang wrote about his frustration with people who make models in the modding community. https://www.blog.radiator.debacle.us/2012/04/on-joiner-detail-and-greeble.html Of course it doesn't entirely apply to SecondLife but some of it does.

Use and abuse texture repeats whenever you can, if a part is present multiple times in a single object, figure out if you can get away with using the same piece of texture for it on all the identical subparts. Pack your UVs to maximize texture area, you can also save on texture size by using non square textures (they still have to fit the 'power of two' rule tho). Use the viewer built-in textures when you can and if you can (default white as a specular map is useful in a lot of cases instead of making a custom one) Recycle textures across multiple objects if they share simmilar details. Once you are happy with all your textures, try to scale them down, uniformly and non uniformly. Sometimes the loss in resolution won't be noticeable and you just saved some memory for very little effort. Non uniform scaling can also create some interesting illusions of detail when pixels are halved in only one direction. For the point above, be mindful of how much space you leave between UV islands, if it's already too tight, reducing the texture will create seams. While a constant pixel size feels nice and homogenous, drop down resolution on small and/or unimportant parts. Remember that a lot of details are essentially "greeble" they exist only to be conciously ignored. Remember that there is no such thing as a free lunch. No matter how you do it, adding detail will effectively raise the cost to render that object, the real question is "by how much?".

I've had this error exactly once, and it was a few days ago. Could it just be a server fluke? (magnum RC too here)

It's funny because the look_at targets where once praised of making secondlife avatars more alive and believeable. Hell, I use a simmilar system in unity to get characters to look at what the player is looking. But this is SL and people just turn it off .

And you underestimate people's eagerness to break a feature that annoys them, if they are given the opportunity to do so. ex: look_at targets.

The only issue i'm seeing... what will happen if some popular but unscrupulous creators decide to reserve themselves exclusive use of some of the layers for their own non-body related products... But then that's the same issue we have with the spare bento bones, some things simply cannot be used together.

Several operations can cause a vertex to end up duplicated (not sure how much of this applies to secondlife but I see no reason for it not to): Hard edge/edge split A change of material (face for SL) UV seams

My point is that the render cost metrics should be determined by the region and not some weird client based consensus, because the second scripts start to use this metric a little too much is the second clients will start to come out with an option to "disable reporting render cost"

Yeah I was baffled when they introduced the features, they would rather implement a "trust" based cludge than actually have the simulator load the mesh. (I assume the simulator just loads the "prim" fallback, since meshs where defined as prim shapes for pre-mesh viewers)

I recall when the feature was implemented what people wanted to know the most was "how do i disable that notification that I might not be rendered by everyone cause I don't really care".

I'm not entirely sure why LL decided to go solely with a fixed distance/radius switch for lods. It would have been quite nice to be have a simple slider that modulates the distance/radius calculation so that the user and creators could decide when the lods will switch based on their use of the object. (with LI/complexity adjustment obviously). Having to blank out lods on large objects because they aren't gonna get used anyway seem just as silly as having lods switch so fast that the high lod might just not exist at all on a small object.

Slightly off topic, but IMHO avatars should have a fixed budget, it works for land after all. And they don't care because it doesn't affect them in any way. Creators generally don't eat their own dog food, if they even spend time in SL at all. I'm not even sure there is a way to convince them to be more mindful because the way they do things right now is the most efficient possible way to release a product with the least amount of time spent on it. Doing any kind of optimization costs time, and that time is better spent working on a new product (or simply not working at all). People who see SL strictly as a business are not interested in spending time on things that doesn't translate into more income. I wish i knew of a compelling argument that would justify "hey you should probably spend an extra week building a low poly model and packing your texture UVs", but I haven't found any way so far. People usually agree with me on this because they genuinly want to make quality game grade assets, or they just laugh at me, calling me a dreamer because I literally suggested to spend more time making less money.

It's not just SL, overlaying alpha textures is a common problem for most (all?) 3D engines. The solution is typically "Don't do that".

Well you know, you neighbors have to make sure that you are who you claim to be. They alsogotta figure out your routine so they don't mow the lawn when you're home, gotta be able to recognise your car in case of theft, etc etc

I'd ask... does it absolutely has to be a laptop? They always cost more than desktops and they all eventually die from overheating because of the lack of adequate cooling..

On a sidenote, on viewers that allow you to set your texture memory higher, setting it too high will cause trashing too. The texture memory setting in the viewer is ONLY for textures, other things (meshs for example) are also loaded in vram but are not counted here.

Try the official viewer

Premium account perk maybe?

My advice for denim is to not focus on the fabric wave. Study the actual material in photos and think about what makes it look the way it is. Here is a blurred picture, you can't see the fabric weave but it is very obvious that those are denim jeans. And that's what truly matters.