Unnecessary pain points in the mesh uploader

[animats]

A few things the mesh uploader ought to do better:

BUGS

• If you upload multiple objects, you get a link set in SL. The root prim is random. Really random; you can upload the same .DAE file twice and get different link order. That's a silly bug.
• If you upload textures with a mesh, apparently the textures don't get uploaded. Another silly bug. It's a documented feature with a checkbox in the uploader. Should be fixed or removed.
• If you upload multiple levels of detail, the documentation says the materials of the lower levels of detail must be a subset of the higher levels. In practice, they have to be exactly the same. (Except when you use a "generated" level of detail - those can have fewer prims than materials and still work, so the server doesn't really require all the materials be used.) The rules ought to be simply that you can't have more than 8 materials over all the levels of detail. Any missing parts can be filled in with "No Geometry" mesh level of detail blocks. This would make creating lower levels of detail by hand or by script less of a pain.

PROPOSED FEATURE - SINGLE FILE UPLOAD

It should be possible to upload all the levels of detail from one file. The current naming convention for meshes provides enough info to do this.

If an upload contains at least one mesh named  "example" and "example_LOD2", then it's a multi-LOD upload. This should work as follows.

• Mesh names "example", "example_LOD2", "example_LOD3", "example_LOD4", and "example_PHYS" are the LODs of "example". This is how name matching works now, but you have to upload them in separate .DAE files.
• The first mesh alphabetically is the root prim. This is how it's supposed to work now, and used to work. Other prims should be ordered alphabetically, for consistency. Even if they're not sorted in the .DAE file.
• The center point of the linkset is from the root prim. All other links are relative to that.
• There is no stretching of lower LODs to fit the higher LODs in the same file. All LODs in a file are in the same coordinate system. So what you see in Blender is what you get in SL.
• Have a check that the bounding box of a lower LOD is not significantly outside the bounding box of a higher LOD, to prevent some obscure types of griefing. Allow maybe 5-10% oversize lower LODs;  beyond that, something is wrong. This replaces the current enforcement by stretching.

These are all pain points that have to be worked around by every mesh user now. These problems discourage user-created lower LODs. Or even ones created by scripts in Blender. Blender can do much better mesh reduction than the uploader can, but that feature is not used much, because the file setup is such a pain. With this setup, you copy each mesh to multiple "_LODx" objects, perhaps in a different layer. Then you run Blender's mesh reduction tools on them, and upload. A plug-in to automate that process would be straightforward. No worries about one of the reduced meshes not using some material.

You could also generate an impostor - a simple mesh with a picture of the full object rendered in Blender. You can do that now, but nobody does it, because it's a pain to add a dummy triangle to each higher level of detail to provide a dummy use of the impostor image.

User-created lower LODs are very rare in SL. I look for them, and find very few of them. I've created some, and it's a lot of trouble and prone to obscure upload errors. It shouldn't be that hard. It should Just Work.

Comments?

 

 

 

[Beq Janus]

Firstly, feature requests should go in Jiras, so once this thread runs the usual course and we filter the trolls and wastrels stuff this into a Jira or set of Jiras, I'm al;ways happy to consider ideas and will contribute back to SL from FS once implemented, but the best place to put this might be LL Jira in the first instance.

Taking your bugs in order.

* What should the root prim be? The problem is that the DAE format has no concept of Root prim and thus there is no marker. Any toolchain specific encoding/ordering cannot be guaranteed, the uploader has to work for Maya, Blender, 3DS, etc etc etc

They are read from an XML DOM there is no order guarantee I don't believe.

If there is a way that makes sense and can be consistently enforced without breaking people's current workflows then I am happy to look at it. See below though that I don't think alpha sorting is the answer.

* Texture upload works just fine. 

quick demo video https://i.gyazo.com/b6f284220b9039343f6ec34c661186d9.mp4

Result:

https://gyazo.com/91e0acf145bba8869a7c3fa0a049ab13

* I don't believe your assertion is correct, though I am willing to be convinced. A subset should be allowed, but the uploader would still need to create a placeholder I believe.
The internal mesh format requires the same number of slots. Each material is a separate drawable mesh, these are indexed into vector and thus If a mesh does not exist with at least one triangle in it then when the LOD switches the pipeline would have to deal with that. It doesn't.

That does not mean it can't, just that it is not a simple alteration in the current state of things and the gain probably does not warrant the invasiveness of such a change.

Feature request

The root prim be the first in alpha ranking? Really? That makes little sense to me. Given that the object name is named after the root prim. The last thing I need is all my objects being called AAA_Object 🙂, in a complex build that actually makes it very hard to achieve. That said I've never found it to be a problem switching the link order so my pain threshold is different.

What does the uploader do when the conglomeration of pieces is not linkable. I have frequently uploaded objects that are greater than the linkable range, it gives me a perfectly nice cluster of items. What behaviour would you expect here?

Making the centre relative to the root is a whole different ball game. There is already a long-awaited change to allow arbitrary pivots, there are a number of issues that arise from that.  IsIs the centre of the root prim going to be the new pivot? that is not a particularly useful state of affairs for people make single mesh items who have been waiting for the ability to define the pivot. Given the constraints that arise from the root of the object in terms of resolution it needs to be clear whether the pivot and the centre are the same thing (this is not of interest to linksets but may be important to single mesh)

I agree that there are a lot of ways this could be improved and I'm happy to have a go at some that make sense to me and others, but we have to be very careful too. Whenever I have made changes in the past there have been others that want it reverted. The majority use case for uploading meshes is not complex multipart objects with textures pre-loaded. Having said that "what is the typical upload use case?"

Beq

 

 

 

[Vir Linden]

Thanks for the comments! We currently have a project underway to improve some of the pain points with mesh upload. We could potentially tackle more things there, with a strong preference to anything that's well defined and limited in scope. As Beq says, the best way to get this kind of thing looked at is to file a JIRA; new bugs filed as feature requests get evaluated weekly.

 

[animats]

Beq has some good points. I have to go out; more later.

What I'm shooting for is: you make it in Blender or Maya, you upload, and you get what you made in SL. Little or no post-upload adjustments needed.

[OptimoMaximo]

1 hour ago, animats said:

What I'm shooting for is: you make it in Blender or Maya, you upload, and you get what you made in SL. Little or no post-upload adjustments needed.

I made a script for Maya that outputs a LSL script for reassembling builds' parts to circumvent a few painful drawbacks i was experiencing, at the time.

Essentially, the pains i'm referring to are: the inconsistent LoD generation of pieces when uploading files containing more meshes that end up linked together, and the Custom LoDs file generation with its naming convention was also another pain to me. So i opted for single pieces uploads that in both cases were less prone to give me headaches, either for possible mistakes in the LoDs naming conventions/other reasons (i got bad LoD/physics coupling in few istances where i was sure i did everything correctly) or to simply have the built in LoD generator do a more controlled job on the single pieces upon upload, as opposed to uploading a linkset. So i ended up writing a scripted solution that takes Maya's axis origin as the rezpoint and goes through my selection of objects in the viewport, outputting a standardized LSL script that would then reference all those objects names, positions and rotations relative to Maya's axis intersection at 0,0,0 coordinates, rez their inworld counterparts from a box and apply the transforms to them (via a dedicated script residing in the rezzed objects) relative to the box with absolute precision. It works fantastic for me and albeit being limited to 72 pieces per script (since the list is being filled already at initialization), i haven't found any reason yet to try and make a "limitless" selection or do a auto-linking for me.

What i try to convey here is that, since the nature of collada files and the uploader don't cater to your needs (as Beq explains above), nothing stops you from writing a utility script Blender/LSL that does a link order change for you automatically based on your Blender scene's selection of objects. Python is pretty powerful and has a lot of tools to very easily manage strings and arrays.

Sure thing the uploader might do a better job at naming the linked parts after their mesh counterparts in the collada files, instead of giving a name only to the root and defaulting everything else to "Object".

Custom Pivot points would be awesome, but i'm not holding my breath, waiting for it.

[OptimoMaximo]

5 hours ago, Beq Janus said:

* Texture upload works just fine. 

It doesn't when uploading a rigged object.

 

EDIT: or at least it never did so i stopped trying embedding media to the file, that is. If that was fixed and I'm unaware of that, my apologies.

Edited June 18, 2019 by OptimoMaximo

[Da5id Weatherwax]

2 hours ago, animats said:

What I'm shooting for is: you make it in Blender or Maya, you upload, and you get what you made in SL. Little or no post-upload adjustments needed.

There's a project I've been working on, on and off, for a while that is a part of this, although a bit OT for a thread in the uploader - to try and put together a set of blender nodes that come as close as possible to reproducing the shaders used in SL. The idea being that you could plug in your "3 textures" and get a reasonable representation in blender of what it will look like once uploaded and those textures applied. Getting "close enough to be in the same county" isn't hard, but getting it close enough to be anything approaching "right" is a lot harder, let alone achieving the ultimate goal of incorporating the other math to bring in the other parameters applied to  the SL rendering pipeline and the defaults with different graphics quality settings. I'll probably have another poke at it once 2.80 goes stable.

[Beq Janus]

3 minutes ago, Da5id Weatherwax said:

There's a project I've been working on, on and off, for a while that is a part of this, although a bit OT for a thread in the uploader - to try and put together a set of blender nodes that come as close as possible to reproducing the shaders used in SL. The idea being that you could plug in your "3 textures" and get a reasonable representation in blender of what it will look like once uploaded and those textures applied. Getting "close enough to be in the same county" isn't hard, but getting it close enough to be anything approaching "right" is a lot harder, let alone achieving the ultimate goal of incorporating the other math to bring in the other parameters applied to  the SL rendering pipeline and the defaults with different graphics quality settings. I'll probably have another poke at it once 2.80 goes stable.

I've tinkered a little with that, the principled BSDF should "in theory" get us some of the way if the PBR is explicitly avoided. splitting out and recombining is all doable. but the lighting is the hardest part I suspect.

1 hour ago, OptimoMaximo said:

Sure thing the uploader might do a better job at naming the linked parts after their mesh counterparts in the collada files, instead of giving a name only to the root and defaulting everything else to "Object".

There is a Jira for that. https://jira.secondlife.com/browse/BUG-202864

The fix is not as simple as I first thought. The viewer has the information available to it, and it is in fact saved but there is no space for it in the upload format requiring a protocol/format change. I've added my suggestion to Liz's jira. 

3 hours ago, animats said:

Beq has some good points. I have to go out; more later.

What I'm shooting for is: you make it in Blender or Maya, you upload, and you get what you made in SL. Little or no post-upload adjustments needed.

That is a far tighter integration than any game engine I know of, even more than Unity or UE. The problem you have is that none of those tools are "game asset designers" they are one part of a chain of tools. You may start in ZBrush, move to a retopology tool, create a normal map bake down from the high poly to the retopologised HIGH LOD model, you take that map and perhaps a colour map out into substance painter. You probably upload the mesh (sans textures) and then use the local texture feature of the viewer to tweak the exports from substance to get something that looks right in SL. The fact that the uploader supports "textures" is increasingly quaint when materials ought to be being used to try to keep the vertex monster in check.

Blender covers an increasingly large part of the spectrum well and for free and is probably far more common here in SL than in the wider "professional" market where Autodesk hold sway. (even more so if you only count the legitimately licensed versions of Autodesk products), I'd love to see Linden Lab as a corporate sponsor and perhaps get some directed effort towards shader and asset import limitations. (https://fund.blender.org/corporate-memberships/)

Related, but separate and on my wishlist, is having a materials asset type. which contains a bundle of maps, and their settings, you'd then apply that to a face. I don't think that it has any real place in the mesh uploader though. unless you were to move to a full-blown asset importer. 

 

[animats]

• Alphabetical ordering of prims. Yes, as Beq points out, it's silly. But the uploader used to follow the order in the .DAE file, which you can make Blender sort alphabetically. Or so says this forum comment. That's why I suggested the current random behavior should be made to work the way the only available documentation says it does. Anyone have a better idea? Logically, you'd have the root prim as the parent in the Blender/Maya hierarchy, with the child prims under it. But (I think) parenting is currently interpreted as "merge all the children into one mesh".So that's out.

  7 hours ago, OptimoMaximo said:

  What i try to convey here is that, since the nature of collada files and the uploader don't cater to your needs (as Beq explains above), nothing stops you from writing a utility script Blender/LSL that does a link order change for you automatically based on your Blender scene's selection of objects. Python is pretty powerful and has a lot of tools to very easily manage strings and arrays.

  Nothing you do Blender-side helps when the linking order gets randomized during upload. I need to construct some test cases, but some weird sizing problems seem to appear in out of order link uploads. More on that later.

• Removing the restriction of all LODs having exactly the same material list. Documentation claims the lower LODs only have to be a subset of the higher LOD. The error message even reads "Material of model is not a subset of reference". And when the built-in mesh reducer is used, it can create models that don't use all the materials. Find out how the "Generated" LOD system does it, and that should help to figure out how to do this.

[OptimoMaximo]

15 hours ago, Beq Janus said:

There is a Jira for that. https://jira.secondlife.com/browse/BUG-202864

I've just read that Jira entry, and it's referring to the automatic splitting of excessive materials into new meshes and their consequent renaming. What i was pointing out is, actually, a less borderline situation, where the number of materials comply to the limit of 8 and there's no automatic splitting performed by the uploader. I also read your comment in such regard, but the Jira itself aims at the limit case.

In my user case instance, anyway, it doesn't matter that much: my main problem was the inconsistent LoD generation for which some pieces were more aggressively reduced than other, basing off the overall amount of triangles, disregarding the process on a per-piece basis. So the use of my scriptset is still relevant to me, whether or not the naming behavior gets fixed, because the LoD generator isn't actually under control as it is with single parts separate uploads and, as mentioned, the Linkset LoD and Physics naming convention system is just a pain and inclined to user mistakes and/or erroneous behavior anyway. Therefore, as end user, regardless of the method i choose to upload meshes (auto-LoD/Physics or hand crafted), this method saves me a lot of headaches and trial-and-error upload attempts, the system just rebuilds my linkset and *I* decide the link order inworld.

[OptimoMaximo]

On 6/19/2019 at 4:00 AM, animats said:

Nothing you do Blender-side helps when the linking order gets randomized during upload. I need to construct some test cases, but some weird sizing problems seem to appear in out of order link uploads. More on that later.

That's exactly the point why i did my script system, i found size/position/rotation discrepancies too that my method gets rid of, snapping all the objects to the correct location and rotation with a sub-millimetric precision (because Maya works in centimeters, locations get at worst 3 decimals). I'm sure you'd get the same result from Blender.

On 6/19/2019 at 4:00 AM, animats said:

But (I think) parenting is currently interpreted as "merge all the children into one mesh".So that's out.

I just did a test and it's not so, at least from Maya (straight DAE export, not FBX to DAE conversion method). Parenting many objects to a root keeps that object as such, but the order is random. In my test i used one cube as root and other cubes as children on the same leaf level. When i did the same but with all prims parented it worked fine, retaining the link order for 2 consecutive uploads, in the parenting reverse order. So the root stayed as root, its direct children became the last in link order, this cube's direct child became the second to last in the linkset, the second to last's child became the third to last in the linkset and so on. I haven't checked for position and sizing, but it seems reliable

EDIT: i can send you the collada files if you want to test them, since i can't attach them here

 

Edited June 20, 2019 by OptimoMaximo

[Beq Janus]

5 hours ago, animats said:

Removing the restriction of all LODs having exactly the same material list. Documentation claims the lower LODs only have to be a subset of the higher LOD. The error message even reads "Material of model is not a subset of reference". And when the built-in mesh reducer is used, it can create models that don't use all the materials. Find out how the "Generated" LOD system does it, and that should help to figure out how to do this.

If you can find a mesh that reproduces this then I'll definitely dig into it. I don't believe it is the case because the internal mesh asset format has no way to deal with such an eventuality. I believe that at least one of the MAV missing level of detail messages is due to this. I will have a look when I get some spare cycles. 

 

 

[Beq Janus]

58 minutes ago, OptimoMaximo said:

I've just read that Jira entry, and it's referring to the automatic splitting of excessive materials into new meshes and their consequent renaming. What i was pointing out is, actually, a less borderline situation, where the number of materials comply to the limit of 8 and there's no automatic splitting performed by the uploader. I also read your comment in such regard, but the Jira itself aims at the limit case.

In my user case instance, anyway, it doesn't matter that much: my main problem was the inconsistent LoD generation for which some pieces were more aggressively reduced than other, basing off the overall amount of triangles, disregarding the process on a per-piece basis. So the use of my scriptset is still relevant to me, whether or not the naming behavior gets fixed, because the LoD generator isn't actually under control as it is with single parts separate uploads and, as mentioned, the Linkset LoD and Physics naming convention system is just a pain and inclined to user mistakes and/or erroneous behavior anyway. Therefore, as end user, regardless of the method i choose to upload meshes (auto-LoD/Physics or hand crafted), this method saves me a lot of headaches and trial-and-error upload attempts, the system just rebuilds my linkset and *I* decide the link order inworld.

No, that Jira is nothing to do with material at all. It is to do with linksets and the fact that all but the root prim of an uplpoaded multipart mesh are called Object even though the scene file and the internal mesh held by the viewer retains the full label i.e. the same issue that you mentioned in the sentence I cited. The final upload to the server has no such label because it is not defined in the upload format, thus it cannot be fixed by the viewer alone. 

[OptimoMaximo]

5 hours ago, Beq Janus said:

No, that Jira is nothing to do with material at all.

Well, i read the description of that Jira and it says: "When a mesh is uploaded ~ if it's number of faces/Material IDs exceed 8, it is broken up into the original mesh, plus an appropriate number of child-meshes inside a linkset in SL where all they are all named "Object"."

So i can't see how the thing is not related to materials, in that Jira. I was already aware of both behaviors, btw. 

[animats]

6 hours ago, Beq Janus said:

If you can find a mesh that reproduces this then I'll definitely dig into it. I don't believe it is the case because the internal mesh asset format has no way to deal with such an eventuality. I believe that at least one of the MAV missing level of detail messages is due to this. I will have a look when I get some spare cycles.

What happens if you force the uploader to generate fewer triangles than materials in the lower LODs? This.

Simple test case - 8 faces, each a different material and color

This was uploaded with the default generated LOD settings, which forced all the lower LODs down to 8 triangles.

 

Low LOD. It looks like two triangles, one on each side. But mesh information says 8.

 

Same thing in wireframe. Only two triangles. Unless maybe they're on top of each other? I'm not seeing the texture-fighting that usually happens when you have coincident triangles, so that's unlikely.

Somehow, the uploader disposed of 6 of the 8 materials for the low LOD. But what did it do with them? It looks like the reduced mesh generator can get rid of unwanted materials, somehow. Even if we can't do that with manually generated LOD files.

I left this object at Animesh1/145/212/23 on the beta grid if anyone wants to look at it.

 

Edited June 19, 2019 by animats

[Ana Stubbs]

I paid a visit (your escalator looks like it needs maintenance, it's running very jerkily) .

 

There IS something funny going on with that - I can get texture info for faces 0 and 3 (the visible ones), but if I select the hidden ones individually I get... nothing, nada, zilch.

Oh, and my viewer can't agree on how many vertices there are.

 

Answers on a postcard please about how to construct 8 triangles with only 12 vertices.

Edited June 19, 2019 by Ana Stubbs

[animats]

Cylinder at medium LOD. Four sides, four colors, a tetrahedron.

I've looked at it in wireframe, and I've looked at it at very close range. There are only four triangles and four colors there. The extra materials aren't hidden inside; if you get the viewpoint inside the object, you see nothing, since the faces are one-sided. I don't know how the lower-LOD generator makes the unwanted materials go away, but it definitely does it.

[Profaitchikenz Haiku]

8 hours ago, Ana Stubbs said:

I paid a visit (your escalator looks like it needs maintenance, it's running very jerkily) .

That'll be the script run percentage being low, you should see what it does to my train.

I'm interested in the random disposition of the root prim in an uploaded linkset because I see this issue in the XML export files I have re-uploaded. Is the same set of routines called for mesh uploads with multiple prims as the XML uploader calls?

[animats]

On 6/18/2019 at 7:17 AM, Vir Linden said:

Thanks for the comments! We currently have a project underway to improve some of the pain points with mesh upload. We could potentially tackle more things there, with a strong preference to anything that's well defined and limited in scope. As Beq says, the best way to get this kind of thing looked at is to file a JIRA; new bugs filed as feature requests get evaluated weekly.

I'm trying to get some consensus on how this ought to work first. You can't discuss that on the JIRA system, because you can't comment on other people's JIRA entries. So this is a good place to discuss it. A JIRA will follow if there's reasonable agreement on how this should work.

[Aquila Kytori]

22 hours ago, animats said:

Somehow, the uploader disposed of 6 of the 8 materials for the low LOD. But what did it do with them? It looks like the reduced mesh generator can get rid of unwanted materials, somehow. Even if we can't do that with manually generated LOD files.

 

'Ive looked at it in wireframe, and I've looked at it at very close range. There are only four triangles and four colors there. The extra materials aren't hidden inside; if you get the viewpoint inside the object, you see nothing, since the faces are one-sided. I don't know how the lower-LOD generator makes the unwanted materials go away, but it definitely does it. 

 

Could it be that the "missing materials" are each assigned to a single vertex? Which would explain whey you can't see them.

 

 

 

 

 

 

Edited June 20, 2019 by Aquila Kytori

[Ana Stubbs]

25 minutes ago, Aquila Kytori said:

 

Could it be that the "missing materials" are each assigned to a single vertex? Which would explain whey you can't see them.

 

 

 

 

 

 

That makes sense.

Theorising here (and knowing that in SL, different faces can't share a vertex) - the two visible triangles would account for six of the twelve vertices in animat's model, leaving the other six to hold the six remaining materials.

That would exactly explain what I observed, and means that the materials are in fact all present, just unrendered.

Correct me if i'm wrong, but I believe we can't recreate this manually, because the uploader removes lone vertices.

[Beq Janus]

2 hours ago, Ana Stubbs said:

That would exactly explain what I observed, and means that the materials are in fact all present, just unrendered.

Correct me if i'm wrong, but I believe we can't recreate this manually, because the uploader removes lone vertices.

I'll have a look at how it works when I get a chance. but yeah, as far as I can tell there is absolutely no way to upload a mesh without having at least one triangle per submesh (where a submesh is what we're calling material)

what you are seeing as vertices are probably very tiny triangles is my guess.

However, until I look that remains conjecture, so I'll take a peek when I can

 

 

[animats]

11 hours ago, Beq Janus said:

I'll have a look at how it works when I get a chance. but yeah, as far as I can tell there is absolutely no way to upload a mesh without having at least one triangle per submesh (where a submesh is what we're calling material)

what you are seeing as vertices are probably very tiny triangles is my guess.

However, until I look that remains conjecture, so I'll take a peek when I can

Thanks. Somehow the built-in LOD generator pulls this off. Tiny triangles? Degenerate triangles? I dunno.

[Beq Janus]

OK, so....we're all kinda right.

@animats is right that the viewer is able to generate mesh that the user is not (currently) allowed to upload, kind of.

Yours truly is right that it is impossible to upload a mesh asset that does not have matching material counts for each LOD.

@Aquila Kytori is on the right track, that the "unused" materials are assigned a placeholder. The placeholder is a single triangle of zero size. Which somewhere along the way must be decaying to a single vert in the export. I'm not inclined to chase that squirrel just yet.

Here is what is happening at upload.

I've documented the mesh asset format on my blog in the past, pulling in the, essential reading, prior art of @Drongle McMahon you can see my blog When is a triangle not a triangle for discussion and links off to other distractions. Skimming through I think it still holds true to what I know now (that was written before I was a viewer dev).

The mesh header prefixes the model and defines the global parameters, including the set of materials to be used. That array of materials is fixed at the head and is thus why I can be so certain of my assertion that each LOD has to have a place holder array, without it, if material 6 was missing the viewer would see material 7 as 6, 8 as 7, and fall off the list looking for 8. 

The way we always deal with this as creators is to insert tiny single triangles to cover the missing material slots. My assumption (which I am about to prove incorrect) was that the viewer did that on upload if GLOD decided to eliminate a material entirely. In fact, the viewer does something a little unexpected, it creates a special placeholder label.

000005          [ ARRAY (8 elements)
000010                  { MAP (len:1)
000025                          Key:NoGeometry
000027                  }
000032                  { MAP (len:1)
000047                          Key:NoGeometry
000049                  }

I've put a full annotated decoding of my 8 material plane (similar to the one Aquila used) https://pastebin.com/W7uN3UBu

The entry of a key, with the string "NoGeometry" creates an entry in the mesh asset for that material, thus fulfilling my requirement above, there is no way for a user to create this themselves. 

So....that's all very good Beq but what about @Aquila Kytori's stray "vertices"?

Well, that happens at the other end of the lifecycle. 

When the viewer is decoding a mesh asset ready to present it to the pipeline it faces a similar problem to the issue expressed before. You really really need to have actaul mesh to render or it would require all kinds of additional sanity checks and edge cases, so it creates some dummy geometry to act as a sentinel. Sentinels are a not uncommon way to simplify bounds checking. Software engineers may well have seen it in many algorithms, it is akin to an "Elephant in Cairo"

 Here is the viewer, placing its elephant:

"It's a triangle Jim, but not as we know it"

The viewer is creating a triangle composed of three indexes into the vertex array, each entry is set to 0, the vertex array is of length 1, and has coords (0,0,0) in the normalised mesh domain (-32768 - + 32767) i.e. the origin, for both positions and normals as well as 0,0 for the UV.

Conclusion:

We are all a little wiser than we were, I hope. There is indeed a path that the human creator cannot access, however, that path does not allow them to avoid the materials. The question is, how would the user access this? The viewer can do it because it "knows" which material it has eliminated and thus uses a placeholder. The placeholder is really no different to what we do manually, though arguably a little more compact. In order to do this in the manual case the viewer would need to be able to follow the unordered material lists through the discrete models and work out which ones were missing. It sounds doable, I effectively do this in my Blender Addon as shown here. The Addon (yep it will be up on github as soon as I get chance) has been used here to auto populate the Lower LODs from the original 8 material plane. I have then manually reassigned the materials on a couple of faces in the Lowest LOD in order to trigger the error shown. The "caution" marker is highlighting the fact that no geometry is present for the expected material in that model. I will have a "fix me" button at some point, which will create an arbitrary triangle, but if we can come up with a better solution that allows the uploader to recognise this without making it harder for users to debug their genuine material cockups.

 I need to think more about it and consider the inverted cases such as imposters where you effectively have a null material in the High, that acquires mesh data in the lower LODs. 

For the terminally curious, here's a short video of me fiddling with that in SLender (the Addon). Quite appropriately the video shows a bug at the end as the High LOD shouldn't have shown an error :-) 

https://i.gyazo.com/9950f318cd3d27fa36d1bf14e0a10b20.mp4

[animats]

5 hours ago, Beq Janus said:

OK, so....we're all kinda right.

@animats is right that the viewer is able to generate mesh that the user is not (currently) allowed to upload, kind of.

Yours truly is right that it is impossible to upload a mesh asset that does not have matching material counts for each LOD.

@Aquila Kytori is on the right track, that the "unused" materials are assigned a placeholder. The placeholder is a single triangle of zero size. Which somewhere along the way must be decaying to a single vert in the export. I'm not inclined to chase that squirrel just yet.

Here is what is happening at upload...

The entry of a key, with the string "NoGeometry" creates an entry in the mesh asset for that material, thus fulfilling my requirement above, there is no way for a user to create this themselves.

Thanks for all that work.

"NoGeometry" is not unexpected. That's a documented feature in the mesh file format:

""NoGeometry" -- optional, boolean, must be true -- If present, there is no geometry for this submesh. This submesh is just a placeholder to let the simulator/viewer know that there is a texture entry for this submesh with no geometry at this LoD. No additional fields may be specified if "NoGeometry" is present." - from http://wiki.secondlife.com/wiki/Mesh/Mesh_Asset_Format

5 hours ago, Beq Janus said:

You really really need to have actual mesh to render or it would require all kinds of additional sanity checks and edge cases, so it creates some dummy geometry to act as a sentinel.

A bit ugly, but gets the job done.

5 hours ago, Beq Janus said:

I need to think more about it and consider the inverted cases such as imposters where you effectively have a null material in the High, that acquires mesh data in the lower LODs. 

Right. That's why I originally wanted this. I wrote an impostor generator for Blender which generates a low-LOD mesh with a new material not present in the higher detail LODs-. I didn't want to modify the user-created higher level of detail model, adding dummy triangles and materials. That would confuse the user, and possibly mess up something they're doing. Mesh cleanup on their model might delete the dummy triangles, for example. Some mesh functions will try to do something with the dummy triangles, confusing the user. Running the impostor generator more than once might add dummy geometry on each rerun, and preventing that requires bookkeeping data somewhere. So, not a good solution.

I read the documentation and found the "NoGeometry" file data item. If only I could generate that...

Quote

if we can come up with a better solution that allows the uploader to recognise this without making it harder for users to debug their genuine material cockups...

Yes. The Firestorm uploader has useful messages about what matches and what doesn't match across LODs. But the messages are in the "Firestorm.log" file, which only developers read. If those messages were displayed to the end user during uploads, there would be much less confusion about material and object matching problems.

Thanks for chasing this down. Now what?