簡略化されたOpenGLをRust-パート3（ラスタライザー）で記述します

RustのOpenGLの簡略化された類似物に関する一連の記事を続けます。2つの記事が既に公開されています。

1. 簡略化されたOpenGLをRustで作成する-パート1（線を引く）
2. Rustでの簡易OpenGLの作成-パート2（ワイヤーレンダリング）

連載記事の基礎は、 haqreuの 「コンピュータグラフィックスの短期コース」であることを思い出してください 。 前の記事では、私はあまり速く行きませんでした。 実際、コースの1つの記事に対して2つの記事がありました。 これは、私の記事で主にRustで作業する微妙なニュアンスに焦点を当てているという事実によるものであり、新しい言語を学習するだけで、しばらくの間プログラミングを行っているときよりも多くの新しい微妙なニュアンスに出会うことになります。 さらにRustを使用するとレーキが少なくなり、元のコースの記事に対する記事の比率を調整します。



その間、私は伝統的にRustや3Dグラフィックスの専門家ではないので、記事を書く過程でこれらのことを正しく研究しているので、それは多くのナンセンスになる可能性があると警告してきました。 これに気付いたら、コメントを書いてください-エラーを修正します。 そしてもちろん、この記事にはあなたが同意しないかもしれない多くの個人的な印象があります。 建設的な批判は大歓迎です。





この記事の結果として得られるもの

三角形のあるモデルを描く

すべてがそのようなものであり、説明するものは何もありません。 コードは、リポジトリの対応するスナップショットにあります 。

平らな色合い

ベクトルとスカラーの積演算が照明の計算に使用されるため、新しい演算子で古き良きVector3Dクラスを拡張する必要があります。 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, } } pub fn norm(self) -> f32 { return (self.x*self.x+self.y*self.y+self.z*self.z).sqrt(); } pub fn normalized(self, l: f32) -> Vector3D { return self*(l/self.norm()); } } impl fmt::Display for Vector3D { fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result { write!(f, "({},{},{})", self.x, self.y, self.z) } } impl Add for Vector3D { type Output = Vector3D; fn add(self, other: Vector3D) -> Vector3D { Vector3D { x: self.x + other.x, y: self.y + other.y, z: self.z + other.z} } } impl Sub for Vector3D { type Output = Vector3D; fn sub(self, other: Vector3D) -> Vector3D { Vector3D { x: self.x - other.x, y: self.y - other.y, z: self.z - other.z} } } impl Mul for Vector3D { type Output = f32; fn mul(self, other: Vector3D) -> f32 { return self.x*other.x + self.y*other.y + self.z*other.z; } } impl Mul<f32> for Vector3D { type Output = Vector3D; fn mul(self, other: f32) -> Vector3D { Vector3D { x: self.x * other, y: self.y * other, z: self.z * other} } } impl BitXor for Vector3D { type Output = Vector3D; fn bitxor(self, v: Vector3D) -> Vector3D { Vector3D { x: self.y*vz-self.z*vy, y: self.z*vx-self.x*vz, z: self.x*vy-self.y*vx} } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

判定：Rustの演算子のオーバーロードは基本的に行われます。

ただし、コピーや移動には困難がありました。 Rustでは、すべてのタイプが移動可​​能またはコピー可能になっています。 型が移動可能な場合、変数の所有権は呼び出された関数に入るため、この型の変数を取るメソッドの呼び出しは、コード内の後続のすべての呼び出しからアクセスできなくなります。 つまり、そのようなコードはエラーの原因になります。

 let x = Vector3D::new(1.0, 1.0, 1.0); let y = x*2.0; do_something_else(x); // error!
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

乗算関数に渡された変数xの所有権。変数は関数のローカル変数に移動され、関数を終了した後に削除されました。返されなかったためです。 実際、 normalized()





関数でこのタイプのエラーが発生しました normalized()





ご覧のとおり、 self



は乗算演算子の右側と左側の両方に立っているためです。 つまり、連続して2回移動しようとしています。 デフォルトでは、Rustのすべてのユーザー構造は移動可能です。

2つの解決策があります。デフォルトで変数をコピーするか、演算子の実装が値ではなくリンクを受け入れるようにするかです。 2番目のオプションを選択しました。 これを実装するには、構造体の宣言の前に#[derive(Copy, Clone)]



と書くだけで十分です。 これは、構造がコピー可能であり、単純なバイト複製によってコピーできることをコンパイラに伝えます。 これで、上記のような呼び出しでは、データのコピーがオペレーターに転送され、呼び出し後も元のデータが利用可能になります。 複雑に見えますが、この追加の複雑さのために、コンパイラーはメモリー・エラーのあるコード（例えば、 Use After Free ）を書くことを許可しません。



ちなみに、Rustにはオプションのパラメーターはなく、通常の方法でエミュレートすることもできません。同じ名前で異なる引数のセットを使用して関数を作成することもできます。 これは、 トレイトを使用することで部分的に回避できます。 しかし、この方法はすべての場合に適しているわけではなく、私の意見では、やや不必要に冗長です。 一般に、ラストのタイプは、不必要な冗長性の印象を残します。 ランタイムにオーバーヘッドを追加することなく、メモリを操作する際のエラーに対する保護に違反することなく、異なる方法で実行できたかどうかはわかりませんが、現在の実装では、特性を可能な限り使用しないという切望されています。



さらに、ライティングを使用してモデルを描画するためのコードは、あまり冒険なしで作成されました。





そして、これがリポジトリの対応するスナップショットです 。

Z-バッファ

プログラミングを始めたとき、Z-bufferはVector3Dクラスが整数座標と実座標の両方である必要があることに気付きました。 袖をまくり、一般化されたタイプとタイプを使用して書き直し始めました。 これが熱の行き先です。 Rustの特徴は複雑な構文を持っていることを述べましたか？ 自分でコードを見てください：

 use std::fmt; use std::ops::Add; use std::ops::Sub; use std::ops::Mul; use std::ops::BitXor; use num::traits::NumCast; #[derive(Copy, Clone)] pub struct Vector3D<T> { pub x: T, pub y: T, pub z: T, } impl<T> Vector3D<T> { pub fn new(x: T, y: T, z: T) -> Vector3D<T> { Vector3D { x: x, y: y, z: z, } } } impl<T: NumCast> Vector3D<T> { pub fn to<V: NumCast>(self) -> Vector3D<V> { Vector3D { x: NumCast::from(self.x).unwrap(), y: NumCast::from(self.y).unwrap(), z: NumCast::from(self.z).unwrap(), } } } impl Vector3D<f32> { pub fn norm(self) -> f32 { return (self.x*self.x+self.y*self.y+self.z*self.z).sqrt(); } pub fn normalized(self, l: f32) -> Vector3D<f32> { return self*(l/self.norm()); } } impl<T: fmt::Display> fmt::Display for Vector3D<T> { fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result { write!(f, "({},{},{})", self.x, self.y, self.z) } } impl<T: Add<Output = T>> Add for Vector3D<T> { type Output = Vector3D<T>; fn add(self, other: Vector3D<T>) -> Vector3D<T> { Vector3D { x: self.x + other.x, y: self.y + other.y, z: self.z + other.z} } } impl<T: Sub<Output = T>> Sub for Vector3D<T> { type Output = Vector3D<T>; fn sub(self, other: Vector3D<T>) -> Vector3D<T> { Vector3D { x: self.x - other.x, y: self.y - other.y, z: self.z - other.z} } } impl<T: Mul<Output = T> + Add<Output = T>> Mul for Vector3D<T> { type Output = T; fn mul(self, other: Vector3D<T>) -> T { return self.x*other.x + self.y*other.y + self.z*other.z; } } impl<T: Mul<Output = T> + Copy> Mul<T> for Vector3D<T> { type Output = Vector3D<T>; fn mul(self, other: T) -> Vector3D<T> { Vector3D { x: self.x * other, y: self.y * other, z: self.z * other} } } impl<T: Mul<Output = T> + Sub<Output = T> + Copy> BitXor for Vector3D<T> { type Output = Vector3D<T>; fn bitxor(self, v: Vector3D<T>) -> Vector3D<T> { Vector3D { x: self.y*vz-self.z*vy, y: self.z*vx-self.x*vz, z: self.x*vy-self.y*vx} } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ここにあるものとその理由を簡単に説明してください。 T上のコロンの後に、境界が書き込まれます：T.が実装すべき特性たとえば、BitXor操作の場合、Tは、ご覧のとおり、乗算、減算、およびコピーを実装する必要があります。 最初の2つで、乗算と減算を行う関数コードでは、これがTで有効であることは論理的です。コピーするのはなぜですか？ ポイントは、すでに上記で説明した状況です。別の関数に移動された変数を再利用することはできません。 したがって、算術x: self.y*vz-self.z*vy, y: self.z*vx-self.x*vz, z: self.x*vy-self.y*vx



をリンクを使用してx: self.y*vz-self.z*vy, y: self.z*vx-self.x*vz, z: self.x*vy-self.y*vx



ますまたは、Tがコピー可能であることを確認してください。 Rustのすべての基本型はコピー可能です。 一般に、リストやファイルをx、y、z、または他の複雑なものに詰め込むことを誰も期待しないため、コピーオプションが適しています。 「やめて、この<Output = T>



何ですか？」-気配りのある読者が尋ねます。 このエントリがなければ、コードは機能しません。 実際のところ、Rustは加算または乗算の結果がオペランドと同じ型になることを保証しません。 したがって、ここでは、乗算の結果もT型になるように乗算を実装するTが必要であることをさらに明確にします。それは難しいですか？ 私はあなたに警告しました。



to（）メソッドは、あるタイプのベクトルを別のタイプに変換することを可能にしますが、特筆に値します。 たとえば、実数から整数へ。 ここでわかるように、NumCastを実装する任意の型は、NumCastを実装する任意の型に変換できます。 Rustのすべてのプリミティブ型はそれを実装しているため、（この型について学習するのにかかる時間を数えることなく）完全に無痛でベクターの型変換を受け取りました。

残りの変更はそれほど複雑ではありませんでした。 その結果、 リポジトリの対応するスナップショットで見ることができるコードを得ました。

TGAキャンバス

テクスチャリングのために、TGAファイルを読み取ることができる必要があるのは、テクスチャが関心のあるモデルに保存されているためです。それでは、サイクルの最初にスキップしたTGAファイルの読み取りに戻りましょう。 そして、私たちはまだそれらを読むことを学んでいるので、結果をTGAに書き込むCanvasの代替実装を同時に作成しないのはなぜですか。 当然、Canvasを抽象化してから、SdlCanvasとTgaCanvasの2つの実装を準備する必要があります。 Javaでは、他の2つのクラスを継承する基本クラスを作成します。 Rustでは、この機能は不純物を使用して実装されています。 自分でコードを見てください。 Canvasの混合物は次のとおりです。

 pub trait Canvas { fn canvas(&mut self) -> &mut Vec<Vec<u32>>; fn zbuffer(&mut self) -> &mut Vec<Vec<i32>>; fn xsize(&self) -> usize; fn ysize(&self) -> usize; fn new(x: usize, y: usize) -> Self; fn show(&mut self); fn wait_for_enter(&mut self); fn set(&mut self, x: i32, y: i32, color: u32) { if x < 0 || y < 0 { return; } if x >= self.xsize() as i32 || y >= self.ysize() as i32{ return; } self.canvas()[x as usize][y as usize] = color; } fn triangle(&mut self, mut p0: Vector3D<i32>, mut p1: Vector3D<i32>, mut p2: Vector3D<i32>, color: u32) { //... } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

SdlCanvasは次のとおりです。

 pub struct SdlCanvas { sdl_context: Sdl, renderer: Renderer, canvas: Vec<Vec<u32>>, zbuffer: Vec<Vec<i32>>, xsize: usize, ysize: usize, } impl Canvas for SdlCanvas { fn new(x: usize, y: usize) -> SdlCanvas { //... SdlCanvas { sdl_context: sdl_context, renderer: renderer, canvas: vec![vec![0;y];x], zbuffer: vec![vec![std::i32::MIN; y]; x], xsize: x, ysize: y, } } fn show(&mut self) { let mut texture = self.renderer.create_texture_streaming(PixelFormatEnum::RGB24, (self.xsize as u32, self.ysize as u32)).unwrap(); // ... self.renderer.present(); } fn wait_for_enter(&mut self) { //... } fn canvas(&mut self) -> &mut Vec<Vec<u32>>{ &mut self.canvas } fn zbuffer(&mut self) -> &mut Vec<Vec<i32>>{ &mut self.zbuffer } fn xsize(&self) -> usize{ self.xsize } fn ysize(&self) -> usize{ self.ysize } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

理解を複雑にしないために、不純物とその実装に直接関係しないコードの一部を削除し、 // ...



置き換えました。 興味のある人は、リポジトリの対応するスナップショットで完全なコードを見ることができます 。 ご覧のとおり、これは少し変わっているように見えますが、実際には通常の継承とインターフェースに非常に似ています。 コードのサイズはそれほど変わりません。 唯一の瞬間、不純物は、構造内の変数の存在を要求することを許可しません。 そのため、ユニバーサル実装とSdlCanvasで必要な変数のいくつかのゲッターを作成して、それらを実装する必要がありました。 上記の実装では、 対応する記事Rust by Exampleが本当に役立ちました。

写真を読むために実際に。 最初の問題は、TGAファイルのヘッダーを読み取ることでした。 元のhaqreuコードでは、これはかなり単純なエレガントなコードで行われます。

 #pragma pack(push,1) struct TGA_Header { char idlength; char colormaptype; // ... short width; short height; char bitsperpixel; char imagedescriptor; }; #pragma pack(pop) // ... TGA_Header header; in.read((char *)&header, sizeof(header));
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ただし、このコードがかなり低レベルであることも明らかです。 ファイルからバイト配列を読み取り、構造体のアドレスにそれを配置します。構造体は、このすべてのデータがファイルヘッダーに配置される方法に対応するように事前に宣言されています。 その前に、私たちは主にかなり高レベルのラストについて書きました。 それでは、低レベル言語として適用された場合の動作を確認します。 一般的に、すべての調査の後、次のコードがあります。

 const HEADERSIZE: usize = 18; // 18 = sizeof(TgaHeader) #[repr(C, packed)] struct TgaHeader { idlength: i8, colormaptype: i8, // ... width: i16, height: i16, bitsperpixel: i8, imagedescriptor: i8, } // ... let mut file = File::open(&path).unwrap(); let mut header_bytes: [u8; HEADERSIZE] = [0; HEADERSIZE]; file.read(&mut header_bytes); let header = unsafe { mem::transmute::<[u8; HEADERSIZE], TgaHeader>(header_bytes) };
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

構造の前にあるプリプロセッサディレクティブは、そのストレージメソッドを定義します。 通常、Rust（およびC ++では）の構造体フィールドは、アーキテクチャに従って配置されます。 たとえば、私のコンピューターでは、i8とi16を含む構造体は3バイトではなく4バイトを占有します。i8は1つのダブルバイトセルを占有するように整列されるためです。 C ++では、これは同じように機能します。 これは、このトピックに関する彼の記事で k06aによって詳細に説明されました。 構造内のデータがバイト#[repr(C, packed)]



隙間なく続くように、 #[repr(C, packed)]



ます。 したがって、私たちの構造は、TGAが発明されたときの厳しい古代にあったように、今では記憶の中にあります。 さらに、ここでは安全でないコードを使用します。 メモリ内のプロットを特定の構造としてチェックせずに解釈すると、静的型付けの考え方が完全に崩れます。 幸いなことに、ほとんどの場合、このコードは機能します。 （ただし、常にではありませんが、 バイト順のあらゆる種類のニュアンスがまだあります ）そして、もちろん、バッファサイズを定数として設定していることに気づきました。 しかし、sizeofについてはどうでしょうか。 さて、それはRustにありますが、定数式として計算されませんが、実行時に考慮されます。 配列のサイズは、コンパイル段階でわかっている必要があります。 これらはパイです。



その後、最も興味深い。 RLE圧縮なしでRGBA（ピクセルあたり4バイト）のような単純なTGAファイルを読む方法を学ぼうとしたとき、いくつかの謎がありました。 私のプログラムは一般的に単純な画像を処理し、そのような混乱を引き起こしました：







この段階でのコードのスナップショットは次のとおりです 。 興味がある場合は、記事を読み続ける前に自分でエラーを見つけてください。 ファイルを読み取る関数のどこかにあります。

  fn read(path: &str) -> TgaCanvas{ let path = Path::new(path); let mut file = BufReader::new(File::open(&path).unwrap()); let mut header_bytes: [u8; HEADERSIZE] = [0; HEADERSIZE]; file.read(&mut header_bytes); let header = unsafe { mem::transmute::<[u8; HEADERSIZE], TgaHeader>(header_bytes) }; let xsize = header.width as usize; let ysize = header.height as usize; debug!("read header: width = {}, height = {}", xsize, ysize); let bytespp = header.bitsperpixel>>3; debug!("bytes per pixel - {}", bytespp); let mut canvas = vec![vec![0;ysize];xsize]; for iy in 0..ysize{ for ix in 0..xsize{ if bytespp == 1 { let mut bytes: [u8; 1] = [0; 1]; file.read(&mut bytes); let intensity = bytes[0] as u32; canvas[ix][iy] = intensity + intensity*256 + intensity*256*256; } else if bytespp == 3 { let mut bytes: [u8; 3] = [0; 3]; file.read(&mut bytes); canvas[ix][iy] = bytes[2] as u32 + bytes[1] as u32*256 + bytes[0] as u32*256*256; } else if bytespp == 4 { let mut bytes: [u8; 4] = [0; 4]; file.read(&mut bytes); if ix == 0 { debug!("{} {} {} {}", bytes[0], bytes[1], bytes[2], bytes[3]); } canvas[ix][iy] = bytes[2] as u32 + ((bytes[1] as u32) << (8*1)) + ((bytes[0] as u32) << (8*2)); //debug!("{}", canvas[ix][iy]); } } debug!("{}", canvas[0][iy]); } TgaCanvas { canvas: canvas, zbuffer: vec![vec![std::i32::MIN; ysize]; xsize], xsize: xsize, ysize: ysize, } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

私を本当に困惑させたのは、 BufReader::new(File::open(&path).unwrap());



File::open(&path).unwrap();



、その後、バグは表示されませんでした。 理論的には、バイトストリームを妨げることなく、バッファリングのみを提供する必要があるため、BufReaderのバグだとさえ思いました。





次に、TGAファイルの問題はすぐに解決されました。 TgaCanvasの最終バージョンのコードは、いつものように、リポジトリのスナップショットで見ることができます 。

テクスチャー

問題は、彼らが待たなかったところから来ました。 Rustは単に文字列を連結し、結果をstrとして返すことができないことがわかります（これはプリミティブ型-文字列です）。 Strには連結メソッドがありません。 文字列にはそれがありますが 、 後で文字列をstrに変換することはできません。 更新：ネタバレのすべてが真実ではありません。 ストーリーのためだけにここに保存しました。 Googolplexの コメントで私の間違いを説明してくれてありがとう。 その後、すべてが非常に簡単です。 結果は、リポジトリのスライスで確認できるコードです 。 記事の紹介で確認できるまさにその写真を表示します。

あとがき

これがサイクルの最後の記事だと思います。 最初は、Rustを研究し、最新の3Dグラフィックスがどのように機能するかを理解するという2つの目標を設定しました。 私はまだC-3Dグラフィックスを完成していませんが、Rustはもう1か月半ほど前に慣れていない言語ではありません。 言語に関する最近の「発見」のほとんどは、わずかなニュアンスです。 ここ数週間、根本的に新しいものを発見していません。 だから本質的に、私は記事で書くことは何もない。 また、レンダラー、カメラの動き、おそらくGuroの色合いに遠近法の歪みを追加し、そのタイプライターを記事1から描画して、関心のある人が引き続き対応するリポジトリで私の進捗を監視できるようにする予定です 。 読んでくれたすべての人に感謝します。 そして、有益なコメントを提供してくれた人たちに感謝します。