ChinRey

All assets are stored in SL's asset databases so that can not be the issue.

You can simply include both a flat and a curved copy of the poster in the package you sell

Are they the same length too? A is expected behaviour for a long, thin cylinder, B is not. There is a quirk in how SL handles LOD for cylinders. For all other objects the swap distances are determined (among other factors) by the size along all three axises. But for cylinders the z size is ignored and since the distance are calculated from the center of the object, you can sometimes get LOD swaps even before you reach the end of it. I once asked Grumpity Linden about it and she said "it's amazing how many tris we save this way." She may have a point; it's been this way for more than 20 years and it's amazing how few people have noticed.

31,676 vertices and 62,672 tris - I think that explains it. You can't expect the viewer to handle high poly meshes reliably. So it's time to clean up your mesh. There are tons of superfluous vertices there so you can easily cut it down to a four digit number of vertices and tris with no notcieable difference in the shape. And if you do the ridges along the sides and the headboard as textures/normal maps, it shouldn't be difficult to get the counts down below 1,000 even.

There is no such thing as a metaverse then since no virtual world is even close to being "used by pretty much everyone".

It can be a "ghost prim" an object that was deleted but for some reason are still in the physics engine. Or it can be some dodgy ground physics. In either case restarting the region should fix the problem. The regular weekly restart may not fix it though but if you ask LL to do a more thorough reboot, the problem should go away. Edit: It can also be a nearby with dodgy physics. Sometimes a sculpt or a mesh can have a bounding box and physics shape that extends well outside the visual shape.

Ok. I don't really have much to add to the replies I posted to those threads but I think I should emphasize one crucial and often overlooked trick I mentioned in both: If you want to ensure seamless joints between two meshes, make sure the overall dimensions of each and the position of every single vertice along the seams are a precisely a number of millimeters that is divisable by 2. If you don't it can be very difficult, even impossible, to align them correctly in-world.

No, that's a different issue. The download weight, which is the weight that usually determines the land impact, is calculated from two factors, the calculated swap distances between the four LOD models (which again depend on the size of the object's bounding box) and the file size of each of them. The file size depends partly on the amount of raw data of course but also on how much the compression algorithm (good old gzip) can compress the data and even minor differences in the data structure can have a significant impact on that. Here's a seriously oversimplified digtal example to illustrate. Take the string 1000010000. It can represented as 2x(1+4x0). But move the 1 in the middle to 1000100000 and we get 1+3x0+1+5x0, a significantly more complex string. No, there's no optimal triangle size, the rule is always to have as few as possible (but not fewer). However, with small triangles you usually need more of them, increasing the file size, and big triangles take up a lot of space, increasing the object size. So by combining them into a single mesh, you get both a relatively large and bounding box, increasing both the factors that determine the download weight. So the general rule is to not combine big and small tris in a single mesh. But remember there is no rule without exceptions. Look at this little cottage for example: The doorframe has 24 small tris and the window 28 so normally we want those as separate meshes. Normally they shuold have been done as separate meshes but this is a 1 LI house so it can only have two parts in the linkset. The door has to be separate to be movable so everything else had to be made as a single mesh. This is a good example of how the different rules for optimisation conflict with each other so you have to choose one or the other.

Awww, I didn't notice your post until now. 😉 It makes no difference whatsoever so do it the way you prefer. I'm not sure I understand the question. Can you give us a link to that 2017 post you found? Here are a few general rules for splitting a mesh into a linkset though: Try to keep the distance between the center of each part to less than 64 m. If it's bigger, you won't be able to link them. (This has changed since 2017 btw, the max link distance used to be 54 m.) If possible, avoid splitting parts that have the same texture. It's no big deal if you have to though. For optimal LOD and LI split big and small tris into separate meshes. For optimal LI, try to get the download weight and server weight of the linkset as equal as possible. If the linkset includes several identical elements (such as windows on a building), upload one copy and duplicate it in-world. These rules often conflict with each other so be prepared to make some compromises. Well, it's always easier to give feedback to a finished build than to some abstract questions so that can't be avoided. But you do know about the beta grid, right? You can do test uploads there for free and that's crucial if you want to improve your meshes without wasting tons of L$.

The only way I can think of is to use one or more flexiprims. A single flexiprim with a good chain texture should work quite decently and with four synchronized flexiprims you can make a chain that looks convising even at close range. Edit: On second thought, maybe two would be enough, not four.

Yes, that's potentially a great use for Second Life. I assume you want your students to be able to walk around inside the house to get a feel of how it works and that causes a few problems. SL avatars tend to be considerably bigger than RL humans so you want to make special avatars to match RL scale. The default camera position far behind and above the avatar won't work inside an RL scale building and even a modern "game style" camera position is too far off to really give the level of immersion you need. So you want to go into mouselook. Both these issues can be solved when you're aware of them but there's a third one, walking speed. In SL it's about twice as fast as in RL. Try to move around in your RL house at a brisk jogging speed and you see the problem. A don't know any solution to this unfortunately. The CtrAltStudio viewer, which was specially made for VR headsets, solved it by continuosly starting and stopping the movements but I don't think any current viewer has any similar function.

I haven't researched it but I can't imagine it would make much difference. If you have 78 faces, presumably with 78 different textures, the load caused by the geometry is a drop in the ocean compared to what the textures cause. So choose whatever suits you.

That's an advanced question, certainly not a noob one. Second Life does not have object instancing (yet) but there can still be a lot to save by assembling objects from a few standardised modules rather than making them from big single meshes since it can drastically reduce the amount of data the client has to download (or retrieve from cache) and process. The most render efficient way to make a tree would be to use a few such modules for the trunk and branches and make the foliage entirely from prim sheets. That would mean a huge icnrease in the land impact though. Land impact has nothing to do with render efficiency, it's all about server load and as far as the server is concerned, an object is an object. It doesn't matter if it's a high poly mesh or a simple prim and it doesn't matter if it's part of a linkset or not. (The latter is a fundamental flaw in SL's software btw but it's one that would be horrendously difficult to fix now.) One of the biggest secrets of efficient building is to find the right balance between render load and land impact. This is a bit of an art really since there are no absolute rules and every case is unique. For trees, splitting the canopy is definitely a part of this balancing act. If you look at the two trees in picture above, the small one has a canopy made from a single mesh. That's the only way to get the LI down to 1 and the foliage only has 24 tris anyway so it's hardly going to affect the load. The big tree, however have a canopy made from three different meshes, some of them copied so adding up to seven parts. With that being said, textures are still far more important for render load than geometry and there's a lot more to save by re-using textures than meshes.

Oh, I hope you don't misunderstand me. It's perfectly possible to make good looking low LI high LOD trees without going all the way down to crossed panels. Take these two trees for example. The one to the left is 21 m tall and 4 LI, the one to the right 10 m and only 1 LI yet (you have to take my word for it here) they never disappear or even distort noticeably until you go beyond your veiwer's draw distance. The trees from the creators I mentioned in my first post are not quite at that level but they are close enough I'm sure you'll be happy with them. Ummm, I think my picture prooves you wrong there. Mesh can do that but there are only a handful of mesh makers skilled enough and very few of them make trees. But sculpts do make a lot of sense for very big feature trees as long as you don't have too many of them and Lilith Heart's old oaks are still among the best there are in SL in that category.

This isn't nice of me but often in the past (not so much recently) I've had the feeling the SL population could be divided into: 0. People who's opinion doesn't matter 1. Programmers

Ok. His cedars aren't too bad actually. At least not from what I've seen. I never needed cedars myself so I never looked too closely at the options for that particular tree.

Off the top of my head I can only think of four mesh tree creators who fit that bill: Reid Parkin (Mesh Plants), Alex Bader (Skye), Teresa Matfield (T-Spot) and one I'm not allowed to mention here. I'm sure there are a few others too so let's see what others recommend. --- Edit: No, make it four. I completely forgot Eldowyn Inshan (United InshCon) since I never got around to use any of her works on my own sim. I've also seen low LI/lag trees with good LOD by others but I don't know of any who does it consistently. I was in a similar situation as you about ten years ago, building a two sim landscape with low lag and long distance visibility. In the end I had to learn how to make trees myself but even after that I was still happy to keep the Teresa Matfield and Alex Bader ones I already had. (Reid Parkin's trees weren't on the market yet at that time as far as I know.) They weren't quite up to the standard I wanted but close enough not to cause any serious issues and far better than most mesh trees on the market. ---- Edit 2: If you want low lag, low LI and good LOD lush vegetation, it's important to think in layers: Very simple (even down to old style crossed panel) meshes for smaller plants and plants that are well away from where people are likely to go, well optimized medium detail plants (like the ones from the makers I mentioned) for the bulk of trees and then a few highly detailed mesh or sculpt(!) ones in strategic spots. The two Grand Old Ladies of SL trees, Lilith Heart and Nadine Reverie are worth checking out for the latter. I already posted a message about this long ago so I won't go into details here. Take a look at https://community.secondlife.com/forums/topic/465598-plants-lag-and-a-new-classification-system-for-vegetation/

Just a quick comment without reading the whole discussion (sorry, I'm a bit busy atm). Normally the edges are the last place you want to simplify a curved surface because that's where the angles between the vertices are most visible.

That's a very good point. SL is only free for people who need the hardware anyway and most people don't.

One thing you can try before you simplify the physics model is to increase the height of your terrain a bit. It's a bit counter intuitive but SL's physics engine doesn't like small meshes and at 1 m you're close to or past the limit where the physics weight starts to skyrocket. If you end up simplifying the physics, you may want to consider simplifying the main model to match too. For walkable surfaces it's often more important to maintain a perfect match between visuals and physics than to add lots of details.

There's nothing you need to do to make it mesh compatible but you do want to tweak those shape sliders to get the best result. It's not about system vs mesh body either. Each mesh needs its own tweaks. It's always the combination. Even the best shape can look bad if the skin doesn't fit it and vice versa.

I don't know of any hang out places for builders but you should really join the classes at Builder's Brewery and also at Happy Hippsters. Not only are they great for learning building skills but also to meet other builders.

One rather important question then: are there still people running Widows 8.1 or earlier here? If so, they may not be able to even run the current versions of the viwers, let alone future ones. Now, Windows versions before 10 are not officially supported by Second Life and I have no idea if this is a genuine problem, which is why I ask. But it's definitely something we should consider.

There are still a lot of aspects of "full PBR" that are missing and for good reason. For those not too familiar with the concept, the idea with Physical Based Rendering is that instead of simply reproducing the colors across a surface, we try to simulate all the physical factors that cause those colors. But there are so many such factors and they interact with each other in so many weird and wonderful ways. If we were to take PBR all the way, we would have to measure render lag in frames per year, not frames per second. Some people wouldn't be happy about that so we have to compromise a little bit to make it work.

Slightly, but not completely, off topic: To understand this, it's important to realise that PBR is not a standard. It's a concept with a lot of different implementation. This is why there is so much confusion about the names of various maps. The Khronos Group is trying to establish a standard for it now, based on Unity's old PBR system. But there are still lots of other variants around and there will probably always be, partly because some won't change, partly because glTF PBR is a very simplified take on the concept and may not be advanced enough for many uses. The SL software very often does a better job scaling from 2048 to 1024 than the most common scaling algorithms used by various image eitors. It's a bit of a hit or miss though and if you really, really, really want to make the most of each pixel and are willing to spend some time and effort on it, head over to the beta grid and try different scaling methods (including the one built into the SL software) and see what works best.