ChinRey

It won't be the first time a file mysteriously vanishes from a server and I assume that's what happened here. I know a few of the developers and they're really nice people and always eager to help. I've contacted one of them about the missing file. Let's see what happens. About the 3DS issue, I suppose it means none of the developers have experience with the program. Maybe it can be sorted out if somebody who does volunteers som help and advice...

Mad Elaine?

You think that is bad? A friend of mine on opensim once gave me a copy of a house she had made. It was (still is) a gorgeous replica of Case Study 22 and I loved it. But when I rezzed it and tried to position it, there were no arrow to be seen. But when I rezzed it, there were no arrows to be seen anywhere. It turned out that it had been accidentally linked to some parts several thousand meters up in the air (there's no linking distance limit on opensim). It took me a while to figure that out.

Oh, you're making hats! You'd better be careful with that, Madelaine. All that mercury nitrate isn't good for your health.

I didn't know until now either. But as I said, I haven't used the LL viewer for ages and only installed it now to test PBR.

I was thinking along the same lines. It wouldn't explain the weird result of the two scripts I posted but it would explain everything else. Come to think of it, we've all been making one aspect of this far more complicated than it needs to be. There's no need for scripts or fancy keyboard shortcuts to identify face numbers anymore. All you have to do is select a face and look at the builder/edit palette: (At least that's how it is on FIrestorm and on the PBR release version of the official viewer. I don't know about the official LL viewer. It didn't have this feature last time I used it but that was many years ago.)

😮 That's really, really weird. Even if the script I posted was hit by the same bug as Wulfie's it should have colored the whole mesh red, not left it unchanged! This probably isn't going to help much but if you have time to do a quick test, add this script to a copy of the mesh and click on it: default { touch_start(integer n) { llSetColor(<1.0,0.0,0.0>, ALL_SIDES); llOwnerSay("Done!"); } } It should color the whole mesh red. If it doesn't, we're well and truly into the twilight zone here.

Try this script too. (Sorry about the verbose comments in it - I did tend to overdo those back in my early SL days. 😉 /* A simple script to colour code the faces of a prim or a mesh (or a multi faced sculpt.) This is meant as a convenient way to see all the face numbers at a glance. To use it, just drag it onto the object you want to code. If the object is in a linkset, you need to open it an drop it into the object. The script will self-delete so there's no need to do anything with it after it's been used. Important note: The script will override all existing textures and colours of the object so use it with caution. If you want to know the face numbers without loosing the existing texturing, use this on a disposable copy of it rather than the original. Face colors: 0: Red 1: Yellow 2: Green 3: Cyan (Light blue) 4: Blue 5: Magenta (Purple) 6: Orange 7: Brown 8: White */ default { state_entry() { llSetTexture("5748decc-f629-461c-9a36-a35a221fe21f", ALL_SIDES); llSetColor(<1, 0, 0>, 0); llSetColor(<1, 1, 0>, 1); llSetColor(<0, 1, 0>, 2); llSetColor(<0.5, 1, 1>, 3); llSetColor(<0, 0, 1>, 4); llSetColor(<1, 0, 1>, 5); llSetColor(<1, 0.5, 0>, 6); llSetColor(<0.5, 0.25, 0>, 7); llSetColor(<1, 1, 1>, 8); llRemoveInventory(llGetScriptName()); } } /* HOW TO MODIFY THE SCRIPT You can change the colour codes any way you like of course. There is no fixed standard to colour coding prim faces but the ones I've chosen are fairly close to what most seem to use. If you want to retain the textures, you can just add two slashes - // - in front of "llSetTexture" -------------- -------------- COPYRIGHT NOTE This script was made by Bel (RenateIsabella Resident) 21.08.2013 to be included in Rey's Toolbox for beginner builders. * Permission is granted to anybody to distribute this file *unmodified* as long as they don't charge anything for it. * Permission is granted to anybody to use modify this script in any way they like for their own personal use. */

Try to log in to the main grid with the viewer. Next time you launch it, it should show the grid selection menu. At least that's how I got around that bug.

Yes but ideally SL diffuse maps shouldn't contain baked lighting either but they do and knowing my fellow content creators here I think it's a safe bet they still often will. I think I explained the difference between textures, diffuse maps and albedo maps earleir in this thread. Or possibly in earlier PBR discussion, I can't remember. Ok. The PBR documentation in the SL wiki says it's from water but I did wonder a bit about that myself, the sky did seem like a more plausible explanation. Anyway, it's good to hear it's been fixed.

I missed a few nuances in Nika's questions so here is a second reply. If you want to keep the original diffuse and/or normal maps you will have to have them in your inventory and add them to the PBR material you want to use. What you can expect at first are objects with glaringly overdone shininess that stand out like sore thumbs among the older content. Hopefully people will come to their senses after a while. The maps for glTF style PBR aren't actually that more advanced than what we already have in SL. The main weakness of SL's current specularity function is that it is so awkward to figure out it's hardly ever used to its full potential. You have those Glossiness and Environment parameters you never get right and then you have to fiddle with the alpha channel of the normal map to set specular intensity. Yes, I think those are a much more significant change than the surface maps. But at the moment the automatic reflection probes pick up way too much blue tint from the water that is everywhere in SL. As it is now you have to use manual reflection proves just about everywhere. Not only is this a waste of prims, it's also not very user friendly for people who aren't experienced content creators.

If it's modifiable, yes. It's hard to say but I wouldn't be surprised if it took much longer than six months. We'll see. In principle yes. It may depends on how old the waterfall is. I'm not familiar with Alex Bader's waterfalls but I know some of his other water features and he has made an amazing progress in water textures over the years. His early attempts were perfectly ok but nothing special by SL standards. His later ones are at a completely different level and it can take a while before somebody figures out how to do it better with PBR.

This is where you use the Knife tool in Blender. I'm not sure how familiar you are with it. Let me know if you need more detailed instructions and I'll try to post it - unless somebody else beats me to it.

It will be imported as separate unlinked objects. If you can get it imported at all that is. I tried with 257 basic cubes and even that took ages to upload and another age to render when I tried to rez the bundle. Edit: Interestingly although totally irrelevant, it turns out the uploader doesn't know how to round off the server weight when it gets this high. So I got:

I do but I haven't added anything to them for years so none of my more recent builds are available in SL. I may change my mind in the future but Second Life is simply too small a market for the kind of meshes I make for it to be worth the time and effort. Apart from some basic crossed sheet ones I've never made any jungle plants anyway so it's not relevant for this thread.

It doesn't have to be but yes, usually it is. That's the way to go, think in layers. I usually build up vegetation in four, five or even six layers. I posted a thread about it here a while ago. Warning: This is a very long and "technical" post, it's a bit outdated and it doesn't say much about LI. I mainly work on opensim now so I'm more concerned about actual resource usage than SL's often misleading land impact numbers. I don't buy plants since I can always make better ones myself if I need them but if I did, the makers and brands I would check out first would be: Skye and possibly Oswell Wayfarer for the relatively low lag filler plants Lilith Heart and Nadine Reverie for upfront high detail plants T-Spot, Reid Parkins, United Inshcon and JubJub Forder for both

The first question is unclear since a mesh doesn't have prims. If you mean upload a complete linkset with 256 or more meshes in one go, you can't. The maximum number of parts of any linkset in SL, regardless of whether those patrs are prims, sculpts, meshes or a combination of them, is 256. This is a hard limit with no way around it at all. Every part of a linkset needs a unique identifier, and address. This address is an eight bit integer which means there are only 256 of them. If you mean a single mesh with a high land impact, there is no fixed limit but the more complex the mesh is, the harder it is for the viewer to process and at some point it just becomes too much for it to handle.

Yes, it's normal behaviour. In addition to the various triangle/vertice count and linkset size limits (see https://wiki.secondlife.com/wiki/Limits), you also overload your viewer if you try to upload something that big in one go. Even if it doesn't crash, it will time out long before it has finished processing that massive amount of data. Yes, you can work around the limitations this way but you really should think twice before you do. You say nothing bad happens but did you try it in a sim full of other stuff or in an empty sandbox? Any reasonably modern computer should be able to handle one or two million tris, maybe even four or five millions if you're not too concerned about low frame rates. But that is for the whole scene. You want to use at least 1/10th of those tris for a single object. I won't tell you right out not to do it because it depends: If it's only for your personal use and you put it in a place where nobody else will see it, well, it's your problem and nobody else's business. If it's in a setting where you have full control of the surroundings and you are careful to compensate by keeping everything else very low poly, go for it! If you're planning to sell or give it away, please don't! You can not expect others to know how to handle something like this safely. If you're planning to put it in a place within sight of land and builds owned by others, please don't. Be considerate to your fellow SL'ers.

One of my tenants had a HiVid (or possibly something similar from another service provider) and yes, it's really cool. But no, it does not sync to everyone's media. Streamed media is synced but that is true for all SL TVs and all web browsers. What makes HiVid different is that they have their own pay-per-minute streaming channel. There is still no way to sync regular YouTube videos or anything like that in SL or elsewhere on the internet.

I think that's the new MeshOptimizer that replaced GLOD recently. I had a similar experience with the bog standard Firestorm: And yes, as Rick so subtly hinted at in the title of that thread, uploader-generated LODs are still the Devil's vomit even after LL changed the algorithm.

I love my greyscale base interior not on its own but because it allows me to play with colors. Dark red and mustard yellow sofa pillows, marine blue recliner chairs, a fruit bowl filled with all kinds of colors, pastel colored art on the walls, a bookshelf with a full rainbow of colors, a bright red guitar on a stand... It works because most of the furnishing is held in shades of grey, giving all those patches of colors the space they need to really come to their own and not interfere with each other. But of course that's a completely different concept than the all grey interior you were talking about an yes, I agree; that would be too bland.

Maybe, maybe not: No need for a JIRA. Those are known issues, listed in the release notes. But they need to be fixed or the whole project is DOA. LL seems to be confident they can but time will show.

All you really need to fully understand PBR are professional level 3D modelling skills and a master's degree in physics. But for those very few people who for some reason chose to dedicate their lives to pursue other paths of learning: what the metalicousionessity does is determine how much the color of the texture/albedo map/diffuse map affects the reflection/shininess. If the metalicness is low, the shine will be white, if it's high the shine will have the same color as the texture. This is actually a cruder and more primitive solution than the one we have now where we can set surface and refelction colors separately. It's not particularly user friendly either, regardless of how well you understand PBR. But computers - who aren't even allowed to study at univiersities yet - prefer it this way and we have to be nice to them because one day they will take over the world.

Thank you but as I said, it's not something I would recommend. It's probably more of a curiosity than a useful trick. You can't get precise kerning this way and for some reason the letters aren't correctly aligned vertically. I don't know why but it seems that darker text is positioned slightly higher than lighter.

Yes, that's the way it would have to be done in SL. It's still frustratingly complex though. You need a way to define the boundaries for the landscaper prim, you probably need some way to pause the script regularly since doing it this way in one go may well overload the scripting engine and above all, llModifyLand(() simply isn't suitable for the task. LAND_RAISE and LAND_LOWER won't give the precision needed whilst LAND_LEVEL will create steps rather than smooth transitions. The reason it works on opensim is that osl has a function, osSetTerrainHeight that can be called from anywhere in the sim (so no need to move the editor around) and sets the elevation for individual terrain vertices. Maybe we shuold campaign for a similar function to lsl? Or maybe not. There is a reason why the osl docs marks the function as "High Threat Level".