Sorting failure between LOD sets and Physics

[Rick Nightingale]

This one has me well stumped...

I have a build, that I've narrowed down to these five meshes after the sorting trouble started:

• Door_Frame.L3
• Door_Lower_Left.L3
• Door_Lower_Right.L3
• Door_Upper_Left.L3
• Door_Upper_Right.L3

The Physics models are named similarly but ending .PHYS instead of .L3. The mesh names and object names are identical. I've checked the spelling (at least 50 times) and repeatedly counted and checked the models in each set. I export the sets as Model.dae and Model_PHYS.dae.

If I upload all the set as above, the Frame physics gets applied to the Lower Left door, the Lower Left door's physics gets applied to the Lower Right door... and it all goes pear shaped. With the full build, everything after the above items ends up with the wrong physics model.

If I leave out the frame from both LOD3 and Physics sets, the four doors get the right physics. If I export the frame and the upper two doors, that works. My physics models are fine, the mesh is fine, everything checks out perfectly individually.

However, as soon as I have the Frame and a Lower door in the export, with or without anything else, it fails and attaches the Frame's physics to whichever the Lower door is there; Left if both are.

Any clues, anyone? I'm close to tearing my hair out here. I've been fighting with this for three hours now!

ETA: There are no scale offsets or rotations, nothing like that. It's simply failing to sort from what I can tell. Also, it's only the physics set which is suffering this; the four LOD models (which are all named in the above format) work as expected.

Edited March 27, 2023 by Rick Nightingale

[EnCore Mayne]

 

[Rick Nightingale]

@EnCore Mayne In my experience the root is always random on multipart uploads. I've read that it's supposed to be in some sort of order, but never, ever have I seen anything other than random root selection. I would love to know what the 'logic' behind that is.

Back to my issue... I have solved it, but not asnwered the big question: Why???

This is a screenshot of the two model lists, just to prove that they are named as I said. The data objects are named identically to the mesh, just in case:

If anyone can spot a mistake in the above, that I haven't in checking it until I'm almost blind, I'll eat my hat.

Now... to fix the issue, I renamed all the highlighted parts to Fred[n]. So, Fred1.PHYS, Fred1.L3, Fred2.PHYS, Fred2.L3, etc, working down the two lists. Suddenly everything worked when I uploaded it to SL.

So... it seems the Mesh Uploader (because Blender has no clue that the physics model is different, only the uploader treats it differently) can't sort Door_Frame and Door_Lower_xxxx in the physics model. I've never had such an issue before.

ETA: I would try to get an independent repro (different design, different PC, LL viewer, same names) and start a JIRA but I just want to get my work done for once.

 

Edited March 27, 2023 by Rick Nightingale

[Rick Nightingale]

It's the underscores I think. I just renamed the physics names to remove the underscores (from the original name list, not Fred, and I left the L3 names with the underscores in, it still sorts in the same order) and it worked.

Edited March 27, 2023 by Rick Nightingale

[Wulfie Reanimator]

1 hour ago, Rick Nightingale said:

In my experience the root is always random on multipart uploads. I've read that it's supposed to be in some sort of order, but never, ever have I seen anything other than random root selection. I would love to know what the 'logic' behind that is.

It was explained in that thread that there is no logic for it. It's not deterministic. The order will be whatever happens by chance in your RAM.

SL-faces are ordered by alphabetical name of the materials in Blender. LODs with matching names are also handled properly by the uploader.

Edited March 27, 2023 by Wulfie Reanimator

[Rick Nightingale]

@Wulfie Reanimator Yeah, I just read that one. At least now I know, lol. Relinking it is hardly a problem though

Unlike having to rename 300 parts in Blender to remove underscores! My fingers hurt.

Edited March 27, 2023 by Rick Nightingale

[arton Rotaru]

The naming convention for uploading multi part dae is as follows.

Frame
Frame_LOD2
Frame_LOD1
Frame_LOD0
Frame_PHYS

Door
Door_LOD2
Door_LOD1
Door_LOD0
Door_PHYS

Applying the same convention to the dae files as well, will load the files in their appropriate slots automatically.

[Rick Nightingale]

Ahh... I knew about naming the .dae files like that to get them auto-selected in the uploader when I load the main file as a convenience. I didn't know that it also applied to the names of the mesh objects within the file. I always thought the different LOD files' meshes were just matched up by alphabetic sorting anyway.

Renaming the objects from my original names before exporting to replace "'.PHYS" with "_PHYS" and removing the ".L3" from the LOD3 model names did indeed work; the physics models were applied in the correct order.

It remains though that I've never had to name my mesh objects with the _LODn suffix to upload them before, and I've done a lot of big linksets like that.

They have always been matched by sorting alphabetically, even if given different names as long as they sort in the same order. And why just the physics models being mismatched? All the LOD objects were matched together, but not the physics. I do think there is some odd behaviour in the difference between sorting the visible mesh objects and the physics objects - well, what I've done shows there is. Perhaps the uploader, looking for the "_" suffix is being confused by the other "_" characters in the object names? It seems the case since just removing all underscores from my original names and leaving my ".L3", ".L2", ".PHYS" suffixes* etc. as they were worked perfectly with 50+ objects in each set. With the underscores in, they were scrambled even though they sorted alphabetically identically. The only thing I've done differently in this project is to use a lot of underscores in the names; I usually use periods. Don't know why I changed really but I wish I hadn't.

Whatever... there's a funny issue there but since I know not to provoke it now, I'll not do so (as the doctor said, if it hurts when you poke it, don't poke it.)

*That's just the way I've named them since long before the _LODn suffix for filenames came along, but I will change to _LODn in the objects names from now on, just to avoid this odd sorting issue... along with avoiding any other underscores in the name,

 

Edited March 27, 2023 by Rick Nightingale