Drongle McMahon

Glad you solved it - it was too puzzling. In case anyone is still wondering, I was not concerned with the count value in one "<polylist", which you show, but with the number of polylists - that is the number of times you find "<polylist" in the whole file. The reason was that there should be one such list per material (for each object, if ther are more than one). So counting them could have indicated whether there was a problem with the export or a problem with the reading of the exported file. That is no longer a question. I'm still puzzled by the fact that the materials were not coloured in the rezzed object as they were in Blender. They normally are for static meshes. Maybe the material colours don't work for models with bone weights even if they are rezzed statically? Trhat's why I asked if you had tried the upload without weights.

Did you try selecting a face and setting the colour? (or applying a texture). Did you look for and count the "<polylist"s? Did you try uploading the same file without skin weights to see if that was different?

If your mesh has two materials, they should automatically be present after you upload. Assuming you are using Blender 2.6x, try these steps. Deselect all vertices, select one material at a time in the materials panel, then click Select underneath. Does that select just part of the mesh? Set each material to a different colour in the material panel. Can you see the colours on the mesh in Solid display (set with the sphere button under the 3D view)? Export with the material colours showing, upload and rez. Do you see the coloured parts in SL? These are the faces and should be selectable individually if you check the "Select faces" checkbox. If you drop a texture on the mesh, it should only go onto the face you drop it on. Note that if one material is only on hidden faces, then you won't be able to select that face or drop a texture on it. You can check the collada file by opening it in a text editor and seeing how many occurences of "<polylist" there are. For each Blender object, each of these describes a part of the mesh carrying a separate material. The material should be named after the "<polylist" and before the next ">". (This will be different if you are using an old Blender with the python exporter script, which uses "<triangles" instead.)

You can also select individual faces of a single (linked) object, with "select face". However, if the object is a sculpty, it only has one face (strange hacks apart).

There is a bug that happens that results in wrong allocation of textures to faces when the lower LODs have fewer materials than higher LODs (a subset - that is allowed, but not useable because of this bug). I have only seen it when returning to high LOD after switching to lower LOD, but perhaps there is another minifestation on copying? So - do you have exactly the same set of materials at all LODs? What happens when you change LOD high -> low -> high? (You can do that by changing RenderVolumeLODFactor under Advanced->Show debug settings). ETA. I just retested to see that the bug isn't fixed yet. The uploader does give an error message and the dreaded red cross, but it still lets you upload with a subset of textures at the lower LODs, and the textures are still wrongly allocated. So I tried a shift-drag copy with the example from the jira, ans sure enough, it produced the same mis-allocation of textures. So I think this might well be your problem. I think the bug is old enough that it's still visible - http://jira.secondlife.com/browse/VWR-28612 (note - the copy is left behind when you drag the original)

"blame the LOD generator" Yes, but there's another possible cause for this sort of effect, and another question I should have asked too. Did you have UV map? If yopu don't have a UV map in the dae file, the uploader seems to use uninitialised data for it. That can be have quite large effects on the download weight because it increases the vertex count when the same geometric vertex has to appear with different UV coordinates for different triangles. How big the effect is depends on how much vertex dupliocation you already have from sharp edges (same vertex with different normals), and on exactly what the uninitialised data is. You can see the effect by applying a texture.

Well done. The effect you discovered is the most important principle of mesh optmisation. If you make bigger things, you also need to know that it depends on the object size.

Yes. I guess it's the LOD generator for the download costs then. However, if you were using an explicit physics mesh, the uploader should use that mesh to make the default convex hull whose weight it shows. In that case, the LOD generator isn't involved in the physics shape, and so the weight should be always the same, as with the second mesh. So I can't explain variation in the physics weights for the first physics mesh.

A couple of questions... 1. Did you provide LOD meshes, or did you let the uploader generate them? 2. Did you specify a physics mesh? - if so, from a LOD or from a file? 3. Which buttons did you press on the physics tab? 4. Are these figures from the downloader, or from inworld? 5. If it was inworld, did you change the physics shape type? It will be easier to suggest what's going on with answers to these. Meanwhile, the LOD generator is non-deterministic, meaning it can produce different results on different occasions with the identical input. Thae differences can affect the download weight. O don't know, but perhaps the LOD generator is different in FS. Then, the default convex hull physics shape, which is what you see the physics weight of in the uploader, is made from the low LOD mesh. If that is different, then the resulting physics weight can be different. Changing the mesh could produce less variation in the vertices that make up the convex hull, even if the detail of the low LOD is still varying. To have consistent and optimal control over the weights, it is usually necessary to provide LOD and/or physics meshes explicitly, rather than relying on the automatic options.

"is there a way to lower server weight" Is your object two linked meshes? Then the server weight would be 0.5 for one without a script and 1.0 for the one with a script(s). If you can join the two mesh parts into a single mesh (doesn't need physical likages), the the server weight of the whole would be 1.0 with the script(s). There are no intermediate server weight values, on;y 0.5 and 1.0. The only reasons I know of for not joining twp meshes into one are (a) you need more than the 8 allowed texturable faces, or (b) you want to animate the two parts differently. As for why the server weight exists - it's somethinmg to do with inter-object low-level message passing between some scripted objects. That's all I (think I) know. Not all scripts invoke it, but all are penalised for it.

You are right that there's a problem for people who don't want to learn all the stuff necessary to make and optimize mesh, of whom there are very many. It would be good if some of us who enjoy that could provide a freely available component set that you could use ... like a 64x64 quarter ring that could be combined to make your hull. With suitable UV mapping, they could be easy to use. I see the main problem there being the creator name thing, like with megaprims where Gene Replacement got blamed for other peoples' mis-uses of his prims. If it weren't for that, I would be happy to participate in making some of this sort of components. Maybe we can ask for a work-around. Anyone got an alt called "Anonymous"?

From the display of the edges, it appears to me that where this effect is happining is where a triangle from the mesh on the right is on top of the triangle from the mesh on the left, while the triangles you can see in the UV window are all from the mesh on the left. Not only does the dark edge effect happen in this triangle, but it doesn't meet up with the textures in the adjecent triangles. I assume that the mesh on the right is getting it's texture from the upper part of the image shown in the UV window, and the darkenning is the antialiasing of the light/dark boundary in that part of the image. If I am right, you should be able to correct this by moving one or two vertices of the offending triangle slightly away from the point of view, or bringing the vertices from the left-mesh-triangle towards the point of view, so that this triangle is no longer obscuring the one that belongs to the left-hand mesh.

I guess setting it to texture means it just bakes the diffuse texture, ignoring all lighting effects. The normal map is just a lighting effect. So that would be ignored too. Baking just the texture can give a different output if different UV maps are used for the input mapping and the bake, but if they are the same, then I imagine it's just going to fill in the mapped parts of the image with unchanged texture. If it's a wall filling the whole UV space, that would just replicate texture, wouldn't it?. I don't do much of this stuff, so a more authoratative explanation from someone else would be useful.

I think it is "feeback loop" It works for me. I can only guess you are using the same image as input to the material as for the baked output. The output needs to go to a new image ???

"I think it's just a setting..." Bake section of Render tab of Properties edit window; Bake Mode -> Full Render ?

The following is just in case you are interested in details. What you need to do is drastically reduce your vertex/triangle count. No material should have more than about 20000 triangles (10000 quads), for the reasons below. Ideally they should have much less, to lower the stress on the gpu and avoid consequent lowering of frame rates. What limit you run into depends on the number of materials you specify andhow many triangles there are in each. Although there is a piece of code that tests for the limit of 65536 vertices per material, and should return an error code, there is* (for now - a bug) another test that prevents that limit ever being reached. This is a limit of 21844 on the number of triangles in the list of triangles for a material. For each triangle, there is a maximum of three different vertices. So even if there are no re-used vertices in the list (eg, if it's all flat shaded), this limit is reached first, with 3 x 21844 = 65532 vertices. However, instead of stopping with an error message, the code simply starts a new material with new vertex and triangle lists. That seems to be able to be repeated indefinitely, but when it's finished, if there are more than eight materials, the extra ones will be discarded, along with all the triangles associated with them. This happens with more than 174752 triangles (if there is only one material specified in the collada file), and leaves holes in the mesh for the extra triangles. Where the holes appear depends on the order the collada exporter sees the triangles. If you try to upload a mesh with more than 174752 triangles, you will see that the uploader will always say 174752 triangles because it has removed the rest. For example, I have a cube subdivided seven times. The Blender model has 98306 vertices and 196608 triangles. It uploads as 174752 triangles and 233685 vertices. So it has about 2200 triangles missing when it's rezzed. The excessive vertex count is because the secretly added materials are intimately interspersed over the mesh surface, so that many vertices have to be replicated in several material lists. *this is in the official viewer, tpvs may have fixed this so that the vertex limit applies.

"I'm running the official viewer, gpu is an NVidia gtx670." Thanks. Same as me. I was wondering if it could be gpu/driver related. If others can test, that might be useful. My driver version appears to be 9.18.13.697.

Yes. I guess that's it. If it does any normal testing at all, then it's not enought to deal with the effects I described. I guess it would need a normal gradient (derivative) really. That also explains why the effect is dependent on the angle of view. I tried a whole lot of cylinders with different segment numbers. All about 10m diameter. The picture is without any post-prcessing except a resize. Blank texture throughout. Iy looks like you can see the artefact clearly at 30 segments, but it's gone at 60 segments. That makes it very expensive in LI to avoid. More worrying is that below 15 segments, the artefact is clearly visible on the outsides! I guess it must be sampling the nearby inside faces even though they aren't relevant. It also affects the insides of standard hollowed spheres and cylinders, as shown here... This could be a problem with a lot of existing stuff.

Played with the RenderSSAO settings a bit. Apart from settings that effectively turned it off completely, only RenderSSAOScale had a potentially useful effect. It's 500 by default. Setting it to 100 reduced the artefact so that it was only visible at small viewing anges (Uh?), while leaving some AO effect on the flat shaded version. Of course, most people will be using the default. So it's a bit like RenderVlumeLODFactor for bad sculpties- you can solve the problem for yourself, but then others all se the horrors you have hidden.

Depends what you meanj by "very few". It is a 32 segment cylinder with a gap to walk in. Actually I was making a tower, but made this to look at the problem. Here is a picture of various versions. The one with the asterisk is the problem one. The cylinder model is smooth shaded, but the SL AO is as if it were flat shaded. The cylinders in the ight column are all a flat shaded model. All except the second row are with SL AO turned off. At the top, as in the second row, no texture applied. The bottom two rows have baked cAO from Blender, baked on the flat-shaded model in the third row (looks like SL AO with no texture), and baked from the smoooth shaded model in the bottom row. bl = texture: no = none; fl = baked ao on flat-shaded model; sm = baked ao on smooth-shaded model. sl = Ambient occlusion on/off in SL So the problem is that the SL AO on the smooth shaded model has the corner effect and it should not (asterisk). This effect is size dependent (presumably because of AO falloff parameters). It becomes imperceptible with the cylinder less than about 4m diameter. So it's a problem for big stuff like buildings. I agree that the appearance of ao on the outer surface is a Blender artefact - so I won't address it further here.

Oh dear. I haven't generally had ambient occlusion turned on in the viewer. Since I got a new computer that can handle it, I turned it on. Alas, I see that the inside of a smooth-shaded cylinder now has ribbed shading, which should only happen if the corners were not smooth. This happens whether I upload a model with the normals set for smooth shading in Blender, or whether I generate them in the uploader. Either way, they viewer ao appears to ignore the normals. Is there a setting I need to make to make it work properly, or is this a bug/limitatiuon? It pretty much ruins the appearance of internal smooth cylinders. Baking the ao in Blender, just to compare, I noticed a strange effect. With all set to flat shading, the inside ao has ribs, and the outside is completely smooth, as I expected. When I set it to all smooth* shading, the inside becomes completely smooth, respecting the smooth shading, but now the outside has very faint ribs! Surely that's not supposedv to happen? *eta - corrected "solid" to "smooth"!! Also "solid" changed to "flat", as Blender has changed that.

I think the effects you describe must be something different from those I was investigating, because you saw the differences in the upload dialog. This doesn't show the physics weights you get with the type set to "Prim". It only shows the weight for type "Convex hull". You are quite right, though, that it is generally much better to apply rotation and scale before exporting the collada file. There are several problems that can arise if you don't do that, and may affect LI.

"Solidify will always turn the entire mesh into a solid." That's true for the solidify modifier, but you can solidify only selected faces with Mesh->Faces->Solidify. It's not quite what's needed because it makes all the joining faces along all edges - so you have to remove the unwanted ones afterwards.

I don't do clothes, but ... One-sided texturing is used because it halves the work the gpu has to do for enclosed solid shapes. So it is necessary for best efficiency (least lag). There is no way to get the viewer to shade both sides. You do have to provide both if you want to see them. You don't need to solidify the whole mesh. You can just do those parts where the reverse side of the mesh will be visible when it is worn. That way you minimise the extra work the gpu has to do. If you want to see in Blender what the one-sided mesh is going to look like, you can turn on Backface culling on the Display section of the Properties sidebar. You don't save any L$ by uploading the texture with the mesh. Each included texture will add the usual L$10 to the upload fee. In fact, if you always upload with the texture, then you have to pay for both mesh and texture upload every time you want to modify either. That increases the cost of modifications. Personally, I never upload textures with the mesh, as I can see no advantage in doing so. I know others like the combined upload, but I have never understood why (can anyone explain?).

Well. I set out to see if I could do an exhaustive analysis with the simplest possible mesh. Two equilateral triangles, one small one and one larger, both perpendicular to the X axis (before applying small shifts). The larger is at the highest X coordinate. I tried applying an X offset of about 0.000001m (about a millionthof the X size) to each vertex, one at a time (as well as some combinations). For each offset vertex, I changed the order of the triangles in the polylist, and for each triangle order I tried all three possible vertex orders of the triangle with the offset (circular permutation only because reversing the sequence reverses the normal, and in other experiments that did affect the weights). I also tried swapping the triangle positions on the X axis for some of these states. I can't show all the results, as I didn't complete them all. Here are the results for both triangle orders with a single offset vertex in the larger triangle, for each offset vertex and each vertex order. The numbers at the vertices show thier order in the <geometry> tag, not in the <polylist>. The large triangle is shown in the view looking from positive X towards the origin, as shown in the diagram. The left shows the large triangle first in the polylist, and the right shows it after the smaller triangle. A spot indicates the vertex which was displaced +0.000001m along the X axis. This is green for cases where the Prim physics weight is the same (0.5) as the case with no displaced vertices, and red for cases with hugely increased weights. The order of vertices in the <polylist> is indicated by the red aorrows, starting at the red number. The weights observed for type Prim are shown in the middle. I can't discerne any consisten pattern in these results. So I am going to abandon hope of understanding what is going on here. It depends on the order of the vertices as much as on the order of the triangles in the <polylist>. It also depended on the physical order of the triangles along the X axis.Incomplete observations with displacements in the small triangle showed they could have even larger effects, also depending on these three factors. In one case, with a displacement in the large triangle, adding a displacement to one of the smaller triangle vertices cancelled out the effect of the first displacement. I suppose this could have something to do with incorrect coordination of the iterators that look through the polylist and geometry during the calculation, so that they are associating coordinates that belong to different vertices. That would occasionally lead to imaginary narrow triangles that would cause high weights. However, as long as I can't see any pattern, I cant see any way of testing that possibility. It might also be some unexpected sensitivity of the approximation of triangle widths. I had hope to be able to invent some rules to avoid these effects, but I have to give up now. Of course the extreme effects in these examples would lead any creator to make changes that avoid them. But in the case of the cylinders, there were substantial but non-catastrophic effects that might be substantial weight increases without the creator realising. Maybe we just have to hope that it gets fixed.