Those screenshots you showed look exactly like what the importer would do. You set the cell sizes and then the editor knows what individual frames are.
How would it know which cells correspond to which frames?
If I have a spritesheet with 10 animations on it, and 5 of them share the same frame, or if any of the animations have frames that aren't organized in a linear fashion, how would the importer understand how to import that?
The method I proposed would cover that possibility. So, I'd like to know how your importer would handle that.
Whether or not it displays the entire spritesheet in the editor doesn't seem particularly significant to me - why is it useful to see the rest of the frames when editing a collision poly, for example?
Seeing the whole spritesheet allows more flexibility for editing the image, and making any potential changes to the organization of frames.
You haven't shown how your importer would solve the issue of correspondence. So with your method there is potential to have to rebuild the polygons.
How would your importer handle changes to frame correspondence? Say I have imported a spritesheet. Then I make changes externally that have modifications to the frame order, frame sharing, new frames inserted, frames subtracted, etc. If I reimport the spritesheet, how does your importer handle all of it without having to rebuild the polygons or imagepoints, frame speeds, animation loop/speed settings?
So far you haven't explained how it would solve these concerns.
What does that make possible that was difficult before? It seems fine to just edit that kind of thing frame-by-frame. That seems like a useful view to see when importing a spritesheet, but once the editor knows what the individual frames are... what's the benefit of still treating it like a whole spritesheet?
It allows the user to edit ONE image without having to click through a bunch of panels to edit a whole animation. It essentially smooths the workflow so the user can focus on working on the graphics. If I want to make some pixel modifcations on all the frames, I can do it quicker if I don't have to click through all the animations and frames, changing tools constantly in the process.
It also allows the possibility of adding a contiguous option to the floodfill tool that can make adjusting colors across all frames with one click.
Basically any edits you can make to one frame now becomes easier because you are editing just one image.
Also as I said before, if you force C3 to use an unmodified spritesheet, it effectively is a deoptimisation. You also can't do things like "crop all frames" which allows for a much tighter automatic spritesheet packing which saves memory, and also actually decreases the GPU fillrate which improves rendering performance. Your screenshots could probably save at least half the space, since there's a lot of transparency there. And with other images there could be issues with color bleed. So as far as I can tell, a better spritesheet importer would solve your problem and not have any significant downsides. Am I missing something?
You could still optimize the spritesheets on export. Maybe some people might not want them optimized, so maybe it could be optional.
You seem to imply that the methods I proposed would prevent you to optimize the spritesheets further, but that is a lie. You can cut the spritesheet up into individual frames and reoptimize them when exporting the project if you wanted to. The purpose of having workable spritesheets in the editor is to make editing graphics/sprites a lot easier- to make the workflow smoother.
Everyone who wanted spritesheets, wanted a workable form inside the editor to solve the workflow issues, and they expected it to be in c3 because you said it would be in it. If you don't want to implement it, just say so and I won't waste my time anymore.