• Announcements
  • Spine 4.2 imports PSDs directly, no Photoshop scripts needed

Nate
Really excited for the ability to directly import PSDs into Spine!

I have a question re: it though. PSD does not show up as an option for me when I try to import data, just JSON and binary file. Is there a step I'm missing, or is there a reliable way to troubleshoot this issue? I'm on Mac OS and I'm on the latest beta version, if that helps. Additionally, the PSD file is all flattened layers (less than 30), with no hidden layers or anything fancy.

I'd appreciate any advice; thank you!

  • SnzdIV ha risposto a questo messaggio
    Related Discussions
    ...

    dlcolon It's a separate import option : top left > spine > import PSD

    • dlcolon ha risposto a questo messaggio

      SnzdIV
      Thank you so much! I actually found it after I decided to play around with the file using the tried and true PhotoshoptoSpine script. I guess the beta got jealous and decided to show itself lol

      Yep, we decided it was more visible as its own option rather than overloading Import Data with more stuff.

      It's worth mentioning again a drawback to Import PSD, which is that layer styles need to be rasterized by Photoshop before saving the PSD. If you aren't using Photoshop, other image editors may always do this when writing a PSD.

      Hi, thank you so much for this. I no longer need to keep PS!
      I have a question, does "Use layer mask bounds instead of whitespace trimmed bounds" thing work on the current version of PSD import? Because it seems to me it's ignoring layer masks when trimming, while it's said all the tags are supported. (technically not a tag? but i can't live without it!)
      Again, thank you for this wonderful update!

      Hi Chive!

      The "Use layer mask bounds instead of whitespace trimmed bounds" feature has been implemented, but we've decided to activate it using the tag [trim:mask]. So essentially, for the trim tag, we have the following options:

      • [trim], or [trim:true], or [trim:ws]: trims at whitespaces
      • [trim:false], or [trim:canvas]: trims at canvas
      • [trim:mask]: trims at the layer mask

      However, I've just noticed that currently it doesn't seem to work as expected 😱

      To ensure we're on the same page, could you show me an example of your layers structure and explain the behavior you're expecting?

      Thank you Davide!


      the structure's something like this!

      and then I exported PSD from ClipStudioPaint, tested exporting with:
      ①Photoshop script(Photoshop CC2024)
      ②Spine PSD import of 4.2.61-beta.
      (both are set padding=0)

      the results are: ①trimmed as intended, using masks as bound, ②whitespace trimmed with 0 padding.
      And then I tested exporting without [merge]tag and layer groups, as individual layers with masks, got the same result from ②.

      I didn't know about [trim:mask] tag! thank you for the info. I assumed it'd automatically work as it's been like that as the photoshop plugin.
      I tested again with [trim:mask] tag, but as you said it doesn't seem to work. it's resulted with whitespace trimming.

      Thank you for looking into this!

      The mask value for the trim tag is new, and since we're currently in the process of writing the documentation, you couldn't have known that 😃

      In any case, thanks for pointing this out; it helped us discover a bug! 😅
      I'll let you know as soon as we fix this.

      Thanks! I'll look forward to it!

      • Davide ha risposto a questo messaggio

        chive

        We realized that the [trim:mask] tag was working only on layers.
        We just implemented this feature also for groups.
        You'll be able to use it in the next beta release (4.2.62-beta) that will probably be ready tomorrow!
        Let us know then if it works as expected 😃

        It seems that the adjustment layer does not work. I've tried it with clip studio paint and affinity photo.

        • Davide ha risposto a questo messaggio

          Bloss0mx

          Adjustment layers are not supported yet, and since it will be complex and time-consuming to implement them, I'm sorry to say that it won't happen soon 🙁
          If you really need them, you can still use the Photoshop to Spine script.

          May I ask you which Adjustment layers you use more frequently? Since there are a lot, it might be helpful to define a priority among them.

            Davide I'm using brightness / contrast adjustment layer, hsl shift adjustment layer and curves adjustment layer in clip studio paint and affinity photo.

            I dont get how to making linked mesh working.

            The logical things for me is to prepend the skin like:

            but

            So i understand it search inside the slot.
            Let's check what skinName i need to put here

            OK the skinName seem to be small-colorable.
            let's try

            Humm

            So i thinks i need to input the full path name after the skinName
            Let's try.

            Hummm
            why it thinks source mesh is "small-colorable".
            Hoow you dont input the skinPlaceHolder.
            Give it a shot.


            What im doing wrong ?
            i've tried with blank file without big lenght of skinname it's doesnt work.
            Thanks for watching this demonstration for how to not work with linked mesh

            • Davide ha risposto a questo messaggio

              @valahaha Sorry you are having trouble! We're working on documentation and Davide will be able to help you out tomorrow. In the meantime, it would help if you can post or email (contact@esotericsoftware.com) a PSD showing what you tried. Then Davide can modify and send it back to you without needing to setup something similar from scratch.

                Nate Hey, thanks for the answer.

                You dont have to be sorry, it's a new features in beta, that's normal.
                I dont really need linked mesh for now, it's more for testing purpose.

                I've tested so many things but i can wait for the documentation.
                I will send a psd files.

                have a nice day

                • Nate ha messo mi piace.

                TRY 1 =
                at s.bqM._(_:197)
                at s.kPv._(_:408)
                at s.ePX.B(_:303)
                at s.ePX._(_:294)
                at s.JjN._(_:313)
                at s.Ipp.run(_:247)
                <events>
                Cause: s.BBp: Parent mesh not found: SCARF
                at s.GLq._(_:395)
                at s.NAy._(_:118)
                at s.bqM._(_:168) ...

                Can't get it working

                Thanks for any help ..

                Cant upload psd here, and sended the mail, response was to post here.

                https://mega.nz/file/0uIkxaaJ#kvLKa-ofNWqiqI9FUr6tfwa8tGRjK5qCQ81tDIRBhRs

                valahaha
                Hi valahaha, I'm sorry you had so much trouble making the linked mesh work.

                You actually helped us in finding another bug 😃
                The target source mesh detection is currently failing when the linked mesh tag value depth is higher than 2, where the depth is the number of parts separated by "/" in the tag value. We have fixed this problem and you will find the fix in the next beta release.

                In general, the syntax for the linked mesh tag value is:

                The linked mesh tag value must be the full attachment name of the source mesh, as it is in Spine. That's the only way to indicate uniquely the desired source mesh.
                Moreover, the linked mesh must be in the same slot as the desired source mesh. This implies the usage of the [slot] tag somewhere to make the source and linked mesh be in the same slot.

                In your example, you have two SCARF[slot] folders, and one of them is ignored, so I suppose you want to focus on the folder with skins. In order to make the small-colorable scarf the source mesh of the small-green scarf, you need to add:

                • [mesh] to the small-colorable scarf
                • [mesh:equipment/neck/scarf/small-colorable/scarf] to the small-green scarf because equipment/neck/scarf/small-colorable/scarf is the attachment name of the source mesh.

                  Davide DAMN i love you, spine team, we always got our back covered that insane !

                  Thanks for all !

                  • Davide ha risposto a questo messaggio

                    valahaha

                    Thank you for your appreciation! 😊

                    4.2.64-beta has been released with the aforementioned fix.
                    However, we had an internal discussion and decided to simplify how the source mesh can be indicated for a linked mesh.

                    As long as there is no ambiguity, you can now specify only the ending part of the attachment name of your source mesh.
                    In your example, you have in the SCARF slot the following attachments:

                    • equipment/neck/scarf/small-colorable/scarf
                    • equipment/neck/scarf/small-green/scarf

                    You can now just add [mesh:scarf] since there's no ambiguity in which attachment you want to select (the linked mesh itself is excluded from the research).

                    If you had another scarf in your slot, for example:

                    • equipment/neck/scarf/small-colorable/scarf
                    • equipment/neck/scarf/small-green/scarf
                    • equipment/neck/scarf/small-red/scarf

                    You would need to add [mesh:small-colorable/scarf] because there would be ambiguity with the small-red/scarf attachment.
                    But it's definitely more concise than writing the entire equipment/neck/scarf/small-colorable/scarf attachment name.
                    In the case you write an ambiguous attachment name for the source mesh, an error dialog will list the candidate meshes and ask you to be more specific.

                    This will be available in the next beta release.