ChinRey

In that case, the biggest question is how many meshes in SL will turn up with backfaces enabled even if theyt don't actually have a single visible one anywhere?

Yes, that's actually a good argument for making backfaces material dependent. How many SL objects would backfaces be useful for anyway? I haven't had time to look at glTF yet and I'm on vacation now but I assume we're talking about traditionalbackfaces with the same texture as the main side and not some new definition of the term. If that is the case, we're talking one mesh in a thousand at most. It wouldn't help the issue in the original post here since you don't want the same texture on the inside of your clothin as on the outside.

Oh good! I was really worried! I have to take your word for it when it comes to efficiency but from a logical point of view it makes no sense to have backfaces as a material parameter. But that's only to be expected; programmers aren't usually good at logical thinking after all.

Are they seriously going to introduce mandatory backfaces??? If anybody has any influence on the developers at all, stopping this is first priority!

No! Linden Lab does not have anybody qualified to do this, their developers do not understand the practical side of mesh making and their content creators do not understand the technical side. If they ever made such tutorials, they would end up as examples how not to do it.

Oh yes, that feature has solved a lot of LOD models challenges for me! It's far from perfect and doesn't always work at all but it still helps a lot. And of course, more to the point here, it's something no decimation algorithm I am aware of supports at all.

I wouldn't worry too much yet if I was you. It's sad you won't be able to enjoy you SL home during the holiday of course but it's not unusual that it takes a few days for a landowner to respond. SL is a hobby for most of them too, remember. Only a few of them have a significant income from it, and even fewer make enough they can hire staff to cover vacations and such. There is no rational reason why a landlord would block access for paying customers of course, so I can only think of five explanations, listed in order of probability: Somebody with more power in the group than they can safely handle has messed up the land settings. The landowner blocked renters who hadn't paid and accidentally did so with some that had paid too. The landowner hasn't paid the tier so LL blocked access to the land for everybody. It's a technical glitch. The landowner has finally cracked under the strain of maintaining an estate and gone slightly mad.

My two tests agree with you there. That is, with "Auto" it did perform marginally better than GLOD for the column. Not anywhere near good enough to keep though and the tree, which was also done with "Auto", was of course a total disaster. I've mnetioned it already but I think the problem is that we need much heavier decimation in SL than they do in a computer game, not only because of the LI calculation's overemphasis on the lower LOD models' weights but also because we tend to have far more complex scenes so simplification of each objects becomes much more important. The lack of object level swap distance adjustment makes this problem much worse. Apart from the messed up normals (see below) the 60 tris throughout all LOD models the "Precise" option delivered would have been ok in a typical Unity/UE setting but in SL it's both way too heavy and too poor quality at the same time. There is another serious issue that I haven't even seen mentioned in any discussions about automatic LOD generation: transitions. Making good LOD models is not only about finding the right tris and vertices to keep for different view distances. It's also about how the various levels relate to each other. Normals are particularly troublesome here. When I made my own lowest LOD model for the column, the challenge wasn't to get the tri coutn low enough - that was dead easy. The problem was to avoid the top of the column to suddenly light up like a beacon or suddenly go all dark. Those effects are really, really noticeable even at that small scale and very visually annoying. As far as I know, all mesh decimators treat each LOD model as a separate entity and do not treat the set as a whole.

Ah! In any case, not much improvement in this case then. It is of course possible MeshOptimizer will handle other models better. This column is open at the top and bottom so it's a shell, not a closed body and I've told that is something MO is particularly bad at. Somebody on the Firestorm dev team has a weird sense of humour.

I thought I'd revisit this thread with a new example since I didn't take into account that Fs at least (don't know about the LL viewer) offer several alternative decimation algorithms now. I do not know what they are but it seems they are just alternative ways to use GLOD rather than completely different algorithms. Maybe @Beq Janus can answer that? (Edit: Aquila andsered it, they aren't.) Anyway, here are five copies of the same marble column. The one to the left is uploaded with proper LOD models, the other with default "Auto", "Precise", "Sloppy" and "Reliable" respectively. The manual, Auto and Reliable copies all have a nice and low 0.1 downlaod weight which means they are well and truly below the limit for 1 LI. The Precise and Sloppy ones on the other hand, both have 3.8 download weight which means they end up at a whopping 4 LI - waaaaay too high for such a simple object. (The reason why the seem to be different size is partly that you see more of the sides of the columns toward the ends of the row, partly that Linden Lab still hasn't noticed it's the 21st Century so Second Life's rendering engine only works properly with old 20th C. 5:4 ratio monitors. On modern 4:3 screens the picture is noticeably stretched sideways once you move off the very center of the picture.) The size of the column is 0.2x0.2x1 m which means it's the medium and to some degree the low LOD models that matter the most. You only see the high model when you bump into the column and you only see the lowest when they are way off in the distance like this: So here are the main - that is medium LOD - models: As you see, "Auto" and "Reliable" do a lousy job, "Sloppy" and "Reliable" are downright distastrous. Moving on to low LOD: This is where the good old Auto really fails and the swap distance is only 9.7 m with LOD factor 1.25 or 17.3 m with LOD factor 2 so that model is still important. But the "Precise" and "Sloppy" algorithms grossly overdo this LOD level. You do not need all those details and this is of course why they give such huge land impacts. The "Sloppy" algorithm really lives up to its name too, adding far more tris to the low (and lowest) models than it thought the medium one was worth. The "Reliable" algorithm still fails miserably to live up to its name. Finally lowest LOD: You do not need much detail at this level, just enough to smoothen the transition as you move towards the object. The proper LOD model only has eight tris and that's enough. The "Auto" model has 12 tris, eight that actually show and four wasted ones, apparently hidden away in some alternative pocket universe. 12 is a good tri count for this but the algorithm doesn't exactly put them to good use, in fact the model it produces is more of a nuisance. The "Reliable" algorithm just gives up at this stage and that's probably just as well. But look at the "Precise" and "Sloppy" variants. They are going all in here keeping 68 tris out of the original 120. That's total overkill of course and look at the second picture in this post again. Those extra tris don't help preserve the looks of the models, they actually distort it! This is another reason why over-strengthening the LOD models is a bad thing.

Yes but there are several factors that makes this much harder for SL than for other game/VW engines. For a start Second Life scenes tend to have far more objects than we usually find in other environments so optimizing geometry (and textures/surface maps) is far more important here. Also, we can't adjust swap distances, draw distance and the number of LOD levels for individual objects and that makes it much harder to make adequate LOD models. Then there is the high land impact penalty for LOD model geometry. I do not know how well this reflects the actual load higher poly LOD models cause but it certainly entices content creators to decimate far more than what you usually see elsewhere. Generally a mesh with LOD models that is perfectly good for, say Unity or UE, will not perform very well in SL and that means the automatic LOD generation algorithms used there won't either. Oh yes, that would be very useful. Is there a chance we'll ever get it?

Maybe we should illustrate this. Here are two copies of the same tree. The one to the left is optimized with manually created LOD models and it's 4 LI. The one to the right is uploaded with default auto generated LOD models and its land impact is 6: Here's how they look at mid LOD: And at low and lowest LOD (those two are identical for both copies in this case): Does anybbody notice the difference? And keep in mind that the tree to the right actually has a 50% higher land impact than the one to the left. This isn't a particularly bad case. I've seen better results from auto generated LOD models but I've also seen much worse. Then again, to be fair making a tree like the one to the left would be well beyond the skills of even most seasoned true professional. Even so: I wouldn't go that far. Second Life is supposed to be a platform for merry hobbyists. We have to respect and accept that they don't have pro level skills. Also, there are some occasions when auto generated LOD models give an acceptable, although never great, result. Here is my advice to all SL mesh makers: If you don't know how to make LOD models manually (or can't be bothered to), do not pretend you are a pro or even an advanced amateur because you are not. Don't get me wrong, it's perfectly fine if you aren't, just do not pretend you are. Err on the right side. It's better to sacrifice a little bit of LI and performance by over-strenghtening the LOD than to have your meshes collapse. Look at Mole meshes. The Moles have no clue whatsoever how to handle LOD but their meshes still hold up well. Crazy high land impact, yes, rather laggy. yes, but they hardly ever collapse and that's the most important thing. At least try to make the LOD models yourself. You'll be amazed how easy it actually is to outperform the uploader's LOD generator. Don't expect perfection. I'm probably one of the top ten, possibly top three, experts SL optimization but even I'm still learning and my meshes are still far from perfect.

That's right!

Ooooo, that's a lovely challenge! Whether it's possible depends on how you define low poly. It should be possible to manage well under 10 000 tris but if you manage to get it below 1 000, you're a true genius! The trick is to treat it like a hair piece. Make as much as possible from a plain low poly base with an opaque texture, then add bent panels with an alpha fur texture on top of it. You also want to give the normal and specular maps some serious attention, they can make a lto of difference for something like this.

I'd say about 3-4 - that is definitely not a positive but hardly a serious problem either - on average but depending on the situation it can be anywhere on the scale.

It's not about the age of the engine actually. Very few, if any, modern game engines can handle the sheer number of fairly high poly mesh assets Second Life is expected to. Still, even though 15 150/29 567 is high, it shouldn't be enough to cause a critical rendering failure like this so there must be some other explanation. I can't think of any though. Sorry.

Obvious first question: how many tris and vertices does the mesh have?

Great explanation but I'm a bit curious about one thing. Since you used FIlterForge to create the normal map, why didn't you use it for the baking too?

AmberJoyBliss' method may be crude but the example she showed us in a previous thread is quite impressive. All those programs that attempt to generate maps from composite textures are rather crude too and it's not always possible to get a good result from them no matter how much you tweak the parameters. More to the point: there is a need for a way to conflate surface maps into a static texture for several reasons. If AmberJoyBliss' method is too crude, she still deserves a lot of credit for bringing up the topic and if somebody has a better solution, let's hear it!

Yes, definitely!

There is a workaround for that problem: include a script that allows the owner to set textures by UUIDs. It's a really clumsy way to do it though and probably not worth the effort but it is possible.

WHat happens is that the normals data is lost in transfer. I don't know how you made the normals smooth in the first place (there are at least thee different ways to do it it Blender) so I can't give you a detailed explanation. But first, do a quick check: Switch to edit mode in Blender and see if the shoe looks smooth or angular there. If it's angular, it's a modifier you haven't applied. Apply all modifiers and the problem should be sorted. If that doesn't help, try to use a different file format when you export.

According to Linden Lab they aren't and for once I tend to believe them. If you choose "Use LOD above", the uploader will only upload one copy of the LOD model, saving bandwidth and eliminiating one time consuming LOD swap. If you select the same file for two or more LOD models, they will be handled as separate filers all the way. Or at least that's how it used to be. Soft Linden filed a JIRA about it back in 2014 and it rmained open for years. I can't find that JIRA now and that may mean the uploader has been updated to detect such duplicate files.

That's not the whole story. "New" land impact calculation is used for any object/linkset that could not have been made before it was introduced. So any feature that was introduced later than that will trigger new LI calculation. In addition to the ones listed in the knowledge base article there are alpha modes other than blending, some script functions and possibly a few other things I can't remember right now. Here's a more practical explanation (if I may so myself). And here's one for those who want all the gory details.

It doesn't. The picture you posted clearly says "vertices", not "edges". This is not unique to Second Life, it's the same with all game and virtual world engines and it's actually to speed up the rendering. As I'm sure you know, a vertice can be assigned to several tris and those tris may be assigned to different materials, they may have different normals at the corner where they meet and those corners may also have different UV coordinates. Blender and other 3D modelling software solve this by assigning multiple materials, normal sets and UV coordinates to a single vertice. In real time rendering a vertice can only have one of each of these so sometimes a vertice has to be split. This means more vertices of course but it also means that each vertice has a much simpler dataset and is easier to handle for the rendering engine. That simplification more than compensates for the added number of vertices so this is how all real time rendering engines do it.