SlideShare a Scribd company logo

大規模タイトルにおけるエフェクトマテリアル運用 (SQEX大阪: 林武尊様) #UE4DD

エピック・ゲームズ・ジャパン Epic Games Japan
エピック・ゲームズ・ジャパン Epic Games Japan
エピック・ゲームズ・ジャパン Epic Games Japanエピック・ゲームズ・ジャパン Epic Games Japan

2017年1月21日に行われたライセンシー様向けマテリアル管理勉強会の資料です。(登壇者: 株式会社SQEX大阪 林武尊様) 「大規模チーム」、「エフェクト」、この二点を軸に、爆発するマテリアル管理や検証をどのように行っているかを説明しただいております。 時間の都合で本編ではカットされた内容も沢山盛り込まれております。

大規模タイトルにおけるエフェクトマテリアル運用 (SQEX大阪: 林武尊様) #UE4DD

1 of 218
Download to read offline
©2016 SQUARE ENIX CO., LTD. All Rights Reserved.©2017 SQUARE ENIX CO., LTD. All Rights Reserved.
Deep Dive
大規模タイトルのエフェクトマテリアル運用
株式会社スクウェア・エニックス 林 武尊
公開版
略称について
略称について
• 『Unreal Engine 4』をスライド内では『UE4』と記載しています
• 『PlayStation®4』も同様に『PS4』と記載しています
©2017 SQUARE ENIX CO., LTD. All Rights Reserved.
自己紹介
©2017 SQUARE ENIX CO., LTD. All Rights Reserved.
自己紹介
• 林 武尊( TAKERU HAYASHI )
• エフェクトアーティスト
• KINGDOM HEARTS シリーズ
©2017 SQUARE ENIX CO., LTD. All Rights Reserved.
今日お話する内容
©2017 SQUARE ENIX CO., LTD. All Rights Reserved.
今日お話する内容
• UE4を使ったPS4の大規模タイトルでの事例
• 経験したことのないスタッフ数
• エフェクトチームでのマテリアルの運用のお話
©2017 SQUARE ENIX CO., LTD. All Rights Reserved.
内容

Recommended

マテリアルとマテリアルインスタンスの仕組みと問題点の共有 (Epic Games Japan: 篠山範明) #UE4DD
マテリアルとマテリアルインスタンスの仕組みと問題点の共有 (Epic Games Japan: 篠山範明) #UE4DDマテリアルとマテリアルインスタンスの仕組みと問題点の共有 (Epic Games Japan: 篠山範明) #UE4DD
マテリアルとマテリアルインスタンスの仕組みと問題点の共有 (Epic Games Japan: 篠山範明) #UE4DDエピック・ゲームズ・ジャパン Epic Games Japan
 
UE4のマテリアルを もっと楽しもう!~マテリアルでぐっと広がるリアルタイムCG表現の幅~
UE4のマテリアルを もっと楽しもう!~マテリアルでぐっと広がるリアルタイムCG表現の幅~ UE4のマテリアルを もっと楽しもう!~マテリアルでぐっと広がるリアルタイムCG表現の幅~
UE4のマテリアルを もっと楽しもう!~マテリアルでぐっと広がるリアルタイムCG表現の幅~ エピック・ゲームズ・ジャパン Epic Games Japan
 
[UE4]マテリアルの注意すべきこと!~テクスチャロードとSwitch~
[UE4]マテリアルの注意すべきこと!~テクスチャロードとSwitch~[UE4]マテリアルの注意すべきこと!~テクスチャロードとSwitch~
[UE4]マテリアルの注意すべきこと!~テクスチャロードとSwitch~com044
 

More Related Content

What's hot

UE4のライティング解体新書~効果的なNPRのためにライティングの仕組みを理解しよう~
UE4のライティング解体新書~効果的なNPRのためにライティングの仕組みを理解しよう~UE4のライティング解体新書~効果的なNPRのためにライティングの仕組みを理解しよう~
UE4のライティング解体新書~効果的なNPRのためにライティングの仕組みを理解しよう~エピック・ゲームズ・ジャパン Epic Games Japan
 
UE4プログラマー勉強会 in 大阪 -エンジンの内部挙動について
UE4プログラマー勉強会 in 大阪 -エンジンの内部挙動についてUE4プログラマー勉強会 in 大阪 -エンジンの内部挙動について
UE4プログラマー勉強会 in 大阪 -エンジンの内部挙動についてcom044
 
そう、UE4ならね。あなたのモバイルゲームをより快適にする沢山の冴えたやり方について Part 2 <Texture Streaming, メモリプロ...
  そう、UE4ならね。あなたのモバイルゲームをより快適にする沢山の冴えたやり方について Part 2 <Texture Streaming, メモリプロ...  そう、UE4ならね。あなたのモバイルゲームをより快適にする沢山の冴えたやり方について Part 2 <Texture Streaming, メモリプロ...
そう、UE4ならね。あなたのモバイルゲームをより快適にする沢山の冴えたやり方について Part 2 <Texture Streaming, メモリプロ...エピック・ゲームズ・ジャパン Epic Games Japan
 
[UE4]自動テストでもっと楽したい!
[UE4]自動テストでもっと楽したい![UE4]自動テストでもっと楽したい!
[UE4]自動テストでもっと楽したい!com044
 
『FINAL FANTASY VII REMAKE』におけるプロファイリングと最適化事例 UNREAL FEST EXTREME 2021 SUMMER
『FINAL FANTASY VII REMAKE』におけるプロファイリングと最適化事例 UNREAL FEST EXTREME 2021 SUMMER『FINAL FANTASY VII REMAKE』におけるプロファイリングと最適化事例 UNREAL FEST EXTREME 2021 SUMMER
『FINAL FANTASY VII REMAKE』におけるプロファイリングと最適化事例 UNREAL FEST EXTREME 2021 SUMMERエピック・ゲームズ・ジャパン Epic Games Japan
 
UE4 LODs for Optimization -Beginner-
UE4 LODs for Optimization -Beginner-UE4 LODs for Optimization -Beginner-
UE4 LODs for Optimization -Beginner-com044
 

What's hot (20)

60fpsアクションを実現する秘訣を伝授 解析編
60fpsアクションを実現する秘訣を伝授 解析編60fpsアクションを実現する秘訣を伝授 解析編
60fpsアクションを実現する秘訣を伝授 解析編
 
60fpsアクションを実現する秘訣を伝授 基礎編
60fpsアクションを実現する秘訣を伝授 基礎編60fpsアクションを実現する秘訣を伝授 基礎編
60fpsアクションを実現する秘訣を伝授 基礎編
 
Lightmassの仕組み ~Lightmap編~ (Epic Games Japan: 篠山範明)
Lightmassの仕組み ~Lightmap編~ (Epic Games Japan: 篠山範明)Lightmassの仕組み ~Lightmap編~ (Epic Games Japan: 篠山範明)
Lightmassの仕組み ~Lightmap編~ (Epic Games Japan: 篠山範明)
 
[CEDEC2018] UE4で多数のキャラクターを生かすためのテクニック
[CEDEC2018] UE4で多数のキャラクターを生かすためのテクニック[CEDEC2018] UE4で多数のキャラクターを生かすためのテクニック
[CEDEC2018] UE4で多数のキャラクターを生かすためのテクニック
 
UE4におけるエフェクトの為のエンジン改造事例
UE4におけるエフェクトの為のエンジン改造事例UE4におけるエフェクトの為のエンジン改造事例
UE4におけるエフェクトの為のエンジン改造事例
 
UE4のライティング解体新書~効果的なNPRのためにライティングの仕組みを理解しよう~
UE4のライティング解体新書~効果的なNPRのためにライティングの仕組みを理解しよう~UE4のライティング解体新書~効果的なNPRのためにライティングの仕組みを理解しよう~
UE4のライティング解体新書~効果的なNPRのためにライティングの仕組みを理解しよう~
 
大規模CSゲームにおけるライトマス運用
大規模CSゲームにおけるライトマス運用大規模CSゲームにおけるライトマス運用
大規模CSゲームにおけるライトマス運用
 
UE4プログラマー勉強会 in 大阪 -エンジンの内部挙動について
UE4プログラマー勉強会 in 大阪 -エンジンの内部挙動についてUE4プログラマー勉強会 in 大阪 -エンジンの内部挙動について
UE4プログラマー勉強会 in 大阪 -エンジンの内部挙動について
 
そう、UE4ならね。あなたのモバイルゲームをより快適にする沢山の冴えたやり方について Part 2 <Texture Streaming, メモリプロ...
  そう、UE4ならね。あなたのモバイルゲームをより快適にする沢山の冴えたやり方について Part 2 <Texture Streaming, メモリプロ...  そう、UE4ならね。あなたのモバイルゲームをより快適にする沢山の冴えたやり方について Part 2 <Texture Streaming, メモリプロ...
そう、UE4ならね。あなたのモバイルゲームをより快適にする沢山の冴えたやり方について Part 2 <Texture Streaming, メモリプロ...
 
ディゾブルマテリアルで表現する立体魔法陣 (UE4 VFX Art Dive)
ディゾブルマテリアルで表現する立体魔法陣 (UE4 VFX Art Dive)ディゾブルマテリアルで表現する立体魔法陣 (UE4 VFX Art Dive)
ディゾブルマテリアルで表現する立体魔法陣 (UE4 VFX Art Dive)
 
UE4 Hair & Groomでのリアルタイムファーレンダリング (UE4 Character Art Dive Online)
UE4 Hair & Groomでのリアルタイムファーレンダリング (UE4 Character Art Dive Online)UE4 Hair & Groomでのリアルタイムファーレンダリング (UE4 Character Art Dive Online)
UE4 Hair & Groomでのリアルタイムファーレンダリング (UE4 Character Art Dive Online)
 
UE4におけるレベル制作事例
UE4におけるレベル制作事例  UE4におけるレベル制作事例
UE4におけるレベル制作事例
 
[UE4]自動テストでもっと楽したい!
[UE4]自動テストでもっと楽したい![UE4]自動テストでもっと楽したい!
[UE4]自動テストでもっと楽したい!
 
豚×京都 ~UE4でなろう破壊神~ (UE4 VFX Art Dive)
豚×京都 ~UE4でなろう破壊神~ (UE4 VFX Art Dive)豚×京都 ~UE4でなろう破壊神~ (UE4 VFX Art Dive)
豚×京都 ~UE4でなろう破壊神~ (UE4 VFX Art Dive)
 
『FINAL FANTASY VII REMAKE』におけるプロファイリングと最適化事例 UNREAL FEST EXTREME 2021 SUMMER
『FINAL FANTASY VII REMAKE』におけるプロファイリングと最適化事例 UNREAL FEST EXTREME 2021 SUMMER『FINAL FANTASY VII REMAKE』におけるプロファイリングと最適化事例 UNREAL FEST EXTREME 2021 SUMMER
『FINAL FANTASY VII REMAKE』におけるプロファイリングと最適化事例 UNREAL FEST EXTREME 2021 SUMMER
 
エフェクトツール機能の実装例
エフェクトツール機能の実装例エフェクトツール機能の実装例
エフェクトツール機能の実装例
 
UE4における大規模背景制作事例(コリジョン編)
UE4における大規模背景制作事例(コリジョン編) UE4における大規模背景制作事例(コリジョン編)
UE4における大規模背景制作事例(コリジョン編)
 
猫でも分かるUE4のポストプロセスを使った演出・絵作り
猫でも分かるUE4のポストプロセスを使った演出・絵作り猫でも分かるUE4のポストプロセスを使った演出・絵作り
猫でも分かるUE4のポストプロセスを使った演出・絵作り
 
UE4 LODs for Optimization -Beginner-
UE4 LODs for Optimization -Beginner-UE4 LODs for Optimization -Beginner-
UE4 LODs for Optimization -Beginner-
 
初心者向け UE4 映像制作での シーケンサー と Movie Render Queue の使い方
初心者向け UE4 映像制作での シーケンサー と Movie Render Queue の使い方初心者向け UE4 映像制作での シーケンサー と Movie Render Queue の使い方
初心者向け UE4 映像制作での シーケンサー と Movie Render Queue の使い方
 

Viewers also liked

マジシャンズデッド ポストモーテム ~マテリアル編~ (株式会社Byking: 鈴木孝司様、成相真治様) #UE4DD
マジシャンズデッド ポストモーテム ~マテリアル編~ (株式会社Byking: 鈴木孝司様、成相真治様) #UE4DDマジシャンズデッド ポストモーテム ~マテリアル編~ (株式会社Byking: 鈴木孝司様、成相真治様) #UE4DD
マジシャンズデッド ポストモーテム ~マテリアル編~ (株式会社Byking: 鈴木孝司様、成相真治様) #UE4DDエピック・ゲームズ・ジャパン Epic Games Japan
 
なぜなにリアルタイムレンダリング
なぜなにリアルタイムレンダリングなぜなにリアルタイムレンダリング
なぜなにリアルタイムレンダリングSatoshi Kodaira
 
GDC ラウンドテーブルで得た情報量 2016 - Demystifying VFX, Art Director & Leadership, RiotGa...
GDC ラウンドテーブルで得た情報量 2016 - Demystifying VFX, Art Director & Leadership, RiotGa...GDC ラウンドテーブルで得た情報量 2016 - Demystifying VFX, Art Director & Leadership, RiotGa...
GDC ラウンドテーブルで得た情報量 2016 - Demystifying VFX, Art Director & Leadership, RiotGa...TARO KOBAYASHI
 
ゲームエンジンの中の話
ゲームエンジンの中の話ゲームエンジンの中の話
ゲームエンジンの中の話Masayoshi Kamai
 
UnityでもTaskが使いたい!~MinimumAsyncBridgeの紹介~
UnityでもTaskが使いたい!~MinimumAsyncBridgeの紹介~UnityでもTaskが使いたい!~MinimumAsyncBridgeの紹介~
UnityでもTaskが使いたい!~MinimumAsyncBridgeの紹介~Shoichi Yasui
 
オックスフォード図書館制作奮闘記
オックスフォード図書館制作奮闘記オックスフォード図書館制作奮闘記
オックスフォード図書館制作奮闘記Aiko Shinohara
 
UE4背景アーティスト勉強会(後編) 実演+解説
UE4背景アーティスト勉強会(後編) 実演+解説UE4背景アーティスト勉強会(後編) 実演+解説
UE4背景アーティスト勉強会(後編) 実演+解説Aiko Shinohara
 
UE4背景アーティスト勉強会(前編) 背景ワークフロー解説
UE4背景アーティスト勉強会(前編) 背景ワークフロー解説UE4背景アーティスト勉強会(前編) 背景ワークフロー解説
UE4背景アーティスト勉強会(前編) 背景ワークフロー解説Aiko Shinohara
 
第5回ue4ハンズオンセミナー
第5回ue4ハンズオンセミナー第5回ue4ハンズオンセミナー
第5回ue4ハンズオンセミナーMasahiko Nakamura
 
UE4の攻略方法を伝授! より効率よく楽しく学ぶ ための鉄則について
UE4の攻略方法を伝授! より効率よく楽しく学ぶ ための鉄則についてUE4の攻略方法を伝授! より効率よく楽しく学ぶ ための鉄則について
UE4の攻略方法を伝授! より効率よく楽しく学ぶ ための鉄則についてMasahiko Nakamura
 
【Unity道場スペシャル 2017京都】最適化をする前に覚えておきたい技術
【Unity道場スペシャル 2017京都】最適化をする前に覚えておきたい技術【Unity道場スペシャル 2017京都】最適化をする前に覚えておきたい技術
【Unity道場スペシャル 2017京都】最適化をする前に覚えておきたい技術Unity Technologies Japan K.K.
 

Viewers also liked (12)

マジシャンズデッド ポストモーテム ~マテリアル編~ (株式会社Byking: 鈴木孝司様、成相真治様) #UE4DD
マジシャンズデッド ポストモーテム ~マテリアル編~ (株式会社Byking: 鈴木孝司様、成相真治様) #UE4DDマジシャンズデッド ポストモーテム ~マテリアル編~ (株式会社Byking: 鈴木孝司様、成相真治様) #UE4DD
マジシャンズデッド ポストモーテム ~マテリアル編~ (株式会社Byking: 鈴木孝司様、成相真治様) #UE4DD
 
なぜなにリアルタイムレンダリング
なぜなにリアルタイムレンダリングなぜなにリアルタイムレンダリング
なぜなにリアルタイムレンダリング
 
Practical usage of Lightmass in Architectural Visualization (Kenichi Makaya...
Practical usage of Lightmass in  Architectural Visualization  (Kenichi Makaya...Practical usage of Lightmass in  Architectural Visualization  (Kenichi Makaya...
Practical usage of Lightmass in Architectural Visualization (Kenichi Makaya...
 
GDC ラウンドテーブルで得た情報量 2016 - Demystifying VFX, Art Director & Leadership, RiotGa...
GDC ラウンドテーブルで得た情報量 2016 - Demystifying VFX, Art Director & Leadership, RiotGa...GDC ラウンドテーブルで得た情報量 2016 - Demystifying VFX, Art Director & Leadership, RiotGa...
GDC ラウンドテーブルで得た情報量 2016 - Demystifying VFX, Art Director & Leadership, RiotGa...
 
ゲームエンジンの中の話
ゲームエンジンの中の話ゲームエンジンの中の話
ゲームエンジンの中の話
 
UnityでもTaskが使いたい!~MinimumAsyncBridgeの紹介~
UnityでもTaskが使いたい!~MinimumAsyncBridgeの紹介~UnityでもTaskが使いたい!~MinimumAsyncBridgeの紹介~
UnityでもTaskが使いたい!~MinimumAsyncBridgeの紹介~
 
オックスフォード図書館制作奮闘記
オックスフォード図書館制作奮闘記オックスフォード図書館制作奮闘記
オックスフォード図書館制作奮闘記
 
UE4背景アーティスト勉強会(後編) 実演+解説
UE4背景アーティスト勉強会(後編) 実演+解説UE4背景アーティスト勉強会(後編) 実演+解説
UE4背景アーティスト勉強会(後編) 実演+解説
 
UE4背景アーティスト勉強会(前編) 背景ワークフロー解説
UE4背景アーティスト勉強会(前編) 背景ワークフロー解説UE4背景アーティスト勉強会(前編) 背景ワークフロー解説
UE4背景アーティスト勉強会(前編) 背景ワークフロー解説
 
第5回ue4ハンズオンセミナー
第5回ue4ハンズオンセミナー第5回ue4ハンズオンセミナー
第5回ue4ハンズオンセミナー
 
UE4の攻略方法を伝授! より効率よく楽しく学ぶ ための鉄則について
UE4の攻略方法を伝授! より効率よく楽しく学ぶ ための鉄則についてUE4の攻略方法を伝授! より効率よく楽しく学ぶ ための鉄則について
UE4の攻略方法を伝授! より効率よく楽しく学ぶ ための鉄則について
 
【Unity道場スペシャル 2017京都】最適化をする前に覚えておきたい技術
【Unity道場スペシャル 2017京都】最適化をする前に覚えておきたい技術【Unity道場スペシャル 2017京都】最適化をする前に覚えておきたい技術
【Unity道場スペシャル 2017京都】最適化をする前に覚えておきたい技術
 

More from エピック・ゲームズ・ジャパン Epic Games Japan

『バランワンダーワールド』でのマルチプラットフォーム対応について UNREAL FEST EXTREME 2021 SUMMER
『バランワンダーワールド』でのマルチプラットフォーム対応について  UNREAL FEST EXTREME 2021 SUMMER『バランワンダーワールド』でのマルチプラットフォーム対応について  UNREAL FEST EXTREME 2021 SUMMER
『バランワンダーワールド』でのマルチプラットフォーム対応について UNREAL FEST EXTREME 2021 SUMMERエピック・ゲームズ・ジャパン Epic Games Japan
 
SAMURAI JACK開発事例:海外むけアクションゲームをオーソドックスに作ってみた UNREAL FEST EXTREME 2021 SUMMER
SAMURAI JACK開発事例:海外むけアクションゲームをオーソドックスに作ってみた UNREAL FEST EXTREME 2021 SUMMERSAMURAI JACK開発事例:海外むけアクションゲームをオーソドックスに作ってみた UNREAL FEST EXTREME 2021 SUMMER
SAMURAI JACK開発事例:海外むけアクションゲームをオーソドックスに作ってみた UNREAL FEST EXTREME 2021 SUMMERエピック・ゲームズ・ジャパン Epic Games Japan
 
『ガールズ&パンツァー 最終章』第3話 アニメとゲームエンジンの融合(ジャングル完結編) UNREAL FEST EXTREME 2021 SUMMER
『ガールズ&パンツァー 最終章』第3話 アニメとゲームエンジンの融合(ジャングル完結編)  UNREAL FEST EXTREME 2021 SUMMER『ガールズ&パンツァー 最終章』第3話 アニメとゲームエンジンの融合(ジャングル完結編)  UNREAL FEST EXTREME 2021 SUMMER
『ガールズ&パンツァー 最終章』第3話 アニメとゲームエンジンの融合(ジャングル完結編) UNREAL FEST EXTREME 2021 SUMMERエピック・ゲームズ・ジャパン Epic Games Japan
 

More from エピック・ゲームズ・ジャパン Epic Games Japan (20)

猫でも分かるUE4を使った VRコンテンツ開発 超入門編 2021
猫でも分かるUE4を使った VRコンテンツ開発 超入門編 2021猫でも分かるUE4を使った VRコンテンツ開発 超入門編 2021
猫でも分かるUE4を使った VRコンテンツ開発 超入門編 2021
 
Unreal Engine 5 早期アクセスの注目機能総おさらい Part 2
Unreal Engine 5 早期アクセスの注目機能総おさらい Part 2Unreal Engine 5 早期アクセスの注目機能総おさらい Part 2
Unreal Engine 5 早期アクセスの注目機能総おさらい Part 2
 
Unreal Engine 4.27 ノンゲーム向け新機能まとめ
Unreal Engine 4.27 ノンゲーム向け新機能まとめUnreal Engine 4.27 ノンゲーム向け新機能まとめ
Unreal Engine 4.27 ノンゲーム向け新機能まとめ
 
Unreal Engine 5 早期アクセスの注目機能総おさらい Part 1
Unreal Engine 5 早期アクセスの注目機能総おさらい Part 1Unreal Engine 5 早期アクセスの注目機能総おさらい Part 1
Unreal Engine 5 早期アクセスの注目機能総おさらい Part 1
 
UE4を使った映像制作 (UE4 Character Art Dive Online)
UE4を使った映像制作 (UE4 Character Art Dive Online)UE4を使った映像制作 (UE4 Character Art Dive Online)
UE4を使った映像制作 (UE4 Character Art Dive Online)
 
Hair Groom入門 (UE4 Character Art Dive Online)
Hair Groom入門 (UE4 Character Art Dive Online)Hair Groom入門 (UE4 Character Art Dive Online)
Hair Groom入門 (UE4 Character Art Dive Online)
 
UE4で”MetaHumanを使わずに”耳なし芳一になる10の方法 | UE4 Character Art Dive Online
UE4で”MetaHumanを使わずに”耳なし芳一になる10の方法 | UE4 Character Art Dive OnlineUE4で”MetaHumanを使わずに”耳なし芳一になる10の方法 | UE4 Character Art Dive Online
UE4で”MetaHumanを使わずに”耳なし芳一になる10の方法 | UE4 Character Art Dive Online
 
『バランワンダーワールド』でのマルチプラットフォーム対応について UNREAL FEST EXTREME 2021 SUMMER
『バランワンダーワールド』でのマルチプラットフォーム対応について  UNREAL FEST EXTREME 2021 SUMMER『バランワンダーワールド』でのマルチプラットフォーム対応について  UNREAL FEST EXTREME 2021 SUMMER
『バランワンダーワールド』でのマルチプラットフォーム対応について UNREAL FEST EXTREME 2021 SUMMER
 
Visual Dataprepで建築データを美味しく下ごしらえ UNREAL FEST EXTREME 2021 SUMMER
Visual Dataprepで建築データを美味しく下ごしらえ UNREAL FEST EXTREME 2021 SUMMERVisual Dataprepで建築データを美味しく下ごしらえ UNREAL FEST EXTREME 2021 SUMMER
Visual Dataprepで建築データを美味しく下ごしらえ UNREAL FEST EXTREME 2021 SUMMER
 
Unreal Engineでのコンフィギュレーター制作と映像制作 UNREAL FEST EXTREME 2021 SUMMER
Unreal Engineでのコンフィギュレーター制作と映像制作  UNREAL FEST EXTREME 2021 SUMMERUnreal Engineでのコンフィギュレーター制作と映像制作  UNREAL FEST EXTREME 2021 SUMMER
Unreal Engineでのコンフィギュレーター制作と映像制作 UNREAL FEST EXTREME 2021 SUMMER
 
バレンシアガ『Afterworld: The Age of Tomorrow』の舞台裏 UNREAL FEST EXTREME 2021 SUMMER
バレンシアガ『Afterworld: The Age of Tomorrow』の舞台裏  UNREAL FEST EXTREME 2021 SUMMERバレンシアガ『Afterworld: The Age of Tomorrow』の舞台裏  UNREAL FEST EXTREME 2021 SUMMER
バレンシアガ『Afterworld: The Age of Tomorrow』の舞台裏 UNREAL FEST EXTREME 2021 SUMMER
 
SAMURAI JACK開発事例:海外むけアクションゲームをオーソドックスに作ってみた UNREAL FEST EXTREME 2021 SUMMER
SAMURAI JACK開発事例:海外むけアクションゲームをオーソドックスに作ってみた UNREAL FEST EXTREME 2021 SUMMERSAMURAI JACK開発事例:海外むけアクションゲームをオーソドックスに作ってみた UNREAL FEST EXTREME 2021 SUMMER
SAMURAI JACK開発事例:海外むけアクションゲームをオーソドックスに作ってみた UNREAL FEST EXTREME 2021 SUMMER
 
『ガールズ&パンツァー 最終章』第3話 アニメとゲームエンジンの融合(ジャングル完結編) UNREAL FEST EXTREME 2021 SUMMER
『ガールズ&パンツァー 最終章』第3話 アニメとゲームエンジンの融合(ジャングル完結編)  UNREAL FEST EXTREME 2021 SUMMER『ガールズ&パンツァー 最終章』第3話 アニメとゲームエンジンの融合(ジャングル完結編)  UNREAL FEST EXTREME 2021 SUMMER
『ガールズ&パンツァー 最終章』第3話 アニメとゲームエンジンの融合(ジャングル完結編) UNREAL FEST EXTREME 2021 SUMMER
 
UE4を使用したバーチャルヒューマンの映像制作 UNREAL FEST EXTREME 2021 SUMMER
UE4を使用したバーチャルヒューマンの映像制作  UNREAL FEST EXTREME 2021 SUMMERUE4を使用したバーチャルヒューマンの映像制作  UNREAL FEST EXTREME 2021 SUMMER
UE4を使用したバーチャルヒューマンの映像制作 UNREAL FEST EXTREME 2021 SUMMER
 
オンラインで同期した100体の巨大生物から地球を衛る方法 UNREAL FEST EXTREME 2021 SUMMER
オンラインで同期した100体の巨大生物から地球を衛る方法  UNREAL FEST EXTREME 2021 SUMMERオンラインで同期した100体の巨大生物から地球を衛る方法  UNREAL FEST EXTREME 2021 SUMMER
オンラインで同期した100体の巨大生物から地球を衛る方法 UNREAL FEST EXTREME 2021 SUMMER
 
MetaHumanサンプル解体新書 UNREAL FEST EXTREME 2021 SUMMER
MetaHumanサンプル解体新書  UNREAL FEST EXTREME 2021 SUMMERMetaHumanサンプル解体新書  UNREAL FEST EXTREME 2021 SUMMER
MetaHumanサンプル解体新書 UNREAL FEST EXTREME 2021 SUMMER
 
Twinmotion 2021とAEC分野向けソリューションのご紹介
Twinmotion 2021とAEC分野向けソリューションのご紹介Twinmotion 2021とAEC分野向けソリューションのご紹介
Twinmotion 2021とAEC分野向けソリューションのご紹介
 
UE4.26 レンダリング新機能(CEDEC+KYUSHU 2020)
UE4.26 レンダリング新機能(CEDEC+KYUSHU 2020)UE4.26 レンダリング新機能(CEDEC+KYUSHU 2020)
UE4.26 レンダリング新機能(CEDEC+KYUSHU 2020)
 
猫でもわかる Epic MegaGrants 応募への道
猫でもわかる Epic MegaGrants 応募への道猫でもわかる Epic MegaGrants 応募への道
猫でもわかる Epic MegaGrants 応募への道
 
Unreal Engine と XR でつくる「働く」の未来 | UNREAL FEST EXTREME 2020 WINTER
Unreal Engine と XR でつくる「働く」の未来 | UNREAL FEST EXTREME 2020 WINTERUnreal Engine と XR でつくる「働く」の未来 | UNREAL FEST EXTREME 2020 WINTER
Unreal Engine と XR でつくる「働く」の未来 | UNREAL FEST EXTREME 2020 WINTER
 

大規模タイトルにおけるエフェクトマテリアル運用 (SQEX大阪: 林武尊様) #UE4DD

Editor's Notes

  1. この図の場合は6つですが、派手なエフェクトになると20~30個になったりします。
  2. 1つのエミッターには1つマテリアルを指定し、そのマテリアルが貼り付けられたパーティクルを表示します。 なので1つのエフェクトに20個のエミッターがあれば、マテリアルもしくはマテリアルインスタンスを20個使用していることになります。 つまり、エフェクトは多くのマテリアルを使用して表現します。
  3. この図の場合、エミッシブカラー用のテクスチャAと、オパシティ用のテクスチャBの2枚を使用しています。 「テクスチャAにアルファチャンネルを持たせてそのままオパシティに使用したらいいじゃん」という方もいらっしゃると思いますが‥
  4. エフェクトのテクスチャはそもそもモノクロで十分な場合が多いので、1チャンネルのモノクロテクスチャをエミッシブとオパシティそれぞれ自由に組み合わせられるようにした方が表現のバリエーションは広がります。 もちろん、テクスチャのサンプリング数を抑えるためにアルファチャンネルで運用するのが有効な場合もあると思います。 このあたりは初期に検討しないといけない課題の1つになると思います。
  5. 他にも、テクスチャのUVを歪ませるために別のテクスチャを使用したりもします。 この図はテクスチャAを歪ませるためにテクスチャCを使っていますが、テクスチャBを歪ませたい場合や、テクスチャAとB両方歪ませたい場合もあります。
  6. また、エフェクトが千切れて消えていく表現をするために、オパシティに千切れ用の別のテクスチャを指定したりもします。 この時、そのままテクスチャDの形状で削っていきたい場合もあれば、元々のテクスチャBの形状でも削っていきたい場合もあります。
  7. ここでテクスチャについてまとめると、1つのマテリアルに対してテクスチャを複数枚使い、それが2枚の場合もあれば、もっと沢山使う場合もあります。 もし1つのエフェクトに20個のマテリアルを使用していたなら、テクスチャは4、50枚は使っていることになります。
  8. エミッターAでマテリアルインスタンスを指定していたら、その親となるマスターマテリアルと、マスターマテリアルでデフォルト指定しているテクスチャも参照していますし、マテリアルインスタンス側で差し替えたテクスチャも参照しています。これら全てが参照されていることになります。 つまり、クックすると、これら全てのアセットがクックされることになるので、注意が必要です。
  9. パーティクルは大きく分けると、スプライトパーティクルとメッシュパーティクルに分かれます。 これはざっくり言えば、マテリアルをそのまま板に貼り付けて表示するか、好きなスタティックメッシュを指定して貼り付けるかだけの違いです。 (他にもビームやトレイルなど特殊なものもありますが、ここでは例外として割愛します) この講演では、板に貼り付けて表示するパーティクルを、「スプライトパーティクル」と呼称します。
  10. メッシュパーティクルの場合、指定したメッシュに元々貼られているマテリアルをそのまま使うこともできますし、別のマテリアルで上書くことも可能です。 これはとても便利で強力な機能です。 エフェクトエディタである「カスケード」上で、自由にメッシュとマテリアルを組み合わせることができます。
  11. これがもしもオーバーライドできない仕様だったら、全く同じ形状のメッシュをマテリアルの数分、用意せざるを得なかったと思います。 (なかった時のことは想像したくないですね‥)
  12. エミッターBで指定したメッシュが、元々適用しているマテリアルとテクスチャも参照されていますし、オーバーライドしたマテリアルがマテリアルインスタンスだった場合、その親となるマスターマテリアルが参照しているものと、マテリアルインスタンスが参照しているものが全てクックされることになります。 「何が一緒にクックされるか」については、後ほどあらためてお話します。
  13. つまり、たったエミッター6つで構成されたシンプルなエフェクトでも、これだけのアセットを組み合せて作成したりします。 実際にはもっと少なかったり増えたりしますが、1つのエフェクトで沢山のアセットを使っているということがお分かり頂けたかと思います。
  14. エフェクトを構成するための汎用アセットは、図のように汎用的なメッシュが大量にあり、汎用的なマスターマテリアルやマテリアルインスタンスが大量にあり、汎用テクスチャが大量にあるといった感じになります。
  15. このうち、スタティックメッシュに関しては、先程お話したようにエフェクト側からオーバーライド可能なので、必要な数だけを用意するので事足ります。
  16. しかし問題はマテリアルとテクスチャの組み合わせの部分です。 マテリアルインスタンスは、パラメータを変更したいバリエーションの数だけ用意しないといけません。 例えばテクスチャを自由に差し替えるなら、差し替える数だけマテリアルインスタンスを用意する必要があります。
  17. 図にするとこんな感じです。 ものすごく乱暴に言えば、マスターマテリアルが20種類で汎用テクスチャが100種類あれば、マテリアルインスタンスを2000個用意するといったイメージになります。 しかも実際にはUVのタイリング数のようなパラメータ違いでさらに数が増えます。 これらの組み合わせを汎用マテリアルインスタンスとして最初からある程度用意しておくのか、それともマスターマテリアルだけ用意して、あとは作業スタッフが必要に応じてその都度マテリアルインスタンスを作成するのに任せるのかで、運用スタイルが変わってくると思います。 マテリアルインスタンスのファイルサイズは極小なので、あちこちで同じ内容のマテリアルインスタンスが生まれようとも気にせず運用するのもありかも知れません。 私の場合は、最初にある程度必要だろうと思うものを用意しました。
  18. 今のはマテリアルインスタンスのお話ですが、マスターマテリアル自体も結構な数が必要でした。
  19. こちらは、UE4.13であらためてテクスチャのサイズを計測してみたものになります。 (BC7は計測していませんが、DXT5と同じサイズではないかと思います)
  20. こちらはエフェクトの汎用的なマテリアルを、UE4.13であらためて計測してみたものです。 100KBから500KB近いものまであります。 マテリアルインスタンスとマテリアル関数は、ファイルサイズ面では問題になっていません。
  21. こちらはエフェクトの汎用的なスタティックメッシュを、UE4.13であらためて計測してみたものです。 エフェクトで使用するメッシュは、せいぜい数百ポリゴン程度のものが大半なので、ファイルサイズ面ではさほどネックにはなっていません。
  22. 図にするとこのようなイメージです。 メモリには汎用的なテクスチャ・メッシュ・マテリアルを常駐させておいて‥ レベルに依存せずいつでも表示される可能性があるエフェクトは常駐アセットで作成して、レベルに紐付くものは固有アセットの併用もよしとします。 ザコ敵はレベルに配置されるのでレベルに紐付きますが、色んなレベルで登場する可能性があるのでなるべく常駐アセットで賄います。 しかし本タイトルでの事例ではこんな理想的にはいっておらず‥
  23. 実際には水色の部分のように、プレイヤーの汎用技などにも固有アセットが多くなりました。特殊な表現が多いためです。 しかしプレイヤーはゲーム中にずっと表示されるので、プレイヤーに紐付くアセットはそのまま常駐されます。 なので結果的に、「汎用的ではないけれども常駐される固有アセット」となりました。
  24. 以上がエフェクトアセットの概要になります。 これらを念頭におきながら、どうアセットを運用するかを考えていきました。
  25. ここからは、UE4で開発したあるPS4タイトルの事例のお話になります。
  26. ちょっと特殊なケースになります。 大規模プロジェクトのチーム構成、アセット構成なのですが、ゲーム全体ボリュームは小さめになります。 なのでアセットの総数や総容量の面ではあまり参考にならないかも知れません。
  27. ひとつ注意があり、開発時は最終的にUE4のバージョンは4.12でしたが、今回UE4.13で再計測しています。
  28. エフェクトの総アセット数は約3000となりました。 緑色のグラフが常駐指定したアセットで、汎用的なアセットの他に、セーブポイントとか、敵を倒した時の消滅エフェクトなど汎用的なデータが含まれています。 水色のグラフがプレイヤー専用に作られたアセットです。プレイヤーは汎用アセットだけで作れると理想ですが、賄えていないことが分かります。 そして茶色のグラフが固有アセットで、こちらも数としてはかなりの量を作っています。 とは言え、問題はアセット数ではなくファイルサイズの方です。
  29. 総ファルサイズは約500メガで、テクスチャが占めているだけでなく、予想以上にマテリアルが大きく占めていました。 水色のプレイヤー専用アセットでは、マテリアルが34メガと、結構、容量を食っています。 茶色の固有アセットでは、テクスチャもマテリアルもかなりの容量を占めています。 メッシュも44メガとそこそこの容量になっているのは、キャラクターや武器、背景のギミックやちょっとしたオブジェクトを発光させたり消滅させたりするためにエフェクト用にメッシュを別途用意したのですが、それらが1つ1MBから4MBほどになっていました。 マテリアルインスタンスやマテリアル関数は当然ながらファイルサイズの観点では全く問題になっていません。 (パートごとでは、レベル依存のものが200MB、プレイヤーが80MB、敵が50MBといった感じです)
  30. ここから具体的なアセット管理のお話に入ります。
  31. まず、エフェクトで扱う主なアセットの種類はこのような感じです。 「マテリアル関連」というのは、マテリアルインスタンス、マテリアル関数、マテリアルパラメータコレクション、デカールマテリアルなどがあります。 「パーティクルシステム」は、UE4標準のエフェクトツールである「カスケード」を使って作成したエフェクトデータのことです。 本スライド中に「パーティクルシステム」と言ったらり「エフェクト」と言ったりと表記揺れしていますが、どちらもエフェクトデータのことだと思ってください。 (スケルタルメッシュは基本的に使用していません。理由はパーティクルシステムで直接扱えないためです。  なるべくパーティクルシステムで1つのエフェクトを完結したいというのがエフェクト班での基本方針になっています)
  32. プロジェクト全体のフォルダ構成の中で、エフェクトに関するアセットは全てエフェクトフォルダ内で一元管理しています。 つまり、各キャラクターや各レベルのフォルダ内にそれぞれエフェクトフォルダがある、といった構成にはしていません。
  33. エフェクトフォルダ以下には各パートごとのフォルダがありますが、大きく分けるとプレイヤーやエネミーのようにレベルに紐付かないものと、レベルに紐付くものとに分かれます。 レベルに紐付くものも、当初は背景エフェクト、ギミックエフェクト、カットシーンエフェクトをそれぞれフォルダを分けて管理していましたが、途中でレベルに紐付くものはLevelフォルダ内に集約させました。 その方がレベルごとのファイルサイズの集計がしやすいからです。 (ただしボスに関しては固まっていた方が管理しやすいのでLevelフォルダ内では無くEnemyフォルダ内で管理しています)
  34. それから、メモリに常駐させるアセットは「コモン」フォルダで管理して、常駐はさせないものの汎用的なアセットは「ユースフル」フォルダで管理しています。 コモンフォルダは書き換え権限を私だけもらって管理しています。 欲しいアセットの要望を受けたり、ヒアリングしたりしてその都度反映していきます。 「ユースフルフォルダ」は、似たような固有アセットがどんどん増えないようにするために用意しているフォルダで、誰でもアセットを追加可能です。
  35. プレイヤーやエネミーやレベル内など、各フォルダで固有に作成されているアセットでも、汎用的に思えたらユースフルフォルダに移動しています。
  36. 「コモン」フォルダで使用頻度が低いものは「ユースフル」フォルダへ降格し、逆に「ユースフル」フォルダで使用頻度が高いものは「コモン」フォルダへ昇格させたりしています。 これから詳しくお話するのは、この「コモン」フォルダに入る常駐アセットについてになります。
  37. 常駐アセットはさらに図のようなサブフォルダにアセットを分けています。 特にマテリアルインスタンスは数が多くなるので、用途別にフォルダを分けました。 (この他にマテリアル関数フォルダもあります)
  38. エフェクトのマテリアルで扱う主な要素はこのような感じです。 1つ1つの説明は後に取り上げています。 また、ここでは基本的なものを抜き出しただけで、他にも屈折させたい場合があったり、千切れさせたい場合があったりと、まだまだ要素はあります。
  39. マスターマテリアルが組み合わせ爆発を起こします。 大雑把に言えば、この図のように10種類の要素の組み合わせ分を全て用意すると、マスターマテリアルが1024種類に及んでしまいます。 ※ParColはParticleColor、VerColはVertexColor、DynParamはDynamicParameter、ソフトはソフトパーティクル(DepthFade)、フェードはニアフェードの略
  40. なので、何かを諦めて要素を排除するか、または全てにその要素を含めてしまうなどして、いかに組み合わせを抑えるかという話になってきます。 この図の場合は、4つの要素を統一することで、1024種類から64種類まで一気に減りました。
  41. 具体的にどういった感じで取捨選択していったか。
  42. まずはエフェクトのマテリアルに必要な基本設定から順に見ていきます。 要するにメインマテリアルノードの設定についてです。
  43. まずブレンドモードが、アルファ合成か加算合成かについて。 こちらに関しては、どちらも使うケースがあります。 ブレンドモードだと他にオペイクやマスクドを、岩などで使う場面がありますが、例外になるのでここでは省きます。
  44. 次にシェーディングモデル。 端的に言えばライティングありか無しかです。 こちらは、どちらも使うケースはあると言えばあるのですが、基本的に無しでいきました。 半透明でライティングを使うものに煙がありますが、普段は使用しなかったので例外になります。
  45. そして両面処理。片面か両面か。 スプライトパーティクルは片面でも両面でもどちらでもOKですが、メッシュパーティクルの場合、大抵は両面を使用します。 例えば左の図のようなカップ形状だと、表も裏も見えてくれないと困りますし、右の図のように平面的なモデルであっても、片面だと後ろから見えなくなってしまうので両面の必要があります。 このように、エフェクトの場合、片面を使う場面は、案外かなり限られています。
  46. Separate Translucencyを利用するかどうかについて。 半透明マテリアルでこちらをONにすると、専用のバッファに描画され、被写界深度の後にシーンに合成されるので被写界深度がかかりません。 また、専用バッファに描画されるためバッファの解像度を下げることで、いわゆる「縮小バッファ」としての利用ができます。 こちらに関してはゲーム中に被写界深度の影響をエフェクトに与えるために基本的にOFFにしました。 ただしカットシーンで被写界深度の影響を受けたくない一部のエフェクトは例外として使用しました。 (スライド最後の「補足事項」で少し補足しています)
  47. レスポシブAAを利用するかどうかについて。 テンポラル・アンチエイリアシングを利用している場合に、半透明のパーティクルが背景に溶け込んでしまわないようマスクする機能です。 こちらについては、そもそもテンポラルAAを使っていないのでOFFにしています。
  48. マテリアルアトリビュートを使用するかどうかについて。 こちらは拡張やメンテナンス面で便利だとは思いましたが、使いませんでした。 使わなかった理由がいくつかありまずが、各場面ごとに必要な固有のマテリアルをエフェクトチーム全員が作成するため、マテリアルアトリビュートの使用を徹底するのが難しそうだと感じたのが大きな理由になります。 かといってマテリアルアトリビュートを使うもの、使わないもので混在させるのも、混乱を招きそうだと考えました。
  49. 次に、エフェクトのマテリアルに必要な機能について こちらは、マテリアル内のノード構成をどうするかについてになります。
  50. パーティクルカラーノードを使用するかどうか。 こちらをマテリアル内で使用すると、エフェクト側で指定した色を与えることができます。 基本的に使用します。 ほぼ全てのマスターマテリアルに含まれていて、使用していないものは一部の例外だけです。
  51. 頂点カラーノードを使用するかどうか。 こちらをマテリアル内で使用すると、メッシュに設定した頂点カラーを反映させることができます。 主にメッシュのフチを透明にするために使用しています。 必要無い場合も多いのですが、マスターマテリアルの数を減らすために、ほぼ全てのマスターマテリアルに含めました。 頂点カラーを含めていないものは一部の例外だけです。
  52. テクスチャサンプラーノードは当然使用しますが、カラーのテクスチャとモノクロのテクスチャを、どちらも使用するかどうかについて。 基本的にはモノクロテクスチャを使おうというスタンスですが、カラーテクスチャが必要な場面があるので、どちらも使用します。 ただ、非圧縮のグレースケールも使いたい時がある、BC7を使いたい時もある、といったように使いたい圧縮タイプが増えると、その対応のためにマテリアルが増えてしまうので、基本的にカラーならDXT1、モノクロならBC4の2種類でいきましょう‥というルールにしました。 屈折のためにノーマルマップを使ったりなど例外はあります。
  53. 余談になります。 例えばエミッシブカラーやオパシティが固定値で良い場合に、固定値マテリアルを用意するかどうかです。 こちらに関しては、マスターマテリアルの数を増やしたくなかったので、1x1ドットの真っ白テクスチャを使用するようにしました。 ※ただし処理負荷がシビアな場合には、余計なテクスチャサンプリングを無くすために固定値マテリアルを用意した方が良いかも知れません  参考:篠山さんの講演より  http://www.slideshare.net/EpicGamesJapan/cedec2016-unreal-engine-4  https://www.youtube.com/watch?v=iqYQvpTndTw
  54. パーティクルサブUVは、パーティクルでテクスチャのパラパラアニメを行う、専用のノードです。 このノードを使うと、パターンが切り替わる時にクロスフェードさせることが可能です。 こちらは当然ながら使用します。 ですが、パラパラアニメしない「1枚絵」のテクスチャであってもパーティクルサブUVノードを使うようにすれば、マテリアルを減らせるなあと思いました。 ただし、この場合に何か問題があったような気がします。でも思い出せません‥ 以降、本スライドでは、パーティクルでパラパラアニメさせることを「サブUV」と呼びます。 この後も何度か出てくるので、覚えておいて頂ければと思います。
  55. テクスチャにUV周りの設定ができるような構成にするかどうか。 タイリングに関しては、マテリアル内で使用している全てのテクスチャに対して、設定可能にしています。 ただしスクロール速度の制御や、UVの初期値をランダムにするための構成は、マスターマテリアルに入れているものと入れていないものがあります。 こちらについては後ほどお話しします。
  56. 余談です。 エミッター側からマテリアル全体を90度、180度、270度回転させる機能、UVを反転させる機能と、マテリアル全体のタイリング数を変えられる機能を追加してもらいました。 これにより、マスターマテリアルのみならずマテリアルインスタンスの数も大きく減らせていると思います。
  57. ダイナミックパラメーターを使うかどうかについて。 こちらはエフェクトのエミッター側で最大4つの好きな値を入力して、それをマテリアル側で取得することが可能な機能です。 エフェクトに特化して「動的にマテリアルの値を変えられる」「パーティクルごとに別々の値を与えられる」、この2点がサポートされているのが最大の特徴です。 普段は必要ないのですが、UVスクロール速度をカーブエディタで制御したい場合や、UVの初期値をパーティクルごとにランダムにしたい場合に必要です。 なので、主にメッシュパーティクル用のマスターマテリアルに組み込むようにしました。 ダイナミックパラメーターは、スライド内でこの後も何度か出てくるので、覚えておいて頂けたらと思います。
  58. デプスフェードノードを使うかどうか。 こちらは、不透明オブジェクトへの突き刺さりを緩和する、いわゆる「ソフトパーティクル」を行うためのものです。 全てのマスターマテリアルで使用したい‥と思うところですが、GPU負荷が上昇しますし、パーティクルのすぐ後ろに壁があったり、地面に敷いたりすると見えなくなってしまうので、使い分ける必要があります。
  59. フレネルノードを使うかどうか。 こちらは、(カメラからの視線と、メッシュの法線が正対するか直交するかで色分けできるので)輪郭を光らせたり、輪郭を透明にしたい場合に使用します。 エフェクトの場合は輪郭を透明にしたい場合の方が多いです。 フレネルに関しては、必要無い場合もありますし、使いたい場合もあります。 主にメッシュパーティクルで使用しますが、スプライトパーティクルでも、ビルボードさせない場合に、正面からははっきり見えて欲しいけど横から見ると消えて欲しいような場合で使ったりもします。
  60. カメラオフセットはパーティクルの位置をカメラ方向にズラす機能で、マテリアルでもWorld Position Offsetを使って実現できますし、マテリアルで行わなくても、そもそもエフェクト側にカメラオフセットの機能があります。 ただ、GPUパーティクルではカメラオフセット機能が使えないため、最初はGPUパーティクル専用のマスターマテリアルを別途用意して、そこにカメラオフセットの構成を含めていました。 ですが、その後にGPUパーティクルでも可能な代替となる機能を追加拡張してもらったので、マスターマテリアルには全く不要な要素になりました。
  61. エフェクトチーム内では「カメラフェード」とか「(カメラ)ニアフェード」と呼んでいるもので、パーティクルがカメラに近づくとフェードアウトさせるノード構成です。 こちらはパーティクルがカメラに近づくと、大写しになった後に突然パっと消えるのを軽減させるために欲しい場合がありますが、基本的には入れずに様子を見ました。 どうしても欲しい場合のためにマテリアル関数だけ用意して(各スタッフが固有でマテリアルを作る際に)使ってもらっていました。 ただし、後にエミッターでニアフェードの設定が可能なよう追加拡張してもらいました。
  62. 以上のような感じで取捨選択していき、図のような必要最小限の組み合わせを決めました。 32種類あれば最低限はカバーできるという考えです。 ここからさらに、カラーテクスチャを諦めたり、ソフトパーティクルを諦めたりすれば、16種類、8種類と減らしていくことができると思います。
  63. このまま32種類で運用するとシンプルで分かりやすいですが、DynamicParameterでUVスクロールをコントロールしたいような場合にどうしようかという問題があります。 DynamicParameterを全てのマスターマテリアルに入れてしまうには問題と感じる点が当時にはいくつかありました。
  64. そこでこのように、スプライトパーティクル用のマスターマテリアルには、フレネルとDynamicParameterは必要ないので外し、メッシュパーティクル用のマスターマテリアルには、SubUVを外してDynamicParameterを入れる‥というようにマテリアルを大きく2分しました。 こちらをベースに、最も基本的なマスターマテリアルを用意していきました。 ただし、ここには屈折や、テクスチャを歪ませたり千切れて消えさせるといった要素はありません。
  65. 例えば、「パーティクルが千切れて消えていくマスターマテリアル」が欲しい‥となった場合には、千切れ用に32種類をさらに追加するのかどうかを検討します。 千切れマスターマテリアルの場合は、基本的にアルファ合成しか用意しませんでした。 また、SubUVに対応したものも用意していません。 そうして8種類に絞ってリリースして様子を見て、「加算版が欲しい」という声が多く上がった際にはさらに追加を検討する‥という感じで対応していきました。
  66. スプライトパーティクル用とメッシュパーティクル用に大きく2分してマスターマテリアルを用意しましたが、スプライト用のマテリアルをメッシュに使いたい場面があったり、その逆もあったりします。 メッシュパーティクルでパラパラアニメさせたいとか、スプライトだけどフレネルを使いたいとか、そういう場合です。 例えばスプライトパーティクル用のマテリアルだから片面でいいと思い片面に設定してしまうと、メッシュパーティクルに転用できなくなってしまいます。
  67. この4つを心掛けています。 どれもありきたりとは思いますが、少しだけ補足したいと思います。
  68. 一般的にもよく言われていますが、マテリアルの管理者を1人に絞った方が良いというのは、経験してみてやはりその方が良いと思います。 マテリアル作成をプログラマやTAの方が一手に引き受けている場合でも、エフェクトだけは特殊なのでエフェクトの人が担当する‥といったケースをよく聞きます。 ただ、管理者がエフェクトの実制作作業を抱えると、スタッフからの要望対応やメンテナンスがおざなりになってしまいますし、しかしある程度、実制作をしないと必要性を判断できないので、区切りの良いタイミングで、メンテナンスに集中する期間をもらっています。
  69. Static Switch Parameterを当初は使っていましたが、マテリアルインスタンス側で分岐を変えると別シェーダーになるため、大半のマテリアルインスタンスがマスターマテリアルと同等のファイルサイズになってしまうという事態が起きました。 そこで開発途中からStatic Switch Parameterを完全撤廃しました。 スイッチの切り替えは「管理者しか触らない」ルールにして、引き続き使用していくことも考えましたが、誰でも触れる状態になるので、うっかり触ってしまうヒューマンエラーを懸念して、断念しました。 ただ、Static Switch Parameterは、スタッフ全員が理解する前提で使っていくのも良いと思います。 その方がマスターマテリアルの数が減るので、メンテナンスは断然楽になります。 その際には、マテリアルインスタンスのパラメータグループで一番下に並ぶようにグループ名を決めて、「一番下の項目は触らないでね」という形にするとヒューマンエラーは起こりにくいかも知れません。 もしくは、スライドの右下の図のように「Dont Touch Me」のようなグループ名を付けて、触ったらダメだと一目で分かるようにするのも良さそうです。
  70. ブレンドモードの変更に関しては、基本的にマスターマテリアルはアルファ合成で用意して、加算合成についてはマテリアルインスタンスのマテリアルプロパティオーバーライドで変更しました。 つまり、加算合成だけ中間の親が存在して、スタッフは孫インスタンスを使うことになります。 少しだけメンテナンスが楽になりました。 マテリアルプロパティオーバーライドは、Static Switch Parameterと同じく別シェーダーになるので注意が必要ですが、設定する項目が区切られているので、アリとしました。 「マテリアルプロパティオーバーライドは触らない」ようアナウンスして運用しています。
  71. プロジェクト初期にコアメンバーで話し合って、かなりガチガチに決めていますが、いつも非常に悩ましく思っています。 今の形がベストとは思いませんが、何かしら参考になればと思って取り上げました。 今回、命名規則で実施してとても良かったのが、アセットの制作者を識別する1文字をアセット名の先頭に入れたことです。 このおかげで制作者が一目で分かり、非常に重宝しました(以前のプロジェクトからやってはいましたが、今回管理が非常に大変になって大きく恩恵があった)。 例えばアセットを削除しようとしたら別のアセットが参照していて、誰に確認すればいいのか知りたい場合とか、不具合を見つけたアセットが誰担当なのかとか、エラーログにリストアップされたアセットが誰担当なのかを知りたい場合に、1つ1つサブミットの履歴を確認せずとも一目ですぐに分かります。 また、クック後のファイル一覧からファイルサイズが大きいアセットをピックアップした際にも担当者が一目で分かります。
  72. こちらはマテリアルの命名規則です。 フレネルは f 、ソフトパーティクルは s といったように、マテリアルの機能が分かるような1文字を加えるルールにしていますが、パっと見ではどうしても分かりにくいです。 悩ましいです。 実施していて地味に便利なのが、SubUV用のテクスチャを使用している際に、8x4など縦横のパターン数をアセット名に含めておいた点で、そうするとテクスチャを目でみて確認せずともパターン数が分かるので、分割数を指定する際に楽でした。
  73. パーティクルシステムだけは、アセット名の先頭は制作者ではなくVFXの「V」を入れています。 これは他セクションと直接絡むアセットだからです。 (ただ、その隣のカテゴリを1文字にするのは正直厳しく、被りまくります。例えば「エム」はマジック、マップ、ミッション、ミニゲームなど色々被って困りました。なので2文字は使った方が良いなと‥) 命名規則をここまでがちがちに決めると、慣れるまでが面倒ですが、守ってもらうようにしています。 ただしDevelopersフォルダ内のアセットの命名は自由です。
  74. ちなみに、マテリアル関数についてはUE4標準で説明文を記入できる項目があります。
  75. それから、パーティクルシステムにもタグ付けの機能を追加してもらいました。 説明文を記述することができ、担当者、カテゴリ、属性、進捗状況などをプルダウンから選んで設定できます。 そして、コンテンツブラウザ上でもポップアップ表示されます。 こちらは、サウンドの方や敵担当プログラマや、または制作者じゃない人が、何のエフェクトか確認するのにとても便利です。 それどころか、自分でも何のエフェクトだったか分からなくなってしまうので、説明文を入力する場所は必須だと思っています。
  76. そして、パーティクルシステムを検索する、「アセットサーチャー」という独自のウインドウが作成されました。
  77. 先ほど説明した、アセットに設定したタグの内容で検索をかけたり、エミッターが使用しているモジュールで検索をかけることが可能です。 使用を廃止したモジュールや、ポストエフェクトに影響を与えるような、設定に注意が必要なモジュールを使用しているエフェクトをリストアップすることができます。 また、エフェクトのプレビューが可能で、プレビューでのポストプロセスの設定変更も可能です。 そして、カスケードを開かずとも、タグや重要な設定項目の変更を直接行うことが可能です。
  78. そこで、セッションフロントエンドのオートメーションを使って、何からも全く参照されていないアセットのリストアップが可能な検索機能と、もしくはアセット名の末尾に参照数を付与してリストアップする検索機能をプログラマに追加してもらいました。 ただし、何かに参照されていても製品には乗らないものもあるので、参照数に関しては、まずは大体の目安にするようにしています。
  79. 似たアセットがありこちで生まれてしまうことがあります。 これは汎用素材で賄えていないことの証なので、基本的には汎用素材を充実化させることで解決したいところですが、すでに似たアセットがいくつもあって、統合していきたい場合もあります。 そういう時には‥
  80. 統合作業用にローカルコレクションを作って、そこに似たテクスチャを登録すれば、一覧できるので統合の検討や統合作業が楽になります。 テクスチャだけでなく、メンテナンスしたいマテリアルを登録して、完了したら登録を外していくなど、コレクションには結構使い道があると思います。
  81. ‥知っていると便利です。 それから、削除してしまいたいアセットが何かで参照されている場合に、そのまま強制削除すると参照先でリンクが切れた状態になってしまうので、「削除しました」と文字で書いたテクスチャとそのテクスチャを使ったマテリアルを用意して、削除したいアセットの代わりにそれらを置換することで、参照先で「削除されたのだな」と一目で分かって便利です。
  82. そんな時、テクスチャの設定に関しては、プロパティマトリクスを利用することで設定漏れを発見して、一括変更したりしています。
  83. マテリアルに関してはプロパティマトリクスが使えないので、大量のマテリアルに対して修正しないといけない場合に、プログラマにコマンドレットを作成してもらったことが何度かあります。 実行ファイルで直接アセットデータを書き換える形です。 例えば、プロジェクト初期にモノクロテクスチャに非圧縮グレースケールを使っていましたが、BC4に置き換えるために用意してもらったことがあります。 また、メインマテリアルノードの設定を一括変更するのにも用意してもらったことがあります。
  84. ただ、開発が進むにつれて気軽に一括変更できなくなっていきました。 それは、間違った設定のままエフェクトがFIXされていて、設定を変えると見え方が崩れるものが出たからです。 なので、今後は設定の漏れがあるものをリストアップだけして、手動で変更していく方向で検討しています。
  85. 巨大なサイズのテクスチャは、サイズマップで調べています。 テクスチャのLOD Biasの設定は反映されませんが、Maximum Texture Sizeの設定は反映されます。
  86. 私含めアーティストはハードウェアやソフトウェア周りに非常に疎いですが、良く分からない単語を知らないまま使うのが気持ち悪かったりするので、すごくシンプルにでも説明した方が安心してもらえると思います。
  87. まず、ナイトリークックについて。 開発途中から、毎晩自動でクック、パッケージングされるようになりました。 その際に出力されるログに、クックされたアセットのパスが載っているので、秀丸マクロやエクセルマクロを使ってエフェクトのアセットをカテゴリごとに分けて、ざっくりと集計できるようにしました。 ちなみに背景班は、集計するPythonスクリプトを用意していました。
  88. それから、ナイトリークックの自動集計結果がグラフで表示されるウェブページが、プロジェクトのサイト内に用意されました。 各パートごとのファイルサイズが一目で分かり、日々の推移も確認できます。 こちらでデータの総容量を確認していました。
  89. 手元でクックしてファイルサイズを調べたい時は、専用マップを作って、Unreal Frontendでクックしていました。 ファイルサイズを調べるだけならデプロイして実機に出す必要が無いのでお手軽です。
  90. ここで、各アセットをクックして判明したちょっとしたことを取り上げたいと思います。
  91. UE4.13でPS4向けにクックしたものです。 まずはテクスチャ解像度と圧縮方式を変えての計測結果です。
  92. まず、注意が必要なのが非圧縮のグレースケールです。 非圧縮ですが1チャンネルなので、本来はDXT5と同じサイズです。 なので、綺麗なモノクロ画像が使いたい場面で有効だと思いますが、テクスチャエディタでsRGBの設定をONにすることができ、ONにすると非圧縮4チャンネルのサイズになるので注意が必要です。 また、ベクターディスプレイスメントマップはインポート時の画像にアルファチャンネルがあっても無くても非圧縮4チャンネルのサイズになります。
  93. 次に、テクスチャの各種設定を変えてみての比較です。 LOD Biasの値を変えてみたり、Maximum Texture SizeやNever Stream、NoMipmapなどの設定を変えたものを比較しました。
  94. LOD Biasにプラスの値を入れるとクック後のファイルサイズに反映されますが、マイナスの値を入れても反映されません。 また、NoMipmapに設定すると、ミップマップを作成しないのでLOD Biasは当然、反映されませんが、Maximum Texture Sizeはちゃんと反映されます。 なので、テクスチャの最大サイズを変えたい場合はLOD BiasではなくMaximum Texture Sizeで変えた方が良いと思います。
  95. 次に、スタティックメッシュの分割数を変えてみての比較です。
  96. それから、Mayaでの頂点カラーの設定の有無や、UE4にインポートした時のオプションにある「自動ライトマップUV作成」と「自動コリジョン作成」にチェックが入っていた時といない時で比較しました。
  97. 結果、「自動ライトマップUV作成」と「自動コリジョン作成」にチェックが入っていると、約1.7倍のサイズになりました。 どちらもエフェクトではほぼ使用しない上に、デフォルトではONになっているので、注意が必要です。
  98. そしてマテリアルでも、ブレンドモードやシェーディングモデルなど、各種設定を変えてみて比較しました。 計測したマテリアルの中身は、エフェクトでの標準的な構成です。
  99. 一応計測した結果を載せてはいますが、UE4.14からマテリアルのファイルサイズが削減されるということですので、ひとまずは「ライティングを有効にするとサイズが増える」程度の認識で良いかと思います。
  100. 次に、クックした時に、何が一緒にクックされるかについて。
  101. まず、マテリアル内で未使用のまま残ったノード群は、クック後のファイルサイズに含まれてしまいます。 特にテクスチャサンプラーノードが残っていると、参照しているテクスチャも一緒にクックされるので注意が必要です。
  102. それから、パラメータ化したテクスチャノードに、デフォルトで設定しているテクスチャもクックされます。 スタティックメッシュに直接、設定しているマテリアルもクックされます。
  103. マテリアルエディタやマテリアルインスタンスのエディタのプレビューに、スタティックメッシュを使用していると、そのメッシュもクックされます。 キャラや背景オブジェクトなどポリゴン数が多いものをプレビューに使っている場合にはご注意ください。 また、マテリアル関数のInputやOutputノードに、プレビュー用に接続しているテクスチャも、クックされます。
  104. カスケード上で非表示にしているエミッターが、参照しているメッシュ、マテリアル、そのマテリアルが参照しているテクスチャなど諸々のアセットも、クックされます。 これは結構、注意が必要だと思います。
  105. エフェクトアセットをゲーム中に表示して、見た目をチェックしたり処理負荷を計測したりするといったことについてお話します。
  106. まず、UE4エディタ上でのエフェクトのチェックについて。
  107. 実際の処理負荷は実機上で計測してみないと分かりませんが、シェーダー複雑度、パーティクル数、エミッター数、パーティクルに内包したライトの数や範囲は、パフォーマンス面での指標になります。 特に、当プロジェクトではエミッター同士で親子関係が可能なよう独自拡張していますので、エミッターを100個生むような構成が簡単に可能で、エミッター数が多いとCPUのパフォーマンスが大きく落ちるので注意が必要でした。 また、パーティクルのライトの数も、うっかり大量のパーティクルとともに生成してしまうと、画面がひきつるほどの負荷になります。
  108. 次に、実機上でのチェックについて。
  109. エフェクトチームに共有ブースがあり、そこでPS4上でプレイチェックしたり、処理負荷チェックしたりしました。
  110. 具体的な処理負荷の計測の流れですが、まずは床と平行光源しかないマップを新規に用意します。 そこに先ほどご紹介したエフェクト切り替え表示アクターを配置して、処理負荷を計測したいエフェクトを複数、登録します。 次に、実機に出力したら、余計な処理を全てOFFにします。 キャラクターをOFFにしたり、メニューをOFFにしたりです。 また、処理が暴れるのを抑えるために、コンソールコマンドで垂直同期をOFFにし、フレームレートも天井を上げるためにMAX120フレームにしました。
  111. 計測するエフェクトですが、この講演の冒頭のヒットエフェクトのような感じの構成のものを基準のエフェクトとして用意しました。 エミッター5つのシンプルな内容です。 そして、基準のものと比較したいエフェクトを沢山用意して、実機上で切り替えながら計測しました。
  112. エフェクトを1個、中央にポツンと表示しても、誤差の範囲で計測しづらかったので、単体表示の場合と、25個敷き詰めて表示した場合と、それぞれを計測しました。 ちなみに計測する値は、コンソールコマンド「Stat Unit」で表示される、Gameスレッド、Drawスレッド、GPUスレッドの各処理時間の値です。 標準のエフェクトと比べて、こちらのエフェクトはGameスレッドが何ミリセック増えた、Drawスレッドが何ミリセック増えた‥といった感じで差分を出していきました。 これをUE4のバージョンアップごとにはやってられませんが、一度やっておくと参考になります。
  113. ちなみに、UE4.9の頃に計測した結果の中から、マテリアル関係のものをピックアップしました。
  114. World Potision Offsetに関しては、頂点をテクスチャでもこもこさせる程度の構成です。 Powerは1つのマテリアルに10個ほど入れてエミッター5つで計50個、さらにエフェクトを画面に25個、敷き詰めて表示して、GPUスレッドが微上昇した感じです。 (Powerノードは色のコントラストの調整に使えてとても便利なのですが、重い重いと聞いていたのでなるべく使わないようにはしています。   ですが、マテリアル内に数個、単純な色の調整に使うくらいならそこまで過敏にならなくても良いのかなと思いました) DynamicParameterは、GPU負荷がかなり上昇した結果になりましたが、かなり怪しいです。計測ミスな気がします。こちらだけUE4.13で計測し直したところ、上昇は見られませんでした。 半透明マテリアルのGPU負荷は、描画面積でも大きく変わるので、あくまで目安にしています。
  115. UE4上でのチェックや、実機上でのチェックは以上のような感じになります。 チェック関係で他にちょっとしたことと言えば、特に重たい表現は、使って大丈夫か?軽くならないか?など描画エンジニアに相談しています。 例えばパララックス・オクルージョンは見た目も派手なのでバンバン使いたいけど重たいものの1つです。 こちらは実機で計測して、step数に気を付けることと、使用する場面を限定してもらうよう班内に周知しました。 例えば、画面上に大きく映る場合は、大技で画面に1個ならOK、といった感じです。
  116. また、エフェクトの描画に不具合が起こった場合は、レンダードックでシーンをキャプチャーして、描画エンジニアに提出して調べてもらったりしています。 シンプルなのでアーティストでも使いやすいと思います。 キャプチャーデータを提出時には、描画のどのタイミングで不具合が起こっているか、分かる範囲で大まかに見て伝えるくらいはするようにしています。 ライティングパスで起こっているのか、ブルームの時に起こっているのか、被写界深度の時に起こっているのか、といった感じです。
  117. テクスチャ回りについての補足。
  118. ケースバイケースであっても目安の提示は必要だと思います。
  119. 最初はこちらのようなマテリアルを作成して調べました。 ComputeMipノードを使用して数字のテクスチャを切り替えるマテリアルです。
  120. その後、描画エンジニアがカスタムノードを使ったマテリアルを用意してくれました。こちらだと色付きで境目がとても良く分かります。
  121. カラーテクスチャはsRGBの設定はONのまま運用しています。 モノクロテクスチャはBC4なので、そもそもsRGBをONにすることはできずリニアなデータとして扱われますが、テクスチャ自体はPhotoshopでsRGB環境で作成するので、マテリアル内で2.2乗して暗くする必要があります。 問題なのは不透明度の方で、不透明度も2.2乗しないと結果に対して違和感が出てしまいます。 リニアな中間グレーを人間には「明るい」と感じるように、リニアな0.5の不透明度は「不透明に近い」ように見えてしまいます。 そのため、不透明度にも累乗して対処しました。 (テクスチャのアルファチャンネルをOpacityに接続する場合でも同様の注意が必要です)
  122. 最初はPowerノードを使って2.2乗させていましたが、大半のマスターマテリアルに含まれることになるため、描画負荷を少しでも軽減させるためにPowerノードを減らすために代わりに乗算ノードで2乗させるようにしました。 2.2乗と比べると若干明るい結果になりますが、許容範囲としました。
  123. 頂点カラーもリニアな値なので2乗しています。 特に頂点カラーのアルファの値は累乗して補正しないとモデルがなだらかに透明になっていくように見えません。
  124. それから、「2乗しました」ということが一目で分かるようマテリアル関数化しました。 中で2乗しているだけなのでほとんど意味がない関数ですが、分かりやすいとスタッフにも案外好評です。
  125. ちなみに、もしも2.2乗する構成から2乗する構成に移行する場合、テクスチャをPhotoshopのレベル補正で中間ポイントを0.91あたりで調整すれば‥
  126. 2.2乗の場合と2乗の場合で見た目がほぼ一致しました。
  127. (こちらは検証してぴったり一致するのを確認しました)
  128. エフェクトは突発的に表示され、しかも一瞬だけで、画面に近い場合も多いです。 なので低解像度のMiplevelで表示されやすく、絵柄が炎のようにディティールがはっきりしたものは低解像度であることが目立ったため、例外的にNeverStreamをONにしました。
  129. 次に、マテリアルについての補足です。
  130. 講演の前半の方で軽く触れたSeparate Translucencyの設定ですが、こちらがONとOFFのマテリアルを混在させると、OFFにした半透明が描画された後にONの半透明が合成されて描画順に影響が出てしまうので、基本的にはどちらか一方に統一した方が良いと思われます。 そして、例外的にもう片方の設定のマテリアルを使いたい場合に、どういう場面で使うかと、どう管理するかを考える必要が出てきます。
  131. 今回のプロジェクトではSeparate Translucencyは各セクションと話し合った結果、基本的にOFFでいこうとなりました。 被写界深度はカットシーンで入っていたり、ゲーム中にもほんのり入っていたりしますが、エフェクトに被写界深度の影響を与える方針です。 なので、プログラマにSeparate Translucencyの設定をデフォルトでOFFにするよう変更してもらいました。 その後、カットシーンでのみSeparate Translucency ONを使いたい場面がちょこちょこ出てきたので、ONにしたアセットを管理する専用のフォルダを用意して、最初はOFFのものと同名で保存するようにしていたのですが、同名だとアセットを検索した時に2つ引っ掛かってしまい危険なので、命名規則にSeparateを有効にしたことが分かる文字列を追加しました。
  132. Usageについては必要最小限の設定にしたいところです。 しかし汎用マテリアルは私しかアクセス権が無いため、Usageに新たにチェックが入る度に報告をもらってサブミットするというのは手間なので、エフェクトで主に使用される、「Particle Sprites」、「Beam Trails」、「Mesh Particles」の3点については、あらかじめチェックONにしています。 切り詰めたいなら、最低限のチェックにするか、またはBeam Trailsだけは外しておくのが良さそうです。 ちなみに「Static Lighting」はスタティックメッシュに貼り付ける場合にチェックが必要ですが、UE4.13でクックしたところ、半透明マテリアルで「Static Lighting」にチェックを入れても、ごく僅かしかファイルサイズが増えなかったので、こちらもONにしておいて良いかも知れません。
  133. 大量のマテリアルに対して、同じノード構成を組み込む必要があった際に、メインマテリアルノードの詳細パネル内に専用の項目を追加してもらいました。 チェックボックスをONにするだけなので、設定がとても楽です。 例えば、シーンの露出補正によってエミッシブカラーの値が保たれるようにするチェックボックスがあります。
  134. (知っておいて損はないというくらいの?感じで)
  135. プロジェクト初期の頃はRGBまとめて接続していましたが、プラットフォームによっては赤く表示される現象が出たためです。
  136. エフェクト用のマテリアルで工夫しがいがある部分としては、まずはDynamicParameterの4チャンネルの値の活用があります。 マテリアルインスタンスが大量に増える原因になっているパラメータを、DynamicParameterで賄うのが良い活用方法だと思います。 それから、もしも色の指定が固定値で良いのなら、ParticleColorノードの4チャンネルの値を、別の何かに自由に使えます。 例えば、屈折マテリアルでは、屈折の強さの制御に使っていたりいます。 DynamicParameterとParticleColorを合わせると、エフェクト側から8つの値を自由に変更可能になります。
  137. それから、マテリアルでParticleRandomノードを使えば、GPUパーティクルに限定されるものの、パーティクルごとに0~1のランダムな値を与えることが可能です。 GPUパーティクルではDynamicParameterが使えないため、UVスクロールの初期値ランダムやSubUVの開始パターンのランダムに利用するといったことが考えられます。
  138. それから、Static Component Mask Parameterノードを利用すると、RGBAの4つのチャンネルの中からどれを使用するかをマテリアルインスタンスで自由に切り替えられます。 こちらを利用すれば、BC7のテクスチャにモノクロ画像を4つ格納して、マテリアルインスタンスで使用する画像を自由に切り替えられるので、夢は膨らみます。 ただし、Static Switch Parameterと同様に、設定を切り替えると別シェーダーになるので、エミッシブカラーとオパシティで16通りの組み合わせの中間親のマテリアルインスタンスを運用する必要があり、そのままでは非常に分かりにくいアセット運用になってしまいそうなので、何かしら管理が楽になる工夫や拡張が必要な気がします。
  139. 最後に、マテリアルの利便性を向上させるために行っていることです。
  140. 面倒ですが徹底すれば、マテリアル関数の機能と使用方法のドキュメントを別途用意して、スタッフがいちいちドキュメントを開いて使い方を確認しないといけないという状況が和らぎます。
  141. 適切なデフォルト値を入力することで、マテリアル関数を使用した際に効能がすぐ分かるようになり、そこで何を値を変えなくても標準的な効果が発揮されることで若干の手間を省けます。 また、Use Preview Value as DefaultをONにすることで、マテリアル関数に何も入力しない状態でエラーになってしまうのを防ぐことができます。
  142. コンテンツブラウザ上でマスターマテリアルの中身が一目で分かるよう、アイコン画像のテクスチャをデフォルトに指定して、サムネイル化する工夫をしました。 ただしクック後のデータに含まれるので16x16の小さな画像を最低限の数だけ用意しました。 これだけでも閲覧性はかなり上がりました。 もうちょっと解像度を上げて、ソフトパーティクルのS、フレネルのFなどを画像に加えたものを用意した方が、より良いと思っています。
  143. マテリアルインスタンスで親マテリアルを差し替えた時に、パラメータ名が同じ場合は設定内容を引き継いでくれるので、パラメータ名はシンプルでストレートなものが良いと思います。 その前提の上で‥
  144. 多くのマスターマテリアルに含まれるような基本的な設定項目だけは、設定しやすい順に並んで欲しかったので、エミッシブカラー、オパシティ、ノーマルなどの一部のカテゴリだけは、グループ名の先頭に連番を加えました。 少なくとも汎用マスターマテリアルでは統一しているので、レイアウトが統一され、スタッフにとっては設定がしやすくなって良かったように思います。
  145. それから、UV周りの計算順について。 UVは先にスクロール速度を与えてから、その後にタイリングさせる方が良いです。 そうすると、タイリング数を変えてもスクロール速度が変わりません。 これはちゃんとやっておけば良かったと後悔している例になります。 後から変更するとそれまで作成したアセットに影響が出るので修正できませんでした。 こういった些細なことが、作業効率に影響するので、注意が必要なひとつの例になります。
  146. さいごにもう少しだけ。