モノクロのテクスチャを使う場合に、圧縮形式を「TC_Grayscale」にすると非圧縮のグレースケール扱いになると思うのですが
テクスチャに圧縮ノイズが入らなくて綺麗なままなのでアーティストとしてはこちらを使いたくなります。
これを使用することについてどう思いますか？
メモリアクセス面で圧縮時に比べて遅くなるというのも聞いたりしますが、できるだけ使用を控えた方が良いのでしょうか。
アーティスト・プログラマ双方からご意見を伺えると嬉しいです。
1チャンネルのテクスチャを扱う場合は「TC_Alpha(BC4)」を使うのがセオリーなのだとは思いますが
こちらも圧縮によってDXT1と同じくらい汚くなってしまう印象です。
http://game.ekikara7.jp/archives/34533
よろしくお願いします。
TC_Grayscale = 非圧縮
TC_Alpha = BC4
で正しいと思います。
メモリの非圧縮はメモリ領域の圧迫もありますが、仰るとおりテクスチャを読み込む際のGPUのコストに直結します。
ですので、GPUコストが高い場合は、BC4への圧縮も検討材料の一つだと思います。
ただ、本当にテクスチャアクセスネックなのか？ネックじゃないのにBC4にしてビジュアル面が劣るのは良くないので、ちゃんとプロファイルする必要があります。
UE4のプロファイラでは、これらのテクスチャフィルタリングがどれだけ最適化として効果があるかは、On/Offにして処理時間を見るしかなさそうです。
本格的に最適化をする場合は、プログラマにGPUプロファイラで挙動を見てもらい、テクスチャアクセスがネックとなったら、ビジュアル面と処理負荷とのご相談になると思います。
ご参考]
TargetPlatformBase.h
else if (Texture->CompressionSettings == TC_Grayscale)
{
TextureFormatName = NameG8;
}
else if ( Texture->CompressionSettings == TC_Alpha)
{
TextureFormatName = NameBC4;
}
Bc4の汚さあたりは、アーティストの方がどう思っているのか気になります。
＞sumio-katakuraさん
こちら確証できてホっとしました。
ありがとうございます！
テクスチャアクセスのプロファイリングについてもプログラマに相談してみたいと思います。
このあたりすでにやってみたよという方がもしいらっしゃれば話も聞いてみたいですね‥！
すみません、こちらですが「DXT1と同じくらい汚くなってしまう」というのは大袈裟でした。
DXT1や5と比べるとかなり良くなりますね。
普段はTC_Alpha（BC4)でOKなように思います。
ただし圧縮タイプをTC_Alphaに設定するとテクスチャエディタでsRGBの項目にチェックを入れられなくなるので
TC_DefaultやTC_Grayscaleと混在するとマテリアルエディタでのリニアワークフローを保つための構成の複雑度が増してしまいますね‥
そのあたりも含めて、引き続きみなさんモノクロテクスチャの設定とマテリアルエディタ内での扱いをどうされているかお聞きしたいです。
私はアーティストですが、TC_Grayscaleを使用していません。
主にマテリアルインスタンスを使用して制作していますが、マテリアル側で設定したテクスチャの形式がマテリアルインスタンスでも引き継がれており、エラーメッセージが表示されるのでグレースケールのデータでもカラーとして扱っています。
ベースカラーなど色を扱うデータ以外はｓRGBリニアにして使用しています。グレースケールでもsRGBリニアです。
あとは単純にそこまで調べていないというのもありますが、テクスチャの形式が増えると管理が大変になるので使ってないというのが正直なところです。
どのようなテクスチャをグレースケールで作成するのかを決める事ができればそれにあわせてマテリアルを作成できるとは思いますが、ある程度物量を作っていかないと仕様として確定しにくいので最初から決めるのは難しそうだなと思っています。
できるだけ軽くてきれいな形式で使うのはベストなので、うまく使ってる人がいたら運用例をお聞きしてみたいですね。
sinocofさん
貴重な意見ありがとうございます。
ここらへん詳しくないのですが、どのようなエラーメッセージが出るのでしょうか？エラーが出るだけで描画の不具合などは発生しないのでしょうか？？
sRGBとの兼ね合いや処理負荷を考えていくと、確かに管理コストはすぐに跳ね上がりそうです。。
運用ポリシーの一例などがあれば興味ぶかいすね。。
＞sinocofさん、sumio-katakuraさん
貴重なご意見ありがとうございます！
大変参考になります。
扱う形式が増えると管理が大変にというのはまさに‥
なるべく混乱を招かないシンプルなルールで運用した方が良いですよね。
グレースケールをカラーとして使用する場面が度々ある場合は、そのケース専用に親マテリアルを用意するような運用が良いかも知れないですね。
エラーメッセージについてはこちらで試したところでは出ないので一見大丈夫かと思っていました。
例えば親マテリアル内のパラメータ化したTexture Sampleノードの「Sampler Type」プロパティがColorの際に、マテリアルインスタンス側でLinear ColorやGrayscaleのテクスチャを差し込んでも問題なく表示できています。
ただ、親マテリアル内ではsRGBにチェックを入れたテクスチャを使用していてマテリアルインスタンス側ではsRGBのチェックを外したテクスチャを差し込んだ場合に、赤く表示されてしまうという不具合？（仕様？）は確認できています。
なので、sRGBのオンオフどちらも使用できる親マテリアルにしたい場合は、どちらを有効にするかswitchできる作りにする必要がありそうです。
すみません、エラーではなくWarningでした。
このような感じでマテリアルインスタンスで異なるテクスチャタイプを入れるとwarningが表示されます。
ｔ.j berriさんが仰るとおりマテリアルエディタ内でテクスチャのTextureSampleのSampler Typeが異なるテクスチャがセットされるとエラーが出てコンパイルされないですね。
マテリアルインスタンスの場合、入力されてるタイプが違うよって警告されてるだけで表示はされてるのでこのままでも使用できるのでしょうが、
ちゃんとした開発を運営していくのであればこの警告も避けたほうがよいかなと思います。
テクスチャの管理とメモリの問題が大きいですが、個人的にはラフネス、メタリックなどはマスクマップに一緒に入れるのでアセットに必須で入力が必要なものはカラーリニアでもち、
それ以外で場合によって必要となるものがグレースケールかカラーリニアか判断することになるのかなと思います。
UE4の場合マテリアルってある程度の用途が定まった上で作成されているので（例えば岩マテリアルとか植物マテリアルとかマスターマテリアルでは表現ができないものは用途に合わせて作成していく、何にでも使えるようなマテリアルは作成が推奨されない）
そのマテリアルの設計と相談の上でグレースケールかカラーリニアを使うのかを判断すればスイッチ使わずに仕様化できるかもしれないですね。
それでも、ややこしいことには変わりないですけどね…^^;
