Mario wroteIIRC the Unity approach does actually just use the computed mesh(es) from the "main" entity. In Godot, such an approach doesn't work, because instead of directly submitting meshes, we have to go through creating Mesh2DInstance objects behind the scene, and then setting their triangle soups via VisualServer. See:
https://github.com/EsotericSoftware/spine-runtimes/blob/4.1/spine-godot/spine_godot/SpineSprite.cpp#L501
When constructing the triangle soups, the soups are temporary. SpineSprite would have to keep them around for another node to access them and set them on their own Mesh2DInstance children.
I'd be surprised if that is the most efficient way. My gut tells me rendering to an offscreen buffer, then post-processing that with an adequat outline shader is likely better.
Noted, I have a lot of reading and learning ahead but it's fun to dig into this.
Looks like I solved it using Godot's Viewport node.
I'm really starting to love the simplicity of Godot. And the few artifacts should be fixable with a better shader. Post processing indeed seems to be the better direction to explore.
Hmm, one limiting factor of Viewport approach is that due to SpineSlot and SpineBone Node hierarchical expectations, everything ends up inside the Viewport. So say I want to add a particle effect to the weapon via SpineSlot Node, that particle has to go inside the viewport and therefore also gets outlined as a child Node of SpineSlot.
It would then be preferable if SpineSlot and SpineBone had an exported SpineSprite property in the inspector instead of enforcing the current Node structure so I could place SpineSlot outside the Viewport.
Workarounds as of this moment I can think of - one would be to have the particle outside the viewport and script it to follow SpineSlot transform in _process. Another would be to have duplicate SpineSprites - one for outline via Viewport, and the other for everything else such as adding slot specific particle effects. Viewports can be stacked and not pass on their contents to parent Viewports but they don't have a transform, so this is a dead end.
To illustrate a common problem:
Since SpineSlot expects to be a child of SpineSprite, Viewport post processing currently is all or nothing deal. Viewports can be stacked, but I can't place only a SlotNode in the Viewport due to current parent/child requirements of SpineSlot.
