C3 Spritesheet feature isn't true spritesheeting :(

Post » Fri Mar 17, 2017 4:28 pm

Prominent wrote:The main thing here is that the whole sheet is shown in the editor

What's the benefit of that if you can import and export whole animations as spritesheets? That seems to solve the problem of managing art resources as spritesheets, but what's the purpose in showing a whole sheet? If you're going to modify the collision polygon for example, you can do that easily enough frame-by-frame, right?
Scirra Founder
B
403
S
238
G
89
Posts: 24,654
Reputation: 196,145

Post » Fri Mar 17, 2017 5:27 pm

Ashley wrote:What's the benefit of that if you can import and export whole animations as spritesheets?

Construct doesn't have exporting of spritesheets from the sprite editor. It only exports per frame, so you have to reassemble them in an external paint editor before doing further work to them, especially if you want to animate them in the external editor. So it becomes redundant work that takes away time.
Then you have to reassemble them into a form that can be reimported back into construct- more time taken away. And what happens if you add or remove frames in the process- there becomes inconsistencies.
Ashley wrote:That seems to solve the problem of managing art resources as spritesheets, but what's the purpose in showing a whole sheet? If you're going to modify the collision polygon for example, you can do that easily enough frame-by-frame, right?

Showing the whole spritesheet has many benefits:
+You can paint anywhere on it without flipping through frames/animations. This lowers the amount of times you must click and reposition the mouse- allowing work to be done more fluidly without pauses. You can apply changes to pixels/details across multiple frames this way more fluidly without swapping between tools/panels.
+If you show the whole sheet, you can rely on one image. So you can export that one image instead of clicking through each frame/animation exporting each one having to reassemble them all into something workable in an external editor.
+You can then reimport just one image, and still have all the frames/polygons/imagepoints still positioned on the sheet where you have assigned them previously. If you have added another frame somewhere in the sheet, or inserted a frame, you can include tools to drag/position those frames to their new locations(you can reposition the frame and it would reposition the corresponding imagepoints/poly relatively). You could just click a frame and drag it across the spritesheet to the new location- duplicate if necessary for new frames.

The frames would have a relative position to the spritesheet, and the imagepoints/poly would be relative to the frame.

Basically this way would lower the amount of redundancy involved, improving the workflow. It would also open up other possibilities, like applying effects across the entire sheet- like changing the color palette.
Also, it might open the possibility of exporting/importing to certain formats that spritesheet editors use.
B
48
S
23
G
66
Posts: 1,144
Reputation: 39,059

Post » Fri Mar 17, 2017 5:38 pm

Prominent wrote:
Ashley wrote:What's the benefit of that if you can import and export whole animations as spritesheets?

Construct doesn't have exporting of spritesheets from the sprite editor.

Yeah, I meant we could add that - so you can export and reimport as a spritesheet.
Scirra Founder
B
403
S
238
G
89
Posts: 24,654
Reputation: 196,145

Post » Fri Mar 17, 2017 5:44 pm

Ashley wrote:Yeah, I meant we could add that - so you can export and reimport as a spritesheet.

Yeah, but what happens if you add or remove frames, or whole animations? How does Construct interpret those changes?
If I export all the animations to one sheet. How do I import all the animations from a sheet.
How do I import a whole sprite sheet with multiple animations(not just frames), into the editor without any prior animation data existing?.. How do I tell construct which frames correspond to which animations in the spritesheet?
If I'm forced to split the sheet into multiple sheets per animation, it doesn't solve the issue.
You're saying all this can be done and still have imagepoints/polygons stay intact? frame speeds? loops settings?
B
48
S
23
G
66
Posts: 1,144
Reputation: 39,059

Post » Fri Mar 17, 2017 5:52 pm

Well, that's why going frame-by-frame also works well - it's unambiguous when you insert a new frame, you know exactly where it will go, or you can copy another frame including all its metadata like collision polys. If you work with spritesheets and add a new frame somewhere, it's not easily possible to tell what changed with the newly imported spritesheet - even if Construct kept animations as single spritesheets. Basically all it can see is it's got more or fewer frames, but it doesn't know where exactly they were added or removed, so where should it move the polys and image points and all that? So spritesheets may be useful as an import format but they don't seem so effective as a way to update existing animations - unless you do an "import the same frames over existing ones" type import.
Scirra Founder
B
403
S
238
G
89
Posts: 24,654
Reputation: 196,145

Post » Fri Mar 17, 2017 6:05 pm

Ashley wrote:Well, that's why going frame-by-frame also works well - it's unambiguous when you insert a new frame, you know exactly where it will go, or you can copy another frame including all its metadata like collision polys. If you work with spritesheets and add a new frame somewhere, it's not easily possible to tell what changed with the newly imported spritesheet


That's not true though- you must be seeing this in a way that makes you believe that the spritesheet format would be ambiguous. It doesn't have to be.
You could still create frame and animations in the same procedure as it is done currently, however it would simply place the frame over the spritesheet. You'd still have the frames displayed in the animation panel, and could reposition them(to determine the play order), select them, etc. When you select them, a box on the spritesheet would display to indicate where that frame is located on the spritesheet. If you select the animation in the animation list panel, all the boxes could display in the spritesheet, allowing you to easily see the correspondence.

The great thing about this method is you can make changes to the spritesheet with lesser impact on the corresponding frame data, because that data would remain in tact and can be adjusted independently. There would be no need to rebuild all the data because it would be already developed- you would simply shift the frames or animations, and all the data shifted(if the artist decides to reorganize the sheet, etc, which wouldn't happen often because the organization is usually planned). Or you could remove or add the frame data, even duplicate it. This would all be done independant of the actual spritesheet, so you can work with the spritesheet without effecting the frame/animation data.

At the moment the sprite image is tied to the data too closely- the spritesheet method allows more flexible workflow that is simpler and less of a hassle with working with many frames/animations. Most sprites have lots of frames and animations, so the spritesheet method I describe makes more sense.
B
48
S
23
G
66
Posts: 1,144
Reputation: 39,059

Post » Fri Mar 17, 2017 7:04 pm

My point is even if C3 does all of that, if you then try to import a spritesheet again with a new frame in the middle, how does it know to shunt along all the metadata of the frames after it? That's a tricky problem. However you seem to suggest that is unlikely...

Prominent wrote:There would be no need to rebuild all the data because it would be already developed- you would simply shift the frames or animations, and all the data shifted(if the artist decides to reorganize the sheet, etc, which wouldn't happen often because the organization is usually planned).


...in which case an "import sprite sheet and replace existing images" ought to cover the workflow of using spritesheets, right? Then the rest of the ideas sound like they're just a different way of presenting the same information.
Scirra Founder
B
403
S
238
G
89
Posts: 24,654
Reputation: 196,145

Post » Fri Mar 17, 2017 7:28 pm

Ashley wrote:My point is even if C3 does all of that, if you then try to import a spritesheet again with a new frame in the middle, how does it know to shunt along all the metadata of the frames after it? That's a tricky problem. However you seem to suggest that is unlikely...

Prominent wrote:There would be no need to rebuild all the data because it would be already developed- you would simply shift the frames or animations, and all the data shifted(if the artist decides to reorganize the sheet, etc, which wouldn't happen often because the organization is usually planned).


My point is that it wouldn't need to do that automatically. The user could manage that more efficiently if the frame/animation data is controllable independently of the spritesheet.
Your proposed addition doesn't solve the issue of managing frame/animation data whenever the sprite animations are changed externally, because how would it know the correspondence with those changes.
In either your case or my case, it wouldn't be able to know the correct correspondences to all the potential changes. In my case however, the frame/animation data is independent and can remain present regardless of additions/subtractions from the spritesheet. This would allow flexibility in the workflow.

Ashley wrote:...in which case an "import sprite sheet and replace existing images" ought to cover the workflow of using spritesheets, right? Then the rest of the ideas sound like they're just a different way of presenting the same information.

But your proposed method can't determine correct correspondence to all potential changes to the spritesheet being imported. What if frames are reordered in the spritesheet, removed, added, changed, resized, etc. You proposed method wouldn't cover these cases.
However, my proposed method allows for this flexibility. Regardless of whatever changes are made to the spritesheet, the frame/animation data remains as defined by the user and can be adjusted manually for whichever changes they made to the spritesheet without having to recreate the data. Nothing is lost while the spritesheet is being developed- the animation/frame data can be modified to reflect the current designs of the spritesheet.
B
48
S
23
G
66
Posts: 1,144
Reputation: 39,059

Post » Sat Mar 18, 2017 1:40 pm

Prominent wrote:My point is that it wouldn't need to do that automatically. The user could manage that more efficiently if the frame/animation data is controllable independently of the spritesheet.

Based on what you wrote, I imagine a new window with the imported spritesheet displayed and coloured rectangles on top of it with the collision polygons to represent the frames. Then the user could drag and drop those rectangles to reorder them manually on the spritesheet while the frames would keep their data (collision polygons, image points, etc.). Is this what you're proposing?
B
137
S
33
G
17
Posts: 1,560
Reputation: 20,797

Post » Sat Mar 18, 2017 4:13 pm

glerikud wrote:
Prominent wrote:My point is that it wouldn't need to do that automatically. The user could manage that more efficiently if the frame/animation data is controllable independently of the spritesheet.

Based on what you wrote, I imagine a new window with the imported spritesheet displayed and coloured rectangles on top of it with the collision polygons to represent the frames. Then the user could drag and drop those rectangles to reorder them manually on the spritesheet while the frames would keep their data (collision polygons, image points, etc.). Is this what you're proposing?


Maybe- let me show some images of what it would be like just to be clear (I made these sprites by the way).. This is just a rough concept, but shows how the gui doesn't need to change at all.
In this first image, it shows all the boxes for the currently selected Animation in the animation list:
Also note how I've added a new tool on the toolbar- these new tools could be used to position/resize the boxes that define where the frames reference the spritesheet.
Image

In the next one I show what happens when you select a frame from the frames list on the bottom:
You'd be able to position/resize it via new tool(s) on the left toolbar and the x,y,width,height inputs above.

Image

Next I show how the polygon is displayed for the currently select frame when you have the polygon tool in use:

Image

As you can see, the frame thumbnails in the frame list show the corresponding area on the spritesheet. None of the gui has changed. The main window shows the spritesheet.
And yes glerikud, if you reposition one of the boxes, it would reposition the corresponding imagepoints/polygons as well.
There could possibly also be a way to click a button to hide the rest of the spritesheet and just show what is within a box.
@Ashley

edit: also, faulknermano explained it well and added another idea that would make it even more flexible: c3-spritesheet-feature-isn-t-true-spritesheeting_p1108695?#p1108695
Last edited by Prominent on Sat Mar 18, 2017 11:07 pm, edited 2 times in total.
B
48
S
23
G
66
Posts: 1,144
Reputation: 39,059

PreviousNext

Return to General Discussion

Who is online

Users browsing this forum: No registered users and 1 guest