Drongle McMahon

Arton, do youknow what the "Back end enforcement for mesh upload" does?

Yes. It would be nice if we could put them all in one file. I don't see why it shouldn't work, in principle, with the naming convention, but I guess it would take a lot of rewriting of the code, especially to maintain backward compatibility with the old system.

Ah. I think you have misunderstood the instructions for the new naming convention. You have put all the objects in the same dae file. This isn't how it works. Each LOD has to have its object(s) has to be in a separate file. So you use the "Selected only" option in the Blender exporter for each object. Then you use the high LOD ("Cube") to open the uploader. Then for each LOD in the main tab, you select "Load From File" and then "Browse" to select the file with the appropriate object. So, for example, this might be a file "cube_lod2.dae" that contains just the "Cube_LOD2" object, and so on. Similarly, you upload the physics object dae file on the Physics tab of the uploader dialog. If you have more than one object in th high LOD model, then you can apply the naming scheme to each object and export all the high LOD meshes to one file, all the "x_LOD2" lehes to the next file etc. The naming scheme will then make sure the right meshes are associated between the LODs (and phsysics). Note that you don't have to use the naming scheme (at least the last time I tested it). If you don't, then the code is supposed to fall back to the old syatem where the objects are associated by their order in each file. In Blender you can control that order by using the "Sort by object name" exporter option (but then you have to avoid the "_LODx" suffixes completely). The naming scheme was introduced to deal with errors that people often encountered with incorrect association of multiple meshes in different LOD files, including the mismatched material error. So if you are starting from scratch, it's probably a good idea to use the naming scheme. I notice that the meshes in your dae file don't contain any material (The uploader looks for a "material" attribute in the <polylist> tag). You need to create a new material and assign it to all faces of the meshes (to start with), although I think it should still work without it because the uploader should assign a default material.

At what point in the upload process do you see the error message? Can you let us see the dae files by putting them somewhere accessible? That would be the easiest way to see what the problem is. When you say you renamed them, did you use the original name with those suffixes ("aname", "aname_LOD2" etc.), or just the suffix ("aname", "_LOD2", etc.; since that's what you wrote)?

I agree with Gaia - maybe the dae file too. Meanwhile, it looks to me as if the UV mapping of the long sloping beam used for the bake is different from the one used to apply the texture inworld. Dou you have more than one UV map in Blender, and are you sure the right one is exported. Remember that the uploader will only use one UV map, even if you export more than one to the dae. By the way, the scaling of the woodgrain is completely different on the beams and the steps. It would look better if they were the same. This may be difficilt because you are using a baked texture for the beams, presumably without repeats. However, if the steps positions are accurately regular, the ao should repeat for each step, and so it should be possible to use repeats. It's quite a lot of work to get things exactly right for that, but you can get much better texturing.

"Not following the new naming convention for LOD files." Just to reiterate from my comment on that KB article, to avoid confusion: The article says the naming convention applies to the names of files for LOD and physics. It doesn't. It applies to the names of the objects in the LOD and physics files. The file names don't matter at all.

You might want to look at this thread to see if there's any clues there. The sort of behaviour you describe seems to arise when materials end up with the same names, in one way or another. The general observation doesn't just apply to the latest viewer, but the internal assignment and treatment of material names might have changed. If your effect is the same phenomenon, then you would find that the changes you make to faces other than the "master" face (face 0, I think) revert to the master face properties if you log out and back in. It might be informative to do that test.

Ah. It seems that my variations were all because this is in fact a consequence of the object naming. The uncapped variants were exported from a duplicated model in which the object name was different (Blender doesn't allow duplicate names) although the material names were identical. Trying this out with the same model geometry, but with only eight materials, there was no problem using an object called "Cube" for the visible LODs and one called "Dube" for the physics, irrespective of whether or not caps were removed. Furthermore, "Dube" could also be used as a lower LOD mesh for "Cube". However, with the ten materials, if I used "Dube" as a LOD mesh, then the upload failed with the error message that says materials are mismatched (which isn't true, of course - it's only the object names that differ). If I used "Dube" as the physics mesh, it was simply ignored, so that there was no Prim-type shape and no physics in the preview. There was no error message and the model could be uploaded (as Aquila reported). After renaming "Dube" to "Cube_PHYS", according to the official naming convention, it now worked as the physics mesh for "Cube".. Also, to my surprise, it also worked as a lower LOD visible mesh. Indeed, the identical mesh named as "Cube_LOD2" also worked as either LOD or physics mesh for "Cube". So did "Cube_LOD6", "Cube_LODn" and "Cube_LOD". but not "Cube_LO" or "Cube_PHY". So it appears that the the fall-back to use legacy model association, which seems to work with multi-mesh models when they all have less than 8 materials, does not work fully when a mesh gets subdivided because it has more than 8 materials. Using the new naming convention, the same meshes will work, and there is some relaxation of the requirements. So if you want to avoid this problem with meshes having more than ten materials, you have either to make the object names all the same in the visible and physics model, or use the new naming convention. Now I will drive myself insane looking at the source code to see where this happens... :matte-motes-confused: Note: The anomalously high triangle-based physics weights were still there with all successful ten-material uploads.

ETA: it seems this is all caused by object naming effects - see post below I think there's something more subtle going on here. First, using the ten-pillar model, I noticed that with the capped physics. which does upload, the root of the linkset is the mesh with the last two materials, while with the uncapped physics, the root is the six first materials.When both visible and physics were uncapped, the model ulpoaded properly. With the fully capped models, the first eight pillars had a physics weight of 7.3 (i.e less than 1 each), but the two others had a physics weight of 46 (23 each - orange in physcics display).(Actually. given previous knowledge about triangle-based physics weights, that discrepancy isn't very unusual). I didn't complete the upload of the next ones, but judging by whether the preview showed the physics, any (partially) uncapped visible model model would work properly with any (partially) uncapped physics model, but not with the fully capped physiocs model! Then I tried with a different model - two six-sided cylinders with eight materials on the first and the ninth material on all faces of the second. That uploaded without any problems whether the physics cylinders were both capped, if either was uncapped at one end, or if all the caps were deleted. In other words, it didn't exhibt the problem at all. Note, these were all with "use LOD above" in all LOD slots - so it's nothing to do with decimation. MeshUmportUseSLM was always off (I hate slm). It's may be difficult to make a repro for a jira that ties down the circumstances where this happens.

It could also be that Blender does not generate the correct DAE code for a mesh with more than 8 materials? That seems most unlikely because eight materials has no special significance in Blender. That is to say, there is no discontinuity in the dae that arises with nine, as compared to 8, materials. On the other hand, there is a major discontinuity in the uploader, which starts to divide the model.

So it doesn't use the bounding box of the combined meshes for the CH physics, although it does use it for LOD and pivot (and stretching handles). Stranger and stranger. Also, reproducing your case, I find that if you leave all the 20 end faces there, the triangle physics works as you would expect. Deleting just one of them results in the behaviour you described. That seems to be specifically for >8 materials, as deleting the end faces on a model with 8 pillars/materials works as expected.

Ugh! I hadn't looked at that. I'll have to look at the code and see how that happens. Surely they can't just have forgotten about it? I assume both objects get the CH of the whole linkset. rather than each getting their own proper hull. Is that right? Anyway, that's yet another good reason not to use the auto model splitting. I think we have to assume that this whole thing was done just to accomodate people who wanted to upload multi-material objects made by other people and who don't know how to use 3D software themselves (i.e. .......s).

That does provide an easy way to offset the pivot/origin, but, as with the older methods, it also means the bounding box of each of the meshes is that of the combined linkset. When the splitting produces different sized or widely spaced objects, that can have very large effects on the LOD switching and download weights. These may then be difficult to control, as it means you have to control the splitting by ordering the materials (if I recall correctly, this is now alphabetical in LL viewer - not tested in latest release*). There are also horrible things that can happen with the splitting if materials have > 21844 triangles. As usual, you will get better control if you do the object splitting (and pivot offset) yourself before uploading, instead of relying on these automatic hacks. *Tested it - yes, it's alphabetical now. Is it in Firestorm too?

No doubt you won't find this answer satisfactory, but here it is anyway... There are two intuitive, but opposite ways of ordering LOD (levels of detail). On the one hand, you might think it obvious that that the highest number should indicate the highest detail. On the other hand, you might think that the lowest number should indicate what's seen at the shortest distance (which to me seems a little less obvious). It so happens that the former of these Obvious Alternatives (sorry) was chosen by the earliest coders of SL. Thus in llvolume.h we find "const S32 MIN_LOD = 0; const S32 MAX_LOD = 3;", where MAX_LOD is used to indicate the maximum level of detail. So that choice was embedded in the code from the very start. Now when the developers came to coin the new naming convention, it was natural for them to use the numbering that was already implicit in the code, avoiding the need for conversion, and probably minimising the likelihood of errors. Personally, I find the naming convention cumbersome, or even obstructive. I believe (last time I looked, at least - see wiki comment) that as long as you avoid any "_LODx" suffixes, you can obtain the old behaviour irrespective of the setting of ImporterLegacyMatching. So with Blender, where alphabetical ordering in the exporter can be used to control the associations in LODs of multi-mesh models, there are no problems. That means you can still use the same dae file at different LODs, something I used to do quite often when optimising LODs for different purposes, without having to go in and rename the meshes in all the files every time.

"Or is the common practice to leave Physical unchecked" Yes. It still works for collisions without being made physical. You only need it to be physical if you want it to respond to pushing, gravity etc. In that case, you can adjust various parameters in the edit dialog. Bear in mind also that making things physical places a large burden on the physics engine in the region server, contributing to lag. So it should be done only where necessary for the function of the object (such as sliding down a hill). If you want, you can set your table to physical to find its position, but that's not as good as doing it by eye, as there's usually a small offset between physical objects. If there wasn't, they would be continually agitated. If you make objects physical that can't maintain that separation, you can get very destructive effects.

Guessing, but it looks to me as if you have a few duplicated faces, with the normals flipped. Turn of backface culling and then try deleting the faces. If they are duplicated, you will still see the duplicate face when one is deleted. Or switch to wireframe view, which lets you see the inverted normals. Also, there is a black spot that looks like an isolated vertex. What is that?

Oh dear. Thanks for trying. Sorry to have led you into fruitless work. :matte-motes-frown:

Arton and Whirly have described another cause for the same parent-child-like behaviour, when spaces in the material names lead to duplicate material names because the Collada dom drops the part after the space. Apparently this was accepted as being a bug, as a fix has been developed (not yet in release viewer). I'm not sure the fix will work, but its existence emphasizes that it is unwise to do anything depending on this effect.

Yes. That is exactly the behaviour you see with the "secret" materials. I tested it and confirmed that the second face does revert to face 0 colour on relogging. It would be interesting to know what an independent observer sees. So my guess that the effects with the secret faces is just due to them having the same name may be correct. This also gives another possible explanation for the behaviour reported in this thread. I still don't see how that fix is supposed to change anything with the material names, as these are not fetched with getElementLabel. Thus material names with spaces will surely neither trigger the use of IDs instead of names, nor get fixed if it is triggered by something else. I suppose we'll have to wait and see. It's frustrating not to be able to see MAINT jiras to decipher the logic behind the fix.

Whirly: I am puzzled. It looks like that is only checking names for mesh, not material names. So it would not trigger if mesh names were unique but material names were duplicated (Arton's problem, I think). The material name used is apparently the "material" attributes of the <polylist> etc., not the "name" attributes of the <material>. It is collected directly by a call to the Collada dom library (in load_face_from_dom_polylist etc.). So it isn't affected by forceIdNaming. In that case, Arton's problem with material names isn't going to be fixed. Have I understood something wrong? Arton: I would be interested what the symptoms are of the broken mesh. In partucular whether they are the same as those we see when "secret" materials are made for mesh with >21844 triangles. I have previously guessed that these symptoms were the side effect of the secret materials having the same name. The main effect is the parent-child face effect, where changing parameters for the one "parent" face changes all, while changing the child face parameters affects only the selected face. (I think the latter is probably only seen in the local viewer. It doesn't survive relogging, when all the faces revert to the parent's paramaters).

Thanks Arton. I'm going to assume Maya will do the same too. So I submitted a jira. What odds will you give me on it's being fixed or ignored? :matte-motes-smile:

Mesh uploaded from Blender now get "_0" suffix appended to their names. I am thinking of submitting a jira asking for this suffix to be removed. My reading of the source code suggests this would happen for any strictly compliant Collada file, but before submitting the jira, I would like to find out whether the same thing is happening with meshes from other software. Please let me know here. Note that this applies only to uploads with the latest official LL viewer, which has included the uploader changes from Project-Importer. I don't know the status of other viewers with respect to those changes.

The strict naming convention described by by Arton is the safest way of doing this, although it's inconvenient in some circumstances. It's also compulsory with models where any meshes have more than 8 materials*. A bit more, just to confuse everyone... If the uploader finds meshes in a lower LOD file that don't match the convention, it switches to "legacy" matching. However, this is NOT the same as it used to be. It used to be simply based on the order of the meshes in the dae file, but now the meshes are sorted by name**. So the "legacy" matching is now alphabetical instead of simple ordering in the file. Fortunately for Blender users, if you used the "sort by object name" exporter option, this makes no difference. The application of this "legacy" matching is supposed to be controlled by the setting of the debug parameter ImporterLegacyMatching, but in my experiments, it was always active whether this was TRUE or FALSE. There is a wiki page that covers the naming convention, but the information there is outdated, as indicated in my comment there, and the naming convention applies to the meshes, not the files. *This is now permitted, although it's a fudge - the uploader splits the mesh into multiple meshes each with up to 8 materials. You might as well do the splitting yourself, as that gives you better control over LOD switching etc. Also, there are potential problems if any of the materials has more than 21844 triangles (as usual). The "legacy" matching of LOD meshes doesn't have to work for meshes with more than 8 materials for backward compatibility because they weren't allowed before. **Where that name comes from is another story. That has changed too. It appears that it looks first for a name or ID attribute in the <mesh> tag, but that isn't allowed in the Collada spec. So then it looks in the parent tag, which is a <geometry>. That does have a name, but the uploader tag appends "_N" to it, where N is a zero-based index, to avoid possible duplication of sibling names. That may be needed for other kinds of element in the Collada file, but is redundant with <geometry> because the collada spec doesn't allow multiple children there. (I will try to make a jira asking for this index to be removed for meshes.) The name used to come from the <instance geometry> tag than instantiates the mesh, and Gaia very kindly added a name attribute to that in the output of the Blender exporter, so that we could get names without the appended sibling index, but it seems that good work is now undone.

Hmm. Strange things going on with the uploader creasing. My object has 32 segments. yours has 16. If I use the 32 segment one, the uploader creasing works, but if I use a 16 segment version, the artefact is still there, as you found. For the 16 segment object, we should expect just 32 extra vertices, but, with the default 75 degree crease angle, we get 80 extra. I can't work out where they are from. If you increase the angle, the vertex count reduces at a couple of critical angles, but not as far as the expected number. The edge split works for both the 32 and the the 16 segment objects. It's preferable to the crease angle because you can apply it to just one of the rim edges (using marked sharp, not angle), so that is less increase in the vertex count. If the artefact depends on the order of presentation of the facets to the rendering engine, then I guess there's no obvious way that the crease or the edge split should change that order. Neither is there any reason they should have the same effect. So perhaps it's not surprising that there are some cases where they don't work. Still, I think I would always prefer doing the edge split in Blender, because that gives you more accurate control. It also gave me the expected increases in vertex counts where I looked at them. I can't guarantee that it will always work though because I don't know exactly why having the edge split changes the order of facets for the renderer.

I just tested with the latest LL release viewer [3.8.5 (305531)], and both the edge-split and the two material solutions still worked on my hemispherical cup example. So did the crease angle on upload. I think the edge split (or crease angle split) needs to completely separate the inside and outside to work fully, although only splitting half of the rim did reduce the artefact a lot.