My questions regarding glXF (which I havenāt been able to get a good answer to even in calls with Khronos by the way) are intended to align Needle better to how glTF evolves ā in an ideal world we would never deviate from existing standard, but in practice standard evolution is horribly slow, so slow that we sometimes have to think ahead and solve real-world problems
Not easy to design though when keeping other, ādumberā clients in mind for downwards compat, isnāt it?
by user 395602247196737546
Well thatās one advantage of glTF - the files load everywhere, our custom extensions just wonāt do anything for the time being (e.g. referencing / composition / custom component logic etc.)
That being said, we make sure that files can be exported as ādumbā glTF files as well 
Yeah good example with the glXF repo with 2 years of no changes. Looks pretty dead from a devās PoV but from a standardization PoV itās maybe on the brink of full spec?
by user 395602247196737546
Thatās what i meant, if you rip out the heart of the format (geometry, materials, textures) and just plop ugly low res stuff in there just so your extensions can do lots of magic on top of that ā what is the point of keeping the ugly low res stuff in glTF format then?
by user 395602247196737546
In my opinion the glXF standard is problematic: itās mostly an effort by Adobe to standardize what Aero can do, and to kind-of-but-not-really counter Appleās preliminary behaviours in USDZ.
Basically for every such standard movement we have to take an educated guess if itās worth pouring energy into driving standardization forward or not
.
Another example is KHR_animation_pointer where we did, in fact, do a lot of work to push standardization further ā to the point where itās supported in a lot of places and will likely be ratified soon
The alternatives were worse in that case ā e.g. the MSFT_lod extension kind of works around that problem but requires HTTP Range Requests to work, which isnāt supported by many servers. So for these files we could mark the NEEDLE_textures_progressive extension as required and when a viewer doesnāt know what to do with it they wonāt load it.
Ah my HTTP game is not the strongest but range requests refers to a client requesting specific file parts only, right?
by user 395602247196737546
Yeah, thatās how MSIX package updating works and why it rung some bell in the back of my head.
by user 395602247196737546
Canāt see anything about that technicality in the spec though: glTF/extensions/2.0/Vendor/MSFT_lod/README.md at main Ā· KhronosGroup/glTF Ā· GitHub
by user 395602247196737546
Exactly, it means āgive me bytes 10000ā¦12000 of that file instead of all of itā ā nice in theory but in practice useless if not every server supports it (and itās a rather low percentage right now)
Ok but thereās some additional postprocessing steps bound to happen anyway for the client to know what file parts to request in the first place. Thatās just not part of the extension spec.
by user 395602247196737546
Well itās not required, you can of course load the full file first ā you get the advantage of individual LODs but not faster load times.
In our case (deferred textures and meshes and multiple scenes and ā¦) that would mean hundreds of megabytes of upfront download. Not what we want
So we instead decided to put the payloads into separate files instead.
Yep and from a business point of view thatās a wise choice you made
by user 395602247196737546
Not your business in particular but in the sense of onboarding or whatever the correct marketing term is.
by user 395602247196737546
I sure hope we get to a point where glTF has some way to do composition, but so far Khronos aināt looking in that direction (excluding the minimal attempts in glXF)
In the meantime, Iām happy we can provide people the ability to use it on top of our custom extensions ā for most of them without even knowing or thinking about that theyāre dealing with glTF under the hood, which I think is a clear win