feat: ScriptedImporter for .ktx2 files

[hybridherbst]

First quick stab at implementing a Scripted Importer for .ktx2 files in Unity. For reasons, it seems that the .ktx extension is "blocked" by Unity for future use, but I've seen ktx2 in the wild way more often so I think this is an acceptable compromise.

("The scripted importer 'KtxImporter' attempted to register file type '.ktx', which is handled by a native Unity importer. Registration rejected." – but then no actual import result is produced. I think it only supports KTX1, maybe?)

If you know more :) about the plans for .ktx2 engine importer support that would make this redundant happy to hear.

[atteneder]

Awesome!

I'll have a look soon, thanks.

[hybridherbst]

Ping! @atteneder

[atteneder]

@hybridherbst I rebased it on branch ktx-1 (for older Unity versions; will merge it into main as well once it's done) here:

https://github.com/atteneder/KtxUnity/tree/feat-scripted-importer

Only concern: In case of error I would not create the red fallback texture at all. Why: consistency with other formats (tried to import a broken JPG, which results in no assets at all).

Is there an argument I'm missing?

[hybridherbst]

I'm afraid this isn't quite consistent in Unity (e.g. broken textures import as "nothing", broken compute shaders import as "some default compute shader") - maybe worth asking the AssetDB team and/or the Standards team what the best practice is here.

Personally I like fallback things, because they don't break the rest of the import pipeline (follow-up assets and prefabs will import correctly, an error will still be displayed), but I can see arguments for the other way as well (if one thing is broken everything else should break as well to force you to fix it asap).

[atteneder]

@hybridherbst Yeah, it boils down to a matter of taste or workflow preference.

I've asked around, waiting for responses.

My main concern with the fallback is fails going unnoticed. E.g. an ORM texture of a glTF fails and goes red won't necessarily look wrong on a model. I'm thinking a non-solid texture (e.g. a pixel style exclamation mark or checkerboard pattern) might be more obvious. Not a request for change...just brainstorming.

[atteneder]

After internal feedback I've decided to not return a dummy texture. I added error codes and now a somewhat usable error will be shown in the inspector (and logged to console as well).

@hybridherbst Completely unrelated: I occasionally get errors that certain formats (BC7/DTX5) don't support non-multiple-of-4. That's either a misconfiguration (of my code) or a platform specific thing. I should probably look into this before releasing. I've seen you ran into this as well. Let me know if you have insights.

[atteneder]

I've merged and released it in 1.2.0 and 2.1.0 respectively 🎉

Thanks a lot for the initiative!

[hybridherbst]

Very cool! Would you like to track follow-up tasks somewhere? E.g. there needs to either be the texture compression dropdowns similar to what Unity provides for built-in textures, or a way to keep the .ktx2 files around for runtime loading.

[atteneder]

@hybridherbst good idea! I've started a discussion. Let's sketch out the workflows first and derive required features from there.