アカウント名:
パスワード:
初日は4090を載せたマシンでも尋常じゃなく重かったが、強制的に設定が変更されたおかげでずいぶん軽くなった。とはいえ、・ズームアウトして街全体を設計する・ズームインして市民1人1人の生活を観察する。背景には自分が作ってきた街並みが見えるといったように神の視点と人の視点がシームレスに繋がっているのがCS2の素晴らしい点なので、画質はこのゲームにとって割と本質的な要素であると感じる。最適化を頑張ってほしい(今必死に取り組んでいるところだろうが)
最適化を頑張ってほしい(今必死に取り組んでいるところだろうが)
今というか今さらだよねぇ何年前に当たり前になった技法なのかと小一時間
# えらいひとがごねて仕方なく阿呆な実装せざるを得なかったんかな
「見えない部分の描画は省く」って、何十年前レベルの手法じゃ?詳しくないけど、Zバッファ法だっけ?
わたしマクドナルド理論きらい。(´・ω・`)
LODの場合、そもそも細かく描いても意味がないメッシュ(ポリゴン)は省きます。今時のGPUだとあまりにも小さく描かれる場合は早い段階で描画対象からカットされますが、それでもGPUに描画対象として投入するコストはかかりますから。他にはボーンも減らしたり、スキニング削ったり…安いモデルへの切り替わりで目立たないようにするのがちょっと大変ですが。
確かこのソフト、住人モデルを自動生成してると聞くので、その辺でLOD導入手間取ったんじゃ。
LODの観点だと、「歯に至るまで」ってのは些末な問題で「詳細に描画」てのが問題ですね。
「歯を描く」ってのは、「口を開けていて、歯が見える」状況を想定してるってことで、そういう想定をするなら、LODを真面目にやるなら高ディテール→歯の一本一本精密にモデリング(口の中を覗き込むようなアングルでもOK)中ディテール→歯を前から見た一枚板(ちょっと離れた人物の描画。口の中は前歯が見えるだけって程度)低ディテール→口の中はテキトーにマッピングですませる(モブは口の中がどうなってるかなんてもう見えないけど、色合いは合わせる)ぐらいのLODかな。LOD対応しても、歯の描画は残る。
こんなの真面目にやると面倒なので、詳細なモデルデータから低ディテール版を自動生成ってのもよくある。
住人モデルを自動生成、となると、各デティール毎にモデル自動生成処理を作るってことになるかな。住民モデル生成処理が増えるので導入はすごく手間取りそう。
このゲームの場合離れると相当な距離になるので、口が開かなかったり顔に骨入ってなくて肌色一枚くらいまで落としたのあってもいいかも。
オブジェクトごとにバラバラに描写していると、低ディテール版の自動生成ではうまくいかないことも多い。たとえばオープンワールドゲーだと、地形は遠くまで描写するけれど、木や建築物などは、ある程度近づかないと描写をしないことが多い。
地形の低デティール版を単純に自動生成した場合、遠方の山が禿山になってしまうので、エンジンのクセに合わせたテクスチャを用意する必要がある。
ゲームは触ってないけどオプション項目的にLODは使ってないでしょ。テッセレーションによるポリゴン分割で調整してるんだろうけど、それがうまく機能してないか単純に負荷が高い。LODは読み込みやモデル切り替え時の負荷に問題あったり、ざっくり言うと汚いので美学に反してるんだろう。せっかくIIとして作り直したんだしね。
当たり前になった技法云々は、今回ストーリーにもあるLODの方じゃないLODも割と進化していて、UE5のNanite(仮想ジオメトリ)だとLODを勝手に調整するから、数億ポリゴンとか突っ込んでも動くぞってのがウリになってる
見えない部分の描画を省くってのは、Zバッファ法だけだとGPU負荷が高いからオクルージョンカリングとかでまずは大雑把に消し込んでいくのが主流だと思うAABBなりOBB単位で遮蔽判定するけどそれはモデル単位だろうから、歯が人物モデルと一体化してると一緒に「描かれる」判定になって描画されるんじゃないかな(でGPU側のZバッファによって、実際には描き込まれない)
UE5のNaniteは動的に生成するオブジェクトとか、動くオブジェクト一般に適用するのが結構難しい。こういうSim系のソフトに使えると非常に効果的だと思うけど、もうちょっとユーザ側(UE5使ってゲーム開発する人)の経験が増えないと一般的にならないと思う。
UE5のNaniteは動的に生成するオブジェクトとか、動くオブジェクト一般に適用するのが結構難しい。
その辺はVR方面のFoveated renderingのほうがいいのかなアイトラッキングを中心点にしている動的な方である必要は低いからfixed foveated renderingのほうで
動的でもスマホレベルの描画性能できるならiGPUのみで十分行けるんじゃないかな
それは基本的にはVR向けなどの超高解像度のレンダリングを低負荷で行うための技術です。主にGPUのラスタライズ性能の補完になる。
UE5のNaniteは頂点処理や、もっと言えばゲーム制作側のLODの設計負荷を減らすための物。ラスタライズ性能が十分に足りてるGPUでこそ効果がある。
数億ポリゴンとか突っ込んでも動くぞってのがウリになってる(※実際には色々調整必要)の後半省いてたけど、まー実際にはそうだよね Matrixデモも性能出すためにこう工夫してたよって講演 [unrealengine.com]有ったし、XBOX Series SでUE5動かす上でやっぱり負荷が高すぎる [4gamer.net]ってのも講演があったし
Naniteもあくまでインポート時に必要な解析 [unrealengine.com]をしてるから、動的オブジェクトとは相性悪いだろうね
インポート時 —
3Dゲームの黎明期からあるんだよなあ…。例えばマリオ64でもやってる。当時既にLoDという名前だった。(雑誌で宮本氏が話してた記憶)
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
私は悩みをリストアップし始めたが、そのあまりの長さにいやけがさし、何も考えないことにした。-- Robert C. Pike
今は軽い (スコア:0)
初日は4090を載せたマシンでも尋常じゃなく重かったが、強制的に設定が変更されたおかげでずいぶん軽くなった。
とはいえ、
・ズームアウトして街全体を設計する
・ズームインして市民1人1人の生活を観察する。背景には自分が作ってきた街並みが見える
といったように神の視点と人の視点がシームレスに繋がっているのがCS2の素晴らしい点なので、
画質はこのゲームにとって割と本質的な要素であると感じる。
最適化を頑張ってほしい(今必死に取り組んでいるところだろうが)
Re:今は軽い (スコア:0)
最適化を頑張ってほしい(今必死に取り組んでいるところだろうが)
今というか今さらだよねぇ
何年前に当たり前になった技法なのかと小一時間
# えらいひとがごねて仕方なく阿呆な実装せざるを得なかったんかな
Re: (スコア:0)
「見えない部分の描画は省く」って、何十年前レベルの手法じゃ?
詳しくないけど、Zバッファ法だっけ?
Re:今は軽い (スコア:2)
わたしマクドナルド理論きらい。
(´・ω・`)
Re:今は軽い (スコア:1)
LODの場合、そもそも細かく描いても意味がないメッシュ(ポリゴン)は省きます。
今時のGPUだとあまりにも小さく描かれる場合は早い段階で描画対象からカットされますが、
それでもGPUに描画対象として投入するコストはかかりますから。
他にはボーンも減らしたり、スキニング削ったり…
安いモデルへの切り替わりで目立たないようにするのがちょっと大変ですが。
確かこのソフト、住人モデルを自動生成してると聞くので、その辺でLOD導入手間取ったんじゃ。
Re: (スコア:0)
LODの観点だと、「歯に至るまで」ってのは些末な問題で「詳細に描画」てのが問題ですね。
「歯を描く」ってのは、「口を開けていて、歯が見える」状況を想定してるってことで、そういう想定をするなら、LODを真面目にやるなら
高ディテール→歯の一本一本精密にモデリング(口の中を覗き込むようなアングルでもOK)
中ディテール→歯を前から見た一枚板(ちょっと離れた人物の描画。口の中は前歯が見えるだけって程度)
低ディテール→口の中はテキトーにマッピングですませる(モブは口の中がどうなってるかなんてもう見えないけど、色合いは合わせる)
ぐらいのLODかな。LOD対応しても、歯の描画は残る。
こんなの真面目にやると面倒なので、詳細なモデルデータから低ディテール版を自動生成ってのもよくある。
住人モデルを自動生成、となると、
各デティール毎にモデル自動生成処理を作るってことになるかな。
住民モデル生成処理が増えるので導入はすごく手間取りそう。
Re: (スコア:0)
このゲームの場合離れると相当な距離になるので、口が開かなかったり顔に骨入ってなくて肌色一枚くらいまで落としたのあってもいいかも。
Re: (スコア:0)
オブジェクトごとにバラバラに描写していると、低ディテール版の自動生成ではうまくいかないことも多い。
たとえばオープンワールドゲーだと、地形は遠くまで描写するけれど、木や建築物などは、ある程度近づかないと描写をしないことが多い。
地形の低デティール版を単純に自動生成した場合、遠方の山が禿山になってしまうので、エンジンのクセに合わせたテクスチャを用意する必要がある。
Re: (スコア:0)
ゲームは触ってないけどオプション項目的にLODは使ってないでしょ。
テッセレーションによるポリゴン分割で調整してるんだろうけど、それがうまく機能してないか単純に負荷が高い。
LODは読み込みやモデル切り替え時の負荷に問題あったり、ざっくり言うと汚いので美学に反してるんだろう。せっかくIIとして作り直したんだしね。
Re: (スコア:0)
当たり前になった技法云々は、今回ストーリーにもあるLODの方じゃない
LODも割と進化していて、UE5のNanite(仮想ジオメトリ)だとLODを勝手に調整するから、数億ポリゴンとか突っ込んでも動くぞってのがウリになってる
見えない部分の描画を省くってのは、Zバッファ法だけだとGPU負荷が高いからオクルージョンカリングとかでまずは大雑把に消し込んでいくのが主流だと思う
AABBなりOBB単位で遮蔽判定するけどそれはモデル単位だろうから、歯が人物モデルと一体化してると一緒に「描かれる」判定になって描画されるんじゃないかな
(でGPU側のZバッファによって、実際には描き込まれない)
Re: (スコア:0)
UE5のNaniteは動的に生成するオブジェクトとか、動くオブジェクト一般に適用するのが結構難しい。
こういうSim系のソフトに使えると非常に効果的だと思うけど、もうちょっとユーザ側(UE5使ってゲーム開発する人)の経験が増えないと一般的にならないと思う。
Re: (スコア:0)
UE5のNaniteは動的に生成するオブジェクトとか、動くオブジェクト一般に適用するのが結構難しい。
その辺はVR方面のFoveated renderingのほうがいいのかな
アイトラッキングを中心点にしている動的な方である必要は低いから
fixed foveated renderingのほうで
動的でもスマホレベルの描画性能できるならiGPUのみで十分行けるんじゃないかな
Re: (スコア:0)
それは基本的にはVR向けなどの超高解像度のレンダリングを低負荷で行うための技術です。
主にGPUのラスタライズ性能の補完になる。
UE5のNaniteは頂点処理や、もっと言えばゲーム制作側のLODの設計負荷を減らすための物。
ラスタライズ性能が十分に足りてるGPUでこそ効果がある。
Re: (スコア:0)
数億ポリゴンとか突っ込んでも動くぞってのがウリになってる(※実際には色々調整必要)
の後半省いてたけど、まー実際にはそうだよね
Matrixデモも性能出すためにこう工夫してたよって講演 [unrealengine.com]有ったし、XBOX Series SでUE5動かす上でやっぱり負荷が高すぎる [4gamer.net]ってのも講演があったし
Naniteもあくまでインポート時に必要な解析 [unrealengine.com]をしてるから、動的オブジェクトとは相性悪いだろうね
インポート時 —
Re: (スコア:0)
3Dゲームの黎明期からあるんだよなあ…。
例えばマリオ64でもやってる。
当時既にLoDという名前だった。
(雑誌で宮本氏が話してた記憶)