- Unity's SVG implementation is mesh-based (ie, they dynamically flatten into meshes based on SVG paths.). Incorporating that into a Spine skeleton involves a bit of ambiguity. Plain region attachments could just be transformed into MeshAttachments but Unity might be storing extra stuff like per-vertex colors that Spine Attachment doesn't. And MeshAttachments, since the "flattening" exists purely on the Unity side, would lose information necessary for, for example, deformation animation and weights since there is no guarantee that their vertices would match up. This is also a lot of speculation as Unity's experimental package doesn't expose much to us at the moment, which is probably fine since it's not ideal for their experimental package's API to solidify before it's ready.
Just based on that, seems like making Unity SVG support (the mesh kind) and Spine-Unity is questionable and still a bit farther away.
2.
But for what you specifically have achieved so far, being able to render SVGs onto textures, it's a bit more straightforward.
For rendering, every renderable Spine Attachment stores information about what Material and UV coordinates it uses. Since you're already able to render your svgs into textures, we only need to package up that information into what the SkeletonRenderer system can use.
Add the using above your script:
using Spine.Unity.Modules.AttachmentTools;
Then for each renderable attachment, you load in the necessary rendering information.
The simplified version of it is.
var r = yourTexture.ToAtlasRegion(templateMaterialSoItKnowsWhatShaderAndPropertyValuesToUse); // 1. Pack info for an unatlased texture into an object.
attachment.SetRegion(r); // 2. Store that info to the attachment.
These are the two basic steps, and you'd do this for all your renderable attachments.
The above is also the underlying idea behind Mix and Match. https://github.com/pharan/spine-unity-docs/blob/master/Mix-and-Match.md
The current API is conducive to Mix and Match and its related workflow.
But for full texture replacement, especially from a pre-atlased source, may be a bit different and there may be some utility methods missing. It probably won't be too hard to add though, and they likely make sensible additions to AttachmentTools.
But depending on your data source, it may be better to go a different route too.
AtlasAsset is actually an extendable class. We're coming out soon with a Spine-Unity SpriteAtlasAsset type which can allow you to source regions from Unity SpriteAtlas instead of Spine atlases. If a similar asset type could be created with your SVG-to-texture code in it, it would probably work fine, even in edit mode.