[BUG-8734] [Project-Importer] LoadFromFile in lower LOD slots fails.

[sl-service-account]

Steps to Reproduce

Files m1cylx, where x=6,5,4,3 are cylinders with x sides.

1. Upload model m1cyl6.dae; put m1cyl5, m1cyl4, m1cyl3 in sequential LOD slots.
2. Upload model m1cyl6.dae; put m1cyl3 in lowest LOD slot
3. Upload model m1cyl6.dae; put m1cyl3 in low LOD slot

Actual Behavior

Each lower LOD slot gets filled with the LOD above, whatever file is loaded in the file selector.

1. All LODs end up as the high LOD, m1cyl6.
2. Lowest LOD becomes same as low LOD.
3. Low LOD becomes same as medium LOD.

Expected Behavior

Expected specified meshes to be uploaded for all LODs. Expected uploader triangle counts to be correct for the specified files.

Other information

This blocks very necessary tests of effect of model fragmentation with explicit LOD meshes. Needs immediate repair because it blocks other tests.

Attachments

• m1cyl3.dae 2015-03-10 11:33:25
• m1cyl4.dae 2015-03-10 11:33:25
• m1cyl5.dae 2015-03-10 11:33:25
• m1cyl6.dae 2015-03-10 11:33:25
• mcyl3renb.dae 2015-03-19 04:57:55
• mcyl3renbx.dae 2015-03-19 04:57:55
• mcyl4renb.dae 2015-03-19 04:57:55
• mcyl4renbx.dae 2015-03-19 04:57:55
• mcyl5renb.dae 2015-03-19 04:57:55
• mcyl5renbx_x.dae 2015-03-22 11:29:16
• mcyl5renbx_xy.dae 2015-03-22 11:29:16
• mcyl5renbx.dae 2015-03-19 04:57:55
• mcyl6renb.dae 2015-03-19 04:57:55
• mcyl6renbx_x.dae 2015-03-22 11:29:16
• mcyl6renbx_xy.dae 2015-03-22 11:29:16
• mcyl6renbx.dae 2015-03-19 04:57:55
• qcyl5_lod2uc.dae 2015-03-28 22:18:25
• qcyl5.dae 2015-03-28 22:18:25
• qcyl6.dae 2015-03-28 22:18:25

Links

Related

• [ ] https://github.com/secondlife/jira-archive/issues/16552

Original Jira Fields

| Field | Value | | ------------- | ------------- | | Issue | BUG-8734 | | Summary | [Project-Importer] LoadFromFile in lower LOD slots fails. | | Type | Bug | | Priority | Unset | | Status | Been Triaged | | Resolution | Triaged | | Reporter | Drongle McMahon (drongle.mcmahon) | | Created at | 2015-03-10T15:33:25Z | | Updated at | 2015-04-09T20:39:30Z | ``` { 'Business Unit': ['Platform'], 'Date of First Response': '2015-03-12T21:05:10.066-0500', "Is there anything you'd like to add?": 'This blocks very necessary tests of effect of model fragmentation with explicit LOD meshes. Needs immediate repair because it blocks other tests.', 'Severity': 'Unset', 'System': 'SL Viewer', 'Target Viewer Version': 'viewer-development', 'What just happened?': 'Each lower LOD slot gets filled with the LOD above, whatever file is loaded in the file selector.\r\n1. All LODs end up as the high LOD, m1cyl6.\r\n2. Lowest LOD becomes same as low LOD.\r\n3. Low LOD becomes same as medium LOD.', 'What were you doing when it happened?': 'Files m1cylx, where x=6,5,4,3 are cylinders with x sides.\r\n1. Upload model m1cyl6.dae; put m1cyl5, m1cyl4, m1cyl3 in sequential LOD slots.\r\n2. Upload model m1cyl6.dae; put m1cyl3 in lowest LOD slot\r\n3. Upload model m1cyl6.dae; put m1cyl3 in low LOD slot\r\n', 'What were you expecting to happen instead?': 'Expected specified meshes to be uploaded for all LODs. Expected uploader triangle counts to be correct for the specified files.', 'Where': 'See env', } ```

[sl-service-account]

Kyle Linden commented at 2015-03-13T02:05:10Z

Hi Drongle,

It appears your model names are wrong with the new mesh import feature set. Please review this newly published mesh import test document and let us know if you find anything else.

http://wiki.secondlife.com/wiki/Mesh_Import_test

Thanks!

[sl-service-account]

Drongle McMahon commented at 2015-03-19T02:37:53Z, updated at 2015-03-19T02:51:35Z

Kyle. It is true that the single meshes in each file have different names. However, I do not see where in the test document any behaviour is defined for that situation. neither am I aware of anywhere (other than, perhaps the source code) where any "correct" naming scheme is defined. Could you perhaps tell me what is required for "correct" names, or point me to where it is documented?

Furthermore, in llFloaterModelPreview from the Project-Importer repository, there are comments that seem to indicate the intention to fall back to the old index-based LOD model associations...

1396 // If you don't take the time to name your LOD and PHYS meshes with the name of their corresponding mesh in the HIGH LOD, then the indexed method will be attempted below.

1423 & 1479 // Fall back to old method of index-based association if we could not find a match based on the mesh names

Are you now saying that there is compulsory naming scheme, so that there is no fallback, and huge numbers of existing collada files will be rendered useless?

Also, the release notes for the viewer version in question say...

"LODs and Physics reps can now be explicitly associated with a given mesh in the full LOD model using name-based matching."

This says "can" not "must". If it's to be the latter, it needs to be changed.

"By properly naming the meshes in your lower LOD meshes and physics reps, you can avoid issues with ordering of the meshes within your DCC tool and other material mismatching errors."

Where is "properly naming" defined? Other than the source code ... is it perhaps the suffixes "_LOD2", "_LOD1", "_LOD0", "LOD_PHYS"?* If so, that is overly restrictive. For example, any suffix should do, since the LOD is defined by the uploader slot the file is selected into and does not therefore have to be specified by the suffix. Perhaps best would be a minimum length unique match, so that a suffix on the high LOD would not prevent matching.

In any case, if there are problems with the names I used, it remains the case that the observed behaviour is unacceptable. There is no possible rational argument for substituting the effect of "Use LOD above" for the obvious intention of using something from the chosen file. Instead, the choice should revert to its previous state and an informative error message should be generated. Telling the user to look in the log file may be acceptable for debugging, but surely not for normal use.

*I guess I will have to try this when I have a chance.

ETA: The first of the quoted source code comments would seem to indicate that the corresponding meshes in each LOD have to have the same name. If that is the case, that is a major inconvenience - for example, if you keep all your LOD models in the same Blender file, which is the most efficient way to make them, they cannot have the same names. So you are forced to rename them every time you export them, then rename them back again after exporting.

[sl-service-account]

Drongle McMahon commented at 2015-03-19T03:40:41Z

Tested (1) after renaming all files so that the mesh names (and IDs) were the same in all of them. (2) after adding the suffixes from the source code, _LOD2, _LOD1, _LOD0 to names & IDs in medium, low and lowest LOD files respectively. This had no effect on the unexpected behaviour originally reported. So neither of those naming schemes appears to be "correct".

[sl-service-account]

Kyle Linden commented at 2015-03-19T04:21:18Z

Hi Drongle,

Thank you for reviewing the new import method, your feedback is appreciated. The naming scheme is not clearly documented and we will need to address that before we move this viewer beyond the project stage. Regarding the naming scheme, here is what I did to make your models upload and behave as you expected.

• Load each model in your preferred 3d modeling program
• Rename the 6 sided cylinder model "cylinder" and export as collada file.
• Rename the 5 sided cylinder model "cylinder_LOD2" and export as collada file.
• Rename the 4 sided cylinder model "cylinder_LOD1" and export as collada file.
• Rename the 3 sided cylinder model "cylinder_LOD0" and export as collada file.
• If you had a physics model you would name it "cylinder_PHYS"

File names remained the same.

The 'fallback' method does work but is now much more strict about model and material relationships.

Please let me know if you have any other feedback.

Thank you!

[sl-service-account]

Drongle McMahon commented at 2015-03-19T08:57:05Z, updated at 2015-03-19T09:07:58Z

Kyle. Thank you for your prompt reply.

Unfortunately that doesn't work when I do it. Before my previous comment, I had tested renaming them by editing the collada file, as the comment indicated. I have now done the same renaming them in Blender, as you instructed. It still didn't work properly. In the Blender exporter, the name and ID are not the same, and I don't know which the viewer prefers to use. Also I don't know where it takes the name from.

Blender names the tags for object "cylinder_LOD0" as and the node in the as . As they are, the node name or ID would be consistent with you instructions, as would the geometry name, but not the geometry ID. So, in case the viewer is using the geometry ID, I edited the collada files to remove the Blender-generated suffix "-mesh" throughout the files. They still didn't work. They still behaved as described in the report.

I will upload the files here. They are called mcylXrenb.dae for the unaltered Blender exports, and mcylXrenbx for those edited to remove the suffix, where X is the number of cylinder sides. It might be helpful if you could upload the files you obtained after renaming, so that we can inspect them for differences. May I also be so bold as to ask whether you did check the triangle and vertex counts in the uploader during the upload, and/or whether you inspected the actual uploaded LOD meshes (e.g. by dialing in low values of renderVolumeLODFactor with a prim cylinder beside the mesh to check the switch). Simply completing an upload without those checks does not test for the unexpected behaviour, as the upload proceeds to completion, but with the wrong model in each slot.

[sl-service-account]

Drongle McMahon commented at 2015-03-19T20:22:30Z

Here is an extract of the log file obtained with ImporterDebug on when uploading the LODs mcylXrenb.dae, putting them in order into slots high, medium,low, lowest. These have the specified naming scheme, "cylinder" in the high LOD (X=6) and "cylinder_LOD1" for the low LOD (LOD1) etc., for names and IDs of and tags. From this and the accompanying notes it appears that the uploader is appending "_1" or "_0" to the names from the file, and that this is probably preventing the name matching. It is also evident that the code that generates the fallback messages is doing the incorrect substitution of the LOD models when the name matching fails.

Notes: Uploading mcyl6renbx.dae, with mcyl5renbx.dae, mcyl4renbx.dae, mcyl3renbx.dae in medium, low and lowest slots. This is after specifying the low LOD (LOD1) file. Line 04: the names and IDs of and in this file are all "cylinder_LOD1", but the uploader appears to have appended "_0" Line 05: names & IDs in the high LOD file (mcyl6renbx.dae) are all "cylinder", but the uploader similarly appended "_1", and that remains here in the names searched for, so that there will never be a match. Line 09: at thispoint, the low LOD (LOD1) is the auto generated low LOD, cyclinder_1_LOD1 Line 13: the medium LOD (LOD2) is already incorrectly filled with the high LOD mesh (38 verts). Line 25: here is the fallback for the medium LOD (LOD2), but it uses the high LOD name/mesh "cylinder_1" Line 26: now the fallback with the low LOD (LOD1) uses the high LOD too (from where?) Line 27: but the lowest stays with it's previous name/mesh, as From File hasn't been done with it yet. Line 32: so now the low LOD (LOD1) is using the hiugh LOD mesh too (38 verts)

01   2015-03-19T19:09:39Z INFO: LLDAELoader::OpenFile: Collada Importer Version: 1.4.1
02   2015-03-19T19:09:39   Z INFO: LLDAELoader::OpenFile: Dae version 1.4.1
03   2015-03-19T19:09:39Z INFO: LLDAELoader::OpenFile: Importing cylinder_LOD1_0
04   2015-03-19T19:09:39Z INFO: LLDAELoader::OpenFile: cylinder_LOD1_0 references mat-material
05   2015-03-19T19:09:39Z INFO: LLModelPreview::updateStatusMessages: Instance cylinder_1_LOD0 LOD 0 Verts: 6
06   2015-03-19T19:09:39Z INFO: LLModelPreview::updateStatusMessages: Instance cylinder_1_LOD0 LOD 0 Tris:  2
07   2015-03-19T19:09:39Z INFO: LLModelPreview::updateStatusMessages: Instance cylinder_1_LOD0 LOD 0 Faces: 1
08   2015-03-19T19:09:39Z INFO: LLModelPreview::updateStatusMessages: Instance cylinder_1_LOD0 LOD 0 Material mat-material
09   2015-03-19T19:09:39Z INFO: LLModelPreview::updateStatusMessages: Instance cylinder_1_LOD1 LOD 1 Verts: 6
10   2015-03-19T19:09:39Z INFO: LLModelPreview::updateStatusMessages: Instance cylinder_1_LOD1 LOD 1 Tris:  2
11   2015-03-19T19:09:39Z INFO: LLModelPreview::updateStatusMessages: Instance cylinder_1_LOD1 LOD 1 Faces: 1
12   2015-03-19T19:09:39Z INFO: LLModelPreview::updateStatusMessages: Instance cylinder_1_LOD1 LOD 1 Material mat-material
13   2015-03-19T19:09:39Z INFO: LLModelPreview::updateStatusMessages: Instance cylinder_1 LOD 2 Verts: 38
14   2015-03-19T19:09:39Z INFO: LLModelPreview::updateStatusMessages: Instance cylinder_1 LOD 2 Tris:  24
15   2015-03-19T19:09:39Z INFO: LLModelPreview::updateStatusMessages: Instance cylinder_1 LOD 2 Faces: 1
16   2015-03-19T19:09:39Z INFO: LLModelPreview::updateStatusMessages: Instance cylinder_1 LOD 2 Material mat-material
17   2015-03-19T19:09:39Z INFO: LLModelPreview::updateStatusMessages: Instance cylinder_1 LOD 3 Verts: 38
18   2015-03-19T19:09:39Z INFO: LLModelPreview::updateStatusMessages: Instance cylinder_1 LOD 3 Tris:  24
19   2015-03-19T19:09:39Z INFO: LLModelPreview::updateStatusMessages: Instance cylinder_1 LOD 3 Faces: 1
20   2015-03-19T19:09:39Z INFO: LLModelPreview::updateStatusMessages: Instance cylinder_1 LOD 3 Material mat-material
21   2015-03-19T19:09:39Z INFO: LLModelPreview::rebuildUploadData: Falling back to model index 0 for LOD 4 of cylinder_1
22   2015-03-19T19:09:39Z INFO: LLModelPreview::rebuildUploadData: List of models for LOD 4 did not include index 0
23   2015-03-19T19:09:39Z INFO: LLModelPreview::rebuildUploadData: Assigning LOD3 for cylinder_1 to found match cylinder_1
24   2015-03-19T19:09:39Z INFO: LLModelPreview::rebuildUploadData: Falling back LOD2 for cylinder_1 to found cylinder_1
26   2015-03-19T19:09:39Z INFO: LLModelPreview::rebuildUploadData: Falling back LOD1 for cylinder_1 to found cylinder_1
27   2015-03-19T19:09:39Z INFO: LLModelPreview::rebuildUploadData: Assigning LOD0 for cylinder_1 to found match cylinder_1_LOD0
28   2015-03-19T19:09:39Z INFO: LLModelPreview::updateStatusMessages: Instance cylinder_1_LOD0 LOD 0 Verts: 6
29   2015-03-19T19:09:39Z INFO: LLModelPreview::updateStatusMessages: Instance cylinder_1_LOD0 LOD 0 Tris:  2
30   2015-03-19T19:09:39Z INFO: LLModelPreview::updateStatusMessages: Instance cylinder_1_LOD0 LOD 0 Faces: 1
31   2015-03-19T19:09:39Z INFO: LLModelPreview::updateStatusMessages: Instance cylinder_1_LOD0 LOD 0 Material mat-material
32   2015-03-19T19:09:39Z INFO: LLModelPreview::updateStatusMessages: Instance cylinder_1 LOD 1 Verts: 38
33   2015-03-19T19:09:39Z INFO: LLModelPreview::updateStatusMessages: Instance cylinder_1 LOD 1 Tris:  24
34   2015-03-19T19:09:39Z INFO: LLModelPreview::updateStatusMessages: Instance cylinder_1 LOD 1 Faces: 1
35   2015-03-19T19:09:39Z INFO: LLModelPreview::updateStatusMessages: Instance cylinder_1 LOD 1 Material mat-material
36   2015-03-19T19:09:39Z INFO: LLModelPreview::updateStatusMessages: Instance cylinder_1 LOD 2 Verts: 38
37   2015-03-19T19:09:39Z INFO: LLModelPreview::updateStatusMessages: Instance cylinder_1 LOD 2 Tris:  24
38   2015-03-19T19:09:39Z INFO: LLModelPreview::updateStatusMessages: Instance cylinder_1 LOD 2 Faces: 1
39   2015-03-19T19:09:39Z INFO: LLModelPreview::updateStatusMessages: Instance cylinder_1 LOD 2 Material mat-material
40   2015-03-19T19:09:39Z INFO: LLModelPreview::updateStatusMessages: Instance cylinder_1 LOD 3 Verts: 38
41   2015-03-19T19:09:39Z INFO: LLModelPreview::updateStatusMessages: Instance cylinder_1 LOD 3 Tris:  24
42   2015-03-19T19:09:39Z INFO: LLModelPreview::updateStatusMessages: Instance cylinder_1 LOD 3 Faces: 1
43   2015-03-19T19:09:39Z INFO: LLModelPreview::updateStatusMessages: Instance cylinder_1 LOD 3 Material mat-material
44   2015-03-19T19:09:39Z INFO: LLModelPreview::updateStatusMessages: Instance cylinder_1_LOD0 LOD 0 Verts: 6
45   2015-03-19T19:09:39Z INFO: LLModelPreview::updateStatusMessages: Instance cylinder_1_LOD0 LOD 0 Tris:  2
46   2015-03-19T19:09:39Z INFO: LLModelPreview::updateStatusMessages: Instance cylinder_1_LOD0 LOD 0 Faces: 1
47   2015-03-19T19:09:39Z INFO: LLModelPreview::updateStatusMessages: Instance cylinder_1_LOD0 LOD 0 Material mat-material
48   2015-03-19T19:09:39Z INFO: LLModelPreview::updateStatusMessages: Instance cylinder_1 LOD 1 Verts: 38
49   2015-03-19T19:09:39Z INFO: LLModelPreview::updateStatusMessages: Instance cylinder_1 LOD 1 Tris:  24
50   2015-03-19T19:09:39Z INFO: LLModelPreview::updateStatusMessages: Instance cylinder_1 LOD 1 Faces: 1
51   2015-03-19T19:09:39Z INFO: LLModelPreview::updateStatusMessages: Instance cylinder_1 LOD 1 Material mat-material
52   2015-03-19T19:09:39Z INFO: LLModelPreview::updateStatusMessages: Instance cylinder_1 LOD 2 Verts: 38
53   2015-03-19T19:09:39Z INFO: LLModelPreview::updateStatusMessages: Instance cylinder_1 LOD 2 Tris:  24
54   2015-03-19T19:09:39Z INFO: LLModelPreview::updateStatusMessages: Instance cylinder_1 LOD 2 Faces: 1
55   2015-03-19T19:09:39Z INFO: LLModelPreview::updateStatusMessages: Instance cylinder_1 LOD 2 Material mat-material
56   2015-03-19T19:09:39Z INFO: LLModelPreview::updateStatusMessages: Instance cylinder_1 LOD 3 Verts: 38
57   2015-03-19T19:09:39Z INFO: LLModelPreview::updateStatusMessages: Instance cylinder_1 LOD 3 Tris:  24
58   2015-03-19T19:09:39Z INFO: LLModelPreview::updateStatusMessages: Instance cylinder_1 LOD 3 Faces: 1
59   2015-03-19T19:09:39Z INFO: LLModelPreview::updateStatusMessages: Instance cylinder_1 LOD 3 Material mat-material

[sl-service-account]

Kyle Linden commented at 2015-03-20T03:44:01Z

Hi Drongle,

I will need to review your newly uploaded models and see if I can import them myself. In theory you did the right things but it still failed. This has me puzzled and I'll have to investigate further.

Thank you,

[sl-service-account]

Drongle McMahon commented at 2015-03-22T11:34:24Z, updated at 2015-03-24T11:52:14Z

I think I may have found where these problems are coming from...

LLDAELoader::OpenFile and LLFloaterModelPreview::rebuildUploadData both use LLDAELoader::getElementLabel to find the name of each object being uploaded in a file. OpenFile starts looking in the tag, but rebuildUploadData starts looking in the tag (all via the dom library).

GetElementLabel tries first to use the name attribute, and then the ID attribute of the tag. If it doesn't find either, then it looks in the parent tag. The tag is not allowed name or ID attributes. So it always has to look in the parent, which is . The tag can have both name and ID attributes, but does not have to. If it doesn't, getElementLabel has to look in its parent, which will normally be .

When it takes the name or ID from the parent tag, getElementLabel adds an index to the name to distinguish sibling children of parents with multiple relevant child tags. This is added as a string "_X", where "X" is the zero-based index. If the name from the attribute has one of the pre-defined LOD suffixes, containing the substring "_LOD", then it is supposed to insert the added index immediately in front of that substring. Otherwise, it appends it to the end of the attribute name.

OpenFile puts a messgae in the log giving its version of each object name it is importing. It does this with the names derived from the tag. However, it then calls ProcessElement on the scene, which recursively iterates through all the tags and replaces the derived name with the name derived from

. When a file is first opened, the lower LOD slots contain the auto-generated LOD meshes, which are given names consisting of the high LOD mesh names with the pre-defined LOD suffixes "_LODX". LLFloaterModelPreview::rebuildUploadData contains the code that makes the associations betweeen models in different LODs based on their names. At this stage, the models have the names derived from their tags. For each LOD, the expected name is constructed from the name of the high LOD model with the pre-defined LOD suffix "_LODX" appended. First, that is searched for in the data loaded in the corresponding LOD slot. If it is found (and ImporterDebug is on), a message is output saying it is "Assigning" the model, with the names of the model and the corresponding high LOD model. If the expected name is not found, then it looks in successively higher LOD data, for a name constructed with the LOD suffix of the searched LOD, not that of the LOD where data being sought. If that is found, then it is used in the lower LOD slot, and a message is produced describing "Falling back" to that data. If this search of the higher LODs yields nothing, then the reversion to the old index-based association is supposed to happen. Here is the first problem. Since the original names of the generated LOD meshes were produced to be exactly the same as the expected names searched for in the higher LODs, doing this search guarantees that they will be found. So the subsequent code, which is supposed to implement the old index-based associations, will never bu invoked. That intention is therefore thwarted by the search of the higher LODs. My view is that this step should be abandoned. Using load-from-file in a LOD slot clearly indicates that use of the LOD above is not the intention, but as it is, using legacy files that used to work with index-based association, now fails with the obviously unwanted use of the LOD above. For reasons given below, where the name matching fails for other reasons, this is also affecting files using the new naming scheme with LOD suffixes. To investigate these problems, I used the following files, with different (and all legal) name (and ID) attributes in the relevant tags... mcyl6renbx_x: , , ; 6-sided 24 tris mcyl5renbx_x: , , ; 5-sided 20 tris mcyl6renbx_xy: , , , , tags cannot have a name. So here getElementLabel has to use the sibling index. This is always zero. So with mcyl6renbx_x, the name "cylinder_geom_0" is as expected, with the index appended. For mcyl5renbx_x, the index should be inserted. So the name should be "cylinder_geom_0_LOD2". Instead it is "cylinder_geom_LOD2_0". The index has been appended instead of being inserted. If getElementLabel makes the same mistake with the name from , then the result, "cylinder_ig_LOD2_1" would not match the expected name "cylinder_ig_1_LOD2". That would explain the failure and the consequent fallback to the higher LOD mesh. I can't immediately see why getElementLabel fails in this way. log extracts... // open mcyl6renbx_xy, ... LLDAELoader::OpenFile: Importing cylinder_geom_0 LLDAELoader::OpenFile: cylinder_geom_0 references mat-material ... LLModelPreview::rebuildUploadData: Assigning LOD3 for cylinder_ig to found match cylinder_ig LLModelPreview::rebuildUploadData: Assigning LOD2 for cylinder_ig to found match cylinder_ig_LOD2 LLModelPreview::rebuildUploadData: Assigning LOD1 for cylinder_ig to found match cylinder_ig_LOD1 LLModelPreview::rebuildUploadData: Assigning LOD0 for cylinder_ig to found match cylinder_ig_LOD0 ... LLModelPreview::updateStatusMessages: Instance cylinder_ig_LOD0 LOD 0 Tris: 2 ... LLModelPreview::updateStatusMessages: Instance cylinder_ig_LOD1 LOD 1 Tris: 2 ... LLModelPreview::updateStatusMessages: Instance cylinder_ig_LOD2 LOD 2 Tris: 6 ... LLModelPreview::updateStatusMessages: Instance cylinder_ig LOD 3 Tris: 24 ... ... // enter mcyl5renbx_xy, , into lod2 slot ... LLDAELoader::OpenFile: Importing cylinder_geom_LOD2_0 LLDAELoader::OpenFile: cylinder_geom_LOD2_0 references mat-material ... LLModelPreview::rebuildUploadData: Assigning LOD3 for cylinder_ig to found match cylinder_ig LLModelPreview::rebuildUploadData: Assigning LOD2 for cylinder_ig to found match cylinder_ig_LOD2 LLModelPreview::rebuildUploadData: Assigning LOD1 for cylinder_ig to found match cylinder_ig_LOD1 LLModelPreview::rebuildUploadData: Assigning LOD0 for cylinder_ig to found match cylinder_ig_LOD0 ... LLModelPreview::updateStatusMessages: Instance cylinder_ig_LOD0 LOD 0 Tris: 2 ... LLModelPreview::updateStatusMessages: Instance cylinder_ig_LOD1 LOD 1 Tris: 2 ... LLModelPreview::updateStatusMessages: Instance cylinder_ig_LOD2 LOD 2 Tris: 20 ... LLModelPreview::updateStatusMessages: Instance cylinder_ig LOD 3 Tris: 24 // open mcyl6renbx_x, no name in , ... LLDAELoader::OpenFile: Importing cylinder_geom_0 LLDAELoader::OpenFile: cylinder_geom_0 references mat-material ... LLModelPreview::rebuildUploadData: Assigning LOD3 for cylinder_node_1 to found match cylinder_node_1 LLModelPreview::rebuildUploadData: Assigning LOD2 for cylinder_node_1 to found match cylinder_node_1_LOD2 LLModelPreview::rebuildUploadData: Assigning LOD1 for cylinder_node_1 to found match cylinder_node_1_LOD1 LLModelPreview::rebuildUploadData: Assigning LOD0 for cylinder_node_1 to found match cylinder_node_1_LOD0 ... LLModelPreview::updateStatusMessages: Instance cylinder_node_1_LOD0 LOD 0 Tris: 2 ... LLModelPreview::updateStatusMessages: Instance cylinder_node_1_LOD1 LOD 1 Tris: 2 ... LLModelPreview::updateStatusMessages: Instance cylinder_node_1_LOD2 LOD 2 Tris: 6 ... LLModelPreview::updateStatusMessages: Instance cylinder_node_1 LOD 3 Tris: 24 ... // enter mycl5renbx_x, no name in , ... LLDAELoader::OpenFile: Importing cylinder_geom_LOD2_0 LLDAELoader::OpenFile: cylinder_geom_LOD2_0 references mat-material ... LLModelPreview::rebuildUploadData: Assigning LOD3 for cylinder_node_1 to found match cylinder_node_1 LLModelPreview::rebuildUploadData: Falling back LOD2 for cylinder_node_1 to found cylinder_node_1 LLModelPreview::rebuildUploadData: Assigning LOD1 for cylinder_node_1 to found match cylinder_node_1_LOD1 LLModelPreview::rebuildUploadData: Assigning LOD0 for cylinder_node_1 to found match cylinder_node_1_LOD0 ... LLModelPreview::updateStatusMessages: Instance cylinder_node_1_LOD0 LOD 0 Tris: 2 ... LLModelPreview::updateStatusMessages: Instance cylinder_node_1_LOD1 LOD 1 Tris: 2 ... LLModelPreview::updateStatusMessages: Instance cylinder_node_1 LOD 2 Tris: 24 ... LLModelPreview::updateStatusMessages: Instance cylinder_node_1 LOD 3 Tris: 24

[sl-service-account]

Drongle McMahon commented at 2015-03-23T19:29:15Z, updated at 2015-03-25T20:04:14Z

Another thought - getElementLabel could look at the url attribute of as a third option if name and ID are not found, removing the leading "#". That would avoid having to look at the parent . I think the url is a required attribute, so that should always work.

Furthermore, if it used the url (-#) as the preferred option, and used the ID as the second option, then I think it would necessarily get the same name for the calls from OpenFile and from rebuildUploadData, because the url in is the ID of the referenced with "#" prepended, and both have to be there for the reference to work. In the Blender exporter, these are all the object name anyway. I suppose other software might use an inappropriate ID. It might be odd if the url was an external reference, but I don't imagine the uploader can handle that anyway, can it? Or does the collada library sort that out anyway?

[sl-service-account]

Kyle Linden commented at 2015-03-27T16:47:29Z

Hi Drongle,

Thank you for the updated information and your investigation results. It was helpful and appreciated.

Thanks!

[sl-service-account]

Kyle Linden commented at 2015-03-27T22:51:06Z

Hi Drongle,

It turns out this is already fixed! Will you please confirm this is working as expected with the following build.

http://automated-builds-secondlife-com.s3.amazonaws.com/hg/repo/viewer-loader-mods_viewer-loader-mods/rev/299459/arch/CYGWIN/installer/Second_Life_Project_Importer_3_7_26_299459_i686_Setup.exe

Thank you

[sl-service-account]

Drongle McMahon commented at 2015-03-29T02:15:12Z

I would say no, it is not fixed. In one respect it is, because the sibling index is now inserted in the right place. That does let it work as intended in the case that the "correct" naming convention is used.

However, if it is not used, (a) the result is not the intended fallback to the old index-based method. Instead, (b) the uploader gives an incorrect error message "Material of model is not a subset of reference model", when in the test case two files do use the same material (and material name). This blocks upload by disabling the calculate button. (c) the log file gives a different message, saying the offending model was not used, which is true. (d) Instead of restoring the previous state, it still uses the next higher LOD instead, which is clearly not the intended result, and not useful because the upload is blocked anyway.

This still leaves all existing LOD files unusable (except where anyone just happens ton have used the new naming convention that they could not have anticipated) because the fallback to indexed method does not happen. I would anticipate that users would find that unacceptable.

The test files I used are qcyl6.dae (high LOD), qcyl5_lod2uc.dae (medium LOD consistent with new naming convention) and qcyl5.dae (medium LOD, not consistent).

By the way, the "LOD2" etc appear to be case sensitive. At the very least, please make it case insensitive. Preferably, make it accept other conventions, such as "_me*", "_lo$" etc etc., or best of all, use a fuzzy or partial matching algorithm and accept it whenever it's non-ambiguous.

In the case of files that only have one object (about 99% of my files), why impose anything at all? There cannot be any ambiguity in those cases. So insisting on a naming convention there, and disabling so many existing files, is then a completely unnecessary burden. Skipping the tests when the object count is 1 should be trivial to code. (Of course it wouldn't be necessary if the fallback to indexed method worked). More difficult when objects are split by > 8 materials, but that's a new thing anyway, so that no working legacy files would be affected.

[sl-service-account]

Kyle Linden commented at 2015-04-07T17:15:48Z

Hi Drongle,

Thank you for the feedback. I have shared this with the team.

Keep an eye out for a new Project Viewer soon.

Thanks again for your efforts.