• Editor

  • I tried to export with command line but not file is created.

    الإنجليزية
Related Discussions
...

  • Nate

  • منشور رقم 21
  • هذا المنشور باللغة الإنجليزية
Nick wrote

** warning ** I am not a native English speaker. Sometimes people may find my way of expressing my thought a little rude. I want you to know that it is not what I want to achieve in case you get bad feeling reading the post.

Understood, no worries. It is a good reminder though that text can be difficult to judge tone. We should all assume the best intentions!

Nick wrote

I don't think I can change your mind.

I have to make a lot of decisions and (usually!) have put a lot of thought into them. I do care about what you want, if I didn't I wouldn't bother explaining why I think as I do. Consider my explanations not as being defensive, but as being open so you can address whatever is preventing me from agreeing. I am always open to being convinced something is better.

Don't give up! Focus on the problem you are having, not necessarily a particular solution you think is best, and we'll find a way to make it nice.

Nick wrote

I am talking about keeping things simple while you are talking about functionality and making things flexible from a programmer stand point.

What we provide has to work for everyone in every conceivable situation, so we aim for flexible first, then easy to use next, in the order of the most common use cases.

The runtimes are really for programmers. Some game toolkits allow doing a lot with a UI, but at some point code will need to be written. Still, I hear what you are saying, that you are doing something common and it's not as easy as you'd like.

Nick wrote

We all know it is not good to have things duplicated but for productivity, it is a trade off, a good deal and is not a problem at all.

The skeleton data is designed to be loaded once, then shared across multiple skeleton instances. Duplicating skeletons goes against this and isn't how we designed it to be used. I don't want to throw the design out the window as a workaround for how images are packed.

Giving it some more thought, it could be that we need more powerful texture packing. Here's two ideas:

1) Maybe when you pack a skin folder, you could give the texture packer a prefix for the region names. From my examples above, if you are packing images/skin1 you could specify skin1/ as a prefix, resulting in region names like skin1/head/red.png.

2) Or, when the texture packer knows the Spine project, it could detect when packing a subfolder of a skeleton's images path and adjust the paths so they match what they were in Spine. In the above example, if images is the skeleton's images path, the packer would see the root of the input folder images/skin1 is under the images path and prefix skin1/ automatically. This seems pretty good, as you don't need to specify the prefix manually.

With that you can pack an atlas that contains only a subset of the Spine project's images, but still has names that match the attachments in Spine.

The next part is that you want to load skeleton data with an atlas that doesn't contain regions for every attachment. Currently AtlasAttachmentLoader throws an error, but we could add a setting so it just doesn't set a region in that case. That could show up as a checkbox in game toolkit UI.

What do you think?

  • NNick

    • منشور رقم 22
    • هذا المنشور باللغة الإنجليزية

    Sorry but I got a lots things in my hand and don't want to get into this topic anymore. You should be busy fixing those export bugs too as the last export bug mentioned here: http://esotericsoftware.com/forum/exported-images-are-corrupted-in-latest-beta-15489 is actually quite easy to happen. I found that almost half of my exports (150 spine projects) has this issue. My game is quite visual broken right now after upgraded to use v4 beta export.

    To summarize my point of view about the discussion here, I would say being able to do selective export from the editor with the 'export' check box on the skin is amazing. I am sure it is very useful to many users. Not being able to override that checkbox value from command line is an inconvenient / a disadvantage to the software. Regarding the suggestion here, the effort of doing all those things are adding too much burden to the workflow. I believe most of us would rather choose do the selective export from the Editor which is simple enough and do not introduce restrictions on image folder nor adding more code to the project. It is a little inconvenient to open the project and toggle the skin check boxes but hey it works! and it is easy to follow and anyone, esp the artist, can do it.

    • Nate

    • منشور رقم 23
    • هذا المنشور باللغة الإنجليزية

    When you have a problem, it's productive to let us know so we can provide a solution. It's not productive to propose a solution, ignore the reasons why it's suboptimal, decline to discuss alternatives, and continue to propose the same, suboptimal solution.

    In the future we'll likely have the texture packer adjust the region names as described above.

    • NNick

      • منشور رقم 24
      • هذا المنشور باللغة الإنجليزية

      Nate, sorry to hear that you feel this discussion this way.

      The only reason I post this topic and I drop this discussion is to be productive on my project. I am not here to help you achieve you optimal solution but to help myself save more time on workflow. Continuing this discussion do me no good.

      If I can go from Editor check box export to -skin command line, it is improvement to my workflow.
      If I go from Editor check box to the solution you provided, with all those restrictions and additional works, it is not really helping my workflow.

      As I said, we are focusing on different things here and I don't have anymore new discussion point to offer and I don't see this discussion going anywhere so I decided to accept that -skin CLI is not going to happen and I choose the next best solution in terms of productive for my project.

      Whether it is suboptimal, I am NOT ignoring it. I accepted it and told you this is a tradeoff between simplicity and 'optimal' on the project.

      If you still don't understand why I don't like your proposed solution, try to answer these questions:

      1. How much time you need to type -skin "the_skin_name" ?
      2. How much time you need to open a .spine project and toggle the export check boxes and do export?
      3. How much time you need to spend to do all the stuff you mentioned in the 'optimal' solution?

      Now tell me:

      In term of productivity, which on is the best and which is the worse?
      In term of project maintenance (simplicity), which one is the best and which is the worse?
      In term of risk, which one is easy to make mistake?
      In term of people involved, which one is the minimal and which one require more people? e.g. artist, programmer

      Do you now see the reason why I continue to propose my suboptimal solution and keep declining to discuss your optimal solution? The point is I don't need that extra optimization in the cost of sacrificing the things mentioned above.

      Let's just move on and have a nice day.

      • Nate

      • منشور رقم 25
      • هذا المنشور باللغة الإنجليزية

      I can appreciate you want something that works for your use case and makes your life easier. As the architects and domain experts, we have different goals: to find what works best for all users in every possible use case.

      Duplicating a skeleton for each skin is not a workflow we want to promote. The workflow I proposed will be much better: run the texture packer for each skin, so each atlas contains only regions for that skin. Then you just use that atlas at runtime, after checking a box so missing regions are not an error.

      2 أشهر لاحقا

      • Jjimanjr

        • منشور رقم 26
        • هذا المنشور باللغة الإنجليزية

        Hey Nate,

        I would like to continue the discussion if possible and bring my own arguments for a single-skin export.

        The big issue here is that the way Unity works at the moment, all references are automatically loaded. There is some movement towards the Addressables worflow and use of AssetReference instead, but for the time being once you reference an AtlasAsset, all the textures get loaded. We are trying to avoid that.

        The proposed solution with a different AttachmentLoader would only block some sprite references being assigned. The reference to the materials and textures would still exist and Unity will still load them netting us absolutely no win. Furthermore, we use the SkeletonAnimation component to instantiate our characters and I can't find a way to configure that component with a custom AttachmentLoader. Even if we went past that and found a way to specify a different AttachmentLoader to the component, it would mean that things that are already done automatically now would need to be handled by ourselves (reference the textures, load them, assign them to materials and to attachments).

        The small size of the skeleton data is actually exactly the reason we prefer this solution. We can duplicate the skeleton data multiple times (taking a hit of maybe 200-300KB) and avoid loading all the textures (90MB in our case).

        I don't know what the perfect solution would look like. Perhaps Spine supporting the Addressables workflow with AssetReference to the materials instead of direct references. But that sounds like a massive task for you guys that might not be worth it atm.

        Lastly, I guess you could consider this a "niche use case", but we can't afford to have our single artist maintain 90 different skeletons just to avoid the "bad habbit" of duplicating skeletons. We will happily take the "one file, 35 skins" approach any day over "one file per skin". What Nick is actually doing above would be an upgrade to our workflow and we will actually start using that to cut down on our memory usage

        • Nate

        • منشور رقم 27
        • هذا المنشور باللغة الإنجليزية

        Ignoring Unity for a moment, our runtime design separates the skeleton data from the atlas. In the most common use case the atlas has all the images for all the attachments in the skeleton data. If that doesn't work for you because such an atlas would be very large, you would still load all the skeleton data but instead load an atlas with only the images you need. This is a very straightforward solution.

        It has been suggested to create a copy of the skeleton data for each skin, with each copy having only that skin. Also you would create an atlas for each skin. This would give you an atlas that has images for all the attachments in the skeleton data (even though that has never been a requirement). This would solve your problem, but it is not a good solution and we do not recommend it.

        The skeleton data and atlas are not tightly coupled. There is no reason that the atlas has to have all the images for all the attachments in the skeleton data. You can load skeleton data with an atlas that contains only a subset of the images. You can load skeleton data and pack your own atlas at runtime from individual images. You can load skeleton data without any atlas at all. All the flexibility is there for any use case.

        That said, now we can talk about Unity. Harald is our Unity expert, so I will ask him to address that side of things. If our spine-unity APIs or Unity editor interface are tedious or awkward when your use case is to load an atlas that contains a subset of the images, then we are happy to improve that.

        • Jjimanjr

          • منشور رقم 28
          • هذا المنشور باللغة الإنجليزية

          This is absolutely 100% a Unity issue related to how it interacts with your SDK. I totally understand the design decisions otherwise.

          • Harald

          • منشور رقم 29
          • هذا المنشور باللغة الإنجليزية

          Automatic loading of all referenced atlas assets has been a thorn in my side for quite some time. I'm sorry that we didn't yet get to implement a comfortable solution for this problem.

          I have now created an issue ticket here for this feature, describing a potential implementation which should provide for a comfortable Inspector interface:
          https://github.com/EsotericSoftware/spine-runtimes/issues/1890
          Please let us know what you think, especially if you see any problems with the planned implementation.

          • Jjimanjr

            • منشور رقم 30
            • هذا المنشور باللغة الإنجليزية

            Thank you for looking into this! As specified above by Nick and by me, the ability to export a single skin into a skeleton from command line would help our workflow tremendously.

            As for a built-in feature for this, Unity on-demand loading of assets seems to be heading towards Addressables:

            1. Resources is slowly being deprecated by Unity in favor of Addressables (and most of the time people suggest not using Resources for performance reasons) so I don't think investing into that type of solution would be a good idea
            2. AssetBundles are actually also being transitioned to Addressables
            3. Addressables seems to be the right way to go about this and even supports inspector editing using AssetReference class

            • Harald

            • منشور رقم 31
            • هذا المنشور باللغة الإنجليزية

            Thanks for the feedback, always much appreciated. Unfortunately Addressables are not available on Unity versions 2019.1, 2018.3 and earlier, and on none of the 2017 versions. While we would like to favour Addressables and newer technology, we know of many customers who have their existing workflow based on asset bundles, so this might still be worth supporting. We might prioritize the implementation accordingly, however.