Drongle McMahon

Oh dear. The order you get with singularity is just the order the polylists appear in your file. So it seems that viewer is still using the old system. How old is it? I think you would have to contact the developer(s) to clarify whether it has the new code in in that I mentioned. I'll see if I can find their code. Had a look. Model.cpp is hugely different. The sorting stuff isn't there. So I think it's clear that Singularity is using the old method of face numbers, which is just the order the assigned geometry (polylists) appear in the dae file. If so, that's a definate incompatability with the LL viewer. What about Firestorm, anyone? I like your idea of optionally defining the face numbers at upload a lot. It might not be very easy because they would have to get the right name from the name attribute of the material tag. Otherwise you would be confronted with the "lambert..." names and no know what they were. As I said though, that would probably be better anyway. They could use an interface that put the material colours next to the name too, or even the textures if they are uploaded.

Here's another test. Used Cathy's dae, first as it is, then with "lambert8SG" replaced by "lambert08SG" and "lambert9SG" by "lambert09SG". That changes the alphabetic order to be the same as the numeric order. Here are the reports of a script that gives the face colours in face-number-order...  ETA: the material names were added by hand, not available to the script.

"... should we also export materials in alphabetical order?" My conclusion that the materials, and thus the faces, are sorted by name came from both inspecting the code of the current release viewer and doing some tests, also with that viewer (i.e. Firestorm etc. could be different). I am fairly confident that is right, although it would be good if somebody else could do an independent test. If I am right, then sorting the materials in the collada (it would have to be the polylist order, for the uploader to notice - the material or effect tag orders don't seem to matter) would not make any difference, as the uploader does it anyway. There's no guarantee that this will stay the same though. I think this sorting was introduced at the same time the material names, instead of their order in collada, were used to match polylists (SL faces) between LOD models. I don't see why the latter would require alphabetical ordering in the high LOD though. It works by re-ordering the materials list, then the geometry lisdt, according to the order in the high LOD. Maybe it was just considered neater if that was already alphabetical. For anyone interested, the code for the sort is in LLModel::sortVolumeFacesByMaterialName(), which is called by LLDAELoader::loadModelsFromDomMesh(). I can't say I have read it carefully enough to know if it always happens. To test in practice, I used a cube with four materials names Amat ... Dmat. Changing the order in Blender changed the order of the polylists in the collada file, but did not affect the face numbers. Changing the names in the collada file to change the alphabetic order, without changing their order in the file, did affect the face numbers. ETA: It might be suggested that the uploader should really use the name attribute of the <material> tag instead of the material attibute of the <polylist>. That would be the name actually given to the material, whether in Blender or Maya, or presumably anything else..

To make the distinction clear, here are the links for a material called "A" exported from Blender. The name used by the uploader is now "A-material". It has "-material" tacked on the end, but since the name is still there in front, its alphabetic order will still determine its face number. Thus in Blender the face numbers can be controlled by the material names. 

Here's some extracts from your collada file. The links I mentioned are shown by colours and arrows. You can see here where the problem comes from. The last two links use the given material name "A", but the one the importer uses, the material attribute in the top box, is different. It's "Lambert8SG". At the bottom you can see the other ploylists with similar material attributes (except for the last one which isn't used and will therefore be ignored by the SL uploader). It's the order of these names that will determine the face numbers. So now we need to solve the question of where these names come from, and then how to control them. Any ideas?  ETA: it might be worth pointing out that these Maya names are unlikely to be generally effective for alphabetic sorting because they don't sort in the order of the numbers they contain. In number order these would be 8SG, 9SG, 10SG, 11SG. In alphabetic order they are 10SG, 11SG, 8SG, 9SG. So even if you find a way of getting the numbers in the right order, that will not generally produce the correct alphabetic order.

It would be interesting to look at your collada file for a simple object to see if we can work out what's going on with the names. I guess we would need to know the material names in Maya too.

Some time ago, there was an important change to the situation described in the link referred to a couple of times here. Before, when the older thread took place, the order of the face numbers was decided only by the order of appearance of the <polylist> in the geometry, with no effect of the material names. This was changed when material matching across LODs was changed to depend on material names. Now the faces are sorted according to the material names. The first in alphabetical order is face 0, the next id face 1, etc. In Blender, this means that the order of materials in the material list no longer determines the face numbers. As I don't use Maya, and don't know the detail of the exporter, I can't say for certain how things will work there, This is because of the complicated indirect nature of the association of faces with material properties in Collada. The <polylist> has a "material" attribute string that is matched to by a "symbol" attribute in a <instance_material> tag inside a <bind_material> section. That <instance_material> then also has a "target" attribute that points to the <material> via its id. That indirects again through an <instance_effect> child to reach the <effect> that actually contains the material properties, colour etc. Since Blender uses the material name with appropriate suffixes for all these links and attributes, the alphabetical ordering would be the same wherever in the chain the uploader took the name from. However, by experimentally manipulating the collada file, it can be shown that the importer actually uses the "material" attribute of the <polylist> as the basis for alphabetic sorting of the faces. Thus it does not matter what appears in all those other links, or even if the links are broken. There is nothing in the Collada specification that requires the "material" attribute of the <polylist> to be related in any way to the name of the <material> or the <effect> or the name of the material in the authoring package. To be clear about how the face numbering will work in Maya, it would be useful for someone to determine whether and how the "material" attributes of the exported <polylists> (or<triangles>, or <ploygons>) are determined in Maya. This is most easily done by exporting a simple cube with three or four named materials on it, and looking in the collada file at the places indicated above.

Solutions here.

Most likely too many triangles (>21844) in a material. See last message in this thread. and this jira. After 21844 triangles, the uploader makes a new "secret" material that behaves oddly. Which triangles get assigned to it depends on the way the 3D program orders them. Subdivision can produce checkered or Serpinski-like patterns. It's best to never use more than 21844 triangles (10922 quads etc) per material if you want to avoid these artefacts and remain in control of texturing.

There may be a clue in BUG-8987 to the reason single extra vertices sometimes work and sometimes don't. Normally, only vertices referenced in triangles are considered by the uploader, but if it's the first vertex in the vertex position list, then an unreferenced vertex can affect the bounding box. It's interesting and useful that Arton's collapsed triangle works. The uploader does contain code to reject "degenerate" triangles - those with no area. Each time a vertex used in a triangle is added to the geometry, it is tested against the limits of the bounding box. If it lies outside it, the box is extended to include it. So I guess that must be done with the degenerate triangles too, before they are detected and eliminated.

Sounds like a bug to me. Surely face numbering should not depend on whether a mesh is rigged or not. Can you give us a list with, for each material: name, order in Blender (or whatever) material list, face number inworld? There might be a clue there. Can you see the same effect if you use just a simple 6-sided cylinder with the same materials on it, listed in the same order? Does changing the material names (to make new alphabetical order), and/or their order in the list, make any difference to the face numbering, in the cases of rigged or unrigged? Is this a new effect? There were changes in material hadling in the latest viewer release.

Here's another example that illustrates two ways custom LODs are worthwhile. This is a girder that uses a lot of extra geometry to get proper highlights on rounded edges. It uses single segment edge bevelling with edited normals (which gives about half the LI of the easier two segment bevel with profile=1). Uploading with auto-LODs gives triangle counts 1249, 313,73,37, which gives a LI of 4 (at 1x1x6 m). The custom LODs are 1249,241,25,13, for an LI of 1. The autoLOD one could be reduced by setting the lowest triangle count to 1, and actually it's so bad it might as well be. So LI alone isn't reason enough on its own. Instead, it's the quality of the LODs. The first picture shows the two models, custom LODs at the back, auto LODs in front, with the lower LODs at the nearest distances they appear with the LL default RenderVolumeLODFactor (1.125). The picture below shows the three lower LODs at the same scale, so that you can see what's happening. All taken at noon with no extra lighting.  At the first step, the custom LOD simply replaces the smooth shaded bevelled version with an unbevelled version with sharp corners. The auto LOD generator can't handle this at all. It leaves horible angled faces with smooth shading and horribly incorrect highlights. That's the first reason for using custom LODs. If you use geometry to get proper highlighting, it will be badly messed up at the first LOD switch in the auto-LOD. For the lowest two LODs, the custom LOD model uses alpha masked textures on simple planes instead of geometry. That way it can save huge amounts of geometry, which is why it's LI is lower that the auto LOD model. That's the second reason, but it's not just for lowering LI (for which you can use the triangles=1 trick anyway). It's for appearance. These lower LODs are far better than the disintegrating scraps left by the auto LOD.  PS. I had to copy your pictures and up the gamma by 1.4 to see your them at their best. Maybe you would do better to tweak them a bit before uploading?

"...what happens if there are >43688 tris.." I made a seven times subdivided cube, which has 196608 triangles all with the same material. Sure enough it gets subdivided into two objects when it has used up all eight slots with secret materials. Because of the way the subdivisions are implemented in Blender, this makes two "Serpinski" objects. Here they are unlinked. We used to get just the one on the left. Now we get the holes too. More fun for the subdivision fans. Child faces on the left one are coloured in the closeup. Red is the "parent" face.  The one on the left gas one "parent" and seven "child" faces. I played a bit more with these. It seems changes to the object other than to the textures can also override the child face properties, including stretching with handles or the edit box spinners, any other "torture", shift drag copying, etc. I am guessing the temporary visibility of textures and colours on the child faces are client-side effects, and that anything that regreshes the server objects causes the parent properties to overwrite them. If that's the case, then the child face changes should be invisible to other observers. There wasn't anyone around to confirm that*. Trying to adjust material properties of the child faces was interesting (normal map, shininess etc.), The changes were visible as long as the child face was selected, but disappeared as soon as it was deselected. So they are less stable than colour etc. *But it was reverted to all "parent" properties after logging out and back in.

I have to update what I said because the Project-Importer stuff has now been added to the latest release viewer. This changes things considerably. You can now upload mesh objects with more than eight materials. They will get split by the uploader into separate objects, each with no more than eight materials, which will appear as a linkset inworld. The worst bug, where you could get a single material split between object if it had more than 21844 triangles, appears to have been fixed, so that the split will always put the whole of a material into one object*. Of course the LOD switching of the linked objects is independent. So you will get uncoordinated LOD witching. Obviously you can control this better by doing both material and object splits yourself, rather than leaving them to the whim of the uploader. Unfortunately, you still get problems (failed upload) if you use LOD files where materials with >21844 get split int the high LOD but not the lower LODs. That leads to mismatched "secret" materials which are detected as an error. So the advice to always avoid materials with >21844 triangles still stands. While testing this, I looked a bit more closely at the secret materials. You can select them separately with Select Face in the edit dialog and they behave exactly with the parent-child relationship. If you change anything on the parent, it gets changed on the child too, but if you change the child, the parent is unaffected. If you set the child (secret) face to a different colour, a script that uses face numbers to report the eight face colours does not report the colour you can see. It appears that the script can only see the parent face, not the secret face. My guess would be that that's the same for setting properties as well as reading them. So the secret face seems to exist for the edit dialog, but not for LSL. I have no further ideas about when or why other faces would be affected too. *Don't know what happens if there are >43688 tris - presumably that still gets split within material?

Concerning the "strict naming" of "custom LOD files". This paragraph appears to be inaccurate and/or superceded by code changes* in two ways. First, I recall that it was the naming of the objects in the file that had the strict suffix requirements, not the naming of the files. Second, this requirement seems to have been relaxed, even with ImporterLegacyNaming set to False. Thus the file combinations listed in BUG-8996 are uploaded successfully whether ImporterLegacyNaming is True or False. Neither the file names, nor the object names in those files have the prescribed suffixes. This is presumably because something like the changes requested in that jira, which make life much easier, were made. This part of the documentation was probably written before those changes. {*tests in release viewer 3.8.4 (305119)}. (Note however that this may change again with recent commits for 8.3.5)

"Someone like Drongle ... " You mean there are others? :matte-motes-agape: It's in the wiki, here where it says ... The width of a triangle is defined as the width (smaller side) of the tightest rectangle you can draw around the triangle. The average is computed "harmonically" (1/avg = 1/a + 1/b + ... ), which was done to favor weight smaller triangles more heavily. This average is then clamped to be between 0.001m and 20m (right now) and then used in the simple formula: C = MAX( constant * num_triangles / triangle_width, minimum_mesh_cost ) The surrounding rectangle thing is why long thin triangles are as bad as ones that are short and thin. The harmonic averaging makes sure smaller triangles have larger effects. The variations I found suggest that these calculations don't really work at all as described there. Otherwise, why would triangle and vertex orders have large effects even when the triangles are identical? But the effects of small triangles are more-or-less as expected.

"...as in 64k faces limit per mesh it could never be fixed if it is a COLLADA~SL limitation and not a bug..." It's not a limitation of Collada, nor really of SL. It's certainly an unintended effect of the code in the uploader functions. In fact, the intended limit is 64k vertices (not faces), as stated in both the wiki and the source code, which is supposed to raise an error if it is exceeded. However, that limit is never reached because the limit on the number of triangles is necessarily always triggered first. That creates the new "secret" material, resetting the vertex counter in the process. While the 64k limit on vertices is a necessary consequence of the internal data format (vertices are referenced by 16-bit indexes), I could not see why the triangle count is so limited. The list of triangles (three vertices each) is kept smaller than 64k by the triangle limit, but there doesn't seem to be any need for 16-bit indices for that list. So it does look like a bug that could very easily be fixed, by modifying only the viewer code. However, experience tells us that this doesn't mean it will be fixed even if I am right there. The "secret" material(s) does indeed count as one of the allowed eight, so that it can affect the number of other materials you can make. There is a development viewer [Project-Importer] that is supposed to allow more than eight materials. It does that by splitting the mesh into separate mesh objects, each still limited to eight, which become a linkset on upload. However, the interaction between this mechanism and the "secret" material generation is, as you might guess, horrendous. For example, a mesh with eight materials can get split into two meshes with half of the mesh faces in one of the materials haphazardly allocated to different objects. So I don't know if this will ever appear in a release viewer.

The trouble with using bug/undocumented behaviour is it just might get fixed. Still, this one has been there for quite a while.

No obvious clues there then. Does any of your materials have more than 21844 triangles? (maybe the main bodywork?) Note that's triangles, not polys - the uploader triangulates everything before it uploads it. If it does, then maybe the "secret" material effect modifies the behaviour of the whole Material system and not just the affected materials. You could check this by uploading a version after deleting geometry until all meterials are less than 21844 triangles. If you see the behaviour with 21845 and not with 21843, that would be pretty conclusive. By the way, this jira has the initial observations on this effect of triangle counts, if you are interested. ETA: The simple workaround is to split the sets of faces with more than 21844 tris and give the parts different meterials but the same textures. I think you have used all eight though (number 7 in edit dialog), in which case that solution isn't available.

This sounds interesting. The only circumstances where I have consistently seen this kind of behaviour before is where the mesh uploader has generated "secret" new faces when the triangle count for a material exceeds 21844. In that case, the "secret" faces can be selected separately, and colour changes applied to one of them affect all while colour changes to the others affect only themselves. From looking at the source code, I think the "secret" faces get the same name as the one in the collada file that had the excess triangles. So I speculate that it's the shared name that somehow leads to the observed behaviour. I have no evidence for that though. From you description, this is not the same effect, because you indicate that you made the affected materials deliberately, but I suppose it could be related. Perhaps it would be easier to think about this if we had more information about your model - number of objects, number of materials, number of triangles in each material, names of materials. Also, it might depend on what software the mesh was made with. Other questions are whether the behaviour you described in consistent, because viewer-server communication delays can sometimes produce intermittent effects like this, and whether it also affects face properties other than glow. Does it happen only when changes are scripted, in which case it could be an LSL problem, or does it also happen when you change properties using the edit dialog? Finally, can you reproduce it on a simplified mesh?

Yes. The triangle-based physics weights do behave strangely. Removing small triangles usually works, but there's certainly more going on. Changing the order of the triangles in the polylist in the Collada file can sometimes have significant effects, or even just changing the order of the vertices in a triangle. (If you search here for "triangle physics episode" you can find some details, but I wouldn't recommend spending time on it as it doesn't seem to yield a general way of minimising weights.)

Arrgghhh! Tiny narrow triangles around edges of the added cuboid -> High physics weight. Remove all except the top surface in the physics mesh (and maybe make that as large as possible without undesirable collision effects). It's counter-intuitive, but the physics weight of triangles get smaller the bigger they are. Tiny or narrow triangles are BAD.

Complete guess - could it be that there are two of that poly there with opposite normals? Then if you don't have backface culling on and the upside-down one gets rendered last, it's black because it's showing the unlit side. In SL, the backfaces are not rendered, so there's no black face obscuring the one the right way up. To test that hypothesis, just see what happens if you turn backface culling off in the viewport.

The problem arises because you need smooth shading across the edges around the circumference of the sock, but not across the horizontal edge loops. In Blender there are two other ways of achieving this without adding the edge loops. First, you can turn on "Auto Smooth" under the triangle tab in the properties panel and set the smoothing angle to an appropriate angle. Unfortunately the vertex normals made by auto-smooth don't get exported by the current Collada exporter. So that doesn't work for SL (unless you transfer them to another copy of the mesh using a data transfer modifier*). The same effect can be obtained by using the edge-split modifier with the appropriate angle setting. This also gives you finer control if you use the marked sharp edges instead. You can also split edges explicitly with the split edge tool. These all break the connection of the faces either side of the split edge, duplicating the vertices, so that the normals are no longer interpolated across the split edges. These methods use less extra geometry than the added edge loops, but result in a perfectly sharp edge which shades unrealistically. The edges made by adding edge loops look better because their shading makes slightly rounded edges which look more realistic, especially for shiny objects where they are necessary for realistic highlights. Here are these different methods, rendered in Blender (orthographic camera) at the to and in SL, at the bottom. (1-5) are all simple geometry: (1) Flat-shaded; (2) + smooth-shading (3) + auto smooth 85 deg; (4) + auto smooth 180 deg, with normals transferred from 3; (5) Edge split 85 deg. (6) is the smooth shaded model, 2, with the added edge loops. (7) is the same as 6, with an added edge loop on the top too, to make the top look flat. Notice that the models look similar in Blender ans SL, except for 3, which looks like 2 because the auto-smooth vertex normals are not exported unless they are first transferred to a new copy of the mesh to make "custom normals", as in 4. 

Here's how it works. Three diagrams on the left or each row show sections through a simplified cylindrical model. The model shading is simulated on the right by using the top-down Matcap in Blender. The top row has top and bottom closed. In the middle, both are open. At the bottom is the same as the top, but with extra edge loops close to the top and bottom of the vertical sides, as Aquila suggested.  Blender mainly works initially from face normals*. These are shown, in the middle of each face, by the light blue lines on the left. They stick out from the middle of the face at right angles to the faces. Note that the top two are the sane except for the missing faces. At the bottom you can see the extra face normals belonging to the narrow faces made by the new edge loops. Collada only uses vertex normals. For a smooth shaded object, these are generated by interpolation (more-or-less averaging) the adjacent face normals. These vertex normals, that get exported to the dae file, are shown by the green lines in the middle diagrams. The vertex normals bordering the removed faces are now different because the contribution of those face normals has been removed. When the mesh is shaded in the viewer, the normals of each point on the surface is interpolated between the vertex normals. The results of this interpolation at a sample of points is shown by the orange lines in the third column. Now you can see why you see the shading on the top right. The normals at the top of the band point upwards, towards the light, while those at the bottom of the band point downwards, away from the light. So the lower part of the band gets less light and is darker. The whole of the longer part of the cylinder has normals pointing downward. So it is shaded as if it receives little illumination. When the top and bottom surfaces are removed, the effect on the band is still there, although less pronounced. The long cylinder is now more brightly shaded lower down than at the top. When the extra edge loops are added, the new perpendicular vertex normals near the top and bottom cause all the interpolated normals to be parallel. So now the shading on the vertical faces is even. All the curvature is compressed into the narrow space between the old and new edge loops, resulting in the appearance of rounded edges. *Now we can also have editable custom vertex normals. These provide other ways of solving the shading problem. But that's more complicated. So I will leave it out for now.