Spine-c Runtime questions

Nnarubius · 5 de Mar de 2014

Hi, I'm new to Spine, and I'm working with the generic spine-c runtime in my own 2D engine. Before I purchase Spine and go all-out, I wanted to see how the runtime worked and see if I could get the example animations working in engine.

I'm a little unsure about how to do some of the things I want, whether the generic c runtime is up to date and performs as expected, and how Spine is meant to solve certain problems related to 2D animation. So I'll break up my questions into questions, improvements, and suggestions.

Questions:

When trying to access the renderobject from a RegionAttachment, I get nothing. I would assume that the provided attachment loader would store the atlas page->renderobject on the RegionAttachment, but I am unable to cast back to my custom Texture.
I'm unable to get the goblins to provide attachments that aren't null other than the spear and dagger (only one should be showing up too, not both). I've tried setting the skin manually, etc. and have no luck. All the attachments on the slots are null except for the weapons.

Improvements:

After looking at some of the code in the runtime, I quickly noticed some optimizations that should probably made in the main branch. The first thing is that Spine is storing angles in degrees and converting to radians every time.
Even moreso, the conversion is self->rotation * 3.1415926535897932385 / 180 which is not constant. So every time that code is run, the processor is recomputing Pi/180 which should be a constant.
All the iterables like slotcount, etc. are stored as signed integers. They should be stored as unsigned integers just for clarification and to keep from going out of bounds (just nitpicking).

Suggestions:

Just looking at skeletons in 2D or 3D, Gameplay may want to have authored locations on bones, simply for their transforms. Not to actually store a region or anything. Maybe they want to know where to attach a pouch or where to IK a hand on a weapon. How can someone achieve this without adding more RegionAttachments?
My issue with the way things are structured is that slots don't actually contain transform information. They are simply holding bones and attachments together. Even worse, the transform information is stored only on the RegionAttachment, not the superclass Attachment. I would assume that slots have the transform information for any types of attachments.
I would imagine that slots could have more than one attachment, but I'm not exactly sure how that would play out with lookups and swapping, etc. If that were the case, then slots would have transforms and attachments would too.

Please correct me and let me know if I'm doing something wrong, etc.
I am still very interested in Spine and want to know more about it.

Narubius

Pharan · 5 de Mar de 2014

Hey! Not official:

For the first bullet point under Suggestions;
It's perfectly fine to add a bone to a skeleton in the editor so you can find where to put something in code. Find the bone in the skeleton and what you have access to are the bone's position, rotation and scale relative to the skelton's origin point (I think these are called worldX, worldY, worldScaleX, worldScaleY, worldRotation).
For position, if you combine it with your skeleton object's position with these values, you can get game world or screen space positions (depending on your engine, I guess).

From what I understand of the runtimes, Slots seem to purely serve image-swapping, image-ordering, and other general-holding purposes.
I think the way to think about it would be that only Bones hold logical, usable transforms.

There is offset information stored in image/region attachments purely to allow each image to be aligned properly relative to its parent, but as every image is potentially of different size and shape, each of them need their own offset info. I wouldn't really think of them as "having their own transforms" though this is quite a semantic matter rather than a what-data-is-there matter.

I hope that helps until Nate has official stuff to clear things up for you.

Nate · 18 de Mar de 2014

narubius escreveu

When trying to access the renderobject from a RegionAttachment, I get nothing. I would assume that the provided attachment loader would store the atlas page->renderobject on the RegionAttachment, but I am unable to cast back to my custom Texture.

I'm unable to get the goblins to provide attachments that aren't null other than the spear and dagger (only one should be showing up too, not both). I've tried setting the skin manually, etc. and have no luck. All the attachments on the slots are null except for the weapons.

AtlasAttachmentLoader sets the renderObject to an AtlasRegion. AtlasRegion has an AtlasPage which has a rendererObject that is your texture. See spine-sfml for reference code.

Look at the spine-sfml example, set the skin, then setSlotsToSetupPose.
http://esotericsoftware.com/spine-using ... in-changes

After looking at some of the code in the runtime, I quickly noticed some optimizations that should probably made in the main branch. The first thing is that Spine is storing angles in degrees and converting to radians every time.

Even moreso, the conversion is self->rotation * 3.1415926535897932385 / 180 which is not constant. So every time that code is run, the processor is recomputing Pi/180 which should be a constant.

All the iterables like slotcount, etc. are stored as signed integers. They should be stored as unsigned integers just for clarification and to keep from going out of bounds (just nitpicking).

Every compiler is going to combine PI / 180 into a constant. Converting the rotation from degrees to radians is 1 just multiply.

Using unsigned types for a number that cannot be negative is not recommended. Eg, see Google's style guide (look for "Integer Types", expand that section, then see "On Unsigned Integers"). Also here is a good explanation.

Just looking at skeletons in 2D or 3D, Gameplay may want to have authored locations on bones, simply for their transforms. Not to actually store a region or anything. Maybe they want to know where to attach a pouch or where to IK a hand on a weapon. How can someone achieve this without adding more RegionAttachments?

My issue with the way things are structured is that slots don't actually contain transform information. They are simply holding bones and attachments together. Even worse, the transform information is stored only on the RegionAttachment, not the superclass Attachment. I would assume that slots have the transform information for any types of attachments.

I would imagine that slots could have more than one attachment, but I'm not exactly sure how that would play out with lookups and swapping, etc. If that were the case, then slots would have transforms and attachments would too.

You can use a bone as an attachment point for things at runtime.

Slots are mostly to control draw order in a sane way. Slots having only one attachment is part of keeping things sane. As Pharan mentioned, attachments each have their own transform to define how they are attached relative to the bone (sometimes called the offset SRT). It doesn't make sense to store this in the slot.

Attachments are stateless. If you have many skeleton instances, they will all use the same attachment instances (see diagram). Because of this, the slot does need to store some state that is specific to the current attachment and the slot's skeleton. This is currently just one piece of data: the time the attachment was set (not currently used by any attachment, but will be used for animated attachments). In the future more data will be added, eg the vertices that describe a mesh attachment's current deformation.

I'm also toying with the idea of allowing a renderObject to be set on the slot. This would be used if available rather than the attachment's renderObject, allowing you to customize the texture used by an attachment without needing to create a new attachment. Eg, say you have 100 swords, they are all the same and should be attached to the bone with the same offset SRT. Currently, you could attach them all in Spine, but this is tedious. You could attach one and programmatically create 99 more with different textures, but there is a lot of variables for an attachment and such a common task should be easier. If the slot had a renderObject, you could attach 1 sword in Spine and then easily change its texture at runtime. Changing the texture of an attachment should also be keyable, so it can be animated. This would also apply to meshes, where it solves a problem in probably the best way. You can read more about the problem.