ChinRey

What are the tri and vertice counts for your mesh? The by far most common rereason for the missing LOD message on the high level is that the model is so complex it takes ages to load.

If it's the rotation roundoff issue I mentioned, you have to link first, then adjust.

In addition to the high altitude problem there's also a rotation roundoff issue that can happen even at ground level. If possible, try to choose a root prim with no rotation. If you don't, you may have to correct some of the child prims every time you link or unlink prims to/from the set.

Minimum tri count (Level: Basic) No, there is no minimum tri count for a LOD model but I had to come up with some sort of headline for this post. However, you get to point where there's nothing to gain, neither when it comes to LI or lag, by reducing further. Exactly where that point is depends on the geometry of the model but it's usually somewhere between 12 and 20 tris. It can be as high as 30-40.

Oh yes, that's more like it!

I have to correct myself here. The loose vertice is removed by the uploader but only after the bounding box has been defined: This is bascially the same principle as LL used for their infamous 8+ faces mesh upload function. You mean a small object right in the middle of a big bounding box like this? That's possible too but it's a completely different trick that I definitely won't recommend, among other things because this method does retain one loose vertice. If you need to keep the pivot point at the center you have to use hidden tris of course but how often is that factor relevant? In the few cases the poivot point is a significant factor chances are you don't want it at the object's center anyway. When it comes to LOD control there's no need to extend along more than one axis. Look at the formula for calculating swap distance from high to mid: d=√(x²+y²+z²)/0.6*L (L is the viewer's LOD factor) You can see even at a glance that unless the x, y and z sizes are vairly similar, it's really only the largest of them that significantly affects the swap distances so there's no point in extending the bounding box in several direction. Unless you need to preserve the pivot point of course. You do need to use "hidden" tris in those cases but how often is that relevant? There is no reason why the loose vertice should affect the normals of the ones that end up being uploaded. I have absolutely no idea what you're talking about. Tes, that was a bit tongue-in-cheek.

Physics (Level: Basic) This is something we see here every now and then. Some beginner is desperately trying to reduce the land impact of their build but no matter how hard they decimate the LOD models, nothing changes. This is usually because of bloated physics models. Land impact is the highest of three weights, server weight, download weight and physics weight. The LOD models only affect the download weight and if the physics weight is higher, it's not possible to reduce LI by simplifying the LOD. Very few objects in Second Life need a fancier physics model than a simple cube and with that the physics weight will never be an issue. I wn't go into too much details here since physics is a topic on its own but one of my alts posted this on another forum a while ago. It's about opensim physics and opensim uses different physics engines than SL but the absic principles are the same.

Remember the prim!!! (Level: All) Rule #8 in my general principles for efficient mesh says: Don't do Mesh for Mesh' Sake! I think I need to say more about that since I didn't know back then just how important this is. A while ago I tried to help a friend on the OS grid converting a huge and laggy house with hundreds of prims to less laggy mesh and I got a bit of a shock. No matter what I did, I could not get the render lag down. I reduced the linkset down to a tiny fraction of the number of parts and a tiny fraction of the triangle count and it still hit my fps harder than the original prim build! Do not use a mesh for something that can be made from a single prim, that's a no-brainer, but in that particular case a single mesh couldn't even match 20-30 prims with 50 times as many tris. This was on opensim as I said and I haven't tried anything similar in SL but it's the same viewer and the same render engine so it shouldn't be any significant difference. There is a downside to using a linkset of prims instead of a mesh though and it's all about server performance. Apart from the physics, an object is an object as far as the simulator is concerned so it handles a 60,000 tri mesh just as easily as a simple prim cube. And it seems the server doesn't recognise linksets. It could and should treat an entire static linkset as a single object but it doesn't (SL's poor implementation of linked objects is another of LL's five biggest mistakes - Philip Rosedale said it was the biggest). This means that large prim builds put quite a bit of extra work on the server and that is also reflected in the land impact.

Well yes and no. That is, it's a very good explanation of some of the most important principles for good decimation. It's not a good example though. For a mesh sign like that you should always use a hidden impostor. That trick is so suitable for this specific kind of object no other solution is even close.

To triangulate or not to triangulate, that is the question (or maybe not) (Level: Basic-Intermediate) Like all game and VR engines, Second Life uses - let's call it "game mesh" - which is a but simpler than the "full mesh" used in CAD, 3D printing and other 3D model applications. One of the differences is that game mesh does not use quads or more complex polys, it's all triangles. So everything has to be triangulated but the question is how and when. Ideally we do not want to triangulate in Blender and we certainly don't want Blender to do it automatically when we export. The reason is that the SL mesh uploader does it more efficiently, significantly reducing the file size and thus the download weight. Drongle McMahon explained why in a post here long ago here but all we really need to know is that it does. Unfortunately, the uploader sometimes gets it wrong. It can't handle concave polys at all for a start and it also has a tendency to create long and narrow tris that can mess up the texture mapping. Usually it's fairly obvious which polys you can let the uploader handle and which you have to triangulate manually but sometimes a bit of trial and error is necessary.

Make a master model (Level: Basic) Look at Fluffy's sphere simplification trick. It has one drawback: Once you're broken the edge loops it becomes a lot harder to decimate further for the next LOD level(s). The simple solution is to keep an unreduced master model you can go back to.

Oh yes, that's one of my favorite tricks too. It was actually next on my list but I couldn't find the linjk to the Polycount page. Three comments: I think it's a good idea to mark the tips with an aproximate level - basic, intermediate, advanced etc. That way it will be easier for people to decide which technique they should lelearn first. This trick is usually only relevant for the high LOD model, sometimes - but not very often - for the mid. For the other LOD models it's nearly always better to eliminate whole edge loops. Remember to triangulate the polys or you may end up with some rather funky results. I only triangulate the ones with more than four vertices like this (I'll explain why in another post - it's a topic in itself) like this: And this forces me to post two more tricks:

The 25% Rule (Level: Basic) This is if you want to optimize for performance, not for land impact. It may actually increase the LI but unfortunately that's how it often is in SL, techniques that reduces the actual load may well increase the LI and vice versa. Hyper Mole did some tests to figure out mesh when it was released. Sadly she passed away shortly afterwards so she didn't get to do much but one of the things she found out was that if you can't reduce the tri count from one LOD level to the next by about 25% or more, it's better to "Use LOD model above". The reason is that switching between LOD models is work for your computer too so you may end up loosing more than you gain. This is not a strict rule though. If you can get a 20-24% reduction, you're probably fine. Besides, there are other reasons why you may want to keep an even smaller reduction. Land impact is one possible reason, a small reduction at one level may save you a LOD swap further down the line and it may also help smooth out the transitions throughout the LOD levels.

And now a post that doesn't just contain links: Basic sphere simplification (Level: Basic) This is one of the most fundamental aspects of LOD model creation - and very important for the main model too! How high a curve resolution do we need for a sphere? There's a lot to save here. With a curve resolution of 32 a sphere will have 960 tris, reduce it to 12 and it's only 120. But if you go too low, the sphere ends up looking angular even with smoth normals. Here are two spheres with 24 (528 tris) and 16 (288 tris) curve resolution respectively: As you can see, 16 is usually too low for the high LOD model but it should be more than enough for mid and way too much for low and lowest. This is no hard rule though. How low you can go for each model depends a lot on size and context. Special tip btw: It's a good idea to plan ahead and make a high poly "master model" than can easily be reduced. If for example I wanted 24 for the high and 16 for the mid model, I would make the mesh with 48 curve resolution and then delete every other edge loop for the high and two out of three for the mid. Saves a lot of retopoing work this way. Oh and another special tip: You do not always need the same curve resolution in both directions for the sphere. You can often get away with lower resolution horizontally (around the "equator" of the sphere) than vertically (across the "poles"), sometimes it's the other way round. Here is a table of tri counts for some curve resolutions (if there are two numbers in the resolution column, the first one is for the resolution around the "equator" of the sphere, the second for the resolution across the "poles"). Resolution Tris 6 24 7/8 42 8 48 9/10 72 10 80 11/12 110 12 120 13/14 156 14 168 15/16 210 16 224 17/18 272 18 288 19/20 342 20 360 21/22 420 22 440 23/24 506 24 528 25/26 600 26 624 27/28 702 28 728 29/30 812 30 840 31/32 930 32 960 As you see, even a small reduction in the curve resolution can save a lot of tris so choose those numbers carefully, give the sphere as many vertices as it needs, not more and not less.

The extended bounding box (Level: intermediate) There are quite a few post about this buried in the forums but here's one I made just now: https://community.secondlife.com/forums/topic/494793-imposters/#comment-2547283

Next is: Hidden impostors! (Level: intermediate) How about making impostors without having to do all the mess with special textures and all? Sometimes you can. This doesn't work very often but when it does, it's absolutely brilliant. You got this store sign with lovely mesh letters that collapses even at a short distance or has an astronomical LI? A hidden impostor will save your day. Two examples here: https://community.secondlife.com/forums/topic/455999-how-to-make-a-mesh-object-have-lower-prims/#comment-2134060 https://community.secondlife.com/forums/topic/473910-how-to-make-efficient-mesh-general-principles/#comment-2457262

Let's begin with: Impostors! (Level: fairly advanced) This is a technique with rather limited use in SL (unless LL comes up with a decent way to auto generate impostors) but it's still very useful for some objects. There's a thread about it here and it seems to cover most of the relevant info:

I'm starting this thread to create a place where everybody can share their tips and tricks for LOD model creation. It'll probably mostly be links to other threads in the forums but that's fine. There is already lots of good information posted here and there's no need to repeat things as long as we know where to find it. There's hardly any chance LL will pin a thread about something they regard as trivial as mesh quality so remember to bookmark this page before it's buried in the masses of forum posts. But before we start getting practical, read this: https://community.secondlife.com/forums/topic/473910-how-to-make-efficient-mesh-general-principles/. And always remember and try to abide with these principles!

Some excellent answers already but to add a little bit, sometimes it's possible to use the same texture for the main model as for the impostor. I've posted two examples of it here earlier: https://community.secondlife.com/forums/topic/455999-how-to-make-a-mesh-object-have-lower-prims/#comment-2134060 https://community.secondlife.com/forums/topic/473910-how-to-make-efficient-mesh-general-principles/#comment-2457262 This trick doesn't work very often but it's very useful when it does. Yes, LL didn't think things through when they decided that fixed, object radius dependent swap distances were a good idea. It's good for prims but for meshes it really only works for mid sized (say 1-2 m object radius) objects. Small objects swap way too early and big ones way too late. Of all the content creation related mistakes LL has ever done, I think this is one of the top three... I mean four... no five. But we can trick the viewer into thinking an object is bigger than it is. Look at this: That little dot at the top is a loose vertice. What it does, is double the nominal height of the vase, significantly increasing the swap distances. You have to sort the vertices so the loose one is number 1 on the list to prevent it from being culled by the uploader but that's easy to do in Blender. Select the loose vertice only and: You can achieve the same by substituting a degenerate or 100% transparent tri for the loose vertice but I prefer this method. It's cooler, more elgant and it does save one tri and two vertices from the model.

LL is making good money from the mesh body business. They get a share from every MP sale, they get tier from every in-world store and they charge a fee every time a merchant withdraws money from SL. If LL wanted to outcompete the commercial mesh bodies, they could simply upgrade the system avatar. The system avatar is a mesh body, allbeit a very outdated one, and apart from some seriously out-of-the-ordinary avatars there's nothing an add-on mesh body can do that couldn't have been done easier and more efficiently with an upgrade. Another alternative for them would be to buy a license for a pair of ready-made commercial mesh bodies. This is what at least one of the popular mesh body makers did and LL could too. It would have to be rigged to the SL skeleton and mapped to the SL UV map of course but it would still be much easier than making a brand new mesh body from scratch. The only sensible reason why they do neither is that they want to keep the mesh body/head business alive.

The developers are actually trying in their way. They replaced GLOD with MeshOptimizer in the mesh uploader recently. But you've seen the two tests I posted in this thread and you read Beq's reply so you know she's done much more extensive testing with similar results. But to sum it up, LL's developers have spent quite a bit of time and effort replacing one useless automatic LOD generator with another useless automatic LOD generator. A good content creator on the team wouldn't have helped much solving the problem but at least he or she could have saved them from wasting all that development time on a hopeless solution.

That's not quite true. LL had some really good content creators in the beginning. Eric Linden is of course an SL legend and the other content Lindens did some marvelous work too. And they did teach the users. At another SL related forum somebody ocne told a story how he had been chided by Eric Linden for using a 1024 texture on a house. The early Moles too were - and still are - very good at what they're good at. You won't find many better scripters than Silent Mole or better texture artists than Crazy Mole and they're all excellent prim and sculpt builders. But most important perhaps, they had developers and administrators like Cory and Ryan Linden who were also very skilled content creators and understood very well. The whole organisation was aware of the needs and requirements for good content creation. The problem really only started with mesh. Just like us, the LDPW had to try to figure out this new thing from the incomplete, confusing, user-unfriendly and as often as not downright misleading documentation provided by developers with no real building skills or experience. But unlike us they never never really tried to untangle the mesh mess the developers had left us. Hyper Mole started but she didn't get very far before she sadly passed away and none of the others picked up where she left. Worse, they seem to believe they are the crème de la crème of SL mesh makers. Patch once said as much which is why I called him arrogant in my previous post. This means they see no need to improve their lackluster skills so they're stuck. Now of course, the LDPW isn't doing anything to help or guide independent content creators, except of course for leading by (bad) example, but if the rest of LL are led to believe this is as good as it can possibly get, they see no point in investing resources on improvements. But enough rant for now. It would be just as obscure on YouTube or at a small blog for that matter. What is needed is systematic documentation officially approved, endorsed and promoted by Linden Lab. Probably financed by them too. Eoght years ago there would be no shortage of well qualified volunteers happy to spend their spare time on such a project but today, no. Kyrah and I have already explained why we don't spend as much time as we used to offering help here and I'm fairly confident we speak for many others. Developing and maintaining such an organized help resource for content creators would be a much bigger job and I can't imagine many would be willing to do it for free anymore.

Beq is one of the exceptions to the rule of course. Yes, and that is also a very good point. Mind you, I did not say that strict logic always is the best approach to a task. In fact with highly complex tasks, such as creating software for a whole virtual world or organizing your texture collection, you eventually have to take some shortcuts and implement some "fuzzy" solution to be able to do it at all.

Maybe. I only know him from this forum and he may well show nicer sides of himself elsewhere. But in any case, he once made it absolutely clear that he and LL did not appreciate or even aknowledge the vast amount of time and energy me and many other volunteers used to spend trying to help and advice other content creators and that makes it very hard to find the motivation to go on. Why? As Kyrah said, it's really only about repeating what's already been said over and voer and over again. The people who really care, like Chic and RIck and Fluffy, probably need to vent their frustration every now and then and they certainly have the right to do so. But nothing will ever come of it because Linden Lab don't care and don't even seem to understand that this is an issue and without them on board there can't be anything but idle talk.

Since Kyrah reopened this thread: For me the big change came when Patch had the nerve to accuse us all of not doing enything to help. Yes, I know he's an arrogant little self-centered, big mouthed bully who knows zilch about content creation but he is also LL's official voice in these matters and his message was clear: the volunteer work we were doing here to help inexperienced content creators and promote better building practices is worthless as far as LL is concerned. I still try to respond if I have a quick and easy general solution to a something somebody is struggling with but I hardly ever spend hours and hours on Somebosy Else's Problem anymore. I have better and more rewarding things to do with my life.