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