I'm working with canvas/webgl, so, basic javascript here. I noticed in some of the examples it being possible to generate a dropdown list with all available animations. This was the code provided:
function setupUI () {
var setupAnimationUI = function() {
var animationList = $("#animationList");
animationList.empty();
var skeleton = skeletons[activeSkeleton].skeleton;
var state = skeletons[activeSkeleton].state;
var activeAnimation = state.tracks[0].animation.name;
for (var i = 0; i < skeleton.data.animations.length; i++) {
var name = skeleton.data.animations[i].name;
var option = $("<option></option>");
option.attr("value", name).text(name);
if (name === activeAnimation) option.attr("selected", "selected");
animationList.append(option);
}
animationList.change(function() {
var state = skeletons[activeSkeleton].state;
var skeleton = skeletons[activeSkeleton].skeleton;
var animationName = $("#animationList option:selected").text();
skeleton.setToSetupPose();
state.setAnimation(0, animationName, true);
})
}
setupAnimationUI();
}
I can see we're iterating over skeleton.data.animations.length, grabbing the name with skeleton.data.animations.name, rendering out the html, and then swapping out the animation new option is selected.
However, I'm hoping for a way to generate a list of all possible attachments in a given slot. I actually already know how to swap out attachments with skeleton.setAttachment(slot, attachment), so recreating the latter half of the above example above won't be difficult for me.
So, what should I be iterating over, if I wanted to generate a list of all possible attachments under a slot named "head", for example? I could manually write out a list, but I just have so many attachments for each slot that I don't want to even begin to write them out by hand.
This will be a big help, even though some some of my items will inevitably operate in a skin-like fashion (sometimes an item will need multiple attachments over multiple slots). However, I feel limited by the existing skin system, so I'll be manually writing code to handle some situations. Here is a working (though miniature) example, where I've written out the list of attachments in each slot by hand: http://kyttias.tk/avatar_demo/
(If anyone is interested in the demo above and want a closer look, I'm providing this zip file open source! It includes all the json data, images, atlas files, and even the spine and psd I created the art in. On the surface, it looks similar to the existing "skins" demo in the webgl bundle on git, but there are absolutely no skins involved and it's purely individual attachments, sometimes linked by code. My reasoning is mysterious, I know, but this is just what fits my needs better.)
While I'm mostly just here hoping I can find a way to iterate over all possible attachments in a slot to generate a drop down list, I do have one other question. I've only looked at webgl for rendering to html5 canvas because it seemed to have the widest implementation of spine's current features (due to limitations in the other methods?) but I'm kind of wondering if I could just... maybe... not use atlas files? And if I need to use something other than webgl to render to canvas, that's fine, I don't need all of the newest features, nor even meshes, just simple rotations, translations, and scaling.
See, unrelated to the demo given above, I'd like to port over the avatars from a flash game to html5 and while you think 7180 attachments in 23 friggin' huge atlas pngs would be the better route, the atlas files actually (surprisingly) take up more room on disk than the individual items, anyway (in my extreme case). They also take a good 10 minutes to pack each time I need to make any edits. And, while I'm impressed spine loads all of this in about 5 seconds, my fast internet is mostly to thank here. I'd really prefer to only load the currently attached attachments, not massive atlas pngs, if possible. The majority of these attachment images will never ever change, but the atlas pngs will constantly be trying to rearrange the images in new ways each time they're repacked (which will be weekly as new items are added). They just can't be cached the way individual images can be. The largest of the atlas pngs is capping it at over 10MB
and total? Well, let's just say it's unreasonable to ask users to download 43MB of image data that can't be cached for very long. I'd really rather have users only load what NEEDS to be displayed. (And for my sanity, I'd rather not spend my time waiting for the texture packer to do it's thing without so much as a progress bar indicating it's actually doing anything, nor telling me when it's done.) So... thoughts?
I'm sorry this is a lot to respond to in one post. D;