PayasoPrince wrote:Though, I'm a bit confused by your response. What third party asset are you referring to?
Unity natively supports .DDS textures.
Oh, thanks for the hint, somehow I missed that. Strangely it seems to have been supported for quite some time already. Then ignore what I said about thirdparty assets for importing if Unity already imports dds files including all mipmaps. If you are fine with the lossy compression of the mipmaps in the dds files, then there is no need to go down the path that Misaki mentioned above (loading mipmap levels from separate textures for each level).
PayasoPrince wrote:That being said, I understand how mipmaps work in Unity. What I don't understand is how the Spine atlas uses the material. Does it work the same way any other model + material works?
Yes. Just be sure that if special additional materials are generated next to each main material for e.g. blend modes (e.g.
_Material-Multiply
) or for rendering with masks (e.g.
_Material_InsideMask
), you need to assign your custom texture for each of the Materials.
PayasoPrince wrote:In other words, if I simply drag a .DDS file into the material like the example below, is anything unique happening behind the scenes, or will it allow Unity to use the mipmaps in the .DDS texture file?
The texture assigned at the Material is used, just drag the dds file onto your Material's texture property if you want to use it instead of the exported
.png
atlas texture.
PayasoPrince wrote:I really feel like there should be any kind of documentation on this.
It is not simply a "Unity thing", because Unity supports .DDS files and custom mipmaps easily.

Could you please describe what you think needs special documentation? Textures are used normally, so I'm unsure what of the standard behaviour we should document here. The spine-unity runtime uses normal
MeshRenderer
and
MeshFilter
components for rendering, just with some logic to bind the Material depending on the atlas page required, if multiple are needed.
Perhaps you are thinking about mipmaps the wrong way: note that to the graphics API behind the scenes, a texture resource is always a combination of all mipmap levels from 0 up to N (the pyramid up to level N), which is an inseparable unit. This texture resource is then bound before rendering, and the respective suitable mipmap levels' texels are accessed by the shader during a texture-sampling call. So anything that can be assigned as a
Texture2D
slot at your Material will be used normally, as it would when assigned at a cube or quad. Now you can use Misaki's mentioned code to fill the mipmap levels of a texture in an import-postprocessing step, or load it directly by using a dds file with pre-authored mipmaps.