おそらく長い間考えていました。現在、「レンダラー」と呼ばれる抽象基本クラスがあり、オブジェクトをレンダリングおよび登録するための仮想メソッドがあります（VBOにメモリを割り当てるには、オブジェクトを登録する必要があります）。
しかし、そのように保つべきかどうかはわかりません。基本の抽象クラスを維持するべきだと考えています。OpenGL以外の別のAPIでオブジェクトをレンダリングする別の「レンダラー」を作成しません。つまり、OpenGL以外のDirect3Dやその他のグラフィックAPIは使用しません。
しかし、OpenGLレンダラーの複数の実装がある場合があります。たとえば、OpenGL ESと通常のOpenGL用の実装です（それらが大きく異なる場合はそうです）。
Direct3Dなどの別のAPIを使用する場合、コンテキストの作成がおそらく私にとっての主な関心事になるでしょう...私はそれをきちんと行う方法がわかりません。
これが意味をなさない場合は申し訳ありませんが、私はずっと長い間考えていたと思います。
3DAPIを活用するのは簡単な作業ではありません。私はまだその目的に向かって取り組んでいますが、OpenGLサポートはほとんど欠落しているため、APIは非常に理論的です。少なくとも、Direct3D実装でまともなマイルストーンに到達し、OpenGLでまともなドキュメントを見つけて、 OpenGLバリアントを構築して、私がどこまで到達できるか、そして私の仮定のどれだけが実際に現実に準拠しているかを確認します。
それはおそらく、OpenGLの実装が既存の設計で簡単であることがわかったとき、または（より可能性が高い）OpenGL（およびMacOS + Linux）を削除することを決定したときに、そのような天才であることに本当に驚かされるときです。それと一緒に）完全に:-)
とにかく終わらないプライベートペットプロジェクトなので、私はそれを行うことができます。やる可能性がほとんどないものや、やらなければならないことがあるものについては、やらないことをお勧めします。大変な作業です。
少なくとも、あなたがしなければならないことは次のとおりです。
もちろん、私にとっての大きな問題は、パフォーマンスを損なうことなくDirect3DとOpenGLを抽象化しようとしているだけでなく、その過程で3D-gfx-know-howを構築しようとしていることです。そのため、「最高の」デザインを思いつくのは難しく、多くのことをやり直す必要があります。
もちろん、私はすべて間違っている可能性があり、Direct3D / OpenGLは、マクロを使用した1：1マッピングを介して処理できるものと実際には同じですが、それほど単純ではないことは確かです。それは、固定された機能セットを備えた同じハードウェア上で引き続き機能し、HLSLとGLSLは、最終的に両方に対して単一の統一言語を作成するのに十分類似しているとさえ信じています。
それでも、私がここでとりとめのないことをすべて書いている理由は、あなたを落胆させるためです。私が知る限り（そして何を推測するか、おそらく私の名前を聞いたことがないでしょう-それが何を意味するかを自分で推測してください）、それはかなりの挑戦です。
何をしたいかによります。なぜ両方のAPIをサポートしたいのですか？非常に説得力のある理由がない場合は、Windows用のD3DとLinux用のOpenGLを使い続けます。
あなたがやろうとしていることは、レンダラーのインターフェースを定義する抽象基本クラスと、OpenGL用とDirect3D用の2つの異なる実装を使用して行うことができますが、これには、追加されるすべてのレンダリング呼び出しの仮想関数呼び出しが含まれますオーバーヘッド。
このトピックについて説明する2つのリンクを追加しました。複数のAPIをサポートする必要がない場合は、対象のプラットフォームに適したAPIを使用してください。
http://www.gamedev.net/topic/160063-support-for-both-opengl-and-directx/
私の質問は常に「今はやりたくないとしても、この実装を別の実装に置き換えるのは理にかなっているだろうか」です。
文字列、ベクトル、またはゲーム内のプレーヤーを表すクラスのようなものの場合、答えはおそらくノーです。実装を変更することもできますが、複数必要になることはありません。レンダリングシステムのようなものの場合、答えはイエスです。これを別の実装に置き換えることは理にかなっているため、抽象化にプログラミングすることは、決してそうしない場合でも良い考えです。
当然のことながら、ルールを盲目的に適用しないでください。ソースコードの効率と乱雑さの欠如も重要ですが、それは良いガイドラインだと思います。
そうは言っても、私は低レベルのレンダリングを抽象化しようとはしません。それは難しすぎます。単にその機能を持たないレンダリングシステムで、テッセレーションハードウェアの使用可能な抽象化をどのように提供しますか？代わりに、「風景を描く」、「3つのモデルを描く」、「アニメーションモデルを描く」などのレベルで抽象化を行います。
2番目のシステムを実装することは決してないかもしれませんが、そうすることは理にかなっているので、そうしない明確な理由がない限り、抽象化を提供してください。
これがどのように役立つのかわかりません。この部分を抽象化するため、基盤となるAPIがDirect3DであるかOpenGLであるかはライブラリユーザーに影響しません。それらは機能的に同一であり、どちらもまったく同じことをします。彼らは異なるプロラミングモデルを使用しており、異なるデザイン/マーケティング戦略に基づいていますが、いずれも根本的に他のものより優れているものはありません。
両方のAPIのファンの間で頻繁に戦いがありますが、単純な真実は、彼らが同じことをしているということです。
とはいえ、さまざまなバックエンドをサポートしたい理由の1つは、移植性です。OpenGLは、コンテキストの作成といくつかの小さな詳細（垂直同期のオンとオフの切り替えなど）を除いて、特別なことを何も必要とせずにすでに移植可能です。Direct3DはWindowsとXBoxで動作し、それだけです。
OpenGLに加えてOpenGLESバックエンドを作成することも考えていません。なぜなら、それはあなたの人生を不幸にするのに十分な別の獣である可能性が高いからです。しかしもちろん、それはあなたが何をしようとしているのかに大きく依存します。
「単純な」ことについては、OpenGLESはある意味で携帯電話でも実行される「単なるOpenGL」です。いいですね。良すぎて真実ではありません。
「それほど単純ではない」場合、OpenGL ESは、何らかの効果のために使用している1つの機能を常に欠いていることがわかり（とにかく、私はそれを削除しました）、穏やかなダウングレード方法を見つけるのに大きな頭痛の種になります。 。