Rustでの簡易OpenGLの作成-パート2（ワイヤーレンダリング）

そのため、前の記事の続きで、ワイヤーレンダーの作成に取り掛かる第2部を作成します。 この一連の記事の目的は、Rustで非常に単純化されたOpenGLの類似物を書くことであることを思い出してください。 haqreuの 「コンピューターグラフィックスのショートコース」が基礎として使用されます。私の記事では、 グラフィックス 自体に焦点を当てるのではなく、Rustの実装機能に注目します。 結果として得られるプログラム自体にはあまり価値がありません。このケースの利点は、新しい有望なPLと3次元グラフィックスの基礎を研究することです。 最後に、このレッスンは非常にエキサイティングです。



また、私はRustや3Dグラフィックスの専門家ではありませんが、この記事を書く過程でこれらのことを正しく研究しているので、重大なエラーや脱落があるかもしれませんが、私はそれらを持っているなら修正できてうれしいですコメントで示してください。





記事の最後にあるマシン

行を整理する

さて、悪夢のような手作りの関数行をhaqreuの Bresenhamアルゴリズムの通常の実装に書き換えることから始めましょう。 第一に、高速で、第二に標準的 、第三に、Rust コードとC ++コードを比較できます 。

pub fn line(&mut self, mut x0: i32, mut y0: i32, mut x1: i32, mut y1: i32, color: u32) { let mut steep = false; if (x0-x1).abs() < (y0-y1).abs() { mem::swap(&mut x0, &mut y0); mem::swap(&mut x1, &mut y1); steep = true; } if x0>x1 { mem::swap(&mut x0, &mut x1); mem::swap(&mut y0, &mut y1); } let dx = x1-x0; let dy = y1-y0; let derror2 = dy.abs()*2; let mut error2 = 0; let mut y = y0; for x in x0..x1+1 { if steep { self.set(y, x, color); } else { self.set(x, y, color); } error2 += derror2; if error2 > dx { y += if y1>y0 { 1 } else { -1 }; error2 -= dx*2; } } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ご覧のとおり、違いは最小限であり、元の行に対する行数は変更されていません。 この段階では特に困難はありませんでした。

テストをする

ラインの実装が終わった後、テストで非常に役立ったコードを削除しないことにしました。これにより、テストラインが3つ描画されました。

  let mut canvas = canvas::Canvas::new(100, 100); canvas.line(13, 20, 80, 40, WHITE); canvas.line(20, 13, 40, 80, RED); canvas.line(80, 40, 13, 20, BLUE);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

元の記事の著者がどのような経験を持っているかはわかりませんが、これらの3つの呼び出しは、ラインの実装時に発生する可能性のあるほぼすべてのエラーをカバーしていることがわかりました。 そして、もちろん、私は許可しました。



未使用の関数にコードを削除すると、Rustがコンパイルするたびに警告が表示されます（コンパイラーはすべての未使用の関数または変数を誓います）。 もちろん、下のダッシュ_test_line()



で始まる名前を関数に与えることで警告を抑制することもできますが、どういうわけか臭いです。 そして、潜在的に有用であるが現在は不必要なコードを一般的なコメントに保存するために、私の意見では、プログラミングの悪い調子です。 よりスマートなソリューションは、テストを作成することです！ したがって、情報については、この言語で最初のテストを行うために、Rustのテスト機能に関する対応する記事を参照してください。



これは基本的な方法で行われます。 関数の署名の上に#[test]



行を書くだけで十分です。 これは彼女をテストに変えます。 Rustは未使用の関数などの警告関数を表示しません。 cargo test



を実行すると、プロジェクト内のすべての関数の実行に関する統計がCargoに表示されます。

  Running target/debug/rust_project-2d87cd565073580b running 1 test test test_line ... ok test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

興味深いことに、プロジェクトの入力ポイントがテストとしてマークされた関数であるという事実に基づいて、未使用のすべての関数と変数に対してwarning'iも表示されます。 将来的には、これはプロジェクト機能のテスト範囲の決定に役立ちます。 テストでは実際には何もテストされませんが、描画結果のウィンドウが表示されてすぐに消えるのは明らかです。 良い方法では、Canvasを置​​き換えるモックオブジェクトが必要です。これにより、 set(x, y, color);



関数の呼び出しシーケンスを確認できますset(x, y, color);



セットへのコンプライアンス。 その後、自動単体テストになります。 それまでの間、対応するコンパイラー機能をいじりました。 これらの変更後のリポジトリのスナップショットを次に示します 。

ベクターと読み取りファイル

それでは、ワイヤーレンダリングの実装を開始します。 このパスに沿った最初の障害は、モデルファイル（ Wavefront .objファイル形式で保存されている）を読み取る必要があることです。 haqreuは彼の記事で、 haqreuによって提示される2次元および3次元のベクトルのクラスを使用する学生向けの既製のパーサーを提供します 。 その実装はC ++であるため、これをすべてRustで書き直す必要があります。 ベクトルから自然に始めましょう。 元のベクトル（2次元バージョン）のコードスニペットを次に示します。

 template <class t> struct Vec2 { union { struct {tu, v;}; struct {tx, y;}; t raw[2]; }; Vec2() : u(0), v(0) {} Vec2(t _u, t _v) : u(_u),v(_v) {} inline Vec2<t> operator +(const Vec2<t> &V) const { return Vec2<t>(u+Vu, v+Vv); } inline Vec2<t> operator -(const Vec2<t> &V) const { return Vec2<t>(uV.u, vV.v); } inline Vec2<t> operator *(float f) const { return Vec2<t>(u*f, v*f); } template <class > friend std::ostream& operator<<(std::ostream& s, Vec2<t>& v); };
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

C ++でのベクターの実装では、テンプレートが使用されます。 Rustでは、それらの類似物はGenericsであり、これについては、対応する記事を読むことができ、 rustbyexample.comでの 使用例を参照できます。 一般に、このサイトはRustを学ぶときに非常に役立つリソースです。 言語のあらゆる可能性について、詳細なコメントの使用例と、ブラウザーウィンドウで直接サンプルを編集および実行する機能があります（コードはリモートサーバーで実行されます）。



引数を取らず、ゼロベクトル（0、0）を作成するコンストラクターを作成しようとすると、別の問題が発生しました。 私が理解しているように、暗黙的な型キャストがないため、デフォルト値で構造を初期化することができないため、ラスタ型システムを作成できません。 同様の機能はtraitsを介して実装できますが、このためには多くのコードを記述するか、標準的な特性std::num::Zero



使用する必要があります。これは不安定です。 私は両方のオプションが気に入らなかったので、コードにnew(0, 0)



を書く方が簡単だと判断しました。



一般化されたタイプ、タイプ、および演算子のオーバーロードによるショーダウンには数時間かかりました。 ベクトルの元のクラスの類似物を実装するために、一般化された型の演算子オーバーロード（それ自体は特性を使用して配置されている）を行う方法をさらに掘り下げる必要があることに気づいたとき、私は別の側から行くことにしました。 C ++では数行のコードで行われ、Rustでは時々より複雑で長いコードで実装されるようです。 おそらくこれは、アルゴリズムを理解し、その類似物を大幅に異なるイデオロギーを持つ言語で書くのではなく、文字通りC ++コードをRustに翻訳しようとしているという事実によるものです。 一般に、私が知る限りでは、このことについての私自身の判断に従って、モデルファイルからの情報を保存する必要がある機能のみで、独自のベクターを作成することに決めました。 結果は非常に単純なクラスであり、タスクの現在の段階ではこれで十分です。

 pub struct Vector3D { pub x: f32, pub y: f32, pub z: f32, } impl Vector3D { pub fn new(x: f32, y: f32, z: f32) -> Vector3D { Vector3D { x: x, y: y, z: z, } } } impl fmt::Display for Vector3D { fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result { write!(f, "({},{},{})", self.x, self.y, self.z) } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これでパーサーを使用できますが、Rustでのファイルの操作についてはまだ検討していません。 その後、StackOverflowが助けになり、わかりやすいコード例で答えがありました。 それに基づいて、次のコードが取得されました。

 pub struct Model { pub vertices: Vec<Vector3D>, pub faces : Vec<[i32; 3]>, } impl Model { pub fn new(file_path: &str) -> Model { let path = Path::new(file_path); let file = BufReader::new(File::open(&path).unwrap()); let mut vertices = Vec::new(); let mut faces = Vec::new(); for line in file.lines() { let line = line.unwrap(); if line.starts_with("v ") { let words: Vec<&str> = line.split_whitespace().collect(); vertices.push(Vector3D::new(words[1].parse().unwrap(), words[2].parse().unwrap(), words[3].parse().unwrap())); debug!("readed vertex: {}", vertices.last().unwrap()); } else if line.starts_with("f ") { let mut face: [i32; 3] = [-1, -1, -1]; let words: Vec<&str> = line.split_whitespace().collect(); for i in 0..3 { face[i] = words[i+1].split("/").next().unwrap().parse().unwrap(); face[i] -= 1; debug!("face[{}] = {}", i, face[i]); } faces.push(face); } } Model { vertices: vertices, faces: faces, } } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

彼には特に困難はありませんでした。 ファイルを読み取り、行を処理するだけです。 Rastでこれを作成する方法に関する情報の検索のみが、インターネット上の言語が急速に変化するという事実によって複雑にならない限り、Rust <1.0の古いバージョンでは多くの情報があります。 （ 建設的に修正してくれたstepik777に感謝します ）時々、いくつかの答えを見つけて試してみてください。しかし、このメソッドは名前の変更や削除などが行われたため、うまくいきませんfrom_str()



メソッドの例からこれにfrom_str()



ました



最初、このコードを間違えて、 faces.push(face);



行を書くのを忘れましたfaces.push(face);



長い間、レンダーがすべての顔を通るサイクルに入らなかった理由を理解できませんでした。 入力することで問題が何であるかを見つけた後、コンパイラ出力warning: variable does not need to be mutable, #[warn(unused_mut)] on by default



興味深い行が見つかりましたwarning: variable does not need to be mutable, #[warn(unused_mut)] on by default



変数faceを宣言する行に対して相対的warning: variable does not need to be mutable, #[warn(unused_mut)] on by default



。 未使用の変数に関する警告がまだたくさんあるので、この警告に気付きませんでした。 その後、未使用の変数をすべてコメントアウトしたので、警告が目立ちます。 Rustでは、コンパイラの警告はバグを見つけるのに非常に役立ち、無視するべきではありません。



また、C ++のオリジナルとは異なり、コードが非常にシンプルで理解しやすいように見えることにも注意してください。 同様に、PythonまたはJavaで作成することもできます。 また、元の製品と比較して生産性が高いことも興味深いです。 レンダリング全体の開始から終了までの準備ができたら、パフォーマンスを測定する予定です。

ワイヤーレンダー

最後に、これはワイヤーレンダーです。 ほとんどの作業は前の手順で行われたため、コードは簡単です。

 fn main() { env_logger::init().unwrap(); info!("starting up"); let model = Model::new("african_head.obj"); let mut canvas = canvas::Canvas::new(WIDTH, HEIGHT); debug!("drawing wireframe"); for face in model.faces { debug!("processing face:"); debug!("({}, {}, {})", face[0], face[1], face[2]); for j in 0..3 { let v0 = &model.vertices[face[j] as usize]; let v1 = &model.vertices[face[(j+1)%3] as usize]; let x0 = ((v0.x+1.)*WIDTH as f32/2.) as i32; let y0 = ((v0.y+1.)*HEIGHT as f32/2.) as i32; let x1 = ((v1.x+1.)*WIDTH as f32/2.) as i32; let y1 = ((v1.y+1.)*HEIGHT as f32/2.) as i32; debug!("drawing line ({}, {}) - ({}, {})", x0, y0, x1, y1); canvas.line(x0, y0, x1, y1, WHITE); } } info!("waiting for ESC"); canvas.wait_for_esc(); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

構文のわずかな違いは別として、C ++とは主に多数の型変換が異なります。 まあ、エラーを探していたときにどこでも突っ込んだログ。 これが最終的に得られる画像です（ リポジトリ内のコードのスナップショット ）：







これはすでにかなり良いですが、最初に、現在の形式でプログラムをフィードしようとしているマシンのモデルにフィードすると、単に表示されません。 第二に、これらすべての美しさはひどく長く描かれています（私はプログラムを立ち上げ、コーヒーを飲みに行くことができます）。 最初の問題は、タイプライターのモデルでは、頂点がまったく異なるスケールで記録されることです。 上記のコードは、頭部モデルのスケールに合わせて調整されています。 それを普遍的にするためには、あなたはまだそれを使わなければなりません。 2番目の問題は何のためかわかりませんが、考えてみると、2つのオプションしかありません。非効率的なアルゴリズムを使用するか、このアルゴリズムの非効率的な実装をこの特定の技術スタックに記述します。 いずれにせよ、別の疑問が生じます。アルゴリズムの特定の部分（実装）は非効率的です。



一般に、すでに理解しているように、速度の問題から始めることにしました。

パフォーマンスを測定する

元のプロジェクトのパフォーマンスとRustでの実装を比較する計画がまだあったため、早めに実行することにしました。 ただし、オリジナルの動作原理と私の実装は大きく異なります。 オリジナルは一時バッファに描画し、最後にのみTGAファイルを書き込みますが、私のアプリケーションは三角形を処理するプロセスでSDLレンダリングコマンドを実行します。



解決策は簡単です-Canvasを再作成して、ポイントset(x, y, color)



を描画する方法が内部配列にデータを保存するだけで、SDLを使用した直接描画は、すべての計算が完了した後、プログラムの最後にすでに行われているようにします。 これにより、1石で3羽の鳥を殺します。

1. ファイルにレンダリング/保存する前、つまり本質的に同じことを行う実装の速度を比較する機会を得ます。
2. ダブルバッファリングの準備をしています。
3. 計算を描画から分離します。これにより、SDL呼び出しによって課されるオーバーヘッドを評価できます。

Canvasをすばやく書き換えた後、線の計算自体が非常に高速であることがわかりました。 ただし、SDLを使用したレンダリングは非常に高速で行われました。 最適化の範囲があります。 Rust-SDL2の点描画機能は、予想したほど高速ではないことが判明しました。 画像全体をテクスチャに保存し、このコードでこのテクスチャを出力することで、問題を解決することができました。

  pub fn show(&mut self) { let mut texture = self.renderer.create_texture_streaming(PixelFormatEnum::RGB24, (self.xsize as u32, self.ysize as u32)).unwrap(); texture.with_lock(None, |buffer: &mut [u8], pitch: usize| { for y in (0..self.ysize) { for x in (0..self.xsize) { let offset = y*pitch + x*3; let color = self.canvas[x][self.ysize - y - 1]; buffer[offset + 0] = (color >> (8*2)) as u8; buffer[offset + 1] = (color >> (8*1)) as u8; buffer[offset + 2] = color as u8; } } }).unwrap(); self.renderer.clear(); self.renderer.copy(&texture, None, Some(Rect::new_unwrap(0, 0, self.xsize as u32, self.ysize as u32))); self.renderer.present(); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

一般に、Rustのプログラミングの観点からCanvasを書き換えることに新しいものはなかったので、話すことはあまりありません。 リポジトリの対応するスナップショットのこの時点のコード。 これらの変更の後、プログラムは飛び始めました。 描画には一瞬かかりました。 すでにパフォーマンスの測定に興味がなくなっています。 プログラムの実行にかかる時間は非常に短いため、OSのランダムなプロセスに起因する単純な測定エラーは、この時間を2倍に増やすか、逆に減らすことができます。 どうにかしてこれと戦うために、プログラムの本体（.objファイルの読み取りと2次元投影の計算）を100回実行したサイクルで囲みました。 これで、何かを測定することができました。 haqreuの C ++実装でも同じことを行いました 。



実際、Rust実装の番号は次のとおりです。

 cepreu@cepreu-P5K:~//rust-3d-renderer-70de52d8e8c82854c460a41d1b8d8decb0c2e5c1$ time ./rust_project real 0m0.769s user 0m0.630s sys 0m0.137s
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

C ++での実装番号は次のとおりです。

 cepreu@cepreu-P5K:~//tinyrenderer-f6fecb7ad493264ecd15e230411bfb1cca539a12$ time ./a.out real 0m1.492s user 0m1.483s sys 0m0.008s
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

各プログラムを10回実行した後、最適な時間（実際）を選択しました。 持ってきました。 私の実装では、外部呼び出しが結果の時間に影響を与えないように、SDLへのすべての参照を削除するように修正を加えました。 実際には、リポジトリのスナップショットで見ることができます 。



C ++実装に対して行った変更は次のとおりです。

 int main(int argc, char** argv) { for (int cycle=0; cycle<100; cycle++){ if (2==argc) { model = new Model(argv[1]); } else { model = new Model("obj/african_head.obj"); } TGAImage image(width, height, TGAImage::RGB); for (int i=0; i<model->nfaces(); i++) { std::vector<int> face = model->face(i); for (int j=0; j<3; j++) { Vec3f v0 = model->vert(face[j]); Vec3f v1 = model->vert(face[(j+1)%3]); int x0 = (v0.x+1.)*width/2.; int y0 = (v0.y+1.)*height/2.; int x1 = (v1.x+1.)*width/2.; int y1 = (v1.y+1.)*height/2.; line(x0, y0, x1, y1, image, white); } } delete model; } //image.flip_vertically(); // i want to have the origin at the left bottom corner of the image //image.write_tga_file("output.tga"); return 0; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

まあ、model.cppのデバッグ出力も削除しました。 一般に、もちろん、結果は私を驚かせました。 Rustコンパイラはまだgccほど最適化する必要はないように思われましたが、私は無知で、おそらく最適でないコードを積み上げていました...このコードがなぜ高速になったのか理解できません。 または、Rustは非常に高速です。 または、C ++では、実装に最適なものがありません。 一般的に、これについて議論したい人はコメントを歓迎します。

まとめ

最後に、係数を簡単に調整することで（ リポジトリの画像を参照）、ウィンドウスペースを最適に占有するマシンの画像を取得しました。 記事の冒頭でそれを観察しました。



いくつかの印象：

• Rustでの書き込みが簡単になりました。 初期はコンパイラとの継続的な闘争でした。 今、私はただ座ってコードを書いています。時々、これをどうやって作るかをインターネットで覗きます。 一般に、ほとんどの場合、この言語はすでに馴染みのあるものとして認識されています。 ご覧のとおり、これにはそれほど時間はかかりませんでした。
• ラスタを警告してまだ満足しています。 他の言語では、非常に高度なIDE（JavaのIntelliJ IDEAなど）のみがあなたに伝えていると、コンパイラーはRustで述べています。 良いスタイルを維持し、エラーから保護します。
• Rustの方が速かったという事実は衝撃です。 どうやら、コンパイラは思ったほど生っぽくありません。

最終-サイクルの3番目の部分： 簡略化されたOpenGLをRustで書く-パート3（ラスタライザー）