edesmet

Hello,
In our production we use your photohop To spine script to export assets. It works well and the functionality of composing a json is really interesting and would save us time. However, in practice we cannot use it.

Indeed, we use a rectangular packing and the different image exports don't use a bouding box optimized for the asset but a classic white space trimming on the layers as is.
The packing will be less efficient as we can see on this example:
bubu.png

bubuOptimized.png


It is less interesting in terms of mesh also which are not in the "length" of the parts.
This forces us to rotate the different images manually to find the minimal bouding box and the positioning does not match anymore.
positionning.png

So we can't use the very interesting json function that keeps the positioning and draw order and we have to reposition the different images manually once in spine.

This feature could be integrated in the json export script? Do you have any idea how to do this?

Thanks in advance.
Bu mesaja eklenen dosyaları görüntülemek için gerekli yetkilere sahip değilsiniz.
edesmet
  • Mesajlar: 2

Nick

I used to have the same idea a very long time ago. However, after the polygon packing is available, this is no longer needed.
In fact, it can be implemented very quickly by just rotating the attachment by predefined degrees (e.g. 0, 15,30,45) and see which one provide the best output size. If all you care is the packing of the final texture from Spine, instead of implementing it on the export script, it make more sense to be done in the spine export logic because it is slow doing any thing in export script. Usually, polygon packing is the way to go since most of the time we still need to turn the sprites into polygon meshes in order to create nice looking deforms.
Nick
  • Mesajlar: 273

Nate

Polygon packing can help, as Nick mentioned. Spine's polygon packing will try to find the best texture atlas packing by rotating the images 0, 90, 180, and 270 degrees. Those rotations keep the quality of the images. For any other rotations the image pixels would no longer match the output image pixel grid and would require filtering, affecting image quality. I suppose that could be acceptable in some cases.

Finding the rotation that makes the smallest image in the Photoshop script is likely to be very slow, as Photoshop's scripting capabilities are relatively poor. It could be done as a feature for Spine's texture packer, but that would be pretty complex because Spine would need to adjust the mesh UVs so they still work with the rotated images. I think the easiest place to apply such a feature would be after running the Photoshop script, but before importing into Spine. Such a tool would need to rotate the images and also update the JSON data to set the rotation.

I happen to have some Java code that does the rotation:
http://n4te.com/x/2480-rnUl.txt
It uses libgdx to find all the files, but that could be replaced. It doesn't read or modify the JSON though. That's not super hard, but each attachment would need to be matched up to its image.
Kullanıcı avatarı
Nate

Nate
  • Mesajlar: 11349

edesmet

First, thanks for all your answers.
Unfortunately we don't want to use the polygonal packing for reasons of editing the assets directly on the atlas afterwards as well as to have a mesh as simple as possible by default and edit by hand in spine to have animations that behave well. So I'm currently working on a script (in python) which is placed after the export from photoshop and before the import in spine to be able to do this optimization and modify the json to keep the assets positioning.

when analyzing the export format of your photoshop script I identified some differences compared to your documentation proposed here: http://fr.esotericsoftware.com/spine-json-format
Indeed the hierarchy of skins is not the same:
skins": [
{
"
name": "skinName",
"
attachments": {
"
slotName": {
"
attachmentName": { "x": -4.83, "y": 10.62, "width": 63, "height": 47 },
...
},
vs (my json export from photoshop):
"skins": {
"default": {
"slotName": {
"attachmentName": { "x": 346, "y": -395.5, "width": 122, "height": 241 }
},
where the "attachments" key is ?

Moreover, when using the functionality allowing to export images in subfolders (via [folder:folderName] in the layer name) I get two nested subfolders:

images > folderName > folderName > myAttachment.png

I can't figure out why this duplicate is present here in your script code.

I'm deviating a bit from the conversation but I'd like to understand and eventually be able to send issues to your github which doesn't seem possible: https://github.com/EsotericSoftware/spine-scripts/tree/master/photoshop

Is it possible to submit issues like these or have discussions on the subject to better understand your script?

Thanks for all.
edesmet
  • Mesajlar: 2

Nate

The Photoshop script uses an old version of the JSON format, sorry for the confusion. Spine still supports importing that because we didn't want to break everyone's scripts. There's no attachments key. Under skins, the default is the skin name, then the slot name, then the attachments.

The two folder names has been fixed today, in script version 7.07.

Discussions are best on the forum. The Github issue trackers are best for bugs or pull requests. We don't have an issue tracker for the spine-scripts, but you can post here on the forum.
Kullanıcı avatarı
Nate

Nate
  • Mesajlar: 11349


Dön Editor