I wonder if it would be a difficult thing to get multi-mesh uploads work with a reliable linkset root object while doing this? Like, having the links be in the order the meshes are listed in the file, the first item in the file being root.

I echo Geenz Linden in this. I don't believe that non-creator end users have the stomach for another 5 year epic that touches every aspect of the architecture (and don't think for 1 second that this would not - it demands entire new inworld tools, rendering pipelines, scripting extensions/updates, new shaders and of course, with no limitations on the excesses of unoptimised content import, further narrowing of the target audience).

As nice as this might be for a subset of artists and creators it has little end-user buy-in. Most users will happily accept "prettier content" so long as it does not de-stabilise what they know and love, or need another investment in hardware. They'd much rather have reliable region crossings, a new quality of life features. They certainly don't need more niche terms and acronyms throw at them.

Collada is dead though and what is painfully clear is that we need other transports, new formats through which we can import content and those are needed right now.

What do I think a new importer should look like?

As Signal Linden notes, it should ultimately behave much like Collada, resulting in a coalesced scene. I'd like to see it automatically apply a packaging "rezzer" during this so that "part two of import", actually instantiating things inworld, is less error-prone.

It must support importing assets with LODs as the current system does, but it needs to go a step further and support instancing fully. I should not be importing a street scene which creates 20 identical streetlamp meshes, but one streetlamp in 20 places.

I don't actually think gltf need be the the only form, as an open standard it is a far better choice than some closed autodesk nonsense, but, if this were bound to well-established projects such as AssImp then we can, to some extent, detach the backend from the front end.

Finally, perhaps the most important part for me, as this has been ignored for over a decade and led to so many of the problems of recent years. It must act as a gatekeeper and apply constraints on the un-optimised content that gets thrown into Second Life today. We need to define a new contract with content creators that imparts responsibility for the assets being imported into Second-Life and recognises that they have a role in keeping performance figures attainable to typical end-user hardware.

Hey everyone! Just want to address some concerns I’m seeing on this.

First of all, GLTF -> LLMesh or “SLM” is intended to be an attempt to break down a much bigger feature set into smaller shippable pieces. This isn’t a cancelling or “weaseling out” of any other features we’ve worked on or otherwise previously promised. This is part of a larger attempt to avoid working on what we call “omnibus” projects that take several months to a couple of years to get out the door.

Other features, such as transmission, IOR, Volume, dispersion, GLTF animations, custom rigs, hierarchy, and so on all carry their own significant chunks of work. Some of these from the previous “PMFP” or “GTLF Mesh” project are much further along than others, while others require a lot more effort to get over the finish line. Some of these will require significant server work. Others not so much. Some require careful consideration of how they should mechanically work and how they would interact with existing features. Others pretty much stand on their own and don’t require as much consideration. I can provide examples sometime of these.

GLTF import sets a foundation that we can build upon to help deliver more of these features faster, with more frequency, and with faster integration of feedback from the community.

Tl;dr - Let’s finish off a foundation for improved GLTF import including mesh, and start building the specific features we want on top of that, delivering them sooner than later, and more rapidly incorporating community feedback along the way with each release.

seems nice id rather they finish the full gltf spec tho and bring it into SL insted of half assing stuff like they have done for years

The good part is to have an alternative for the dying Collada ecosystem soon.

The bad part is that it makes it easier to abandon glTF full support when you just have covered a small part, because someone can call the half finished state as "done".

Maybe do it like others, add it and slap a big "Feature Preview" Label on it, until its done. And if you are at it, add greyed out checkboxes for all the still missing features, to make utterly clear whats still missing. Kind of checklist style for all the glTF spec.

Signal Linden would be great if you could add tick boxes for what to upload, which I am missing in the current material uploader which let me choose only one or all in a .gltf / .glb file.

It would be good to go back to the principle that if glTF mesh and any PBR materials on it displays in the Khronos Model Viewer then it will be considered a bug if it does not look identical in Second Life. Everyone will know where they are then with any development tool used.

glTF mesh open, display and even save to inventory was actually working pretty well back in early 2024, right up to versions in June 2024. Early viewer dev versions up to around "Second Life Project Gltf Development 7.1.9.9491082776" continue to work fine and render the glTF meshes that are opened and saved and all faces properly. But later versions don't. Davep indicated it was some experiments with GPU instancing and a glitch with vertex normal handling that broke this.

See https://github.com/secondlife/viewer/issues/1873 for more detail, and SLurl to some example full perm test meshes on the Aditi Beta Test grid.