Jump to content

Default uploaded object names


Drongle McMahon
 Share

You are about to reply to a thread that has been inactive for 3080 days.

Please take a moment to consider if this thread is worth bumping.

Recommended Posts

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

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


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

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

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

You are about to reply to a thread that has been inactive for 3080 days.

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
 Share

×
×
  • Create New...