DX und OpenGL verwendet man normalerweise zum Zeichnen von Polygonen^^ Vorallem OpenGL besitzt nur Funktionen um Primitive (aus denen ja alle 3D Modelle aufgebaut sind) in verschiedenen Arten zu zeichnen, DirectX besitzt noch einige Bibliotheken mit Funktionen um z.B. Meshes einfach zu laden.
Wenn du dich mit 3D beschäftigst, musst du also damit rechnen, mit Primitiven herumzujonglieren. Eine 3D-Engine lädt ja theoretisch nur eine laaaaaange Liste von Polygonen (ein Modell z.B.), wendet verschiedene Berechnungen darauf an (z.B. Bewegung, Kamera, Culling, Texturen, Shader, Schattenprojektion, usw...) und zeigt sie danach, eines nach dem anderen, an.
OpenGL-lernen
Das ist mir schon klar, aber mir geht es darum ein 2D Polygon schnell anzuzeigen...
Desswegen wollte ich Fragen wie ich das schaffe...
//edit:
Nochmal zum Z-Buffer ist das jetzt eine Fuktion der Grafikkarte? Weil wenn nicht und ich muss pixel für pixel auf einem 2D Bild zeichnen würde das 1. seher sehr viel zeit in anspruch nehmen, aber es hätte den netten vorteil das ich eine kleine einfache Kollisionsberechnung drin hätte...
Weil wenn ein pixel den anderen schneidet dann wäre das eine collision.
Andreas
Desswegen wollte ich Fragen wie ich das schaffe...
//edit:
Nochmal zum Z-Buffer ist das jetzt eine Fuktion der Grafikkarte? Weil wenn nicht und ich muss pixel für pixel auf einem 2D Bild zeichnen würde das 1. seher sehr viel zeit in anspruch nehmen, aber es hätte den netten vorteil das ich eine kleine einfache Kollisionsberechnung drin hätte...
Weil wenn ein pixel den anderen schneidet dann wäre das eine collision.
Andreas
Wenn du doch OpenGL oder DirectX verwendest hast du einen ZBuffer in API, wenn du keine dieser Schnittstellen nutzen willst wirst du das selbst machen müssen. OpenGL und DX sind APIs, die in einem Treiber umgesetzt werden welcher das ganze auf die vorhanden Hardwarefunktionen abbildet. Wenn du solche Funktionen in deinem Softwarerasterizer (der dann kein reiner Softwarerasterizer mehr wäre) nutzen wollen würdest, dann würdest du einen (besser gesagt duzende) eigenen Grafikkartentreiber schreiben müssen.
Das ist zwar theoretisch möglich wird aber praktisch an der nicht vorhandenen Dokumentation scheitern. Das XFree Team (bzw leute aus deren Dunstkreis) hat sehr lange gebraucht um auch nur hardwarebeschleunigte 2D Funktionen zu reverseengeneeren. Ati veröffentlich jetzt zwar schritt für schritt Dokumentation zu ihrer Hardware, aber (und ich bitte dich das nicht als Angriff zu verstehen) ich bezweifle ernsthaft dass du das schaffen würdest.
Den Z-Buffer zur kollisionserkennung zu nutzen wird ebenfalls nicht funktionieren. Das ist ja dann nur eine Map mit den Distanzen aus einer Bestimmten Blickrichtung... also mehr soetwas wie eine Topographie, ähnelt also gewissermaßen einer Heightmap.
Funktionierende Kollisionen in 3D sind recht kompliziert. Wenn du dich damit in 2D befasst hast, dann kennst du sicher das Problem der "Overpenetration", also der nichterkennung einer Kollision, weil eine Hohe Objektgescheindigkeit dazu geführt hat, dass ein Objekt durch ein anderes "durchgesprungen" ist. Das passiert bei 3D kollisionen Ständig, weil bei bewegungen in 3 Diemensionen viel häufiger nur kleine Ecken überlappen würden. Da brauchst du auf jeden Fall ein Projektionsbasiertes System.
Ich würde dir auch dringend raten dich erstmal auf eines von beiden zu konzentrieren, da diese Probleme nicht zusammenhängen.
Mathematik wird in diesen Büchern auch vermittelt. In reinen OpenGL/DirectX Büchern meist aber nur sehr wenig. Du wirst wahrscheinlich nicht drum herum kommen auch ein paar Mathebücher zu wälzen, am besten zu Linearer Algebra.
Für die reine Darstellung vermittelt dir aber das Buch von Apetri alles notwendige an Grundlagen. Bücher zu Kollisionen und der gleichen sind aber leider deutlich schwerer zu finden. Ein richtig gutes ist mir da jedenfalls nicht bekannt. Eberlys Buch behandelt zwar auch das am rande, aber nicht sehr ausführlich und (imho) auch nicht besonders gut.
Das ist zwar theoretisch möglich wird aber praktisch an der nicht vorhandenen Dokumentation scheitern. Das XFree Team (bzw leute aus deren Dunstkreis) hat sehr lange gebraucht um auch nur hardwarebeschleunigte 2D Funktionen zu reverseengeneeren. Ati veröffentlich jetzt zwar schritt für schritt Dokumentation zu ihrer Hardware, aber (und ich bitte dich das nicht als Angriff zu verstehen) ich bezweifle ernsthaft dass du das schaffen würdest.
Den Z-Buffer zur kollisionserkennung zu nutzen wird ebenfalls nicht funktionieren. Das ist ja dann nur eine Map mit den Distanzen aus einer Bestimmten Blickrichtung... also mehr soetwas wie eine Topographie, ähnelt also gewissermaßen einer Heightmap.
Funktionierende Kollisionen in 3D sind recht kompliziert. Wenn du dich damit in 2D befasst hast, dann kennst du sicher das Problem der "Overpenetration", also der nichterkennung einer Kollision, weil eine Hohe Objektgescheindigkeit dazu geführt hat, dass ein Objekt durch ein anderes "durchgesprungen" ist. Das passiert bei 3D kollisionen Ständig, weil bei bewegungen in 3 Diemensionen viel häufiger nur kleine Ecken überlappen würden. Da brauchst du auf jeden Fall ein Projektionsbasiertes System.
Ich würde dir auch dringend raten dich erstmal auf eines von beiden zu konzentrieren, da diese Probleme nicht zusammenhängen.
Mathematik wird in diesen Büchern auch vermittelt. In reinen OpenGL/DirectX Büchern meist aber nur sehr wenig. Du wirst wahrscheinlich nicht drum herum kommen auch ein paar Mathebücher zu wälzen, am besten zu Linearer Algebra.
Für die reine Darstellung vermittelt dir aber das Buch von Apetri alles notwendige an Grundlagen. Bücher zu Kollisionen und der gleichen sind aber leider deutlich schwerer zu finden. Ein richtig gutes ist mir da jedenfalls nicht bekannt. Eberlys Buch behandelt zwar auch das am rande, aber nicht sehr ausführlich und (imho) auch nicht besonders gut.
Vielen Dank für die ausführliche Beschreibung!
Ich hab einmal in Java so ein 3D sample geschrieben, doch wie gesagt hab ich das mit der überlappung nicht hinbekommen...
Wenn ich das jetzt mit einer Art Z-Buffer hinbekommen will, müsste ich ja mein eigenes Polygon-zeichnen machen. Das würde aber widerum sehr viel zeit kosten...
Also die Bücher werden gleich bestellt...
Andreas
Ich hab einmal in Java so ein 3D sample geschrieben, doch wie gesagt hab ich das mit der überlappung nicht hinbekommen...
Wenn ich das jetzt mit einer Art Z-Buffer hinbekommen will, müsste ich ja mein eigenes Polygon-zeichnen machen. Das würde aber widerum sehr viel zeit kosten...
Also die Bücher werden gleich bestellt...
Andreas
Wenn du einen Softwarerasterizer schreiben willst, dann ist es soweiso besser wenn du mal eine eigene Polygonroutine geschrieben hast, aber keine angst, dass wird in "3D-Grafik Programmierung" ausführlich und relativ leicht verständlich beschrieben (wenn ich mich recht erinnere, hab jetzt kein Bock nachzulesen ^^).