Addition and multiplication operations are not available.
MizunagiKB opened this issue · comments
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.
No effective solution has been found at this time.
現在のGDCubismでは加算と乗算指定がされたパーツ描画が正しく再現されません。
そのため加算と乗算指定がされたパーツ描画には通常描画を行うシェーダーに強制的に切り替わる様になっています。
現在有効な解決策が見つかっていません。
Does that mean official demo applies add+mul blending with only one layer, but godot must uses two layers?
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
- Godot Engine's drawing rules cannot be changed.
- I am not familiar with how shaders work.
So I added the ability to change shaders to the latest commit of 0.1.
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.
- 2d_cubism_mask_mul.gdshader
Even if you can't find a solution, I would be very happy to hear what you find.
@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.
the build process is very smooth !
I am happy to build in your environment.
Updated Shader to improve drawing reproducibility.
Some Live2D models may not display well.
So cool, I guess it solves a part of problem 👍
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
So cool, I guess it solves a part of problem 👍
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.
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.
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...
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:
- blend_premul_alpha (mix, add)
- blend_mul + alpha 1.0 (mul)
Additionally, we have made shaders available as properties, enabling users to customize them on their own.
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.