ChinRey

Yeah but before we get too excited, remember that this is just wishful thinking; there's no realistic chance LL will implement the idea. Still, it would be itneresting if somebody filed a formal feature request if only to see how they responded.

That's not very different from how it is today. I've yet to see a mesh that couldn't keep at least a dozen triangles in all LOD models without increasing the LI, 20 isn't unusual and 50 isn't too uncommon either. It is a good idea to formalise this but the real problem is that too many content creators (including the Lindens and Moles unfortunately) do not know how to control their LOD levels so they oversimplify out of ignorance. The main problem with LOD in SL, however, is still that the number of levels and the swap distances can't be set for individual objects. I'm not aware of any other virtual environment (exepct the opensim SL clone of course) that has such a crude and heavy handed approach to LOD and if glTF compliance forces LL to change this it may well turn out to be one of the biggest improvements SL has ever got.

I've been thinking along the same lines for a while. I'm not quite convinced it will offer improved performance since it will require client side baking but it offers several other advantages as your pictures show so well. Also, and perhaps most important, because an efficient AO map on a tiled texture require different resolution and repeat rate than the other maps.

I can't really help you with rigging advice but I can explain that huge bounding box at leasy. When you wear a fitted mesh, the bounding box it is assigned is not the size of the mesh itself but the size of your entire avatar multiplied by how much the mesh is tretched by the rigging. This is one of the four fatal mistakes LL made that cause mesh avatars to be far laggier than their calculated render cost indicates. Your hair's bounding box is actually quite small compared to many other fitmesh objects. Now as I said, I can't really help you with the real problem your hair has but have you checked for loose geometry? A stray vertice or tri may explain it.

That's documented in the LSL Portal (https://wiki.secondlife.com/wiki/LlSetKeyframedMotion) although you have to read the text carefully to figure it out. There's always a workaround but do you really need complex physics for this? There is a reason why LL implemented this restriction.

That is usually correct. However, the viewer will try to consolidate draw calls for regular meshes, prims and sculpts but not (and this is important) for fitted mesh. So if there are several faces with the same texture and other surface properties in a scene, they should be handled as a single draw call. The number of draw calls matters a lot but compare a mesh with six faces/draw calls to a mesh avatar where each and every alpha cut needs its own draw call! Besides, splitting a mesh into several faces have a couple of potential advantages when it comes to render efficiency. Splitting adds more opportunities for using using tiled textures for a start, and with them you can get much higher resolution with smaller textures; there can be a lot to save that way. Using simple "single purpose" textures also means there are more chances you can re-use the same textures for multiple objects, you have more ways to create variety by using the same mesh with subtly different tints or different textures. All of these are factors that will reduce the render load. There are certainly way too many meshes with single baked textures in SL today but that doesn't mean it is always better to go back to the good old multiface tiled texture method. It depends on several factors and in the end it's all up to the individual builder's good judgement - or lack of such.

For those you need to make a separate model for the physics. You have to understand what the physics model is and what it's purpose is. For a house it has to functions and two functions only: Keep the avatar from walking through the walls and flying/jumping through the ceiling Give the avatar solid floors (and if you're a good mesh maker) roofs to walk on That's all. Handling physics is one of the hardest tasks the server have to do so you need to make the physics model as simple as possible. For a house that means big flat surfaces representing the major parts of the structure, walls, floors and ceilings and nothing else. I'm not sure how to give more detailed advice without knowing a bit more about your build. Can you post some pictures of it so we know a little bit more?

I'm the kind of person who doesn't fit any stereotype with a name ending with "ie". So I'm not a "normie" and I'm not a "non-normie".

Not at all! 🙂

You can as Aquila demonstrated. Me, I'm usually too lazy for that. Most of the time I simply triangulate an unclear surface temporarily to see which way is up. Take this for example (UV map to the left, mesh model to the right): You can't see which way the UV map is rotated here of course but look at only one triangle: and it's clear as ink. Edit: I think I should comment on this because Aquila makes a very important point that is far to often missed: Let's make this absolutely clear: Blender does not make good UV maps automatically!!! Back when Klytyna was active on the forums, she kept talking about Blender's auto-bakefail and that's a very good word for it. Blender can give you a good starting point but you have to be prepared to do some manual editing if you want a decent result.

If you look closely at the two vertical surfaces closest to the camera, you'll notice their UV mappings are rotated 180 degrees relative to each other. It's hard to see on the very symmetrical grid texture but very obvious with the looser stone texture.

Yes, planar usually works well on simple square surfaces but it doesn't take much deviation before you get into trouble. There's one thing that's not clear from your post: are these meshes UV mapped at all? Btw, I know you're an experienced prim builder and one workaround for objects as simple as these would be to build a prim draft, get all the textures right in an environment you're familiar with, export with Firestorm's dae export function and clean up in Blender without touching the UV maps there at all. You would have to sue default texture mapping for the draft though, planar mapping does not export.

I was called in to help somebody with reducing the LI for a model they had uploaded and I noticed something rather strange. The model was made from 38 meshes and had a total of 874 tris and 3 096 vertices. How is that possible? Even if there wasn't a single shared vertice among the tris and every mesh had a loose vertice, that still doesn't add up to more than 2 660.

Does LL know this? If not, add a comment about it to your support ticket. They will revert the account to an earlier email adress if necessary. Unless something went wrong with LL's routines, that was done automatically when you filed your support ticket.

I know this from the other side. I don't have time to do custom jobs at the moment but back when I did, every now and then a customer wanted their own name as creator so I sent them the dae files. On a few occasions I had to walk them through the upload process too. 😉 I thought that was only fair. It was the customer's design and he/she (usually he come to think of it) was the one who had done all the creative work. In many ways I wish there was more cooperations among builders. Nobody is an expert on every single aspect of content creation and it only makes sense to lean on each others' strength. Maybe it's because I'm a musician in RL so I'm used to art and creativity being a collective effort.

Have you tried a limited dissolve? I don't know for sure if this is the cause but your mesh has an extremely high number of superfluous vertices and tris and I wouldn't be at all surprised if it's enough to cause render failures in SL.

I can see this is a problem for rockets and such but does it really apply to handguns? I have little experience with shooting games so I don't know how it's done there. But I do have experience with shooting and being shot at in real life and you don't see bullets in the air, they are way too small and fast. So if realism is what you want, you don't need temp rezzed bullets, you only need a way to calculate where they hit.

Damanios Thetan used to have a lovely high speed bumper car track for sale. I loved it and really, really miss it. But he gave up on SL and left. 😞 Then there was Pip's HUGE rollercoaster at one of those New York themed sims that went belly up. She's been talking about rebuilding it on opensim for a long time but haven't gotten around to it yet. Oh, and am I the only one who still remember that motorcycle track on that blues themed sim? I don't know. There used to be a few places like that but maybe not anymore. The more I think about it, the more good games of the past I remember. I think this shows the real problem here. There used to be, there used to be, there used to be... We can't really have really high speed action games in SL but we can get fairly close. As for other more relaxed games, most of them can be done in SL and in fact most of them have been done. But somebody have to build those gadgets and scenes, somebody have to write those scripts and - above all - somebody have to host those places and pay that bloated tier. It's not the SL software that is the real problem, it's how much time and effort it takes to make and run those games and how little the ones who do it get in return. There are probably lots of good games of all kinds going on in SL even today, you just have to find them before the owners/creators give up.

Sounds like Decentraland. But really, I think all the recent virtual world wannabes have worse content than Second Life. Yes, those UE and Unity based showcase environments look amazing and so do many of the professionally made and carefully controlled games made on those platforms. But once people try to make complex virtual worlds on one of these platforms, it falls through. Either they end up with scenes so heavy only the strongest game computers can manage them or visuals way below the quality we are used to in SL. If it's the one I think, they don't have much content at all. The only game in town is to buy some small nondescript overpriced piece of land at a price and then hope you can sell it off to somebody at an even higher price. 😉 But with that being said, anything that can improve interactivity and add to the things we can do in SL would be great. So, as Rowan already asked, what did you have in mind?

I did a quick test with a six prim linkset and yes, this is how it worked in that particular case. But just Rolig and Optimo, I do not trust it, at least not until we have a lot more test results. Btw, as a bonus I think I stumbled across a pattern in Firestorm's incorrect link part numbering. Maybe we can finally get that old bug fixed now?

Yes, you can. Just make sure you delete the superfluous thin tris along the edges. This too would make the entire mountain hollow though and that's probably not what you want.

No, it's realism. People are superficial and tend to judge others by their skin colour or nationality or gender or whatever stupid reasons they can come up with. I wish it wasn't so but it is and Second Life is no different from Real Life there. I don't think there are many SL'ers who have never been unfairly banned from some place. It happens all the time. In Second Life the landowner is a supreme ruler and can ban anybody they don't want from their land for any reason they can think of or for no reason at all. Linden Lab will not interfere in such cases and there's not much anybody else can do about it. Fortunately there are always alternatives in SL so if you're not welcome in one place, there is always somewhere nicer to go.

I can't decide, do I want to be a Barbie or a pony?

To clarify this, you can only have one named UV map. But you can effectively have multiple UV maps simply by reusing the same UV space for different faces. Take this pillar for example (it's only a demonstration so I didn't texture it, I just gave the different faces different colours): The UV mapping for the main coulm and the what-cha-call-it close to the top (red and brown in the picture) looks like this: The base (yellow and green): and the capital (everything else): As you see, there's a lot of overlapping here: But since they are different faces, they are textured separately and won't interfere with each other. So although it's nominally only one UV map, for all practical purposes there are three different ones.

No, it's perfectly possible to have a texture/map modifier that only is applied to a single instance of the asset: store it as a prim property and apply it client side. SL already has several texture/map modifiers that are handled this way.