Questions - Considering Buying Spine

Kinvert

Hello,

I am considering Spine. I am not an animator, so I apologize if these are stupid questions. For each of these questions, if possible, can you please point me to an in depth tutorial?

First Question

We want users to be able to create SVG avatars. These will have the same number of 'joints' or bones.

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.

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?

Next Question

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.

Next Question

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?

Next Question

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. What files do you export after everything is animated? Is it JSON?

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?

I need to know how to take the output from your software and implement it in the website.

Thank you,

Keith

Nate

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

Kinvert schrieb
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 schrieb
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 schrieb
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 schrieb
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 schrieb
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 schrieb
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 schrieb
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.

Kinvert

Thank you. This is very helpful and I'm still reading through some of the details. You guys seem to have good documentation.

I have another question.

What design considerations should be made to make it easier to animate? Chances are I have to hire out the art for one quality version character for the demo before we actually start animating. I want to make sure that what we get delivered will be useful past just the demo.

Thanks again!

Nate

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

This is for a website, so we are working with a database.

How is all of this typically stored?

I assume we have individual Images stored for each body part, such as arm, head, etc, and that goes for each 'skin version.

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

What other things do we store? Do we store JSON in the database for the animation? Do we store the mesh somehow?

Any other things to consider when starting to set up the database?

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

Thanks again Nate!

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

The JSON will somehow need to reference the image files, correct? How do I do that when I'm using a database? Remember this is sort of animating generated avatars so there will be many skins etc. I won't have file names directly, but I can query according to the file name. It won't be grabbing the files from a folder I'll have to do querysets.

I don't know everything about your runtimes but we're working in Python and JavaScript.

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?

Nate

Kinvert schrieb
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 schrieb
Sounds like these will have to be Raster images rather than SVG paths?

Rendering SVG is quite complex. Images are much easier.

Kinvert schrieb
What other things do we store?

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

Kinvert schrieb
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 schrieb
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 schrieb
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 schrieb
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 schrieb
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

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

When scaling the skeleton json, can parents and children of parents be scaled rather than the whole thing? For example a user may have a normal sized character but it has larger ears.

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.

Thanks again for all the help Nate.

Nate

Kinvert schrieb
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 schrieb
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 schrieb
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