Quarrel Kukulcan

Joining in Blender is taking two or more separate mesh objects and combining them into one single (and probably noncontiguous) mesh object with the "join" function. Linking in SL is when one or more child prim/mesh objects are connected to one parent prim/mesh object. It's what you end up with if you don't join in your 3D modeler.

Did you make sure "Selection Only" was checked when you exported? Your error log contains references to things like "cubefive" even though those are grayed out in your screenshot. P.S. Also everything Chic said x1000.

I sent you a reply in private about this. You have multiple bark materials with different names in your model. I suspect you didn't change the scale on all of them after you imported.

You said you already have a normal map, though. You even showed how you were using it in your Blender shader screenshot. I was pointing out that if you also make a bump map, the only way you can use it in SL is to convert it into another normal map and use this new one instead of your current one. It will be a waste of time unless the new one looks a lot better. Are you going to try the Animesh trick or are you going to divide the meshes into pieces? You will have to do a lot of things differently depending on which way you try.

SL doesn't take bump maps. It can only take normal maps. If you already have a normal map, there's no reason to make a bump map. The only thing you could do with it is convert it into a different normal map and use that one instead of the one you already have. You don't need a specular map either. These are just leaves.

I thought when owners edited their land, they had a special way to place official Linden trees, and that way is different from rezzing objects. I could be wrong. It works for other people. You'd have to build a single leaf clump billboard cluster in-world with SL's build tools -- NOT in Blender -- and then rez multiple copies of it and move them into position on your bare tree trunk and branches, then link them. SL's particle system is made for an entirely different purpose than Blender's. It's only for fancy graphical effects. Second Life cannot place particles in a custom shape, like along a twisty branch. Second Life cannot use child meshes as particles. It can only use floating images. It also can't make those images line up in 3D with the object they're coming from. SL's particles are specially programmed so they auto-rotate toward the camera and always have their top either toward the sky or pointing toward the direction they're moving.

Making your billboards double-sided has NOTHING TO DO with the shininess problem. It fixes an entirely separate issue. A one-sided billboard will be invisible from the back after you import it into Second Life. It will act like this: If you make your billboards in pairs (and make sure they face opposite ways), you won't have this problem. Okay. Now I AM going to talk about the shininess problem. DON'T TRUST HOW SHADERS MAKE THINGS LOOK IN BLENDER. If you want to know how something will really look in SL, you have to do a test import and look at it in SL. Blender is good for checking that the UV map is correct, but most shader settings don't export automatically and many of them won't work in SL anyway. The leaves won't be shiny in SL unless you fully import the object, rez it, go into the Build Menu and manually turn on its shininess settings. Don't use a normal map. If the shininess in Blender bothers you, just increase the Roughness setting for that material.

It's ENTIRELY DIFFERENT. The only thing that's the same between the two is the word "particle". The particle system in Blender is a way of generating a swarm of starting points across the entire surface of a mesh or in a cloud around some single spot in your model, and then using those starting points as the roots for hair strands or auto-generated child copies of a 3D child object. The particle system in Second Life is a way of making 2D sprite images fountain out of the middle of a prim. I think that the original system trees built into the terrain editor sway because of a special feature that we can't access. It's similar to flexiprims though, and most of the swaying trees I've found that residents created use flexiprims.

It's harder to position leaves with a particle system than manually, because 1. It's yet another Blender feature that you have to learn how to use from scratch, and 2. Like many features, it is better at building a scene that looks good when Blender makes pictures from it but not very good at making an object for Second Life that has low LI and looks good to other residents.

Yeah. SL doesn't let you drag an Animesh prim when it's a child in a linkset, so if you want to align it with something else in the linkset, you have to drag the other thing to align with it. Which you can only do if the other thing is also a child. It's just another dumb thing you have to do to make SL "work right".

Why does this need to be a 3-object linkset? Why not make the physics tree the parent?

The very first thing to do is get a good idea of HOW the leaves will look. What kind of tree is it? Is it one gigantic canopy or lots of separate clumps? Find some reference images of real trees you want your model to look like. Or draw some sketches on paper. A common trick that keeps graphics complexity down in 3D games is using multiple medium-sized panels with images of leaf clusters. You can get a good idea by looking through the pictures at http://www.sbgames.org/sbgames2011/proceedings/sbgames/papers/comp/full/03-92284_2.pdf or watching the video at (You can use Blender to create and bake the leaf clump texture if you want, or you can draw it another way. The important part is the second half.)

Aquila told you what to try: make it Animesh. Because Animesh objects calculate Land Impact differently. But you can't upload an object in Animesh form! You have to upload it as ordinary mesh, then rez it, then use SL's Edit panel (Features sub-tab) to turn on the Animesh checkmark. That means you can't tell what the Animesh version's LI will be while you're uploading. You have to actually *do* the upload (and use the Preview Grid, it has free uploads!), turn on the Animesh option and see what happens. And understand that even though this can't reduce your upload cost, it will still affect how much LI the object uses up in the sim, and that's still good.

What are your Ease In and Ease Out values? You'll want an Ease In of 0 for the second animation so it plays at full strength from the very beginning, and probably a very short but non-0 Ease Out for the first animation so some of it stays in effect briefly when it gets stopped. I won't be surprised if it's impossible to find a value that works seamlessly for all viewers in all lag conditions, though.

You could rename each weight group manually. It'll be a little time-consuming, but if there's no alternative...

I don't understand how you're keeping bone translation distances accurate if you're changing the scaling on import but not changing it back by the reciprocal amount on export. If the animation you're importing is SL-compatible, that means all its distances are in inches. So you'd want to convert from inches to whatever you've set Blender to work in. If you've left it at the default (which is meters), the scale should be the inch-to-meter conversion factor of 0.0254. The scale factor you've typed is 0.3937, which is the conversion factor from centimeters to inches -- it doesn't make sense to apply that to something that's in inches already. Of course, if you're only rotating bones, not sliding them to new positions -- not even the hip bone, which is the only one you can reposition if you're checking "Root Translation Only" -- , scale doesn't matter.

Try a combined bake with diffuse and glossy contributions.

Looks like it moved to Render Properties > Light Paths > Fast GI Approximation (link I found by chance looking for the manual). I wonder if AO works differently in Cycles in 3.0+. In 2.8 it added more ambient light to the non-shadowed areas; you needed to use an AO node in your material if you wanted darker shadows.

There's also the kludgy way of satisfying the requirement: stick a single small triangle somewhere out of the way if you need to ensure a material exists somewhere in a LOD.

When you mirrored, did you enable merge by distance? And did you apply the mirroring? You could have multiple overlapping vertices with partial connections where there should be only one joining everything.

Nope. Also, it occurs to me that if you're talking about landscape-size features meant to be walked over, a normal map will only be able to add a rough appearance to the ground (and at a poor resolution). You can't implement large-scale terrain features that way.

For the first issue, if it works on a plane but not a mountain, something is wrong with your mountain. After all, a plane is just a mountain with fewer polys. You might have forgotten to UV map it, or you have unapplied scaling, or the wrong side is out (a.k.a. flipped normals). SL doesn't support displacement maps, though it does support normal maps, which give the appearance of bumps and valleys on a surface without deforming or adding complexity to the mesh. If you have a displacement map or bump map, you can convert it into a normal map with a tool like GIMP or a website like NormalMap-Online. (You'll need to experiment with the mapping height/scale so the details aren't too weak or overblown, and for SL you'll need to tweak settings so the result looks like it's lit with green light from the top of the screen and red from the right.) If you already have a normal map, just use that (correcting the red or green channel first if you need to) and ignore any bump/displacement maps in your texture bundle.

This page shows how various features affect render weight. Each multiplier will only affect the prim's cost once even if more than one face uses that feature. (PS "alpha" specifically means alpha blend mode only. I'm not sure if "bump" and "shiny" count the old standard settings or only if you supply a normal/specular texture.) https://wiki.secondlife.com/wiki/Mesh/Rendering_weight Neither Full Bright nor an emission mask increase render weight. Full Bright will make that face look as bright as in full sunlight at all times, and also never have shadows cast on it. For an emission mask, you have to re-make your texture with a full image alpha channel at some moderate value that you'll have to experiment with to get right (hint: preview it with the Local Texture feature!), plus you won't be able to have any transparency or translucency. You'll need to set the face's alpha mode to emission and always set Transparency to 0%. What do you mean by "rotating the wall horizontal"? Do you mean lay it flat so the inside points toward the sky, like it's a floor, or rotate it like a doorknob turns so it switches from landscape to portrait?

I tried to append this last night but the forums had cycled into maintenance mode.

It does have that ability. You have to turn it on in your Preferences. After you start Firestorm but before you log in, type Ctrl-P (or Viewer->Preferences menu), go to Advanced tab, click on "Allow login to other grids". You have to change preferences in the standard viewer too. Viewer->Preferences menu, Advanced tab, "Show Grid selection at startup". I don't know what you mean by this. Fly around until you find the distinct low wall marking the sandbox area. No, it doesn't show on the map or any searches, but there are only four squares to the map, more or less. It shouldn't take long to find it by exploring, especially since it resembles the basic starting area layout of the mainland. It all takes some trouble to set up, but the free test uploads are worth it.