※この記事ではgitのタグ「v2.74」からブランチを生成してコードリーディングしています。

CPUなのか？GPUなのか？

前々から疑問に思っていた事がありました。Blenderの画面に表示されている3Dモデル、GPUでレンダリングされているのでしょうか？それともCPUでソフトウェアレンダリングされているのでしょうか？

DCCツールはゲームと違い、モデルの頂点が頻繁に編集されるのでメインメモリからGPUメモリへのデータ転送コストが毎回発生するはずなのでこのような疑問を持ちました。当然マシン環境やDCCツールの機能によってもどちらが適切なのかは変わってるくるはずですが、Blenderはどのような実装になっているのでしょう？

レンダリング部分のコードを突き止める

この疑問の答えを出すためにレンダリング部分のコードを探し出してみましょう。

OpenGLのドローコールが呼ばれていればGPUでレンダリングされていると見ていいでしょうし、CPUでピクセルの配列の色を決定しているようなコードが見つかればソフトウェアレンダリングが使われているということになります。

最終的に該当部分をコメントアウトしてみて、３Dモデルが消えればそこが答えだと証明できるはずです。

part1ではBlenderを立ち上げて何も触らない状態、要するにObjectモードでViewport ShadingはSolidの状態でのレンダリングについて調べてみます。

試しにそれっぽいキーワードでプロジェクト全体を検索してみる

レンダリング部分のコードを見つけ出したいので、手始めに「render」や「draw」でソースコード全体を検索してみます。
　　draw -> 21478 results in 773 files
　　render -> 15695 results in 802 files
・・・。まあ、わかってはいましたけど大量に引っかかりますよね・・・。これを１つ１つ見ていくのは人間には無理でしょう。

Viewport ShadingがSolidの状態なので「solid」ではどうか？
　　solid -> 1484 results in 206 files
これもやっぱり数が多い。

Objectモードなので、「objectmode」ならどうか？
　　objectmode -> 42 results in 12 files
おお！これくらいなら１つ１つ見ていく事も可能ですね！

手がかりになりそうなenum値が見つかる

するとこんなenum値が見つかります。

typedef enum ObjectMode {
    OB_MODE_OBJECT        = 0,
    OB_MODE_EDIT          = 1 << 0,
    OB_MODE_SCULPT        = 1 << 1,
    OB_MODE_VERTEX_PAINT  = 1 << 2,
    OB_MODE_WEIGHT_PAINT  = 1 << 3,
    OB_MODE_TEXTURE_PAINT = 1 << 4,
    OB_MODE_PARTICLE_EDIT = 1 << 5,
    OB_MODE_POSE          = 1 << 6,
} ObjectMode;  

Blenderを使っている方ならお気付きかと思いますが、

モード選択といかにも関係ありそうなenum値ですね。

このenum値の中でObjectモードを指し示しているであろう「OB_MODE_OBJECT」で検索してみましょう。
　OB_MODE_OBJECT -> 32 results in 14 files

いかにも怪しいファイルが

この14個のファイルの中にdrawobject.cといういかにも怪しいファイルがあるのでこれを見てみる事にします。

drawobject.cの中にはdraw_〜〜〜と名前のついた関数がたくさん存在します。この関数の中に該当するものがありそうです。

レンダリング命令の周りのコードにOB_MODE_OBJECTの記述があるかは不明ですが、draw_object()とdraw_mesh_fancy()内にのみOB_MODE_OBJECTが書かれているのでとりあえず追ってみます。

この２つの関数の先頭にブレイクポイントを張って実行してみると、２つとも引っかかるようです。

ここでわかるのは、 　draw_object() -> draw_mesh_object() -> draw_mesh_fancy() という構造で各関数が呼ばれている事です。

draw_object()でdraw_mesh_object()を呼んでいる場所のswitch文は

        switch (ob->type) {
            case OB_MESH:
                empty_object = draw_mesh_object(scene, ar, v3d, rv3d, base, dt, ob_wire_col, dflag);

となっており、OB_MESHの定義に飛んでみるとオブジェクトのタイプ（？？）がいくつか定義されているのでこれは狙っているオブジェクトのレンダリング部分につながっているかもしれません。

試しにこのempty_object = draw_mesh_object(...の行をコメントアウトして実行してみましょう。するとデフォルトで表示されているはずのキューブが丸ごと消えます！

↓↓↓

このコメントアウトを取り消して行を復活させ、今度はdraw_mesh_object()でdraw_mesh_fancy()を呼んでいる場所をコメントアウトしましょう。すると同じくキューブが丸ごと消えます。

オブジェクト選択時のオレンジ色のアウトラインも一緒に消えてしまうので、アウトラインのレンダリングもdraw_mesh_fancy()に含まれていると言えます。

ゴールは近い！！

確認の意味も含めて、アウトラインを残してオブジェクトの面のみを消してみたいですね。

面の色の塗り方はViewport Shadingの設定によって変わります。ですので全体検索では大量に引っかかってしまった「solid」で今度はdraw_mesh_fancy()の中を検索してみます。するとヒットするのは９カ所。これくらいであれば１つ１つ追っていくのは簡単ですね。

9カ所全て見ていくと、drawFacesSolid()といういかにもそれっぽい関数が４カ所で呼ばれているのがわかります。drawFacesSolid()の呼ばれている箇所を上から順に見ていくと、
　１番目：enum値OB_MODE_TEXTURE_PAINTを使ってオブジェクトのモードを判断しているif文内にあるので該当しなさそう
　　（２番目〜４番目はOB_SOLIDが条件に使われているif文内にあるので怪しい）
　２番目：if (draw_flags & DRAW_MODIFIERS_PREVIEW)という条件なので違いそう
　３番目：if文の条件を見るとスカルプトに関連していそうなので除外
　４番目：if文的に２番目ではないかつ３番目ではないのでこれが正解のはず。
よって４番目をコメントアウト。

オレンジのアウトラインを残し、面のみが消えました！！
さて、コメントアウトをもとにもどします。

drawFacesSolidは関数ポインタになっているので、実際に呼ばれる関数を追ってみます。

４番目のところにブレイクポイントを張り、Step into。

するとcdderivedmesh.cの中の

static void cdDM_drawFacesSolid(DerivedMesh *dm,
                                float (*partial_redraw_planes)[4],
                                bool UNUSED(fast), DMSetMaterial setMaterial)

にたどり着きます。

この中でOpenGLの命令であるglDrawArrays()が呼ばれているので、Objectモードに関してはソフトウェアレンダリングではなく、GPUを使ってレンダリングを行っている事がわかって当初の疑問が解消され・・・

いや、待てよ

ObjectモードについてはGPUレンダリングが行われているのがわかりました。

でも最初に書いた「モデルの頂点が頻繁に編集されるのでメインメモリからGPUメモリへのデータ転送コストが毎回発生する」のは主にEditモードでした。

というわけで、part2につづきます。

@fmystB