Drongle McMahon

A model can consist of multiple mesh objects, and each object can consist of multiple materials (sets of faces which are allocated to the same texture). The upload format consists only of triangles. Any higher order polygons are converted into triangles by the uploader. So we only need to consider the numbers of triangles. A single object can have up to eight materials, and each material can have up to 21844 triangles. So the maximum you can have in a single object is 21844 x 8 = 174752 triangles. However, the uploader uses a couple of tricks to give the impression that you can exceed these limits. First, when the triangle count for a material exceeds 21844, it secretly starts a new material. It can do this until you have used up all eight materials. So if you have an object with only one material and up to 174752 triangles, it will appear to upload normally. Internally it is represented as multiple materials, but as they all have the same name, they are supposed to always have the same texture. However, while you are changing textures, you may see some unexpected behaviour revealing the fact that there are multiple textures. These effects are not seen by other observers and disappear after a relog. In the second trick, the uploader will also now accept a single object with more than eight materials, but it does this by internally splitting it into multiple objects, which can be separated inworld by unlinking. The way it does the splitting can have significant effects on the LOD behaviour and the LI. If you have both more than eight materials and some with more than 21844 triangles, you can get some very unpleasant effects in spite of the fact that the model will upload. To avoid unexpected and undesirable effects it is always better to respect the limits of 21844 triangles per material and eight materials per object. You will always do a better job (better LOD behaviour and lower LI) of splitting materials and/or objects yourself than the uploader will, and sometimes it does a very bad job indeed. Since you can have multiple mesh objects in your model, there is no upper limit on the total number of triangles in an uploaded model. However, there is supposed to be an upper limit on the total file size (see wiki limits) which would impose a practical limit. I have never tested that. Finally, you should be aware that minimising the polygon count is one of the most important ways of creating efficiently rendered mesh that will avoid lag. High counts will be penalised by high LI for static objects and by lag for attached objects. It should never really be necessary to reach the limits described here for any object well designed for SL.

Also note that unlit faces will appear black if you have viewport shading set to Texture (button at bottom). If instead you set it to Solid AND set the Shading to Textured Solid (in Properties on right), you should be OK.

You can rotate the UV maps for each face - select the face, select all (A) in the UV editor, then type R90 to roatate 90 degrees etc. It will be easier if you have an image on the cube in Blender so you can see what's going on. Simplest way to do that - switch to Blender Render (middle of top bar) if it's Cycles; Select all the faces (A); open the image in the UV editor window; Set display to Solid (button next to mode, below 3D view), and Shading to Textured Solid (Shading panel in Properties bar on right of 3D view).

"XI" = Mesh->Delete->Dissolve Edges; "AltMI" = Mesh->Vertices->Merge-At Last  If youdon't check "UVs", the texture will be messed up at the corners.

"английский" and "язык" are "english" and "language" (according to Google translate)

The default collision (physics) shape is a convex hull of the low LOD of the uploaded mesh. By definition, it is impossible to get inside a convex hull, as it cannot include concavities or holes. To make a house you can go inside, you need to make a suitable phsyics shape. You do this on the physics tab of the uploader. However, getting physics shapes for buildings that work as expected and still have resonable physics weights (and thus reasonable LI) is not trivial. It generally requires using a specifically designed simplified phsycs mesh. There are many threads in this forum dealing with the details of different ways of doing this.

With alpha masking pixels are always either entirely transparent or entirely opaque, depending on their values relative to the threshold. Changing theb threshold alters the mask if the alpha channel contains a gradient, but will never produce intermediate transparency. If you want graded transparency, you have to use alpha blending (with consequent higher resource consumption and alpha ordering artefacts).

Arton mentioned that you have to pay the fee each time you upload the same texture with a modified mesh. There'a another problem too. The uploader doesn't know it's the same texture. So it treats it as a completely new asset, with a new UUID and occupying extra space on the asset server. So it wastes space on the asset server and slows it down. Furthermore, it makes a new copy in your inventory, clogging that up too (it's in a textures folder with the name of the uploaded model). Finally, if you have several versions of an object, or different objects, all using the same texture, in the same scene, where each object had the texture uploaded, then it has to be downloaded from the asset server again for each of the object, as the UUIDs tell the viewer it's a different texture. All these effects are affronts to the general principles of efficient resource re-use. So there are good resource and performance arguments against uploading textures with the models, even if you can ignore the cost argument.

"THEY ARE BOTH 2 in the UPLOADER" You need to remember that the physics weight shown by the uploader is only ever the weight of the default single convex hull, the one that gets used when the type is set to Convex Hull. Neither analyzed nor un-analyzed Prim-type weights are available until you upload and rez. This is very annoying, but at least one jira requesting it to include the prim-type weight has been outstanding for years. (It might be because the un-analyzed weight is size-dependent and many may resize their meshes after upload and then complain that the weight was wrong.)

I have to agree that those wiki pages are not as clear as they might be. Reading both your answers, I think some of your problems with the SL lighting is because of the differences in SL between specular reflection and the very simplified environmental lighting. I will try to explain how these seem to work, at least as far as I understand them. Environmental reflection is very simplified. The environmental light map (in effect - I don't know if it exists as such at all) takes account only of the sun/moon and the sky. It ignores other light sources, and it ignores secondary reflections and shadowing. It's also very fuzzy. So it is completely incapable of providing the sort of reflection detail I think you are looking for from metallic surfaces. This is indeed a severe limitation on attempts to make things look metallic, or otherwise polished. Also, it is not affected at all by the proper specular parameters - not by the specular map, the "glossiness" (specular exponent). The colour is that of the incident light. The intensity is determined by the environmental map (the alpha channel of the specular map) multiplied by the environment parameter. The reflected light replaces the diffuse reflection to that extent. So with parameter 255 and white map (also 255), there is no diffuse reflection left. This should be a chrome-like effect, but because of the lacking detail, it is a very poor one. The specular reflection is more like what one would expect. It's colour and intensity are controlled by the RGB channels of the specular map and/or the specular colour. The sharpness of the reflection (specular exponent, defining extent of scattering of light around the reflection angle) is controlled by the map in the alpha channel of the normal map, combined with the glossiness parameter. If these are black and/or zero, there is no specular reflection at all. Then at 1, there is a very widely scattered, but low intensity reflection, As the values increase, the reflection gets brighter, but restricted to narrower angles around the perfect reflection from light source to camera. Unlike the environmental reflection, the specular reflection is added to the diffuse reflection. It does not replace it. People are often very unsatisfied with the results from the SL specular reflection, and your comment that you only see it with added local lighting is often repeated. However, I think these impressions are not the result of anything wrong with the reflections themselves, but rather problems with other aspects of the system. First, there is no contribution at all to the specular reflection from what you would expect from an environmental light map and no secondary reflection. So what you get is only direct reflection from the sun or moon, which are effectively point sources. Unless you use very low settings for the "glossiness" this means there are very few surfaces where both sun and camera angles are near enough to give visible highlights, and the results are unrealistic. Local lights give more satisfactory effects simply by increasing the amount of specular highlights visible bacause you can set them to optimal angles. Also, because they are closer, they can illuminate an object over a wider range of angles. Secondly, many objects in SL have perfectly sharp edges, legacy prims for simplicity and mesh because creators want to minimise geometry. A perfectly sharp corner is, of course, very unrealistic. It will never give any specular highlight at all. I think this is largely responsible for people's impression that SL specular reflection doesn't work in sunlight. With mesh, this failing can be counteracted by using extra geometry and edited normals. You can find some examples in some of my recent posts which give realistic highlights in SL with no local lights. For legacy prims, the effect of extra geometry can be approximated with normal maps ( which can do the same for mesh too), although that is hard work. Simple rough normal maps highly repeated can also increase the amount of specular reflection visible from any particular camera angle. Because the use of the alpha channels of the normal and specular maps in SL is non-standard, you usually have to use channel editing to get the right data in the right places when you generate the maps in other software. Only if the software allows exact specification of what data goes in what channel will iot be able to generate SL-compatible maps directly.

You might try reading the following wiki pages, which together try explain the SL advanced lighting rendering system... Second_Life's_light_model_for_materials Alpha_Modes_Do's_and_Don'ts Material_Data Then play around with a cube and a sphere using all the maps and settings to get a complete understanding of how they interact. There may be useful correspondences between maps generated by substance painter and those used by SL, despite the fact that they aren't exact equivalents. Sometimes you will have to invert of otherwise edit alpha channels separately, and maybe RGBs too. I once spent several days trying to make a set of Blender cycles PBR renderer nodes to use a set of maps made for SL to give the identical effect in Blender as in SL. In the end I had to give up.

"WHY would you not analyze your physics model" Two immediate reasons. First, there are many instances, for large objects, where the un-analysed, triangle-based, physics shape has a much lower physics weight (and often therefore lower LI) than the equivalently behaving analysed (hull-based) shape. Most common examples are accurately walkable landscapes and large simple flat walls with holes in. Second, it is occasionally difficult to get complicated shapes to work after "Analyze" without parts getting filled in. Then the triangle shapes can be easier to make. Although for small objects they are usually more expensive, that doesn't matter if the download weight is higher than the physics weight with either. Triangle-based shapes have disadvantages too. They are more prone to penetration, and it is possible (although not very often) to get stuck under floors or inside double-skinned walls. Hull-based shapes always nudge you out if you get stuck inside a hull. Then there's the strange super-high weights that appear in some cases, and the minimum thickness problem we are seeing here.

If any dimension of the mesh inworld is less than 0.5m, the physics shape type is switched to Convex hull without telling you. You can't see the change in the physics metadata display because the viewer doesn't know that it's changed (but I think you can see it if you bake and display the navmesh after setting the mesh to be a static object - if you know how to do that). Otherwise, if it's not that: What did you do on the physics tab of the uploader? Have you looked at the physics shape with Develop->Render metadata->Physics shapes?

I thought I had better test out what I was saying, as I haven't actually made ant letters before. So here is a letter 'E'. It was made by setting the resolution of the text object to 3, then converting to mesh and then extruding. Before extrusion it was 298 vertices. I found that I could bevel the extruded mesh without problems as long as the bevel was small enough. So that gave me the chance to go on again about the importance of rounded edges for getting highlights on normal lighting. First, I made a bevel with two segments and profile set to 1.0. This gives the smoothly rounded edges while keeping the sides flat shaded, but it has a sharp edge geometrically which restricts the angles where you can see the highlights. Then I made a copy, dissolved the edges along the sharp corners, and used the data transfer modifier to transfer the normals from the first model. The two models are shown on the bottom right. The normals are transferred from the two-segment bevel, on the left, top the one-segment bevel left after the deletion, on the right. Now we have proper rounded edges as well as normals that keep the adjacent faces flat. (The deletion of the edge also reduces the geometry substantially.  The picture on the left is inworld. It's in normal 3pm daylight, with no extra lighting and no baked texture. Shininess is set to zero, so that only specular highlights are present (blank specular map, glossiness at 15). There's a sand-grain-based normal map to give a bit of roughness. You can see the prominent highlighting of the rounded edges that is an essential requirement for of the realistic appearance of the object. The same model without the rounded edges looks much worse. Of course, all this is dependent on using advanced lighting. So it's a good idea to add a bit of baked lighting if people not using advanced lighting are going to be looking at it. At 1m height, using the impostor for all low LODs, this letter had a download weight of 0.065*. The high LOD had vertex/triangle counts of 885/1473. Even using an un-bevelled and manually decimated version (274/413) for the medium LOD, it was 0.095. So you should be able to get ten or more letters like this per unit LI, as long as they are in the same model. Separately, they will be at least 0.5 because of server weight. The LI will increase dramatically as the letters get bigger. *Its back face is absent - viewable from one side only - supposed to be mounted on a board.

As an alternative for the first part of Aquila's method, you can use settings in the Font tab of the Properties panel to do the decimatiuon and the extrusion. Here is where the settings are (yellow).  The F selects the font tab. The Resolution/Preview setting (set to 2 here) controls the detail. The Modification/Etrude adds the thickness. You can also remove bottom and/or top faces with the Fill setting (blue). Then you just convert to mesh in Object mode with Object->Convert->To mesh. Here are Three versions.  Top is the default Resolution/Preview of 12, which gave 15268/15256 Vertices/Triangles for this text. Middle is Resolution/Preview set to 2, which gave 2628/2616. Setting to 1, at the bottom, gave 1364/1352, but it begins to look pretty bad. I think 2 is fine for most purposes, but that triangle count will still need imposter lower LODs,as Aquila describes (even a single rectangular plane if you are only ever going to see one side of it). One other thing that might help is to set the camera to orthographic when you make the picture for the impostor, depoending on exactly what you want it to look like.. ETA: On closer inspection (trying to add bevels to get proper specular highlights along edges), there are some problems with the extrusion done with the Font Properties. The faces and the edges don't have all vertices matching. This is OK if you are goint to use it as it is, but if you want to do further modifications, there are problems. So in that case it may be better to use only the Resolution property, and do the extrusion after converting to mesh. There are still problems applying bevels, but there are with the product of the decimate modifier too. Either way, these prevent you making a bevel of sufficient depth without doing some tedious editing first. ETA: It also seems to work better if you convert text to curve, then curve to mesh, both before extruding, rather than directly from text to mesh. There are some artefacts in the direct conversion that this avoids.

Ah yes, that one. When you have a mesh object with more than eight materials, the uploader splits it into multiple objects, so that each has eight or less materials. This is a kludge to make it look as if there are more than eight per object, when in fact there aren't. Unfortunately, it doesn't know it should split the physics model. It wouldn't know how to anyway. So that leaves it with fewer physics objects than visible objects. In this case, it probably split off a tiny piece of your added detail as the new model, and then it might have packed the entire physics model into its bounding box. Otherwise it may have simply found the mismatch and failed to upload the physics entirely. In the former case, as only one of the objects would have a "Prim" type shape, the viewer could not switch the type for the whole thing. However, if you unlink it (it will be a linkset inworld). then you could see whether you could switch one or the other of the constituent objects. That would answer the question. In general, I strongly recommend against using more than eight material per object, thus invoking the kludge. There are several nasty effects that can arise. If you absolutely require more than eight materials, it is always much better to control what happens precisely by dividing it into object yourself, rather than letting the uploader do it with unpredictable consequences. I would rather this kludge had not been introduced.

Hmm. That all rules out a lot of possibilities. The uploader clearly thinks it has a pretty normal physics shape because it has the vertex and hull counts. Did you try uploading the physics model on its own, as high LOD with everything default? Progressively removing parts of the physics model might tell you where the problem comes from (although it won't fit properly, of course). So far, I haven't thought of a reason why the same physics file would work with the simple model but not the one with added details, provided there's only a single object each time. I think you are saying that's what's happening. (I am assuming you haven't forgotten to export only selected objects.) Might need to have access to the dae files to get any further. Sorry.

A bit more info might help. First, is it one mesh object or more? Second, If it was more than one, were the additions you made extra objects? Similarly, were the numbers of object the same in visible and physics models for both versions. Finally (for now) did you use exactlky the same physics file for the second version of the house? Also, can you see anything if you move the exploded view slider?

I'm not sure what you mean by "physics wireframe mode". Can you explain in another way? Did you click "Analyze"? Did you set the physics shape type to type "Prim" inworld? If you can take a picture of the physics shape display (from the Develop menu>show matadata,>physics shapes), that might help with trying to see what's wrong. Should be zoomed out to show most of the mesh. Alternatively, If you can leave it somewhere inworld where I can look at it, I will do so.

It is possible, although there are sometimes problems with the file links. Also, there are some disadvantages - each time you upload the same texture (eg weith an altered mesh) it will make another texture asset with a new ID, and this will be hidden in an unobvious place in your inventory. It also wastes space on the asset server. And you get charged for the texture upload each time upload. Therefore, I always strongly recommend uploding the textures separately.

Are you sure you are looking at the right thread? The first paragraph of my answer there gives precise intructions which, as indicated in the footnote, are for the "official" LL viewer. I can't see anything there about Firestorm. In case your browser is misreading the link, here is that paragraph again... For accurate walkable landscapes, you will usually need two things. First, a triangle-based physics shape that matches the visible mesh. To get this, you have to select the high LOD as the physics mesh on the physics tab of the uploader, and to NOT click "Analyze". Second, inworld, you need to set the physics shape type to "Prim" on the features tab of the edit dialog. Note that you need BOTH things. They are not alternatives. The mesh used for physics is not "optimised". It IS exactly the high LOD visible mesh. You can simply select this on the physics tab. Then you don't need to supply the file again.

Thanks Whirly. Either your memory or your filing system is better than mine - most likely both. If anyone wants the pictures that went along with the jira, they are in message 20 in this thread.

Just to check - it's not by any chance because there'a a "secret" face becuase of one having more than 21844 triangles, is it? Certainly looks unlikely from the pictures, but ....

For accurate walkable landscapes, you will usually need two things. First, a triangle-based physics shape that matches the visible mesh. T get this, you have to select the high LOD as the physics mesh on the physics tab of the uploader, and to NOT click "Analyze". Second, inworld, you need to set the physics shape type to "Prim" on the features tab of the edit dialog. If you have too many triangles, the physics weight will be too high. It can even be so high that you can't rez the mesh. So it is important to reduce the triangle count as far as possible. You may be able to use a simplified mesh as the physics shape, but as you do so the walkable surface will start to mismatch the visible surface more and more. The above points have assumed that you are talking about a mesh landscape, not a sculpty. Sculpty physics shapes are fixed and do not match the visible shape at all (other than overall dimensions). They also refer to a single mesh. If your lanscape is multiple mesh objects, the same should apply. In addition, iy you supply a separate physics mesh, you will have to use the new naming convention (suffix "_PHYS" on high LOD mesh object names) for the objects in the physics mesh, so thast the physics objects get associated with the right visible objects. See this thread for an example.

Since the problem may have arisen from the way you constructed the geometry, here is one way I might have done it (making some assumptions about the aim). This gives a minimally distorted UV map, with or without the added hemispheres... 1. Add cube; edit mode; stretch to desired dimensions. 2. Select and delete bottom face. 3. Select all edges except bottom rim. 4. Mesh>Edges>Bevel, segments=3. 5. Alt select bottom edgesand stretch as required. 6. Select top face and Mesh>Faces>Inset (I); pull to right place. 7. Select middle top face and raise as required. 8. Default UV mapping.