你好!或许你已经解决了这个问题,但我还是在这里写一下我的理解。
这8个值都是控制点的坐标,未经归一化处理。
前面4个值是x方向变换的贝塞尔曲线的两个控制点,后面4个值是y方向变换的。你的情况下只有y方向的变换,所以前面两个控制点的cy1,cy2都是0,实际只有后面4个值有用。
如果在graph窗口观察,应该能更直观地看出这些值就是控制点的坐标(不要在curve窗口观察)
lenore Is it possible to make it look like Spine's gamma color space in Unity without changing the color space settings?
Short answer: no. If it were possible in a reasonable way, we would do it automatically. It can't be done by e.g. performing some additional math in the shaders.
If you prefer Gamma space blending, it's highly recommended to use Gamma color space in your Unity project. Is there a reason why you don't want to change the Unity project setting?
If you really can't do that, your next best option would be to change the Spine Viewport settings to
Linear
to match your Unity project, as described here.If you want to know why it's not possible:
The important part of the blending pipeline happens outside the shaders that we can control. WithLinear
color space active, all objects are rendered to a (linear) frame buffer (FBO / render texture) which is then at the end converted once from Linear to Gamma color space. What would be necessary, is to render all Spine skeleton objects to a custom render texture in Gamma space, and then convert the result to Linear space and render it to the normal scene. However, this workflow has the following major problems:
1) it only blends skeleton objects in gamma space, the resulting skeleton objects are blended with the scene in linear color space.
2) You can't interleave Gamma space skeletons and normal Linear scene objects.
3) It comes with an unnecessary performance overhead which is best avoided.Never mind. I uninstalled and downloaded the new launcher. Seems to be fixed now.
Nate thanks for the reply! And yeah, no worries - I am aware that updating version 4.0 won't be possible and was hoping that maybe somebody could help me understand what was causing the issues and how to avoid them, but at the end (I think) I got to the "root" of the problem myself.
Maybe this will help somebody else also working with GMS and similar cases.
And yeah, I could really use the physics features.
- Dans spine-unity 4.3-beta
We can't provide any useful estimates, sorry. To give you some information to work with: almost all the core spine-csharp and spine-unity runtime code is done porting, however testing will show if or how many bugs need to be fixed after that.
- Dans Rigging accordion
Here's a quick and super simple example, let me know if it's what you were going for or if there are issues!
accordion.zip57kB Harald Thank you for the incredible package! I just wanted to say that this is a game changer. I was planning this elaborate pipeline with Addressables and Attachement API and runtime only skins while loading the images from project folders, but now I can simply export from Spine and it's nearly automatic with no worries about load times or memory budget. Tons of work saved on my side.
Nate I have received the relevant push notifications and noticed your fixes for spine-sfml and spine-cpp. Please excuse me for not being able to conduct the test immediately (due to the 12-hour time difference). I checked the newly fixed part and noticed that it corresponded the logic of cpp to c and changed the logical judgment. This also confirmed my previous conjecture. I will perform batch operations on my model library again later to verify if there are any other problems. All in all, thank you for your help!
Davide thanks you, i set up index.html and everything works; i will try to connect all this with Vite
borleech Thank you for creating this thread!
The reason the mesh shape and attachment switching did not work as expected with your skeleton is that the Mix value for the
Slider Arm L
slider in the setup was set to 100. This caused the pose of theSlider Arm l
animation to affect all animations, resulting in improper attachment switching. Setting the Mix value forSlider Arm l
to 0 in the setup mode should resolve the issue.If the problem persists, please let us know.
Nate
Well that's unfortunate to hear but probably for the best.
In my case, sliders is probably not the best solution since I have a lot of variability going on in what I'm doing. To give you one example, I have about 30+ hand "states" (unique attachments) for each arm, which are used on base and overlaid animations. Creating 60 sliders to be able to clear the attachment mid animation is probably not the most elegant way to go about it.
Still, I fully understand this would be a rare niche use of what Spine usually does and it doesn't warrant burdening the rest of the program for what amounts to quality of life feature rarely used. Besides, I already have workaround ways to handle these issues in place (clone attachments into different slot, hide main hand instead of disabling attachment). As you implied, with sliders this falls into ease of use and smoothing workflow, not functionality.Thanks for the attention and please keep doing what you're doing, these new tools are amazing
답변 감사합니다.
Harald가 답변한 예제 코드를 확인한뒤 Nate가 답변한 큰 템플릿 이미지를 사용해서 해결했습니다.
큰 템플릿 이미지를 메쉬어태치먼트로 사용하여 다른 이미지로 바꿀경우 비슷한 사이즈의 경우 괜찮았지만 템플릿 이미지보다 작은경우 원하는 결과를 얻을수없었습니다.
템플릿 이미지를 대, 중 소,로 구분하여 메쉬 어태치먼트를 생성하고 커스텀 시리얼라이즈로 메쉬 어태치먼트 정보를 저장하여 런타임에서 메쉬 어태치먼트와 텍스쳐를 선택하여 스킨을 만든뒤 기존 스파인에 적용할수있었습니다.
Nate Oh nice to hear that issue related to box selection it's fixed!
Yes, when I restart Spine, the bug with audios disappear, at least until it appears again when I switch to other project or something related to any modify at audio folder.
It's hard to find out what causes this bug exactly. If I discover anything, I'll come back here.
Thanks! Have a great day!
The long audio will be replaced by a shorter one in loop, I always cut the audios to not overpass the last animation's frame. But I don't think this is the issue, because I get the bug with shorter audios too.
Maybe it's just a pile of circumstances (audio folder in Unity, working with GitHub, modifying audios through a web...) and it seems hard to reproduce from zero.
I'll let you know if I find out something else that could help.