Welcome to Spine! :cooldoge: I'm happy to field your questions.

Kinvert a écrit

We hope to have some parts of the avatars be scalable. For example they might want their avatar a little taller. So the number of bones would stay the same, but the whole thing would need to scale.

You can adjust the transforms (rotation, translation, scale, shear) of bones at runtime. For example, you could set the scale on a bone to make the skeleton taller, arms longer, etc, just like you can do in Spine by adjusting the transform.
Runtime Skeletons - Spine Runtimes Guide
API Reference - Spine Runtimes Guide
API Reference - Bone

You can also setup constraints that adjust the skeleton, then control the constraint mixes to get a result somewhere between no constraint applied and the constraint fully applied.
Transform Constraints - Spine User Guide

Kinvert a écrit

We want to create the animations ONCE and have those animations work for all the avatars. We realize we might need to give all bones the same name, etc. Can your software do this?

Absolutely. Spine's slots and skins facilitate such reuse. Skin constraints (and skin bones) allow you to have constraints that are only applied for some skins.
Basic Concepts - Spine User Guide: Slots
Skins - Spine User Guide
Skins - Spine User Guide: Skin constraints
Skins - Spine User Guide: Skin bones

Kinvert a écrit

Can we take an existing rig, and replace its arm SVG with a new arm SVG, then the head SVG with a new head SVG? We can't redo the rigging for each users avatar as there will be thousands of possible avatars they create.

Yes, with proper planning you can setup your skeleton so that you don't need to attach every image to the skeleton in Spine. Typically you'd have attach a set of attachments in Spine as a template, then you'd use copy those attachments at runtime and customize what images they use.
Runtime Skins - Spine Runtimes Guide: Creating attachments

Kinvert a écrit

If we use Mesh, how might this workflow go? For example can we create mesh for "arm_design_2" and "arm_design_5" and when we replace one arm with the other, it will have the correct mesh, and be associated with the correct bone?

If you take a template mesh, duplicate it, and change which image it uses, then it will have the same weights for the same bones, so it will deform in the same way. Note generally it is better for reuse (and other reasons) to use weights rather than deform keys.

Spine also has "linked meshes" which is a mesh that uses the vertices, edges, UVs, triangles, and weights of another mesh (the "source mesh"). This is similar to duplicating a mesh, but a little more efficient because it shares that data. Also Spine-the-editor it is more convenient than duplication, since with duplication if you modify the mesh you'd have to make the same changes to all the duplicates.
Meshes - Spine User Guide: Linked meshes

Kinvert a écrit

How does this export? Avatars will be an SVG. I think there would be an SVG for the arm, one for the head, one for the eyes, etc.

Spine-the-editor works only with raster images. You'll need to export images from Illustrator or other software so you can bring them into Spine. We have scripts for doing that and also generating a JSON skeleton data file so the images are positioned in Spine as they were in Photoshop/Illustrator/etc. Of these, the Photoshop script has the most features and is recommended, if possible. We also have an Illustrator script, though it is more basic (doesn't support tags in the layer names to control how the JSON is generated):
spine-scripts/photoshop at master · EsotericSoftware/spine-scripts
spine-scripts/illustrator at master · EsotericSoftware/spine-scripts

The skeletal data exported from Spine is not tightly coupled to the images: attachments have a name/path that is used at runtime to determine what is drawn for that attachment.
Images - Spine User Guide: Image file lookup

At runtime you are free to render anything you like, though it is most common to render using raster images packed into a texture atlas, usually using one of the Spine Runtimes plus a game toolkit. Rendering SVG is challenging in general for a number of reasons and most game toolkits can't do it at all.

One solution that is mid-way between rendering SVG geometry directly to the screen and rendering raster images is, at runtime, to determine the sizes the skeletons will be rendered at (eg based on the device resolution) then render the SVGs to raster images (eg with some library like AGG, Anti-Grain Geometry), probably packed into texture atlas pages to reduce draw calls. You can then use that atlas as normal to render with the Spine Runtimes and your game toolkit. This gives you the benefit of SVG (eg small files, rasterized at high quality based on the user's screen size) without complex rendering. Just rendering the SVGs to a texture atlas is quite advanced and will take some effort though. Unfortunately we don't have a solution for that out of the box, but it's something we'd like to provide in the future (likely for Unity/spine-unity).

Kinvert a écrit

What files do you export after everything is animated? Is it JSON?

Spine skeletal data is exported as JSON or binary. Binary is recommended for small size and faster loading. JSON is usually fine for development or to inspect the data. Example exports can be found in the Spine installation folder or here:
spine-runtimes/examples at 3.8

Kinvert a écrit

Do you have scripts we can put in the DOM and it will animate the character inside the SVG? Or maybe this has to be done in Canvas? Are scripts on CDN?

If your target is to render on a webpage, the Spine Runtime for TypeScript/JavaScript is spine-ts and it has a few "backends" for rendering via canvas, WebGL, THREE.js, or a YouTube-like animation viewer.
spine-runtimes/spine-ts at 3.8

Another option is the popular but third party pixi.js, which uses our spine-ts.
https://www.pixijs.com/

Note there are technical limitations to spine-ts canvas rendering, notably that canvas cannot natively render meshes. Support to do so can be enabled (useTriangleRendering), but it is relatively slow and may have artifacts depending on the browser. I would suggest using WebGL if canvas cannot meet your needs.
spine-runtimes/spine-ts at 3.8

spine-ts doesn't animate by manipulating the DOM. Instead it does the calculations necessary, then renders textured triangles.

Glad it was helpful!

Generally you need to specify exactly what you need and how you need it, else artists/animators do their own thing and it may not fit well. Ideally you set everything up with placeholder art so you understand your entire workflow from artist to Spine to in-game.

If you are using template images so you don't have to attach every image in Spine then it's important that they are large enough to accommodate all your future items. The excess whitespace around the edges can be trimmed by the texture packer when the images are packed into a texture atlas. If you are going to use SVG, it would be ideal to have it working before you hire art so you can work with the artist to ensure their output is readily usable.

Other than that, the art needed is highly dependent on the movements needed during animations. You can build skeletons that work with a fixed perspective or skeletons that can fully turn around or animate in a fixed number of directions. Some movements may require swapping attachments, eg if you need a different perspective on a torso or other body parts. The more you can spec out about the movements needed beforehand, the closer the artist can get on the first go. They of course need to provide the art in layers so it can be rigged in Spine.

There are some very general guidelines, such as if something will bend, it's often best to create the art in the straight configuration, then weight it to bones and bend it with the bones. We have a series of blog posts about working with meshes:
Blog: Mesh creation tips: vertex placement
Blog: A taxonomy of meshes
Blog: Mesh weight workflows

We are working on more educational videos and have big plans for those.

Kinvert a écrit

How is all of this typically stored?

The browser fetches the images and skeleton data with HTTP requests. You can serve them however you want, eg from the filesystem, from a database, or any other way. Images are typically packed into an atlas, eg:
http://esotericsoftware.com/demos/exports/atlas1.atlas
http://esotericsoftware.com/demos/exports/atlas1.png

You could assemble an atlas from individual images at runtime, though that is more complicated than using a premade atlas. You could possibly have a web server assemble an atlas that contains only the images needed for a particular user's configuration.

Kinvert a écrit

Sounds like these will have to be Raster images rather than SVG paths?

Rendering SVG is quite complex. Images are much easier.

Kinvert a écrit

What other things do we store?

Likely you'll have skeleton data, atlas data, and images files, plus HTML and JS files.

Kinvert a écrit

Will I be able to make a basic stick figure animation, with different colors (skins), and get that working with the trial?

The trial cannot save or export. You can use the exports of the example projects if you want to experiment with the Spine Runtimes before purchasing a Spine license.

Kinvert a écrit

According to Export - Spine User Guide it seems like I store a JSON file?

Yes, though as mentioned, binary is smaller and faster to parse.

Kinvert a écrit

The JSON will somehow need to reference the image files, correct?

When the skeleton data is parsed by SkeletonJson or SkeletonBinary, the AttachmentLoader is what determines how to find the assets needed to render each attachment. AtlasAttachmentLoader is most common but you can customize this, for example to render SVG to build a texture atlas on the fly (but doing that is likely difficult to do in a browser).
Loading Skeleton Data - Spine Runtimes Guide: JSON and binary data

Kinvert a écrit

How do I do that when I'm using a database?

This question is beyond the scope of using Spine. How you build your application is up to you but I would guess the skeleton data is the same for all your users, then you replace the attachments as needed to configure the skeleton with the attachments for a particular user.

Kinvert a écrit

We plan on showing these animations either in an SVG or Canvas. Since I'm mostly setting up the demo myself I'm currently more comfortable with SVG but maybe later on HTML5 Canvas is a better option?

Canvas cannot display meshes (in a reasonable manner). There is nothing out of the box that can render Spine animations in a browser using SVG, to do so you would need a lot of research and to build your own runtime or somehow rasterize SVG. As mentioned, I recommend using WebGL.

It sounds like you need to experiment with the Spine Runtimes, starting with a simple example and build up to the complexity of the app and functionality you have in mind.

Kinvert a écrit

Do you guys have a script I might be able to incorporate that would generate the atlas when a user creates an avatar?

You can use Spine's CLI to pack an atlas.
Export - Spine User Guide: Command line

Spine's packing is based on libgdx's texture packer (which I authored). That is FOSS and you can use it to pack, which is a bit more lightweight than running Spine. It lacks some features Spine has though. Spine's packer knows about a project's meshes so it can pack meshes with whitespace stripping without ruining the meshes.
https://github.com/libgdx/libgdx/wiki/Texture-packer

There is also a popular and feature rich (more features than Spine's texture packer) dedicated packing tool called Texture Packer Pro, though it is not free.
https://www.codeandweb.com/texturepacker

Kinvert a écrit

When scaling the skeleton json, can parents and children of parents be scaled rather than the whole thing?

Yes. Please try using the scale tool in the Spine editor. You can manipulate bones at runtime just like in the editor.

Kinvert a écrit

If we find a good way to rasterize the SVGs, will Canvas still work? I didn't understand if Canvas is bad for SVG mesh or mesh in general etc.

You should explore the Spine Runtimes code, it is very clean and relatively easy to follow. Here is the canvas renderer in spine-ts:
spine-runtimes/SkeletonRenderer.ts at 3.8
Drawing even rectangular images with canvas is barely reasonable: transform, rotate, scale just right. Normally meshes are drawn by rendering triangles, usually in batches. Canvas doesn't have a good way to render triangles. There is code there to do it, but it isn't quite right (see blog post linked in the code) and certainly isn't efficient as there's no batching and it uses a lot of operations to draw a single triangle. Canvas is just not very good. WebGL is much, much better. Our web demos page is all WebGL.
Spine: Demos