ChinRey

Maybe but remember that the only reason the premium gifts have any value at all is that they are so hard to get. It's all rubbish, as others have already pointed out, but their rarity makes them collectible to many SL'ers.

I'm not sure what you mean, this is how the slice function works by default. Alter the Slice Begin and the top of the prim (along the z axis) still stays in the same position. Alter the Slice End and the bottom of the prim is stationary.

I had to do a test build to fact check this and yes, 18 hours for a house like this doesn't seem too far off. Add two more hours to take some good promo pics and a trip to Hell (aka listing an item on MP) and we're at an even 20. The OP seemed to be concerned about the possible profits from their build. I've had a house not too different from this listed for eight years now. A little bit more complex but not that much. It took me a lot longer to build but that's ok, I was experimenting and learning so that doesn't relly count. I've sold 17 copies of it so far, net profit about 40 US dollars. In other words: two dollars per work hour. That's probably what you should expect if you're a moderately well known SL creator. Brand profiling is extremely important in SL so if you're a completely unknown you should expect to sell much less (unless you're prepared to spend even more hours on marketing than on building that is). If you have a well known and well established brand name, you'll probably sell much more. Or maybe I'm wrong. The SL house market may be more segmented than I realise and I never really focused on family homes. Back when I was making houses I specialised on medieval timberframe houses and smaller rustic cottages and they've sold considerably better than my family homes, although probably not enough to give anything like an RL income per work hour.

That's what I thought too but the Beq posted this on her blog: http://beqsother.blogspot.com/2021/09/why-crowds-cause-lag-why-you-are-to.html So unless LL has made a fairly major upgrade since then, and I'm sure we would have heard about it if they did, each alpha cut is still a separate draw call. For those who don't know what a draw call is, each face on each object in a 3D scene, not just in SL but in all OpenGL or DirectX based 3D environments, is drawn as a separate "draw call" by the gpu. Needless to say, each draw call takes quite a lot of time to prepare, the positions of the vertices have to be calculated, the textures and materials have to be loaded from memory and applied to the surface etc. With lots of draw calls this adds up very fast. LL developed a partial fix to this problem, a way to identify and merge faces with identical textures and materials and that helped a lot. Unfortunately this doesn't work with fitted mesh and since each alpha cut is a separate face, each needs its own draw call. If I understood Animats right, Vulkan has solved this problem but a Vulkan based viewer for SL still seems to be far away in the future.

Consolidated draw calls didn't work for fitted mesh last time I checked but that's a while ago. Has this been fixed recently? The big issue with alpha cuts was the many draw calls. If LL has sorted that out, there shuldn't be any problem with them.

The opposition is even stronger among fashionistas in-world. I think it's partly habits. People are used to use alpha cuts by now but they've forgotten how to use alpha layers. But if I understand right (I can't even remember last time I bought any clothes for my SL avatars so I don't really know) many clothes makers don't even include alpha layers in their packages or if they do, they're so off they're not really usable. We can't really expect the average SL'er to make their own alpha layers. When it comes to performance, alpha cuts add a lot to the render load but they do that regardless of whether they are used or not. Using the cuts will actually reduce the lag slightly. All mesh bodies before Senra have alpha cuts anyway so when it comes to lag, we might as well use them.

Yes. Or rather, the makers of the clothes are supposed to make the alpha layers too. This is part of the BOM concept and not specific for Senra. It's just that it's so much more critical for Senra since the clothes that come with them are so poorly rigged, if they are rigged to the body at all, and there are no alpha cut workarounds.

Awww, sorry to se you leave, Lindal, but I think I understand very well. I left Second Life myself four or so years ago for similar reasons. As much as I loved being in Second Life at first, it eventually grew old and I got that "been there, done that" feeling. The only thing I still love doing in a virtual world is create big landscapes but that is way to expensive in Second Life so I found another place for it. I still log on every now and then to do some tests or to chat with friends I don't meet anywhere else but that's it. I never left the forums though. There are too many good people here and besides, I'm still fascinated by the technical aspects of a virtual world. You didn't say anything about the forums but remember that you are always welcome here regardless of whether you're still in SL or not.

It's hard to tell from the photo but it seems to me the lower tip of the ears are about where they should be but since the ears are so small, the top of them are too low. You can say that again.... and again, and again.

Yes, I'm impressed by that too. It's not a mesh head btw so what you see (or rather don't see) is the blend between mesh body and system head. The neck thickness in the picture isn't anywhere near the limits in either direction so that's not an issue. It's the length that is the problem. It's not critical but it's right at the limit of what's acceptable and not ideal. Of course, this and other proportion related issues are less prominent with bigger avatars and there aren't that many people who use RL size avis in SL. But there aren't many who use the goliaths of the past either, most go for something in between these days, and it seems Senra is made specifically for those giants. (Edit: for reference, my ChinRey avatar is 173 cm (5'8) which is on the tall side by RL standards, very short by modern SL standards and diminutive for an old school SL avi. The shapes that come with the Senra body are actually only 190 cm (6'2) which isn't too tall for a modern SL avatar and rather small for an old fashioned one. They aren't very well proportioned though so we can't really judge by them. It would be interesting to see if somebody could come up with a good looking, well proportioned shape for the Senra at that size.) Another issue I noticed but forgot to mention is that the UV mapping for the fingers and toes is very different both from the system avatar and from what is common for commercial mesh bodies. That means it'll need skins specially made for the body and I can't imagine anybody would want to keep the poor quality skins included in the Senra package for very long. The Avatar Complexity measurement is just a meaningless number. There are avis with ARC less than 50,000 that can cause serious lag issues and ones with 200,000+ that cause no significant issues at all. We can however check the two factors that make a difference between different mesh bodies, tri count and alpha cuts. The female Senra body has a liitle bit more than 45,000 tris and the head a little bit over 15,000. A skilled mesh maker who really tried to make them render efficient would have done it at half so it's not good but as I said earlier, it's still better than any commercial mesh bodies. As for alpha cuts, Senra doesn't have any, commercial mesh bodies have dozens. This is even more important than tri count for lag since each alpha cut requires a separate draw call. So overall, although Senra isn't very well optimized, it's not too bad and certainly far better than any commercial mesh bodies.

That's a poor skin and body shape, nothing to do with the mesh body as such. I only spent a few minutes adjusting my regular shape for it and came up with this: Not too bad for a quick hack. However, look at the neck: This is with neck length set to 0! My avatar is a fairly small RL scale one though and that may explain this and some other problems with the shape adjusters. I have a feeling the Senra bodies only really work for old style giant sized avatars. Also, note that I'm only wearing system clothes here. The mesh clothes that comes with the Senra avatar don't fit if you change the body shape. Seems to be some seriously poor rigging here. If that is indicative of the quality of the dev kit, it may be a good idea for clothes designers to skip it, avoid the license agreement and figure out the rigging themselves. I don't know but I doubt LL can enforce the no reverse engineering clause for people who haven't signed up for the kit, especially since a correct rigging is bound to be quite different from the one they used for their own mesh clothes and probably included in the dev kit. Overall I kind'a like the shape. I didn't notice any of the common flaws mesh bodies tend to have but I didn't look that closely either so I may have missed some. From a technical point of view: about three times as many tris as it should have. There's lots of room for improvement there but then again, all commercial mesh bodies I know of are even worse. Add to this that it doesn't have any alpha cuts and we should expect the Senra avatars to be far less laggy than commercial mesh bodies.

Yes, that's a very important point but there's another problem with this. Most of the mesh we see in Second Life is made by people who think of themselves as professionals or at least semi-professional. They are too in the sense that they charge money for their work. Most of them also use those dodgy shortcuts that really only should be used by happy hobbyists, some because they don't have any professional level skills, others because it's "only for Second Life" so it doesn't matter. One of them once said to me straight out that he didn't bother making proper LOD models because "people buy it anyway". I'm all for automated LOD model generation, it's just that I've yet to see an algorithm that can do it well for polylist meshes. Here's another tree, a birch this time: This is a fairly simple and small tree (only 12 m tall) so the land impact is only 1. Triangle counts for the trunk are 84,50, 6 and 6. So reduction between LOD levels are 40.5, 88 and 0 % respectively. Triangle counts for the foliage are 24 throughout. It can't be reduced enough to make a difference without compromising its shape and it's low enough to start with it doesn't matter. Can you find an algorithm that can manage something that is even in the same ballpark? I'm not talking about the absolute numbers here, that will never happen. I mean, can you find one that can deduce the relative reductions between the different levels? A fixed percentage from level to level sure won't do; that idea is definitely a dead end and the sooner we get out of it, the better. I'm flattered It's not nearly as difficult as people tend to think though. This isn't a place for tutorials but I'll share one crucial tip anyway: Think as a craftsman! I once read an interview of a Norwegian wood crafter and he said he never created a shape out of the piece of wood he was working on, he only brought out the shape that was already there. This is perhaps the most important rule all true craftspeople and artists adhere to and what separates them from the countless wishy-washy wannabes. No matter what materials you use - paint, wood, rock, sound, words, food ingerdients or whatever - you never force it, you cooperate with your materials to make the most out of them. A good way to implement this rule for 3D models, at least as an exercise, is to start by setting the limits. Give yourself a certain number of tris and a certain number and resolution(s) of textures. Then, when you've done your best, take a break, look at your work with fresh eyes and ask yourself: what can I leave out? Can I do it with less? Remember WIlliam Faulkner's golden rule of writing: Kill your darlings! It applies here too. Do this for each LOD model and maybe for the physics model too. A good rule is to go for at least 25% reduction between each LOD level (percentages work well as benchmarks but not as absolute answers).

If you want smooth, low lag performance with max graphics quality everywhere in Second Life, you need an AMD Ryzen 12000 series or a NVIDIA RTX9090. You have to expect at least ten years delivery time though and that can be a slight problem. As for GPUs that actually exist, an RTX3060 or 3070 (or a similar AMD) should be more than enough for most purposes in SL. As others have said already, VRAM and even CPU power are often narrower bottlenecks in the SL rendering pipeline than GPU power.

As Wulfie said, yes. However, be aware that unlike temporary prims, temporary meshes are included in the parcel's prim count.

Yes, this is a known problems. When I need the level of precision you're talking about here, I always use a script to set the values.

Here we go again. To add to Animats' list: Replace the viewer's LOD factor with a prim property one. This way it can be adjusted to strengthen only the objects that need it, good content creators would be able to choose the optimal swap distances for each build (it may differ wildly depending on what kind of object it is) and its impact can be included in the LI calculation. Ideally we want a Unity/UE style system where each swap distance can be set separately but that may be too much to ask for. Upgrade the prim system to make it more versatile. According to Avi Bar-Zeev who invented the prim system, the reason why LL went for prims rather than mesh in the first place was that they were far more render efficient and required far less bandwidth than (polylist) mesh. Several tests I've done indicate that this is still the case. On two occasions I found that a prim build rendered faster than a mesh with less than 5% of the tri count. More to the point here: Unlike for mesh, auto-generating LOD models for procedural objects is fairly simple so we hardly ever have to worry much about LOD collapses with them. There is no way back to a pure prim based Second Life of course but the more we can use them, the less lag and LOD issues we'll have. Upgrade the way the servers handle linksets. Optimising for render load often means splitting large meshes into several small ones or (as I said above) replacing them with multiple prims. This adds more server load though since as far as the simulator is concerned, an object is an object no matter how complex it is and regardless of whether it's part of a linkset or not. There would be a lot to gain if the simulator - or at least some of the simulator's operations - could handle whole linksets as single objects. Update the Land Impact formula. It may or may not have been good when it was developed ten years ago but even if it was it does not really reflect the actual load today. Most important in this context is that it seems to give far too much weight to the triangle count, especially the triangle count for lower LOD models, forcing content crators to reduce the LOD more than should be necessary. Upgrade or remove the uploader's LOD generator. To be honest, I'm not sure about this one since it will raise the skill requirements for mesh makers quite a bit and we do actually want inexperienced newcomers to have fun building. But although Linden Lab has finally discovered that GLOD is not a good option, they still haven't realized that the replacement they came up with, MeshOptimizer, isn't much better if it's better at all. Forcing content creators to make LOD models themselves should reduce the problems with collapsing meshes significantly. A "soft" alternative to disabling GLOD/MeshOptimizer completely would be to make them optional and not the default. Upgrade the uploader's preview image. That tiny little thumbnail isn't really very helpful. Promote the beta grid and make it make it more accessible. Or to put it another way: Make it easier for content creators to do test uploads without having to shell out extra L$. Teach the people. Many creators of dodgy mesh genuinely want to improve their skills but information how to do it is hard to find and much of it is downright misleading. Teach the Moles (and the Lindens). Linden Lab doesn't seem to have anybody on their staff or as contractors who understands how to make well performing mesh for Second Life. Many of them are excellent prim and sculpt builders but they never made the transition to making good mesh. Others have tons of experience from other platforms but no understanding of SL's special requirements (this is especially important when it comes to LOD since SL does it very differently from other platforms but also very relevant for texture handling and several other parts of the content creating process). The result of this is that the official LL builds tend to set a bad example, LL can't provide adequate documentation themselves (that would be the blind leading the blind) and the developers don't have access to feedback and guidance how their software solutions work in practice. Burn down Meauxle Bureaux!!! For those not familiar with the region, here's is LL's description: "Meauxle Bureaux is the home of the Linden Department of Public Works, a program focused on improvements related to the experience of living in and visiting the Linden Mainland. This intricate build was lovingly crafted by resident experts for all to enjoy, so come see the ultimate in shared creative spaces!" What it actually is, is a catalog of examples how not to make mesh, much of it even worse than the grim example Animats showed us in the original post. Calling it "crafted by resident experts" is of course a gross insults to the residents who actually know a little bit about how to make mesh but the sim also illustrates how far Linden Lab as a whole (and LDPW in particular) is from understanding even the basics of what has become the main building m,aterial for Second Life. It won't reward bad content creators if the strenghtening is factored in to the LI calculation. (Slight digression to a pet peeve of mine: do not confuse design with the technical aspect of content creation. Some of the worst offenders when it comes to handling LOD, physics and lag are excellent designers creating models that look gorgeous at full LOD. That's why many of them sell so well. It would of course have been better if they also paid as much attention to performance as they do to looks but at least they deserve credit for what they have.) Here's a tip to everybody who make or want to make mesh houses: Do not under any circumstance reduce the outer walls and the main outer surface of the roof! Those surfaces don't have many tris if you make your main model correctly so there's very little to gain from it both when it comes to LI and actual load. There are exceptions to this rule of course but very few and you have to really, really, REALLY understand how mesh works to know when they are appropriate and even those who do understand won't usually bother with that level of microoptimization. Impostors would be very useful for vegetation. Maybe not for big trees since they tend to have swap distances beyond normal draw distance anyway but certainly for medium sized plants. However, look at this: These are not my best optimized trees, I picked them fairly much at random. The red prim in the middle is for scale comparasion. it's 2 m high, about the same as the average SL avatar. Land impacts are (left to right) 2, 3, 5, 5, 1 and 1. They all share the same two 512x512 textures, one for the foliage, one for the bark. Here's how the look at lowest LOD: The big tree to the left is visibly distorted but the swap distance with LOD factor 1 is more than 500 m - two whole sims away. With LOD factor 2 it's over 1,000 m - or four sims. It's perfectly possible to make detailed, low lag, low LI trees for Second Life. All you need is some attention to details and an understanding of how mesh, textures and SL's dodgy LOD and LI systems actually work. I believe it's the lack of understanding that is the biggest issue.

I haven't actually asked any prims but if they have the local position and rotation and not only the global (not sure if this is the case), they must at least be dimly aware of that Divine Root Prim they are all connected to in mysterious ways.

That is correct.

Whether the prim (or mesh or sculpt - that's exactly the same in this context) is linked or not doesn't matter. The very concept of linksets doesn't exists as far as lsl functions not specifically made for linksets are concerned. I may be wrong but I don't think the original SL server software was supposed to handle linksets at all, the feature was meant to be purely client side. The way llSetRemoteScriptAccessPin() is that it assigns a pin, a code to the prim the script is in. This code can be any integer except 0. Once the code is set, it can only be changed by using the function again and it's maintained even in copies of the prim. To disable remote script access you use the function to set the pin to 0. llRemoteLoadScriptPin() basically works the same way as llGiveInventory() but it has a few extra parameters including a pin integer. If, and only if, the pin matches the one assigned to the recieving prim, the script can be made to run on arrival.

Pin is a prim property so once set it's permanent. That doesn't help in this case though since it'll have to be set before you can use a script to add a running script to the prim and llSetRemoteScriptAccessPin() is another of the functions that don't work across a linkset.

That's the easy part. Here's the test script I made: default{ state_entry(){ integer ThisLink=llGetLinkNumber(); integer LinkSetSize=llGetNumberOfPrims(); if(ThisLink>=LinkSetSize){ llOwnerSay("That's all Folks!"); } else{ key NextLink=llGetLinkKey(ThisLink+1); llGiveInventory(NextLink,llGetScriptName()); llRemoveInventory(llGetScriptName()); } } } This script only creates a copy of itself in the next prim in the linkset (before deleting itself) but it shuld be easy enough to figure out how to make it move other items and to other prims too. Yes, that should actually work. Thanks a lot, Qie! The problem is that the root script would have to perform completely different operations before and after the reset but I think I have a solution to that too: send a test message to link no. 2. If no response, copy script to all parts, if there is a response, trigger the listing routine for one part at a time. That being said, this is beginning to look a bit too complicated for a script that really only is useful ocne in a blue moon. Maybe it's better to ask LL nicely to implement cross-linkset inventory functions?

It's supposed to create a list of the inventories across the linkset. The idea is to have an easy way to locate that texture that somehow got lost inside a 100+ size linkset - or that no copy notecard that messes up the perms for it. I suppose I'm not the only one who has run across such problems occasionally. The inventory functions are among those few that still don't have any link equivalents and if I have to set the pin for each prim I might as well add the listing script itself to each or even just check all the inventories manually.

I'm not sure if this is possible but I'm trying to make a script that starts at the root of a linkset, performs a routine, then jumps to the next part of the linkset, performs the same routine and so on. The problem is that the script is deactivated when it's transferred to another prim. I can't use the regular llRemoteLoadScriptPin()/llSetRemoteScriptAccessPin() solution since the target prims can't be scripted. Can anybody think of a workaround for this?

Oh, don't get me started on terrain! This is a thread about avatars and you don't want a long off topic rant from me here!

One way to find out... /me logs on to the beta grid, rummages through her inventory and finds the 2048x1024 she had kept just because she's an incurable packrat. Apparently not. I tried to download it and it's still at that resolution. I don't have a 2048x2048 or anything bigger but I would assume it's the same with them. Texture quality isn't only about resolution and it's not at all unusual to see 512x512s that look sharper and clearer than 1024x1024s. One very important and always overlooked factor is the scaling algorithm. Nearly all textures we see in SL have been resized at at least one point during the creation and/or uploading. Take a look at this wikipedia page: https://en.wikipedia.org/wiki/Comparison_gallery_of_image_scaling_algorithms. It only illustrates a few of the algorithms that exist and don't include the ones I would usually recommend for SL textures but you get the idea. SL uses a lossy texture compression and that also affects the actual resolution. For some textures the loss of details is barely if at all noticeable for others it can be very significant. Then there are lots of tricks good texture artists use to make their texture look sharper and more detailed than they really are. It's hard to quantify and explain, it's all about intuition, experience and attention to detail. But take a look at Crazy Mole's Nautilus textures or Hattie Panacek's Ex Machina and (especially) Rampart Castles ones. Those are two of the greatest texture artists SL has ever seen and it's amazing how much they can squeeze out of a pixel. They can make a 256 look better and sharper than most of us can manage with a 1024.