Drongle McMahon Posted October 21, 2015 Share Posted October 21, 2015 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. Link to comment Share on other sites More sharing options...
arton Rotaru Posted October 21, 2015 Share Posted October 21, 2015 Same "_0" suffix with exports from 3DS Max. Link to comment Share on other sites More sharing options...
Drongle McMahon Posted October 21, 2015 Author Share Posted October 21, 2015 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: Link to comment Share on other sites More sharing options...
arton Rotaru Posted October 22, 2015 Share Posted October 22, 2015 You're welcome! Actually I haven't even noticed the change in the mesh naming, because I barely name my meshes in Max. Since the export order were achieved by another method than naming conventions. :matte-motes-not-entertained: Though, that method of linking/unlinking doesn't work anymore with the current release viewer. No matter the ImporterLegacyMatching is True, or False, as you pointed out in the other thread. So there seems to be a good chance that my old files are broken, unless I fix the names.:matte-motes-impatient: There is also an issue with Material names with the current viewer. Max default names for materials are "Material #35" or something like that. With a space in the name. Which worked with no problem before. With the current viewer, material names are truncated when they contain spaces. The mesh uploads just fine, no error message. The mesh in-world will be broken though. Whirly was so kind and filed a Jira about it for me. Turned out there was an internal issue about it already. So I hope that's a bug, and not an intentional change, as well. Or I will have to rename each material as well....:matte-motes-bored: Link to comment Share on other sites More sharing options...
Whirly Fizzle Posted October 22, 2015 Share Posted October 22, 2015 arton Rotaru wrote: Whirly was so kind and filed a Jira about it for me. Turned out there was an internal issue about it already. So I hope that's a bug, and not an intentional change, as well. Or I will have to rename each material as well....:matte-motes-bored: There is a fix for that lurking upstream Arton. https://bitbucket.org/lindenlab/viewer-loader-mods/pull-requests/3/maint-5678-fixed-materials-with-spaces-in/diff#comment-None Link to comment Share on other sites More sharing options...
Drongle McMahon Posted October 22, 2015 Author Share Posted October 22, 2015 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). Link to comment Share on other sites More sharing options...
Whirly Fizzle Posted October 22, 2015 Share Posted October 22, 2015 Drongle, the JIRA issue I filed for Arton's bug is https://jira.secondlife.com/browse/BUG-10434 That issue was closed as a duplicate of an internal issue - MAINT-5678 Link to comment Share on other sites More sharing options...
Drongle McMahon Posted October 22, 2015 Author Share Posted October 22, 2015 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. Link to comment Share on other sites More sharing options...
Whirly Fizzle Posted October 22, 2015 Share Posted October 22, 2015 I have no idea I'm afraid, I can't read code. I can however build that viewer and let you know if it fixes Arton's bug Stay tuned... Link to comment Share on other sites More sharing options...
arton Rotaru Posted October 22, 2015 Share Posted October 22, 2015 Whirly Fizzle wrote: There is a fix for that lurking upstream Arton. https://bitbucket.org/lindenlab/viewer-loader-mods/pull-requests/3/maint-5678-fixed-materials-with-spaces-in/diff#comment-None Thanks! :matte-motes-smile: At least it's being worked on. :matte-motes-nerdy: Link to comment Share on other sites More sharing options...
Whirly Fizzle Posted October 22, 2015 Share Posted October 22, 2015 Oh well damn. I built that repo but of course self compiles of the LL viewer wont allow any mesh imports at all without some jiggery pokery which is beyond my knowledge, so I can't test it. Link to comment Share on other sites More sharing options...
Drongle McMahon Posted October 22, 2015 Author Share Posted October 22, 2015 Oh dear. Thanks for trying. Sorry to have led you into fruitless work. :matte-motes-frown: Link to comment Share on other sites More sharing options...
Recommended Posts
Please take a moment to consider if this thread is worth bumping.
Please sign in to comment
You will be able to leave a comment after signing in
Sign In Now