PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : Wie rendert OpenGL


whiteshadow666
2003-07-01, 18:30:08
Hi @ all,
bin gerade mit meiner Abschlussarbeit mit dem Thema Stereoprojektion beschäftigt und brauche mal eine Bestätigung meiner Theorie von den Profis (damit seit ihr gemeint ;-)) ).
Und zwar ist es richtig das, wenn in OpenGL eine 3D-Linie zeichnet, dann wird der Anfangs bzw. Endpunkt auf die Projektionsebene projiziert, und diese beiden Pixel werden dann mit hilfe eines 2D-Algorithmuses verbunden. Das würde ja sinn machen weil so wäre es sehr effizienter als sich jeden Punkt (das sind ja unendlich viele) anzuschauen. Wenn das stimmen sollte kann mir einer die Quelle angeben wo man das nachlesen kann. Da leider in meinen Büchern entweder nur uralte Grafikbibliotheken beschrieben werden, oder nicht auf die Funktionsweise der OpenGL-Befehele eingegangen wird.
Und was ist mit Körpern? Diese werden ja in Triangle zerlegt, wird bei denen auch die Ecken auf die Ebenen projiziert und dann mit Hilfe eines Scanline-Algorithmus ausgefüllt? (ich gehe von Untexturierten Objekten aus) oder wird auch noch in z-Richtung raterisiert? Wenn jemand ne Anwort mit Quelle hätte wäre ich echt dankbar!

So das wars eigentlich. Ich bedank mich schon mal im vorraus für eure Hilfe.

White Shadow

Demirug
2003-07-01, 18:44:29
OpenGL rendert überhaupt nichts. *scnr*

OpenGL ist ja lediglich eine API mit der man einen Rendere (Hardware oder Software) steuern kann.

Jedem dieser Renderer ist es nun selbst überlassen wie er ein Dreieck in Pixel zerlegt. Das Scanline verfahren ist eine Möglichkeit. Aber nicht unbedingt die Beste.

Die einzigen Chips von denen ich relative genau weiss wie sie das anstellen ist die NV3X Rheie. Diese schlagen einen recht wilden Zickzack Kurs über das Dreieck ein welcher eine möglichst gute Ausnutzung des Texturecaches erlauben soll.

zeckensack
2003-07-01, 18:46:16
1. 'Vertex' rein (glVertex)
2. Transformation (Ortsvektor*Matrix, Ergebnis ist eine homogene Koordinate).
3. Perspektiv-Division (alle Elemente 'durch' w; Ergebnis ist eine 3D-Koordinate)
4. Primitive assembly (Konfigurierbar durch glBegin; entweder Linien, Dreicke, wasesauchimmersonstnochgibt)

An diesem Punkt werden dann einfach mehrere Eckpunkte abgegriffen, und - wie du schon sagtest - linear interpoliert. Scanlines für Dreiecke, Bresenham für Linien (obwohl das nur die wenigsten Grafikchips machen, meistens werden Linien durch dünne Dreieckspaare ersetzt).

Z wird aber weiterhin mitgenommen, und ebenfalls linear interpoliert. Wird ja auch noch für Z-Buffering/Z-Test gebraucht.

Das ist allerdings nur die logische Funktionsweise, wie genau das implementiert ist wird natürlich nicht festgelegt. Die Implementierung muß sich nur so verhalten, als ob es so wäre :)

Mit Texturen wird das ganze noch etwas komplizierter ;)

White Shadow
2003-07-01, 21:11:48
Kann man irgendwo nachlesen wie die einzelnen Hersteller das implementieren? Gibt es WhitePapers wo das steht? Wäre nämlich wichtig da ich das in meiner Arbeit belegen muss. Wäre dumm zu sagen das ist so ohne das belegen zu können. Ich meine ich könnte argumentieren das alles andere keinen Sinn macht da das viel zu aufwendig ist! naja erst mal danke, da ich doch nicht so falsch lag. Achja und Zeckensack bis auch für z-buffering und licht wird die z-Position nicht benutzt. Als beispiel einfaches erstellen eine unbeleuchteten Linie ohne textur und licht . Es werden auch keine anderen Linien benötigt. dann ware es doch so wie ich es beschrieben habe oder?
thx
White Shadow

Demirug
2003-07-01, 21:22:42
Das genaue Verfahren zur Rasterisierung gehört normalerweise zu den Dingen welche die IHVs nicht so einfach rausrücken.

Von nVidia gibt es zu dem Thema allerdings ein inzwischen öffentlich einsehbares Patent: http://l2.espacenet.com/espacenet/viewer?PN=US6504542&CY=gb&LG=en&DB=EPD

Ob das nun aber 100% genau so in einem Chip benutzt wurde kann ich natürlich nicht sagen.

White Shadow
2003-07-01, 21:44:36
Demi,
kann ich den sagen das die IVH aufjedenfall einVerfahren benutzten, das entweder ähnlich dem ist welche in Foley vanDamm Principles of Computer Graphics beschrieben ist, oder noch effizienter ist. Die wichtige Ausage für mich wäre nämlich das nur der Anfangs und Endpunkt einer Linie ausschlaggebend für das Ergebnis der rateriesirung ist. Das würde nämlich meine Ergebisse bestätigen. Wenn man dies jetzt auch noch auf Triangles übertagen könnte. D.h. eine gefülltes Triangle ist nur von den Eckpunkten abhängig, wäre das perfekt. Wenn mir das jemand bestätigen könnte wäre das sehr schön weil dann wäre ich mit meiner Arbeit endlich fertig. Danke nochmal für deine/eure Hilfe.

White Shadow

P.S. Demi kennste ne gute seite/buch wo beschrieben wird wie Vertex und Pixel Shader funktionieren und wie man diese in OpenGL einbaut?

Demirug
2003-07-01, 22:00:36
Jetzt muss ich auch noch meinen Foley rausholen. :D Da sind aber wie du sicher weist einige Verfahren beschrieben.

Was das Rastern angeht so wird eine Linie immer durch ihrer 2 Endpunkte bestimmt.

Bei einem Dreieck sind es entsprechend immer 3 Eckpunkte.

Diese beiden Dinge werden garantiert. Was aber eben nicht festgelegt ist in welcher Rheienfolge die Pixel innerhalb des Dreiecks bzw auf der Linie abgearbeitet werden. Aber unabhängig von der Rheienfolge kommt am Ende immer das gleiche Bild heraus.

Pixel und Vertexshader gibt es unter OpenGL nicht. Dort nennt man das Fragment und Vertexprogramme. Eine ganze Menge Informationen zu dem Thema findet man im Entwicklerbreich von nVidia.

Xmas
2003-07-02, 02:40:23
Beim Thema Stereoprojektion nehme ich mal an du möchtest dich vergewissern dass beim Rendern immer von der Projektion auf eine Ebene (Bildschirmebene) ausgegangen wird. Das ist in der Tat so.

Aus diesem Grund ist es auch nicht einfach, ein gerendertes Bild korrekt auf eine Halbkugel oder einen Halbzylinder zu projizieren. Dafür müste man meist einen Postprocessing-Schritt zur Verzerrung einbauen. Ebenso ist z.B. eine Fischauge-Linse auf Vertexebene nur dann möglich, wenn eine entsprechend feine Tessellierung garantiert ist.

whiteshadow666
2003-07-02, 17:41:49
Original geschrieben von Xmas
Beim Thema Stereoprojektion nehme ich mal an du möchtest dich vergewissern dass beim Rendern immer von der Projektion auf eine Ebene (Bildschirmebene) ausgegangen wird. Das ist in der Tat so.

Nein es geht hier um eine Fehlerberechnung, da während eines Versuches in dem Institut für welches/bei welchem ich die Arbeit mache, die Beobachter schon eine Änderung der Tiefeninformation gesehen haben, obwohl sich das Pixel noch garnicht verändert hat. Da ihr mir jetzt aber meine Annahme bestätigt habt. Kann ich bestätigen das das an Aliasingeffekten bzw. eines Bewegen des Beobachtern liegt, da für die Fetstlegung der Projektion, die Kopfpostion gemessen wurde. Die Versuchpersonen wurden ja nicht festgeschraubt (das wäre ja unmenschlich *fg*), so dass sie sich nicht bewegen konnten. Also konnten sie alleine durch die Bewegung des Kopfes die projektion ändern. Als Darstellungsmedium wurde eine Workbench benutzt. So jetzt wisst ihr worum es geht ;-).
Achja und danke für eure Hilfe.
White Shadow.

P.S. ich habe schon eine Stereoprojektion für Workbench/CAVE impelmentiert und musste halt nur noch dieses Phänomen erleutern.
P.S.S. gibt es den auch eine hersteller unabhängige Möglichkeit Fragment und Vertex Shader zu implementieren? oder muss man echt für jede Karte einen eigenen Renderpfad anlegen? und wenn ja gibt es eine möglichkeit dies möglichst effektiv sowohl, peformance als auch speicher, zu machen?