MizunagiKB / gd_cubism

Unofficial Live2D Player for Godot Engine
https://mizunagikb.github.io/gd_cubism/
Other
154 stars 17 forks source link

Addition and multiplication operations are not available. #7

Open MizunagiKB opened 1 year ago

MizunagiKB commented 1 year ago

The current GDCubism does not correctly reproduce part drawings with addition and multiplication specified. Therefore, part drawing with addition and multiplication specified is forcibly switched to the shader that performs normal drawing.

problem_01

No effective solution has been found at this time.


現在のGDCubismでは加算と乗算指定がされたパーツ描画が正しく再現されません。 そのため加算と乗算指定がされたパーツ描画には通常描画を行うシェーダーに強制的に切り替わる様になっています。

現在有効な解決策が見つかっていません。

fnaith commented 1 year ago

Does that mean official demo applies add+mul blending with only one layer, but godot must uses two layers?

MizunagiKB commented 1 year ago

The problem is that both Official and GDCubism use the same number of layers, but the drawing results are different.

This problem is mainly due to two factors

So I added the ability to change shaders to the latest commit of 0.1.

ss

You can edit the shaders directly in the /demo/addons/gd_cubism/res/shader folder, or copy them to another location and set them in your editor.

The most obvious one is shadow rendering, where the following shaders are used.

Even if you can't find a solution, I would be very happy to hear what you find.

fnaith commented 1 year ago

@MizunagiKB thanks for your sharing! Although I am not familiar with godot shader too, but I will build this project and try to find out. It is good see some talented person works on godot live2d. Recent Unity Policy changes many things.

fnaith commented 1 year ago

the build process is very smooth ! demo

MizunagiKB commented 1 year ago

I am happy to build in your environment.

MizunagiKB commented 1 year ago

Updated Shader to improve drawing reproducibility. Some Live2D models may not display well.

ss_mao

fnaith commented 1 year ago

So cool, I guess it solves a part of problem 👍

kuwana-live2d commented 1 year ago

Is this problem perhaps caused by not being able to set a custom blend mode in the shader? Is the problem related to the following proposals?

Add more 2D blend modes #470 Add Custom Blend Mode declarations to the shader language #7058

MizunagiKB commented 1 year ago

So cool, I guess it solves a part of problem 👍

@fnaith

I don’t think this method is a panacea, but if the appearance is within an acceptable range, I would like to release it as 0.2.

MizunagiKB commented 1 year ago

@kuwana-live2d

As far as I understand, the current Godot Engine does not allow you to freely specify the blend mode. Therefore, if you perform addition or multiplication on textures with alpha, you will get unintended rendering results. This Issues(#7) is trying to solve the problem by using Shader tricks without modifying the game engine.

The links you provided seem to be related to the blend mode topic. Maybe if what is mentioned in the links is implemented, the problem will be solved.

However, I think my approach is quite exceptional for Godot Engine.

This is also related to the fact that Live2D itself uses a unique technique.

Therefore, at the moment, I think it would be best if we could find a solution using just the GDExtension.

kuwana-live2d commented 1 year ago

@MizunagiKB

As far as I can tell, the recommended way to use custom blends in godot is to use screen texture.

However, according to the document, to get screen texture multiple times, I think you need to use a lot of back buffer copies.

Since live2d sets the blend method when drawing the mesh, I am thinking that you may need to create a backbuffercopy in the drawing unit of that mesh.

I don't know what the performance impact of this method would be, since we don't normally blend in this manner...

MizunagiKB commented 1 year ago

@kuwana-live2d

Given that the blend mode cannot be changed, in order to achieve the desired composite result, it is necessary to obtain information about the rendering destination and write your own composite formula.

Indeed, it is as you have stated.

In GDCubism, we use sub-viewport instead of screen texture, which is used for overall rendering and mask processing. Therefore, if you obtain the results rendered to the sub-viewport as needed, you should be able to perform more complex calculations. However, obtaining the rendering results increases the load and complicates the process. Above all, it exceeds my understanding as a layman.

Currently, we are aiming for a reasonable level of reproduction and are combining the following to create a composition that does not destroy the alpha of the rendering destination:

Additionally, we have made shaders available as properties, enabling users to customize them on their own.

kuwana-live2d commented 1 year ago

@MizunagiKB

I feel that changing sub viewport to back buffer copy(screen texture) would allow you to get the rendering results in the shader, but I am concerned about the performance loss.

I have understood your situation that you are improving the shader code to get as close to correct rendering as possible.

I'll try to find a few more ways you can improve.