Unity3D 에서 불투명한 스파인 리소스가 겹치는 문제

Harald · 17 Th02 2020

Thanks so much for your kind words!

I would assume that you are using ZTest LEqual instead of ZTest Less, right?

When it is set to LEqual, you will receive undesired overdraw (double-shadowing) at equal depth, so when there is no Z-Spacing, it will all be at the same depth (= all overlapping shadow areas are incorrectly accepted). When set to a very small value like -0.00001, you have a chance that numerical rounding errors will put two elements on the same depth. Finding a value that is causing no visual problems like -0.001 will always be in the precision range where there is enough numerical precision available so that no two different elements will end up at the same depth.

Note that precision will depend on Z distance between the camera near plane and the rendered element (the vertex position), and also on the distance between near and far plane. So the same Z-Spacing value may be sufficient when the element is very close, but could lead to precision problems when far away. Just keep this in mind so you don't wonder why things suddenly look wrong when placed further back in a scene.

The precise solutions would be the Reverse Draw Order option with Z-Spacing < 0 which is yet to be implemented, or using ZTest Less and Z-Spacing = 0.

titidatiti · 26 Th02 2020

Harald đã viết
Thanks so much for your kind words!

I would assume that you are using ZTest LEqual instead of ZTest Less, right?

When it is set to LEqual, you will receive undesired overdraw (double-shadowing) at equal depth, so when there is no Z-Spacing, it will all be at the same depth (= all overlapping shadow areas are incorrectly accepted). When set to a very small value like -0.00001, you have a chance that numerical rounding errors will put two elements on the same depth. Finding a value that is causing no visual problems like -0.001 will always be in the precision range where there is enough numerical precision available so that no two different elements will end up at the same depth.

Note that precision will depend on Z distance between the camera near plane and the rendered element (the vertex position), and also on the distance between near and far plane. So the same Z-Spacing value may be sufficient when the element is very close, but could lead to precision problems when far away. Just keep this in mind so you don't wonder why things suddenly look wrong when placed further back in a scene.

The precise solutions would be the Reverse Draw Order option with Z-Spacing < 0 which is yet to be implemented, or using ZTest Less and Z-Spacing = 0.

Thank you for reply! I'm sorry for replying late.
The ZTest is set to less actually.
When I rotate the fake shadow to (0,0,0), the overdraw does not occur:

When the rotationX is not zero, the overdraw occurs:

According to your explanation, the overdraw should appear because the pieces are not at the same depth when rotated. Maybe I should use scaleY instead rotationX to achieve a similar result when the Z-Spacing is set to 0.
Thank you!

Harald · 26 Th02 2020

Hm, rotation by 180 degrees is indeed problematic, didn't think of that.
And yes, your solution of using scaleX would be the proper solution, just be sure to set scale to scaleX = cos(angle), this should do the trick.

KKFM94 · 2 Th11 2020

Harald đã viết
이 작업을 원할 경우 다음을 확인해야합니다.
If you want to make this work, you have to ensure the following:

1) 메시 내부의 순서 정렬 그리기가 앞뒤로 변경되어야합니다 (Spine은 투명도를 올바르게 처리하기 위해 앞뒤 순서를 사용합니다)
2) ZWrite를 활성화해야합니다.
3) ZTest를 활성화해야합니다.
4) 알파 테스트는 매우 적극적으로 폐기해야하며 1.0 이하의 모든 불투명도는 잘립니다. 그렇지 않으면 이상한 테두리 윤곽 효과가 나타납니다.

1) Draw order sorting inside the mesh needs to be changed to front-to-back (Spine uses back-to-front order to handle transparency correctly)
2) ZWrite needs to be enabled
3) ZTest needs to be enabled
4) Alpha Test needs to discard very agressively, everything below 1.0 opacity should be clipped. Otherwise you would receive strange border outline effects.

컬 모드를컬백 (Cull Back) '으로 설정하여 달성하고자하는 것을 이해하지 못합니다. I do not quite understand what you wanted to achieve by setting cull mode toCull Back`.

하나의 대안은 RenderTexture를 사용하는 것입니다 : https://docs.unity3d.com/Manual/class-RenderTexture.html.
One alternative would be to use a RenderTexture: https://docs.unity3d.com/Manual/class-RenderTexture.html.

RenderTexture를 100 % 불투명도로 렌더링하고 투명도를 적용하지 않고 RenderTexture를 원하는 불투명도로 오버레이하여 RenderTexture를 간단한 투명한 재질로 적용한 간단한 쿼드를 통해 렌더링 할 수 있습니다 (50 % 투명한). 이것은 귀하의 경우에 가장 빠르고 쉬운 해결책이 될 것입니다.

You could render the character to the RenderTexture at 100% opacity (so without the transparency applied yet) and then overlay the RenderTexture to your scene at the desired opacity via a simple quad with the RenderTexture applied at a simple transparent material (lets say 50% transparent). This would be the quickest and easiest solution in your case.

앞으로는 일반적인 페이드 아웃 시나리오를 보여주기 위해 예제 장면을 제공 할 계획입니다.

We are planning to provide an example scene in the future to show common fade-out scenarios.

please help me how to Change Draworder sorting inside the mesh.
I tried hard but I couldn't find it

Harald · 2 Th11 2020

Without modifying the MeshGenerator code, you could reverse the order of the draw order items in the Skeleton.drawOrder container.
You can access it like this:

var drawOrder = skeletonAnimation.Skeleton.DrawOrder;
// and you should be able to reverse it like this:
drawOrder.Reverse();

Skeleton drawOrder

DarkTI · 20 Th06 2021

Seems like these days drawOrder is a private variable already

Would it be possible to make reversed draw order a parameter of skeleton, similar to Fix Draw Order, in a future version of spine runtime?
As well as make it work during animations too (ie when reversed order is true, the draw order used by playing animations is also reversed).

Harald · 21 Th06 2021

Sorry for the confusion. In the spine-csharp runtime skeletonAnimation.Skeleton.drawOrder is an internal parameter, .DrawOrder is the public getter for it (it was like this in 3.8 as well). I have edited the above posting accordingly. As applies to almost any method and attribute, when the official documentation states lowercase first letter, it likely is uppercase in spine-csharp to follow the common C# coding style.

Ggunspike · 26 Th02 2022

I am also having this problem. I try to follow the above, but nothing makes sense.

Could you please attach a video or download a related example? :think: :think:

Harald · 2 Th03 2022

A new example component SkeletonRenderTexture has been added to the repository on the 4.0 branch, alongside with a fadeout example scene named 'RenderTexture FadeOut Transparency'. This commit will be merged to 4.1-beta soon.

A new 4.0 spine-unity unitypackage is available for download here as usual:
Spine Unity Download

Fftianf · 2 Th02 2024

Harald Hello, I need Blend transparency to render to the editor in preview. I have reviewed your 4.0 SkeletonRenderTexture Code and 4.1 SkeletonRenderTexture Code. The 4.0 code causes rendering failure and irreversibility when the editor is paused, while the 4.1 code does not have this issue, but only renders within the Main camera. I am not familiar with rendering, so I do not know how to correct this issue. Looking forward to your reply.

Harald · 2 Th02 2024

ftianf The 4.0 code causes rendering failure and irreversibility when the editor is paused

What do you mean by "rendering failure" and "irreversibility "?

[..] but only renders within the Main camera
I am not familiar with rendering, so I do not know how to correct this issue.

I'm not quite sure what issue you want to correct. You should be able to assign a different camera at the targetCamera property of the SkeletonRenderTexture component. Did this not work out as expected?

What are you trying to achieve in general?