ChinRey

Well, it gave us an opportunity to point out that there are actually SL builders who take LOD and the other technical aspects of 3D modelling seriously. As far as I know, the flickering is caused by the draw distance. It happens when an object is right at the limit. That would be really useful. I think I spend more time minimizing the "jumps" between the LOD models than I do reducing their tri counts. It's more about normals than geometry btw. You get those surfaces that suddenly brighten up or darken when the LOD models are swapped. It's dead easy for a model like the tree in Animat's pictures but very often it's a serious headache. This is also arguably the biggest flaw with auto-generated LOD models; neither GLOD nor MeshOptimizer seem to take normal vectors into account at all. (Pro tip btw: Using custom normals to transfer normal data from the main model often often helps. Not always - sometimes it even makes matters worse - but often enough it's well worth adding the trick to your arsenal.) I'm not sure if there's that much point if it's only implemented by one third party viewer though. There are two more advanced solutions than cross-fading, tesselation and morphing with defined paths between the LOD levels. Those would require drastic changes both to the server and client software and even to the content creation work flow so they are not realistic options. I think there are a few AAA games that use tesselation but not many and as for morphing, I'm not sure if the technique has even been invented yet. Maybe I should patent it?

It's a bit hard to comment since the trees in the picture aren't here anymore but judging by the picture this looks similar to some of my 1 L$ budget trees, apart from the blur and a slightly different texture that is. In any case, all my trees have better LOD than this and so do Alex Bader's and Teresa Matfield's just to mention two others. Animats knows this perfectly well so I'm not sure what he's trying to say here.

Oh, I see. Yes, the problem with high reflectivity and normal maps is well enough known.

I haven't noticed such issues in any of the PBR materials I've made so far but I haven't done that many tests and it's all been brick, stone and wood textures that don't need that kind of precision. So I can hardly claim to know everything about it (yet). It does make sense then. Of course, if you want max optimization for performance, the way to do it is to try upload the maps separately first and switch to uploading a complete material if that doesn't work out but I wouldn't hold it against anybody if they're unwilling to make that effort for a fairly minor performance gain. Btw, I assume I'm not the only one to realize that this means we now can upload any texture or surface map with lossless compression. Just put it in the normal map slot of a glTF material and off you go.

It's not my problem, I'm uploading so many textures these days I had to switch to Premium Plus anyway but you're saying that If you want to convert an old style texture to glTF PBR you are supposed to reupload everything and If you have a dozen or more color variants of a texture you are supposed to upload separate duplicates of the normal and metallic/roughness maps for each. There's gonna be a helluva lot of duplicate assets to store, download, cache and render this way. Of course, there's a fairly straightforward workaround for #2 but how many are going to use it or even known about it? Yes and no. If LL is implementing true mip-mapping, it may well be time to retire the lossless compression. But if so, why only for normal maps? It makes just as much sense to switch to lossless compression for textures and diffuse/albedo and roughness maps.

Are you saying normal maps use lossless compression if and only if they are imported as part of a PBR material? There's no mention of that in the documentation and it makes no sense. Where do you have that information from?

You can always upload the maps you actually need separately and assemble them into a PBR material inworld. That makes sense for materials that don't need Metallic-Roughness maps at least and let's face it, many materials don't. But I thought there was no additional fee for the emissive map. Am I wrong?

"Going slow" is the worst thing you can do. The rule is to scale once as the final step in the creation process. You might be missing paint.net. Paint.net is a free mid range image editor and it's the only image editor I know of that supports the fant scaling algorithm. Fant is usually the algorithm that gives the best result for textures. But min you, I say usually. There is no rule without exceptions and this one has a lot of them. Ideally you want to try as many different algorithms as possible and see which works the best. It will also help if you can crop the texture down to a product of the target resolution (for 256: 512, 768, 1024, 1280, 1536 etc.) before you scale although that's not always possible of course.

No, I can't. There's no mention of it in either of the HAVOK manuals and it doesn't seem to make any sense. What I do know is that it's all about ray tracing. SL uses ray tracing to locate the surface an object is to be rezzed on and mesh surfaces you can't rez are also not detectable with the llCastRay() function (thanks to @animats for figuring that out). It's not as simple as those objects being "invisible" to ray tracing though. If it was, the item would just have been rezzed on the next object on the path. This is what happens if you point straight down at the surface but if you rez at an angle (which we usually do of course) it won't detect the next surface along the path either. It looks as if a faulty mesh deflects the ray tracing path somehow. Or it may be because of the way the hulls were generated. Try to make a hull manually from a simple cube. If the cube you use is solid with all six sides, it will work fine even with hull method set to surface. If it has one open side, it won't.

Aww, sorry to hear that. All isn't lost though, you can always rez the furniture outside the house and drag in place. It's inconvenient but it works.

There have been several explanations posted here over the years but finding older post on the SL forums is a nightmare. I managed to locate this though: https://community.secondlife.com/forums/topic/409912-rezzing-things-on-mesh-floors/ It's not the best explanation but hopefully it will do as a start at least.

That's nice to hear. I hope they figure it out and let us know if they need some advice. This is a well known problem and it's caused by an undocumented quirk in SL's physic engine. It's fairly easy to fix once you know how to do it but it can't be done in-world, the mesh has to be reuploaded with a cirrected physics model.

Yes, that's not a bad site. Not all of the items there are low poly though, no matter what they claim. The trees in particular are *extremely* high poly and not recommended for a dynamic environment at all. Sweet Home 3D is an open source interior design program so the models there were never intended to be used in a live virtual reality. Also, check the licenses, there are several different ones there.

If you're using a Windows computer, try paint.net instead. It's so much easier to use than Gimp and Photoshop and although it isn't nearly as advanced as them it has almost all the features you need to make textures for Second Life. I make all kinds of textures and I can't even remember last time I had to fire up Gimp to use some obscure fuction paint.net lacked. Make two layers, add the template to one and create your texture in the other one. Once you're finished, hide or delete the template layer and save the end result as PNG, 24 bit for regular textures, 32 bit for alpha ones.

I've had this bottle of Chardonnay for almost a year now. Time to enjoy it before it's too late. And some suitable music: (Some song facts for those who just have to know: The Swallow was written by Richard Farrini who recorded it with his wife, Mimi Farrini (Joan Baez' sister and a grossly underrated singer and guitarist). Joan Baez was supposed to include it on her first electric folk rock album but that album never happened because Farrini, hwo was the producer, passed away only 29 years old. This recording is from a 1995 Joan Baez concert with Mimi Farrini as a guest artist.)

Oh yes, that's standard procedure if you live near an open and onmonitored parcel. At least it is if you want to enjoy your land in Second Life. One of my neighbors got rather mad at me when she turned up after a few months and saw her land filled up with lots of invisible phantom prims. But she mellowed down a bit when I showed her a pic of how it looked before I added them and after she got hit herself by a massive griefer attack from another unprotected plot, we became best friends.

There was a time when threre were random griefing attacks with those self replicating, noisy, blinking, particle spewing objects somewhere in SL almost every day. The worst one was when somebody was stupid enough to rez a "gift" they received from somebody they didn't know at the Union Passage sandbox. It spread out across all of the Blake Sea and the estates around it. If I remember right, about 70 sims were down for a whole day or more. The girefer objcet was bright red and big enough to show up on the map so the map of the area was crammed fulled of red dots for days until it was updated. Towards the end of that griefer period I managed to catch one of the offenders in the act trying to place some griefer thingy on my land. She had posted some rather incriminating photos and text in her profile so I was able to do some investigating. It turned out there were some people trying to rekindle the "griefer wars" of ye olde tymes and one of the groups - the one who pretended to be the "Protectors of Second Life Against the Filthy Griefers" had this initiation rite for new members that included the candidate finidng some spot in SL to grief. To be fair, the attacks that group initiated were scripted to only last an hour or two but it's still a rather weird thing to do if you want to portray yourself as the "nice guys".

I was wondering about that too but I'm too lazy to check. Does anybody know?

I wouldn't bother with hunting down the script in a case like this. Firestorm has this nifty function that resets all scripts in a linkset in one go.

Scripts are run by the server so none of these standard fixes will work. A stack-heap-collision error means that the script has run out of memory and is trying to use the same memory blocks for code and for data. I suppose I don't have to explain why that is a bad idea. If the body is modifiable you can try to reset the script. There may be a lot of old garbage that that has accumulated over time and resetting will fix that. It's more likely there's something wrong with the script though. Either your copy has been corrupted or it has a bug. Try a fresh copy of the body first - if you don't have a backup, get a redelivery. If that doesn't help, contact the seller.

That's an interesting method. Yes, you'll have to triangulate before you export and you also have to remember to use smooth normals but it's not a bad way to create irregular shapes like rocks. Wow, that's a lot of polys! You can always decimate the shape of course but you'd have to do it very heavily so the first method is probably the one of them that is the easiest to use. There are several other ways to make rocks. I usually start with a relatively high poly sphere (maybe around 500-1000 vertices), resize it along one or two axises, randomize the vertice locations and use limited dissolve and manual vertice delete to reshape and reduce the complexity down to a sensible level. Which method you choose doesnt' really matter as long as you can get a shape and a tri count you're happy with. With a good texture it's quite possible to make very good looking rock with a tri count less than 50 and even as low as 20. Option 3 - do both. Add some very simple geometry around the opening as a base and pile a few simple rock onto it for additional details. The origin of an object in Second Life is right in the middle of the bounding box, that is right in the middle between the outermost vertices along each axis. I don't know of an easy way to find it in Blender and I too woul love to learn fit here is one. That solution won't survive exporting. What you need to do is triangulate everything before you export. You can't really trust the automatic functions for irregular shapes like this unless you really know what you're doing. Also, merge or delete vertices that are too close to each other or crate too sharp angles. Not sure what you mean: in Blender or in SL?

Apparently not. There are still some working tools for creating sculpts but they tend to be very idiomatic both when it comes to how they work and what shapes they can produce. I can try and compile a list of them (that's something I should have done anyway) but there probably won't be any that suits yuour needs.

It's not just Cloud Party. As far as I know, all reasonably modern game/virtual world engines have that feature. As for the "price" to pay, include the swap distances in the land impact calculation so if you increase them you also increase the LI. Keeping the fixed swap distances from the prim system was one of the two biggest mistakes LL made when they developed mesh (and also one of the biggest mistakes when they created sculpts) and I don't understand how they missed something as obvious as that. You can of course get better results by tweaking the uploader settings than you can by using the default values but it will never be optimal and tweaking those settings takes time too and will probably require more test uploads so I'm not convinced it's actually faster in the long run. One more illustration then. This is the roof for the same house as the pair of rooms from my previous post. I haven't finished UV mapping it yet so I'm not going to upload it, just show pics from Blender and from the uploader window: With default settings in the uploader I get 1.364 LI which is a little bit too high but not too bad: However, look at the medium model: 46 tris and still clearly not good enough. Mesh Optimizer isn't actually able to create a medium LOD model at all for this mesh. I have to go all the way up to no reduction at all, giving me a whopping 186 tris and 10.913 LI!!! "Good" (not really) old GLOD actually does a better job(!) but it still can't get it lower than 93 tris and 5.733 LI: As for the low and lowest models, they don't matter much for a mesh as big as this (17x11.5x5.5 m) but GLOD can do a fairly decent job and reduce them down to 24 tris. Mesh Optimizer still can't handle this mesh at all. It needs 179 tris for the low and lowest models and a reduction as minute as that is not worth bothering with. Properly optimised the tri counts for the LOD models would have been 32, 12 and 12 respectively and the LI would be somewhere between 0.8 and 1.1. The uploader can't even get close to that without serious LOD butchery. It is of course a little bit different for furniture, simple indoors objects that don't need to be seen from a distance. For such items you can afford to waste a lot of tris on the LOD models and still keep the LI down to 1 and no amount of optimisation can get the LI lower than that.

One day sounds like a lot to me. This is not a complex build but with all the curves it's not exactly a simple one to create LOD models for either: At 0.5 m height it's 1 LI by a good margin (0.7 download weight) and here is how it looks at low LOD - 18 m view distance with LOD factor 2: I do not know how good or bad this is compared to how others do it and I do not know what people expect but it took me exactly ten minutes to make the LOD models. It's all about developing efficient procedures and also to learn how much it's necessary to reduce. If you have to figure out how to make the LOD models from scratch for every new build and also spend a lot of time testing models to find the optimal one, there's hardly a limit to how much time you can spend but even some very basic routines will save a ton of time. Here's another example. This is a mesh with the interior walls, floors and ceilings for two rooms of a house. A bit complex with four window openings, two doorways and two archways but not much more than you'd usually want for two rooms. (Btw. I always try to combine the interior of two rooms in a single mesh since that gives me six faces to work with for the walls, floors and ceilings of each. And unless it's a very small house I always have separate meshes for interior and exterior since they need very different LOD handling.) 15 minutes of work to create LOD models simple enough to keep the LI down to 1 but detailed enough there are no noticeable reduction whatsoever even with LOD factor 1: Normally I owuld have done it in ten minutes but it's late night here so my brain isn't working too well. I made a mistake with the mid LOD and had to redo it.

The most likely explanation is that the 4 LI readout in the viewer is wrong. That happens every now and then. If this is the case, there's not much you can do about, 22 LI is the correct number and it's what the server operates with no matter what your viewer says. There is one easy way to find out if this is the answer: In the parcel details, check how many prims are used. Then rez a copy of the build and check again.