• EditorBugs

  • 一些在使用中遇到的问题与bug

    中国語

我总结了一些问题与bug，因为我多个版本混用，不知道关于问题或bug的具体出处，但在最新版中验证后发现这些问题或者bug并未被解决，同时还有一些建议，希望能修复bug和不断改进，感谢你们的努力

  1. （bug）点击网格，框选一部分顶点，使用ctrl+数字键存储选中的顶点后，如果使用ctrl + s保存项目，再按相应的数字键，会发现记录过的框选的顶点会消失，取而代之的是整个网格的所有顶点

  2. （bug）给图片设置好网格后，如果在设置模式（非动画模式）下，对这个网格的一些顶点（特别是最外边的那一圈顶点）进行移动，进入编辑网格界面进行设置时，会如果对刚刚移动过的顶点，在其附近创建新的顶点、删除或修改与其有虚线关系的顶点，会发现图片会变形。一开始的顶点移动幅度更多，变形更大

  3. （建议）观察某一个网格的权重时，在权重界面同时使用饼图、叠加和已选，可以有效的观察权重的分布，但是如果某个骨骼的权重占比过小（可能小于10%？），则会显示一片黑色，难以观察到，希望想办法优化一下

  4. （建议）我希望能出一个类似AE或者ps只显示一个图层的功能，比如在图层显示界面单击左键隐藏，右键只显示且能多选？右键双击全显示？如果可以的话还希望能与上面的筛选项配合一下

  5. （建议）当某个骨骼取消旋转继承后，如果再将这根骨骼的父级设置为其他骨骼，会发现这根骨骼会自动进行旋转，我不知道这是否本来就是这样设计的，相对而言每次我都需要手动调整回原来位置或者继承旋转后-绑其他父级-再取消旋转继承

  6. （bug）进入编辑网格界面-描绘-描绘完毕停留在描绘界面时，如果使用ctrl+s退出编辑网格界面，描绘完的网格不会保存，回到了初始状态

  1. （bug）当使用编辑权重-描绘-描绘完毕停留在描绘界面时，如果使用移动-删除-创建的快捷键移动或者删除顶点（特别是最外边的那一圈顶点），返回编辑网格界面会发现图片发生了变形

  2. （建议）在网格描绘界面，细节和凹度的选项很有用，但是精致度貌似没什么作用，这玩意总会导致一堆点全堆在一小片地方，我更希望出一个“间距”，以此来设置生成的点与点之间的间距

  • Misaki がこの投稿に返信しました。
    Related Discussions
    ...

    关于您提到的问题和建议，我将逐一进行解答：

    1. Bug：在使用 ctrl+数字键 存储选中的顶点后，保存项目并再次按数字键时，选中的顶点消失。这可能是一个未被记录的bug，建议在保存前确保所有操作已完成。

    2. Bug：在设置模式下移动网格顶点后，编辑网格时图片变形。这可能与网格编辑的操作顺序有关，建议在编辑前确保顶点位置已固定。

    3. 建议：关于权重显示的优化，特别是小权重的显示问题。可以尝试使用叠加功能来更好地观察权重分布。

    4. 建议：关于图层显示功能的改进，类似于AE或PS的图层管理。这是一个很好的建议，可以提高工作效率。

    5. 建议：取消旋转继承后骨骼自动旋转的问题。这可能是设计上的一个特性，建议在更改父级前调整骨骼的旋转设置。

    6. Bug：在描绘界面使用 ctrl+s 退出后，描绘的网格未保存。这可能是一个未被记录的bug，建议在退出前手动保存。

    7. Bug：在编辑权重时，使用快捷键移动或删除顶点导致图片变形。这可能与网格的初始设置有关，建议在编辑前确保网格的完整性。

    8. 建议：关于网格描绘界面的精致度选项，建议增加“间距”选项以更好地控制点的分布。

    这些问题和建议对于改进Spine的用户体验非常有帮助。感谢您的反馈！

    krammor Thank you for your bug reports and feedback! However, if you post too many different topics in one thread, it can become complicated and difficult to read, so please feel free to create separate threads for each topic if they are different.

    1. Regarding selection groups, in 3.8 the vertex selection state was retained even when the project was saved, but in 4.0 and later versions the vertex selection state is not saved, so this certainly seems to be a bug. Looking at the 4.0 changelog, there were a lot of fixes made to the selection group in the early patch versions, so it may be that the vertex selection state was no longer saved at that time. I have created an issue to fix this: EsotericSoftware/spine-editor843

    2. If it is happening while the Deformed box is checked, it is working as expected and is not a bug. Please see the user guide for details: https://esotericsoftware.com/spine-meshes#Deformed

    3. I think that's an interesting opinion. Do you have any ideas about how it should be displayed?

    4. We have received similar feedback in the past, and there is an issue in our roadmap to improve this:
      EsotericSoftware/spine-editor604

    5. That is the expected behavior. As you are currently doing, it is generally a good idea to enable rotation inheritance once before changing the parent bone.

    6. Hmm, I have confirmed that in Spine 4.2.36, if you press Ctrl+S before finalizing the trace, the trace state is not saved, but I have also confirmed that if you press the OK button for the trace and press Ctrl+S while still in mesh edit mode, it is saved correctly. Since you said you were switching between various versions, could you please check whether the problem can be reproduced with the latest version?

    7. Could you please check whether the state of the Deformed option is affecting the result, as in the case of 2?

    8. I think it's an interesting idea to add the Spacing option, but I think we need to check whether it's possible to add that option while maintaining the speed of the trace calculation, so I'd like to discuss it within the Spine team.

      krammor We discussed the effectiveness of the Spacing option for mesh tracing in the Spine team, and while increasing the distance between vertices can certainly be effective in some cases, the current tracing logic arranges vertices so that the area of the mesh becomes smaller, and increasing the distance between vertices can potentially cause the mesh area to become unnecessarily large. In other words, no matter how we add options, it is quite difficult to get the best results using tracing alone, and there will be some sort of trade-off, so it is recommended that you use tracing to create a rough outline and then make detailed adjustments manually.

      • krammor がこの投稿に返信しました。

          Misaki
          感谢你的回应，我录制了一个视频来诠释这2、6、7这三种情况，这个视频使用的spine版本为最新的4.2.36：

          关于2，其实只要是在设置界面单纯移动顶点或者借助移动骨骼间接移动顶点，再进入编辑网格界面对现有顶点进行修改就会出现这种情况。说真的这种情况有点头疼，当你精心设置好某个复杂网格的权重后，在后期制作动画时想对该网格进行调整就可能会遇到这个问题，只能将就或者再次花费大量时间去重新布网格和刷权重

          关于3，请原谅我提出我不怎么周全的想法，犹如下面这张图一样，当打开权重界面的“已选”选项后，被选中的顶点的饼图将会变得很大，并在周围出现数字：

          关于6，简单测试过4.2和3.8都有这个问题，应该是之前就有的老问题

          关于7，3.8无法重现，原因应该是3.8的快捷键没有涵盖编辑网格界面的移动、删除、创建，什么版本有这三个快捷键哪个版本就能复现这个问题

          关于8，可能我的描述有问题，我的想法是增加一个“间隔”的拖动条，允许使用者对描边时顶点的间距进行设置
          比如这是最新版使用描绘后描绘的结果，但他看起来不怎么好：

          哪怕稍微调整一下参数，也好不到哪里去：

          我的想法是出一个类似于细节、凹度和精致度一样的可拖动条“间隔”，你可以用他来控制描边的点与点直接的间距，比如如果你想间距大点，那将“间隔”的拖动条往左拖拽，你可能会得到（请忽视下方的编辑网格界面，想象你这是在第一张图的编辑网格-描绘界面）：

          此时你又觉得间隔太大了，你想要更密一点的，“间隔”的拖动条往右拖拽，你可能会得到（请忽视下方的编辑网格界面，想象你这是在第一张图的编辑网格-描绘界面）：

          它与细节配合可以同时设置描绘生成的顶点的数量和间隔；与凹度和精致度配合，或许可以适用于一些凹凸不平的图片的网格自动生成

          • Misaki がこの投稿に返信しました。

              • Misaki

              • 投稿 #6
              • 編集済み
              • この投稿は英語で投稿されました

              krammor Thank you for the video and additional explanations!

              Regarding 2, this is by design. When you bind a bone to a mesh, the mesh remembers the transform of the bone at the time of the bind. This is called the bind pose. If the bone is translated, rotated or scaled from the bind pose, the mesh will be deformed. The following blog post, Mesh Binding Tutorial, is helpful to learn more about the bind pose and what to do if you want to change the bind pose later:
              https://esotericsoftware.com/blog/Mesh-binding-tutorial

              Regarding 3, the idea of enlarging the pie chart of the selected vertex and displaying percentages around the pie chart is interesting. I think it could be useful and will consider it within the Spine team.

              Regarding 6, now I understand that you are referring to the behaviour of pressing Ctrl+S before pressing the OK button on the trace. However, I wonder whether this should be saved or not. As far as I have tried on my end, the current specification allows pressing Ctrl+S to save the project even before the trace calculation is complete. However, I don't feel it's reasonable to be able to save a half-finished trace result when the trace calculation has not yet been completed, because the formulae performed up to that point are not saved, and in any case, if you are not satisfied with the result and run the trace again, the trace will start all over again. So should Ctrl+S not be able to be pressed until the tracing calculation is complete? Depending on the complexity of the shape of the contours of this image, tracing can take quite a long time, and in some cases the inability to save the project until tracing is complete can cause frustration for the user. It may be a good idea to display a dialogue informing the user that the trace results have not yet been saved if Ctrl+S is pressed before the OK button is pressed. Do you think it would be helpful in your workflow?

              Regarding 7, thanks to your video I understand the problem! The fact that you can freely edit mesh vertices in this way while tracing is in progress is itself a bug. In tracing it is assumed that only the hull of the mesh can be edited. Created an issue to fix this problem here: EsotericSoftware/spine-editor844
              Thanks for your report as this is an issue that has gone unnoticed for a very long time.

              Thanks for the clarification on 8! This was the kind of use case I had in mind when I read your feedback. But in reality there are so many different shapes of images to trace contours that it is difficult to get it to work well in all cases. In my opinion, it is not necessary to adjust the number of divisions during tracing. It would be easier to use if it worked as a separate function. For example, the current Generate button does not allow you to increase the number of vertices while retaining the weight settings, but it would be more convenient if you could increase the number of vertices without removing the weight settings.

              • krammor がこの投稿に返信しました。

                  Misaki 感谢你的回复，除此之外我没有什么问题了，感谢你们为spine带来更好优化所作出的贡献

                  • Misaki が「いいね」しました。

                    Misaki 再次冒昧打扰一下
                    关于6，我觉得可以在描绘结果计算成功之前设置按下“Ctrl+S”无效，直到结果计算成功。当结果计算完成后按下“Ctrl+S”后则保存当前描绘完成的网格，并直接返回或者退出编辑网格模式。

                    如视频所示，现在存在的问题是：缺少了“保存当前描绘完成的网格”这步。当你在描绘界面结果计算完成后按下“Ctrl+S”后，会不保存描绘完成的网格，并直接退出编辑网格模式

                    • Misaki がこの投稿に返信しました。

                        krammor Thanks for your reply! After seeing your reply, I thought it might be a good idea to save the trace results if the project is saved while the calculation is complete without displaying a dialog, etc., so I created an issue for this improvement:
                        EsotericSoftware/spine-editor845
                        You can subscribe to this issue ticket to receive notifications when there is any progress on this issue.

                        • krammor がこの投稿に返信しました。

                            Misaki 感谢你的回复！

                            • Misaki がこの投稿に返信しました。

                                krammor Regarding the pie chart for weights that you suggested in 3, I have discussed this within the Spine team, but the larger pie might hide other vertices, and if we display the weight values, it might be too small and hard to see, and if you make it large to be readable, it might still hide other vertices or the skeleton itself, which might be distracting. Also, if the weights of the vertices are the weights of a large number of bones, they will be cluttered, so our general feeling is that this may work in some cases, but will not be effective in many cases.
                                Therefore, we would like to know when you actually have a problem with the current UI and when you think it would be useful to be able to check the weight values. Could you give any specific examples of this?

                                • Erika が「いいね」しました。