As we develop GDCubism v0.7, there are two areas we are considering for improvement.
If you are using GDCubism or are interested in it, please feel free to comment.
Comments can be in either Japanese or English.
Specifying the Size of Mask Rendering Textures
GDCubism focuses solely on displaying Live2D models, which results in significant GPU memory consumption. Especially when displaying at 4K (3840 x 2160) resolution, the memory usage quickly reaches several gigabytes.
This is because the mask images created during the rendering of Live2D models are generated at the same size as the final output, and since the mask images are realized with SubViewport, the more masks used in a single rendering, the more GPU memory is consumed (the back buffer cannot be reused).
While higher quality masks result in smoother edges, masks with a resolution higher than the actual output resolution do not seem to add much value. Therefore, we are considering allowing users to change the size of the mask images.
For example, even if rendering at a size of 4096x4096, it would be possible to set the mask to 256x256.
As an item, we plan to prepare a Vector2i item where (0, 0) would maintain the current behavior, and sizes of (1, 1) or larger would generate the mask image at that size.
Rendering Without Using SubViewport
The GDCubismUserModel used to render Live2D models in GDCubism is a class that inherits from SubViewport. This is to handle multiple MeshInstance2D as a single image, but we are considering whether it might be more convenient to separate this.
To achieve the goal of "displaying Live2D models," there seems to be a somewhat high barrier, and if the user understands SubViewport, they could place SubViewport as the parent of GDCubismUserClass themselves. (Combining purpose-specific Nodes rather than creating a highly functional and large Node seems to align more with the Godot Engine's philosophy.)
If SubViewport is not used, it would likely be necessary to adjust the mask to screen coordinates, which may require shader modifications.
GDCubism v0.7 を開発するにあたり、改善を考えている箇所が二箇所あります。
もしGDCubismを利用されていたり、興味がもっているのでしたらお気軽にコメントをお願いします。
日本語・英語、どちらでもコメント可能です。
マスク描画用テクスチャのサイズ指定
GDCubismはLive2Dモデルを表示する事だけに注力しているため、GPUメモリをかなり消費します。特に4K（3840 x 2160）解像度での表示を行うとすぐに数GBに達してしまいます。
これはLive2Dモデルの描画時に作成するマスク画像を最終出力サイズと同じサイズで生成していることと、マスク画像をSubViewportで実現しているため、一度の描画で使用されるマスクが多いほどGPUメモリを消費するためです。（バックバッファを使いまわせない）
マスクの品質が高い方がエッジが滑らかになるのですが、実際の解像度以上のマスクは出力結果にあまり意味をなさない気がするため、マスク画像のサイズを利用者側で変更出来る様にすることを考えています。
例えば4096x4096のサイズで描画していても、マスクは256x256にするといった事が可能になります。
項目としては、Vector2iの項目を用意して(0, 0)の場合は現状と互換の動作、サイズが(1, 1)以上であれば、そのサイズでマスク画像を生成するといったものにしようとしています。
SubViewportを使用せずに描画を行う方法
GDCubismでLive2Dモデルを描画するのに使用しているGDCubismUserModelは、SubViewportを継承したクラスにしています。これは複数のMeshInstance2Dから生成されたものを一枚の画像として扱うためなのですが、これを分離してしまう方が便利なのではないかと考えています。
「Live2Dモデルを表示したい」という目的を達成するには、やや高い壁がある様な気がしており、SubViewportを理解しているのであれば、利用者自身でGDCubismUserClassの親にSubViewportを配置すれば解決出来るだろうと考えます。（高機能で巨大なNodeを作るよりも目的特化Nodeを組み合わせる方がGodot Engineの流儀にもあっている気もします）
SubViewportを使用しない場合は、マスクをスクリーン座標にあわせて用意する必要があるため恐らくシェーダーの修正が必要になりそうです。直接描画時は描画結果も若干変わってしまうかもしれません。
As we develop GDCubism v0.7, there are two areas we are considering for improvement.
If you are using GDCubism or are interested in it, please feel free to comment.
Specifying the Size of Mask Rendering Textures
GDCubism focuses solely on displaying Live2D models, which results in significant GPU memory consumption. Especially when displaying at 4K (3840 x 2160) resolution, the memory usage quickly reaches several gigabytes.
This is because the mask images created during the rendering of Live2D models are generated at the same size as the final output, and since the mask images are realized with SubViewport, the more masks used in a single rendering, the more GPU memory is consumed (the back buffer cannot be reused).
While higher quality masks result in smoother edges, masks with a resolution higher than the actual output resolution do not seem to add much value. Therefore, we are considering allowing users to change the size of the mask images.
For example, even if rendering at a size of 4096x4096, it would be possible to set the mask to 256x256.
As an item, we plan to prepare a Vector2i item where (0, 0) would maintain the current behavior, and sizes of (1, 1) or larger would generate the mask image at that size.
Rendering Without Using SubViewport
The GDCubismUserModel used to render Live2D models in GDCubism is a class that inherits from SubViewport. This is to handle multiple MeshInstance2D as a single image, but we are considering whether it might be more convenient to separate this.
To achieve the goal of "displaying Live2D models," there seems to be a somewhat high barrier, and if the user understands SubViewport, they could place SubViewport as the parent of GDCubismUserClass themselves. (Combining purpose-specific Nodes rather than creating a highly functional and large Node seems to align more with the Godot Engine's philosophy.)
If SubViewport is not used, it would likely be necessary to adjust the mask to screen coordinates, which may require shader modifications.
GDCubism v0.7 を開発するにあたり、改善を考えている箇所が二箇所あります。
もしGDCubismを利用されていたり、興味がもっているのでしたらお気軽にコメントをお願いします。
マスク描画用テクスチャのサイズ指定
GDCubismはLive2Dモデルを表示する事だけに注力しているため、GPUメモリをかなり消費します。特に4K（3840 x 2160）解像度での表示を行うとすぐに数GBに達してしまいます。
これはLive2Dモデルの描画時に作成するマスク画像を最終出力サイズと同じサイズで生成していることと、マスク画像をSubViewportで実現しているため、一度の描画で使用されるマスクが多いほどGPUメモリを消費するためです。（バックバッファを使いまわせない）
マスクの品質が高い方がエッジが滑らかになるのですが、実際の解像度以上のマスクは出力結果にあまり意味をなさない気がするため、マスク画像のサイズを利用者側で変更出来る様にすることを考えています。
例えば4096x4096のサイズで描画していても、マスクは256x256にするといった事が可能になります。
項目としては、Vector2iの項目を用意して(0, 0)の場合は現状と互換の動作、サイズが(1, 1)以上であれば、そのサイズでマスク画像を生成するといったものにしようとしています。
SubViewportを使用せずに描画を行う方法
GDCubismでLive2Dモデルを描画するのに使用しているGDCubismUserModelは、SubViewportを継承したクラスにしています。これは複数のMeshInstance2Dから生成されたものを一枚の画像として扱うためなのですが、これを分離してしまう方が便利なのではないかと考えています。
「Live2Dモデルを表示したい」という目的を達成するには、やや高い壁がある様な気がしており、SubViewportを理解しているのであれば、利用者自身でGDCubismUserClassの親にSubViewportを配置すれば解決出来るだろうと考えます。（高機能で巨大なNodeを作るよりも目的特化Nodeを組み合わせる方がGodot Engineの流儀にもあっている気もします）
SubViewportを使用しない場合は、マスクをスクリーン座標にあわせて用意する必要があるため恐らくシェーダーの修正が必要になりそうです。直接描画時は描画結果も若干変わってしまうかもしれません。