Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
ローポリで見えてくるポリゴンのあれやこれ
Search
kappa
December 10, 2017
0
4.2k
ローポリで見えてくるポリゴンのあれやこれ
3DCG Meetup #13
ローポリで見えてくるポリゴンのあれやこれ
頒布資料
kappa
December 10, 2017
Tweet
Share
More Decks by kappa
See All by kappa
コンセプトから始めるゲーム作成の流れ と その時々の決め事
kappa1116jp
0
610
Featured
See All Featured
実際に使うSQLの書き方 徹底解説 / pgcon21j-tutorial
soudai
167
49k
Why You Should Never Use an ORM
jnunemaker
PRO
53
9k
The Art of Programming - Codeland 2020
erikaheidi
51
13k
Building Adaptive Systems
keathley
38
2.2k
GitHub's CSS Performance
jonrohan
1030
460k
Product Roadmaps are Hard
iamctodd
PRO
48
10k
Happy Clients
brianwarren
97
6.7k
Save Time (by Creating Custom Rails Generators)
garrettdimon
PRO
27
790
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
226
22k
Understanding Cognitive Biases in Performance Measurement
bluesmoon
26
1.4k
Facilitating Awesome Meetings
lara
49
6k
GraphQLとの向き合い方2022年版
quramy
43
13k
Transcript
ローポリで見えてくる ポリゴンのあれやこれ
▪自己紹介 • ハンドル・ネーム かっぱ Twitter @kappa1116jp • ゲーム畑で育った感じ 背景モデラー歴が一番長いけど、なんでも一通りやった気がする人です おもに携帯ハードのゲーム制作が長い(3◦S
とか P◦Pとか ガラケーとか スマホとか) • 3DCG Meetupは2回目の登壇 (前回は同人ゲーム作ったときの企画?(開発進行的)な話をさせえていただきました) 2
▪今回の内容の前に !注意! • 昨今では不要になりつつある情報が多いです 今の時代にそぐわない情報もあるので、頭の片隅に • わりと独学なので偏見、間違っている点があるかもしれません 違うだろ!ってのが有りましたら質疑応答時に 補足していただけるとすっごく助かります!! •
かなり初心者向けの内容になります。 ベテランな人には当たり前で眠い内容になると思いますが、 間違いがないか見張ってて下さい<•><•> 3
▪改めて 今回の内容 で、今回の内容 皆さんが使っている3Dデータ その中でリアルタイムの場合、気にしている点 頂点メッシュの話をメインに、ローポリデータでのこだわり、削減をしている 実例をお話できたらと思います。 ※テクスチャ、マテリアル、シェーダーについては殆ど触れません 「昔は~」な所も多いのでゆる~い気もちでお聞き下さい。 (たぶん時間が余るので頂点以外に処理負荷を軽くするあれこれもお話できれば…)
4
▪改めて 今回の内容 議題 1. 頂点に含まれる情報の確認 2. 1頂点に収まらないケースの確認 3. ポリゴン削減の必要性について再確認 4.
頂点を減らすときの目安 5. 軽いデータについて少し 5
▪ローポリってな~に? この言葉は時代や環境でかな~り振れ幅がある『言葉』のため !超危険ワード!です 10年ぐらい前だと 1キャラ ・携帯機だと400ポリゴンまで ・据え置き機で5000ポリゴンまで 今だと 1キャラ ・携帯機だと700ポリゴンまで(500頂点)
・据え置き機で10000ポリゴンまで(7500頂点) みたいに日々変化し、相手の想定でも大きく変わります 6
▪なんで制限を決めているのか リアルタイムの処理は限界がある 処理落ちやもっさり感、ロードを長い ≠ リッチな表現やいろんな表現をしたい 制限された中でどこまでリッチに、どこまでいろんな表現ができるか デザイナーの腕の見せ所(作りやすさも大事ですが) 7
▪モデルの制約 モデルの規約としては ・ポリゴン数(三角ポリゴン) ・頂点数 の2種類があります。最近だと頂点数で制限するところも増えた気がします。 (自分も最近は頂点数で制限を記載しています) メッシュデータの場合は頂点数がメモリーや処理負荷に直結する値なのですが 便宜上ポリゴン数でカウントして制限していることが有ります。 他にも ・マテリアル数
・テクスチャ枚数 ・テクスチャサイズ ・ボーン数 が決められていることが多いです リアルタイム用のデータだとかなり厳密に設定されています。(なかでも携帯機はより厳密) 8
▪その中でひとまず頂点から DCCツール(maxとかmayaとかBlenderとかMetasequoiaとか)で ポリゴンを作成して、ゲームエンジンで簡単に表示できる昨今ですが、 作成した頂点ひとつにどういう情報が含まれているかご存知ですか? 確認して行きましょう。 9
10 議題 1. 頂点に含まれる情報の確認 2. 1頂点に収まらないケースの確認 3. ポリゴン削減の必要性について再確認 4. 頂点を減らすときの目安
5. 軽いデータについて少し
▪1頂点に含まれる情報ってどんなの?その1 位置として ・位置 座標として XYZの3個情報が入ります ※回転や拡大縮小の情報は オブジェクトとして入るため頂点には入っていません 11
▪1頂点に含まれる情報ってどんなの?その1 面の向き(厳密には違うけど)として ・頂点法線 角度として XYZの3個情報が入ります ※面自体の向きは実は面の生成時にあり 頂点の法線は別のものになります 12
▪1頂点に含まれる情報ってどんなの?その1 テクスチャが貼ってあればUV情報 ・UV1 縦軸,横軸なので 2個情報が入ります 13
•ココまでが基本情報 •ココまでがテクスチャのあるメッシュとしての最低限の構成です 頂点には更に追加できる情報でありますが その分、処理負荷が増える恐れがあります (おもにメモリー負荷とGPU負荷) 次は『追加できる情報』について確認してきましょう 14
▪1頂点に含まれる情報ってどんなの?その2 マルチUVの場合(サブUVとも呼ばれる) ・UVは2~4 UV1と同じく1個につき2個 最大で6個情報が入れられます ※内部的にはUVは4個(UVWX)の情報が入れられますが プラットフォームやゲームエンジンでは4個使えないものもあるので 今回は2個とします。 15
▪1頂点に含まれる情報ってどんなの?その2 頂点に色を付けた場合 ・頂点カラー 1頂点に付きRGBAの4個情報が入れられます ※実は精度に2種類あって0~255の整数しか入らないものと 1677万色まで入るモードが有ります。 ※プラットフォームや描画エンジンでも扱いが違うかも 16
▪1頂点に含まれる情報ってどんなの?その2 ノーマルマップがある場合 ・接線情報 頂点法線のねじれ方みたいに思ってもらうとわかりやすいかも 1頂点に付きXYZの3個情報が入ります 17
▪1頂点に含まれる情報ってどんなの?その2 スキンメッシュの場合 ・スキン情報 関連するボーンの数に応じて変化(だった気がする) 具体的には調べきれていませんが 頂点数によって変化するものということで記載します (※これはCPU負荷だったりGPU負荷だったりする) 18
▪まとめると 位置 XYZ 3個 頂点法線 XYZ 3個 UV1 UV 2個
UV2 UV 2個 UV3 UV 2個 UV4 UV 2個 頂点カラー RGBA 4個 接線 XYZ 3個 頂点に入れられる枠(情報)のすべてです。 19
▪逆に言えば 以上が追加できる情報の数になりますが 逆に言えば 枠より多いものは 1頂点には含むことはできない ということです。含んでしまうと… 1頂点ではなく別頂点として内部的には扱われます 20
21 議題 1. 頂点に含まれる情報の確認 2. 1頂点に収まらないケースの確認 3. ポリゴン削減の必要性について再確認 4. 頂点を減らすときの目安
5. 軽いデータについて少し
▪こういう場合は実は… ・頂点法線が別 ハードエッジでは1頂点に対して 頂点法線を別の方向を持つため 別の頂点の扱いに 22
▪こういう場合は実は… ・UVの頂点が別の位置にある UV上でシームの頂点は別のUV座標を持つため 別の頂点の扱いに 23
・頂点カラーが別 面単位で塗られた頂点カラーは 複数の色情報を1頂点に持つため設定されるため 別の頂点の扱いに ▪こういう場合は実は… 24
・マテリアルが別 描画エンジンでは隣接する面のマテリアルが別だと メッシュ自体が別のものとして扱われる ▪こういう場合は実は… 25
議題 1. 頂点に含まれる情報の確認 2. 1頂点に収まらないケースの確認 3. ポリゴン削減の必要性について再確認 4. 頂点を減らすときの目安 5.
軽いデータについて少し 26
▪そこまで厳密にする必要はあるの? ・正直最近のハードウェアパワーなら誤差の範囲 でも軽くしたつもりが実は…なんてことはやりたくないですよね ・もっと気にしなきゃいけない点 メモリー容量:テクスチャサイズのほうがクリティカル 処理負荷 :マテリアル数のほうがクリティカル 27
▪役立つ場面 ・職人芸なローポリを求められた時 ・リトポロジーの時 28
29 議題 1. 頂点に含まれる情報の確認 2. 1頂点に収まらないケースの確認 3. ポリゴン削減の必要性について再確認 4. 頂点を減らすときの目安
5. 軽いデータについて少し
▪こういう形状、頂点数が少ないのはどっち?その1 ・差し込み形状やるべき? UVが切れるため厳密には変わらない ハードエッジ必須なら変わらない でもスキンメッシュの場合は マージしていたほうが僅かに軽いかも ※形が痩せてしまうボーン配置もありえます 結果:引き分け 30 差し込み
結合 結合してると 痩せる
▪こういう形状、頂点数が少ないのはどっち?その2 ・ずらしたポリゴン 頂点数が変わらないならマージしていたほうが UVが切れないし少ないデータになる (形状修正もやりやすいし) 結果:マージした方の勝利 31 △4ポリ 8頂点 △6ポリ
8頂点
▪こういう形状、頂点数が少ないのはどっち?その3 ・両面ポリゴン シェーダーでやったほうが軽いのですが 全体とマテリアルが別れてしまうと負荷が上がる事があるので ポリゴンで2重面のほうが軽いケースが多いです 結果:ポリゴンで2重面が優勢 32 裏面 表面
▪ポリゴンを減らしてもバレないあれこれ ・角数の雑学 細いと少ない 大きいと多い ※偶数のほうがバランスがいい気がする ・エッジの長さも同じを意識してもいいかも 例:エッジの長さが等しい20面体はかなり丸く見える 33
▪ポリゴンを減らしてもバレないあれこれ 34 8角型 12角型 16角型
▪ポリゴンを減らしてもバレないあれこれ シルエットのとして見える凹みは騙せない ・凹みが貫通している場合は 騙せない ・貫通していない場合は 騙せる 35
▪結果的には ・余分な情報はのせない 1頂点の中身も気を使おう ・あまり無茶はしない 減ってるようで減ってないことがある ・とにかくシルエットに気を使う 逆に言えばシルエット以外はほとんど騙せる 36
37 議題 1. 頂点に含まれる情報の確認 2. 1頂点に収まらないケースの確認 3. ポリゴン削減の必要性について再確認 4. 頂点を減らすときの目安
5. 軽いデータについて少し
▪頂点以外でも軽いデータで気を使う所すこし ▪オブジェクト数 まとめて描画する機構はあるけど、少ないに越したことはない ※スキンメッシュはまとめ描画機構が働かない ▪マテリアル数 マテリアル分オブジェクトが別れてしまう 38
▪おわり ご清聴ありがとうございました 39
▪質疑応答 なにかありましたら 40