Drongle McMahon

"Is the opposite, namely that <0,5m objects may have unintended openings on the sides, also true? " I don't think so. Both triangle-based and convex hull (Analyzed) sjapes can be penetrated, expecially if you are moving fast. With CH shapes, you get pushed our, but with TB shapes you can get stuck between the two faces if the wall has two sides. Your best bet is probably to use Analyze, following Aquila's advice about non-overlapping parts. They physics weight may be a bit higher than the optimised TB equivalent, but it's much easier to optimise and has less problems inworld.

By the way, if it is indeed lots of objects, you might see undesirable LOD behaviour as you move the camera away. Each object switches LOD at a distace proportional to the length diagonal of its bounding box. So smaller objects will switch at nearer points than larger. Some of this can be avoided by combning into larger mesh objects, although there is a compromise to be made because this will increase the download weight part of the LI. It's also harder to make effective physics shapes the more complex a mesh object is, and you are limited to eight texture faces per mesh object. Another important thing with triangle-based shapes (as in your upload view - no "Analyze") is that the shape will switch to Convex hull if any dimension is less than 0.5m, closing off holes for doors etc. This can be a problem with a thinner wall as one separate mesh object. This does not apply with "Analyze"d shapes which are collections of convex hulls.

I'm guessing here, that your model has multiple mesh objects in it, and that your physics mesh has the same number but not in the same order. Unfortunately, the uploader associantes visible mesh objects and physics objects solely according to the order they appear in the collada (dae) files. So it is essential that the order of physics mesh objects matches the order of the visible meshes. Otherwise you get the wrong shape associated with the wrong object (as in getting a box for the staris). Each physics shape is also stretched and/or squeezed so that it fits the bounding box of the associated visible object. That's why the box fits the stairs although it may have been supposed to fit an object of different size. In Bkender, thanks to Gaia et al., this can be solved by using appropraite naming, with a postfix indicating the LOD/physics, something like <xxx_hi, xxx_med.xxx_lo, xxx_lwst, xxx_phys> where xxx is the same for corresponding objects, for the LOD and physics meshes. Then if you select the "Sort by Object name" collada export option (automatically selected by the SL presets), each file will have the objects in the same alphabetic order of xxx. I don't know if/how you can define the order of objects in other software. Maybe others can say. In all cases you also need to have the same number of physics objects as visible objects (not strictly true, but you need to be even more careful if you do).

Mesh Lint sounds good. As for physics - SL doesn't use the physics stuff in collada, or physics from Blender etc. All it does is make a collision shape which is generated from a normal mesh. By default, it will make the convex hull of the low LOD mesh and use that. For something better (essential for buildings if you want to go inside) you can specify a custom physics mesh on the physics tab of the uploader. (You can use one of the LOD meshes instead, but that usually isn't satisfactory for buildings.) There are two types of shape you can use, the mesh itself (triangle-based shape) or a collection of convex hulls generated by using the "Analyze" button. In both cases, the main thing is to keep the shape as simple as possible to limit physics weight and LI. Avoid curved shapes where possible. For triangle-based shapes, avoid all small/narrow triangles, such as those along the edges of walls with some thickness, which increase weight hugely. Just delete those faces. For "Analyze", it's easiest if you use a shape made up of non-overlapping simple boxes, each of which becomes one hull. Otherwise, the hull generator has a hard time avoiding filling in of spaces you want unobstructed. In either case, you need to set the phsyics shape type to "Prim" inworld to use the shape. If your model has multiple mesh objects, then the physics mesh file must contain a mesh object for each, and they must be in the same order. Each physics mesh (even if there is just one) will be stretched or squeezed to fit into the bounding box of the corresponding high LOD mesh. So they need to fill up that space to avoid distortion. There are lots of threads discussing physics shapes in this forum.

Sketchup does seem to make very bad geometry and UV maps. The phenomena you show might be due to duplicate faces, or face where one overlaps the other for some of their area(s). This can result in stippled shading and in black patches on the ao bake. I suggest you put the 3D view into non-see-through mode select individual faces and delete them to see what's underneath. If you find overlaps this way, you will have to repair the geometry. If bearable, I would recommend not using sketchup for anything but a mock-up. Better build from scratch in Blender, after importing trhe sketchup model as a guide if you find that useful. If you know how to refine the geometry, assign materials and UV map in Blender, you must already be not far away from being able to do that.

To get a walkable mesh terrain with the same horizontal resolution (1 metre) as the terrain height map in the raw file, would require sixteen patches of 64x64 m. Once the raw file can be converted to a greyscale image, segments of this could be used as the displacement map in, for example, the Blender displacement modifier, for each 64x54 piece. Uploading these using the high LOD as physics shape without "Analyze" (i.e. triangle based shape) would give the same visual and physical effect as the actual terrain, but could be placed at any height. However, testing an example, it uses up about 3/4 of the available LI. That is obviously impractible (and impossible if it's a homestead). Halving the resolution, using 16 64x64 segments, but with 2m resolution, gives a reasonable walkable surface and uses less than 1500 LI fot the whole region*. That's only 1/10 of the available LI in a full region. So that is useable. Unfortunately, the halving of the resolution is unlikely to produce acceptably accurate fit to the remainder of the build, but you never know. There would, be no height-dependent terrain texture blending. So if that's important, mesh (and sculpty) is a non-starter. *my test with a piece with 10m height variation had LI of 83, download and physics both 83-83. That would be 1328 for the whole region.

Of course it all depends what you want. Basically, the environmental light is the closest we get to metallic reflection. Unlike the specular reflection, which is additive, it replaces the diffuse reflection instead of adding to it. That's like a chrome plated surface, which is, of course, only one kind of metallic surface. If you want something to look metallic in only sunlight, with no local lights, then I find the alpha channel very helpful. The specular reflection from the sun is too limited by the narrow angles. Here's a comparison of the same cube, but with an improved, generally lighter, alpha chanel, on the left, and no alpha channel on the right. As before, this is environment =255 and glossiness = 0.

What about the normal map and its alpha channel? If those plywood cubes are local lights, the specular exponent map in the normal map alpha can have a significant effect. All images are converted to jpeg 2000 before uploading. I think a 16-bit tga uses 5 bits each for RGB and, optionally, the last bit for one-bit-transparency. Whether your tga used the optional bit, or whether SL uses it when there, I don't know. In any case, I highly doubt whether the jpeg2000 uses the reduced colour depth of the 16-bit tga. Unless it does, then there would presumably be no difference in the upload size compared with a 24-bit tga. The main difference would be including the one-bit-transparency if it is used. On the other hand, using a 24-bit tga instead of a 32-bit tga does save upload size because there is no alpha channel data uploaded from a 24-bit tga. (Strictly speaking, it seems tga can specify peculiar colour depth formats that would allow alpha in 24-bit/pixel, but I doubt they are ever used). So the question is, what use is an eight-bit alpha chanel in the specular map? I hope the attached picture will illustrate this. These are all prim cubes with materials applied. The first three all use the normal map shown below, and all four have "glossiness" (specular exponent) set to 0 and "environment" set to 255. So we are looking only at environmental reflection. The first three all have the same diffuse texture and the same rgb channels of the greyscale specular map shown below. For the first, this is in a 24-bit png, which has no alpha channel. In the second, it is a 32-bit png with an all-white alpha channel. This looks tha sames as the first, showing that using a 24-bit specular map with no alpha has thw same effect as a completely opaque alpha chabbel. The third cube uses the same image in the alpha channel as in the rgb channels. This leads to reduction of the excessive shininess of the first two. In my view, this already provides a far superior metallic look. Of course, something in-between might be even better, and this can be achieced by appropriate adjustment of the alpha channel. Finally, using the alpha channel allows the mixing of shiny and non-shiny areas in the same material. This is shown at the right. This uses the default plywood diffuse texture, a grey tint, and the normal and specular maps from an earlier thread. There are three levels of shininess, high for the bolts, lower for the bars, and zero for the panels. ETA: The diffuse twxtures 1-3 are the greyscale map shown, not blank as I said mistakenly! So the same map (rgb at least) is used for diffuse and specular.

You can follow the links from "Mesh" on the wiki front page. The most useful is probably https://wiki.secondlife.com/wiki/Mesh/Mesh_Asset_Format Note that there is a distinction between the upload format, described in the text, where there are separate lists of position, normal and texcoords, and the internal (i.e. inside the viewer code) format described in the figure. (This is a figure I made from looking at the viewer source code - so it does not have any official LL stamp of approval! ... and as it was long ago, there may have been changes in the code). However, the net result is the same whether these vertex parameters are in a single list or in separate lists. As the upload format description says, there must be the same number of entries in each list (as long as the list is there) so that the total amount of data is always the same. Basically, both describe a list of triangles, each of which has three indices that point into the vertex data list(s), one for each vertex of the triangle. If the vertex is part of a smooth-shaded surface, with no UV seams running through it, then its position, normal and texcoord (UV) is the same for all the triangles that share that vertex (ofetn 6, as in a surface made only of quads). So it can appear only once in the list, and all the triangles can use the same index. The position is, of course, always the same, but if the vertex lies on a sharp-shaded edge, then the triangles on either side of that edge will use different normals. So that requires a new index, which will have the same position data but different normals data. This is what I mean by vertex duplication. In an extreme case the duplication can be dramatic. For example the point of a 32-sided cone will be duplicated 32 times. It is reflected in the increased upload vertex count when you change the shading. UV seams have a similar effect. A single geometric point may be represented at multiple positions on the UV map, so that some triangles use the same geometric vertex, but with different UV coordinates. Again, that requires a new index and duplication of the rest of the vertex data. However, if the seams coincide with sharp edges, there is no need for further duplication. Keeping the seams and sharp edges coincident can therefore save download weight, and usually makes good sense anyway. The other factor that increases the vertex count is the borders between multiple materials. In this case, the whole triangle list and the referenced vertex data list(s) are separate for each material. So vertices at the junction of materials (sub-meshes) always have to be duplicated in the separate lists, even if they share normals and UV coordinates. Usually these borders coincide with UV seams, in which case there is no additional increase. As long as you don't use the "Generate normals" in the uploader, the normals will be what they are in the uploaded dae. So you have full control over which edges are smooth and which are sharp. Here are the numbers from an example, a 32-sided cone, with a triangle fan base. It has 34 vertices in Blender. Setting all faces to smooth and before UV mapping, the uploader saya 34 vertices, as expected. Adding a UV map with with a seam around the base and along one conical edge, the uploader says 67 vertices. All the vertices around the base appear at two different places on the UV map, one in each island (+32), and the one where the conical surface is split by the edge seam appears twice in that island (+1). Finally, I set the whole thing to flat shading (all edges sharp). Now it says 129 vertices. The vertex at the point now appears with 32 different normals (+31) and the ones around the base with three different normals (six triangles, but pairs have the same face normal). Those were already duplicated for the UV map, and one was already triplicated. So that another extra 31 vertices. Total is now 67+31+31=129. No need to add anything about baking, as you can read much better advice in the links Arton gave, and other threads on polycount.

"If you are ok with LL taking your creations and selling them for any amount they want to without crediting you or giving you a dime, or even letting you know they are doing it, then you have no worries." ...then you have no worries, as long as everything you upload is either entirely your own or in the public domain (e.g. CC0 license). Otherwise, uploading it is claiming you have the right to grant LL the all-encompassing license they demand, which in general you do not for third-party sourced content (textures etc), even if it is free. Personally, I have stopped uploading anything other than test objects. I do not intend to be paying somebody large amounts of money for the privilege of having them appropriate my creative efforts unilaterally, arbitrarily, and without compensation or acknowledgement, meagre though those efforts may be. Since building was my main interest, my enjoyment of second life is severly compromised. As for authorising bthem to take legal actions in my name....:matte-motes-evil: (This is not legal advice and may be inaccurate. Consult a professional legal advisor for interpretation of the ToS.)

Any chance your garment has inside and outside surfaces, and if so that their UV maps are superimposed? This happens in Blender if you use "solidify", and then the inside and outside bakes are made on top of each other. Which one of inside or outside AO you see in a particular place then depends on the order that the triangles get baked in. If this is the case, you need to move the UV maps so that they don't overlap, or do the bake from a model with the inside deleted.

You haven't told us the actual triangle counts per material of your high LOD model. From the download weight you displayed, it is unlikely that the problems are due to too many polygons, but this depends on the size and the LOD meshes, which could still be hiding a high LOD0 polycount. So, just in case, this sort of behaviour can be the result of the extra materials introduced by the uploader if any material has more than 21844 triangles (jira here, in case you can see it now). Indeed, it was after seeing unwanted texture switching like that you describe that I first investigated the effects reported in that jira.

If I were you, I wouldsimply upload the textures separately. There is no extra cost and you can apply them inworld just as you do for an ordinary prim. It you upload withb theb model, then you have to pay again for both modeland texture every time you change either. Also, you can finde lots of extra copies of the textures in your inventory in folders you didn't know about. From my point of view, there is no advantage to be had from uploading textures with a model. Others may disagree.

Thanks Ivan. As you see, it was all just my stupidity. I just have to hope hope all the information provided by others will be as useful to a wider audience as it was to me. I did learn a lot, even what "selected" means in Blenderese!

AHA! You are right. I've been baking them the wrong way round without realising it. I had obviously completely misunderstood the meanings of "selected" and which was "active", so that in my mind they were the other way round! (i.e. Selected was the one you were working on) Amazing it worked at all! I should have realised because I knew the high poly UV should not matter. As Kwak said, I had mapped it to add some roughness with a texture feeding into the normals. Now I have to admit to being thoroughly stupid. :matte-motes-sick: The simple experiment all makes sense now. Of course, it works perfectly when it's done the right way round ... But why did xNormal give the same artefact? Never mind, I don't want to know!

Thanks for answers everyone... Astrid: As I said, xNormal gives the same effect with the same UV map on the high LOD mesh and just using ray projection. So it's not just a Blender problem. From what I find below, it seems to be something to do with a difference in projection into the UV plane and onto the low poly surface. So using a cage in xNormal might well do a better job, and Blender doesn't have cages for baking (I think). I didn;t try that yet, but I probably should. Dora: The geometry in the simple example is completely flatm with both quads in the same plane, It's only the UV map that changes. So, although what you say is true (and the source of many problems) it doesn't apply here. Aquila: But I want it to be smooth. Also, the simple example is all flat shading. If I set it to smooth, the artefacys still appear, but with fuzzy gradients instead of sharp trasitions. In the crate model I still get the artefact with flat shading throughout. That surprised me too. If you make the UV map by projrct from view in the same direction as the rays will go for the bake, then the artefacts disappear. Perhaps your UV map was made that way, or is close to the same thing? (Yes. Losing Chosen was one of the worst effects of the new ToS!). MIstahMoose 1: Excellent thread. I read a lot of other stuff at polycount too. I think it's close to the same problem. The edges of my bars were sloped so that they didn't fail to project, but in retrospect, they weren't sloped enough. Because they are too steep, UV mapping them with the same projection that the rays will take in the bake completely removes the artefact, but it leaves them with very thin striips of the UV and normal maps. That means the bars look very thin and the specular reflection is very narrow (see pic below). The compromise would be to make the slope more gentle, so they look thicker, sacrificing the correctness of the angle for specular reflection. MIstahMoose 2: Although I do have photoshop, I prefer not to use it for SL because I am intersted in seeing what can be done with free tools here. Unfortunately, that excludes most of the nicest normal map tools, including nDo2. One day I will probably give in. As detailed above, I changed the UV map so that it was the same projection of the surface that was going to be used in the bake. That results in very thin bars, but avoided the arteface. Using more goemetry in the low poly, so that the bars had real thickness, would look much better, but the object here was to make csomething applicable to a prim cube. Here is the result I got (I also flat shaded the top surface of the bars to make them thicker. It will have to ndo for now. My original purpose here was to see how to make it look metallic under local light and daylight. This involves playing with the alpha channels of the normal and specular maps. I think I am getting nearer.The other thing I did was to add some noise to the parts of the normal map representing the bars, in the hope of getting some specular refelection over a wider range of angles. Meanwhile, my mathematical curiosity males me still want to understand the behaviour in the simple example. Maybe I need to head over to BlenderArtists.

The exact effect does depend on the triangulation, which is different in Blender and the uploader, and on smooth vs flat shading. However it is still there whichever of these is. Also, the effect is seen in Blender as well as inworld. So it can't be (only) the uploader, ad it can't depend on the tangent basis (as far as I recall, that is the same in Blender and SL, but I can't find a reference.)

Yes. In fact that's what I did. Just some clone tool work on the red channel. It was fairly laborious though. So I was just interested in understanding what's going on and maybe how to avoid it. Here's the before-and-after. This is a standard prim cube with the maps on it. You'll notice I also rotated the top texture ... there's another story there!

I need some help with improving baked normal maps. I came across this problem while baking normal maps high poly->low poly, Selective->Active, in Blender. It's shown in the first picture by the blue arrows. The vertical edges of the iron bars in the high poly mesh are flat quads. They should have constant angle to light and camera, and thus show no variation in specular or environmental reflection, but as you can see, they have a triangular shaped reflective discontinuity. Looking at the normal map, you can see that this is actually encoded there. So it's not an SL problem, it's a baking problem. I thought it was due to some adjacent smooth shading causing difefrent normals at the corners, but making the whole mesh flat shaded still left the same (or a similar) artefact. Note: these are not actaully the same mesh. They are used they show the effects most clearly. I tried doing the baking in xNormal and got a similar result. So it's a general problem, not specific to Blender. So I looked for a simple case to examine the cause. This is shown in the second picture. The mesh at the top (a), just two quads, is the high poly mesh. It is sloping at 60 degrees towards the low poly mesh, which is a simple plane quad. If the UV map has exacty the same angles as the mesh (b), then the baked normal is constant over both quads. However, when the angles are distorted by moving vertices along the vertical axis of the UV map, the right hand quad gets the wrong normals (c-e). The symetrical distortion (c) is similar to that in the normal mapping of the edges of the crate, and has the similar effect of making two triangles with different normals. However, if the UV map is rotated, so that the vertex displacements are now in the horizontal axis, then the identical distortions don't introduce incorrect normals at all (f-g). In the crate, this is evident in that only the vertical edges have the artefact. The horizontal edges have acceptably constant reflections, in spite of some of their edges being smooth shaded. However, the baked normal of the undistorted rectangle is not the same as before the rotation. All this suggests to me that the artefacts are somehow the result of the way the tangent is calculated when the UV have distortions to to avoid having too many seams. If the tangent is different in the two triangles, then perhaps a different normal, relative to it, is required to represent the same affective direction. My understanding of the calculations concerned is totallyn insufficient to explain this better, and I would be glad if someone could provide, or point to, a better explanation. Meanwhile, what can be done to avoid this kind of artefact? One option is to use very fragmented UV maps in which all angles are preserved, but that is expensive in SL because seams increase LI, and it makes the use of efficient general purpose tileable textures impossible. Perhaps there are ways of limiting the distortions to one axis while avoiding over fragmentation, but that seems to me too complicated to be bearable. Does anyone have any other solutions? Is there a simple way of altering the calculationparameters instead of altering the UV maps? Have I missed something that should be obvious? ETA: I did a whole lot more distortions. It's definately not the angles. Distortions that leave the angles unaltered can give the artefact. Others that change the angles produce no artefact. The obkly constsitent thging seems to be that moving any vertex hirizontally in the UV map has no effect on the baked normal. Moving any vertex vertically produces the artefact, unless it's an even vertical stretching and.or tranflation of the whole thing. Rotation causes the whole thing to change together, without differences between triangles.

In that case, they must have been uploaded without a physics shape. You still have the "None" option with linked invisible prims for physics, but you need another prim to be the root. It can be one of the invisible ones, or it can be a small box prim, as I said in the previous post. Better though to upload them again, this time using the physics tab of the uploader to make a physics shape. Do you know how to do that? For the billboard, I would use a mesh consisting of two boxes, one for the board and one for the stand. They should be non overlapping but part of the same mesh object (assuming the billboard is one object). Load this dae from file and then click Analyze. It should say there are two hulls with 16 vertices. The building is more complicated (and I am assuming again it is one mesh). Again, the simplest option is a set of non-overlapping boxes - the minimum you can use to get collisions with the walls, floors, roof etc, with gaps for the doors. Upload the same way. Remember that the physics models will be stretched to fit the same bounding box as the visible model, So it needs to be already fitted to that. Otherwise collisions will be in the wrong places. You can try to use the visible mesh as the starting point for the physics shape (select LOD in the dropdown on the physics tab), but that is usually much more difficult to get a functionally acceptable shape without excessive physics cost (and consequently high LI).

The physics shape type of the building and of the billboard are both set to "Convex hull". That is the default physics shape type. You can never go inside a convex hull. You need to change it to "Prim", which you can do on the Features tab of the edit dialog (assuming you di upload it with a physics shape). Otherwise you can link it to a small cube prim as root, set the physics shape type to "None" and use invisible prims as the physics. By the way, using the Convex ull type is also the reason why your ;egs sink into the roof if you walk on it. For some reason they made the convex hull physics shape smaller than the actual mesh. You can see that if you turn on Render Metadata->Physics shape in the developer menu. I reported this as a bug years aga, but it is srill that way. So I assume they had some obscure reason for leaving it that way.

First, there are three "weights" for each mesh, and the highest of the three becomes the LI. You can find all the details in the SL wiki by searching for mesh and following the links there. Briefly, the "download weight" depends mostly on the "amount of geometry" and the size of the object. The" amount of geometry" for any LOD is dominated by the vertex count you see in the uploader. Note that this may be much higher than the vertex count in your 3D program because vertices get duplicated (or more) when they lie on sharp edges, UV seams or the boundaries of materials. Keeping as many edges smooth shaded as possible will keep the weight down. However, it's not that simple because there are increasingly simplified LOD meshes/ The effect of the goemetry at each LOD on the download weight depends on the size of the object. For small objects (<<10m) the lowest LOD geometry is by far the most important. As the object gets bigger, the iinfluence shifts towards the higher LODs. For very large objects, only the high LOD matters. Details of this are described here. For most mesh, the download weight should be bigger than the others and bcomes the LI. This is because the physics shape mesh can nearly always be simplified until its weight is lower, without adversely affecting performance. It's best to reduce it as far as possible anyway, to minimize the workload for the physics engine on the server. The server weight (of a linkset) is only 0.5 per object (1 if it's scripted). So that will only become dominant if you have a model consisting of several meshes with simple geometry, which become a linkset after uploading. In that case, you can usually reduce the overall LI by joining the parts into fewer, more complex, meshes. The main exception would be where you need the separate parts to move relative to each other, either manually or in a scripted animation. ETA. Note that textures (and material maps) don't affect LI. This is a pity, because texture lag can be a real problem, but it means your strategy of testing LI before texturing is the sensible one. I never upload textures with the model anyway, for other reasons. However, you do need to do the UV mapping if you want an accurate LI, because the seams affect the download weight. You also need to check at the correct size (or sizes if it's going to be variable).

Select the faces that are missing, then from the menu do Mesh->Normals->Flip Normals

In Blnder, faces are rendered two-didd bu default. That means you see them even if they are facing the wrong way (inverted normals). In the Properties panel on the right of the 3D view, in the "Display" section, there is a checkbox for Backface Culling. That changes it to display only one side of the faces, the one the normal sticks out from, as is always the case in SL. The back side is then invisible. You can also see the normals by clicking the right hane of the two little buttons under "Normals". Flip the by selecting the faces and doing Mesh->Normals-<Flip. Or you can use the recalculate menu option instead. Triangles .... I put the limit in the post, but that is far more than you should need anyway. The effective limit is 21844 per material. More than that and the uploader creates secret materials which can give you a variety of problems. At 174752, it drops any further triangles. I don't think this is you problem, although you don't really need so many. More likely it's the normals. Use smooth shaded surfaces rather than extra faces to get smooth appearance. That will save LI and gpu load as well.

Oh. From your pictures, it appears you have a LOT of triangles. What is the triangle count in the uploader. If it goes too high (>174752) , you will lose triangles.