I need to include multiple bounding box rectangles per frame as I’m animating. This is necessary for creating the experience I want to create with my project.
Is it possible to do this with this software?
It’s possible, but there isn’t a great way of exporting the data built-in, you’ll need to either post-process the data, or write a script to make a custom export.
If by “bounding box” you just mean the bounding box of each frame’s pixels, then it’s really easy: if you export the animation as a spritesheet with “trim cels” enabled, the accompanying JSON will contain the bounding boxes.
If your bounding boxes need to be custom and not directly related to each frame’s pixels, the easiest way is probably to draw the boxes on their own layer(s), so you have at most one bounding box per cel (a “cel” is the intersection of a layer and a frame). Then, you can export just those layers (one by one, probably) to get their metadata in JSON form. The frames will be kept from the main animation, so if you also export that, you can get corresponding JSON metadata files for both the bounding boxes and the frames. With the bounding boxes, you don’t even need to export the spritesheet, just the JSON.
1 Like
One option I’ve thought of is labeling the layers with something like;
box=hurt0
box=hit0, # then in this only having ONE outlined shape each layer.
box=body0, # and so on.
The problem with this solution would be offsets and sizing issues. Hitboxes and hurtboxes may very well exist beyond the scope of the graphics. I can abstract as many layers as I need with this, but without specific instructions there could be issues with data.
Another option I thought of was mapping the outlines of all of them pixel by pixel, and then using math to create dimensions without iteration. Iteration being the primary avoiding point here due to needing so many various bounding boxes. In the layer I can include an abstraction using pixels themselves, which would be a form of data through numerics. It’s an old game dev technique to save space in the console era. The problem with this is, while I can assign a great deal of options to pixel values, changing the information will require a pixel translation tool or list if I don’t create an extension.
Another option is to create an extension to add more json information via a generic tag and string information, to create a modified sheet and atlas type for my particular title.
Considering each bounding box may activate a different specific event, it’s important that each box has it’s own information. In this light, I may end up needing multiple tools instead of just one animation software like this.
You could perhaps take advantage of slices and the Slice tool. One of its perhaps lesser know features is that you can animate each slice, and this frame data can be added to the default JSON export in Aseprite, along with the name of the slice, dimensions and position, etc. It takes some fiddling to get it to work, UI wise, and it might take a while to decode the exported fields.
The good thing about slices is that even though they’re used mostly to cut up a tilemap or some sprite into different parts, that “bounding box” (the slice’s Rectangle “object”) is actually independent of content (i.e., the pixels in an image or a layer). You can have a slice outside the canvas and it’s still going to get exported, I believe.
You’d still have to process the exported data though, mostly for renaming purposes, I guess (you don’t want 40 “Body” slices, numbered from 1 to 40 in Aseprite, but rather a Body slice that appended a number based on the frame number, just as an example).
Another downside is that the UI is not very well prepared to use it that way and it tends to be sort of buggy in my experience, as if they haven’t fully implemented those features to the rest of Aseprite.
2 Likes