Archiv verlassen und diese Seite im Standarddesign anzeigen : Rasterizer und Rayracing/casting Frage
dllfreak2001
2008-10-26, 20:23:12
Es kam ein Kollege ins Forum der behauptet, dass das Rasterizerverfahren
wie es in aktuellen Spielen genutzt wird nur eine abgespeckte Version
von Raytracing ist. So soll der Strahl nur bis zur ersten Kollision laufen und so eine einfache Projektion auf des jeweilige Pixel als Ursprungspunkt durchgeführt (so hab ich das verstanden).
Er sagt der Rasterizer ist eine Unterform des Raytracing.
Ich dagegen behaupte, dass beim Rasterizerverfahren Polygone einfach perspektivisch verzehrt werden und es somit bis auf den gleichen Zweck keine direkte verwandschaft hat.
Du hast recht. Nur die ImgTec-Chips machen sowas in dieser Richtung um die Sichtbarkeit in den Tiles zu bestimmen, aber GeForces und Radeons rastern völlig ohne Raycasting.
Ok danke, da hab ich doch Recht.
BAGZZlash
2008-10-27, 10:21:40
Ich dagegen behaupte, dass beim Rasterizerverfahren Polygone einfach perspektivisch verzehrt werden [...]
Hmmm, Polygone...
http://static.twoday.net/anima/images/homer_simpson.jpg
Sorry, aber der musste sein. :smile:
Du hast recht. Nur die ImgTec-Chips machen sowas in dieser Richtung um die Sichtbarkeit in den Tiles zu bestimmen, aber GeForces und Radeons rastern völlig ohne Raycasting.ich dachte beim Rasterizen wird für jedes einzelne Polygon für jeden Bildschirmpixel ein Strahl von der Kamera durch den Pixelmittelpunkt zum Polygon geschossen, und anhand der Lages des Auftreffpunktes auf dem Polygon (des Samplepunktes) der Farbwert des Bildschirmpixels bestimmt?
Wenn es jetzt so sein soll wie dllfreak2001 behauptet, dass einfach nur ein Polygon perspektivisch verzerrt auf den Bildschirm geblittet wird, dann hieße das aber doch, dass ein Rasterizer nicht pixel-, sondern texelorientiert sei, also nicht Pixel für Pixel durchgeht, wo dieser im Texturraum auf den Polygon zu liegen kommt, sondern Texel für Texel, welche Bildschirmpixel von diesem bedeckt werden. Wie aber sollen damit Filtertechninken wie bi- oder trilinear realisierbar sein? Dafür braucht es doch im Texturraum Samplepunkte zwischen den Texeln, die der Lage der Pixelmittelpunkte im Texturraum entsprechen.
Oder man betrachte texturunabhängige Interpolationstechniken, wie das Gouraud Shading. Da sind ja Samplepunkte auf dem Polygon zwischen den Vertices erforderlich, an denen interpoliert werden kann. Wo bekommt man diese Samplepunkte, wenn nicht durch Strahlen durch die Bildschirmpixel auf das Polygon?
Krishty
2008-10-27, 11:54:49
Da ist ein Fehler in deiner Logik. Wenn die Sample-Punkte durch Strahlen durch die Bildschirmpixel definiert wären, dann setzt das voraus, dass du schon weißt wo die Bildschirmpixel liegen. Das tust du auch und genau da liegen nunmal auch die Samples, darum wäre das total unnötig.
Wenn du die transformierten Pixelkoordinaten der Vertices kennst klapperst du einfach nurnoch jede gerade Zahl (u.U. auch mit einem 0.5er-Offset) ab, interpolierst und bist fertig. Bei Texturen wird perspektivisch korrekt interpoliert, dafür benutzt man AFAIK noch die W-Koordinate. Aber nicht hauen falls das falsch ist.
Sry für die vielen Edits aber in deinem Post ist so Vieles grundlegend falsch, dass ich garnicht weiß wo ich anfangen soll zu korrigieren…
Achja, für Texturfilterung zieht man die Texturkoordinaten der benachbarten Pixel (oder besser die Änderungsrate dahin) heran.
Jetzt kann Coda aufräumen kommen :D
Da könnte man jetzt nen Roman drüber schreiben... Ein Rasterizer rastert (deshalb der Name ;)) auf jeden Fall Polygone, es gibt keine Strahlen.
Da ist ein Fehler in deiner Logik. Wenn die Sample-Punkte durch Strahlen durch die Bildschirmpixel definiert wären, dann setzt das voraus, dass du schon weißt wo die Bildschirmpixel liegen. wo die auf der Bildschirmfläche liegen, weiß ich ja auch.
Das tust du auch und genau da liegen nunmal auch die Samples, darum wäre das total unnötig.die Samplepunkte liegen aber nicht auf der Bildschirmfläche, sondern auf dem Polygon. Es muss also ermittelt werden, wo der zu einem Bildschirmpixel gehörende Samplepunkt auf dem Polygon liegt. Dazu wird im gedachten 3D-Raum ein Strahl von der Kamera durch den Bildschirmpixel auf der Bildschirmfläche geschossen. Hinter der Bildschirmfläche trifft dieser Strahl dann auf einen Punkt des Polygons. Das ist der Samplepunkt auf dem Polygon.
Du musst also unterscheiden zwischen der Lage des Pixels auf der Bildschirmfläche (die bekannt ist), und der Lage des zugehörigen Samplepunktes auf dem Polygon, der bestimmt werden muss.
Wenn du die transformierten Pixelkoordinaten der Vertices kennst klapperst du einfach nurnoch jede gerade Zahl (u.U. auch mit einem 0.5er-Offset) ab, interpolierst und bist fertig. verstehe ich nicht. Was soll "Abklappern jeder geraden Zahl" sein? Ich habe:
- Bildschirmpixel, mit bekannten 2D-Koordinaten auf der Bildschirmfläche und bekannten 3D-Koordinaten im 3D-Raum
- ein Kontinuum von Punkten auf den Polygon, jeder mit einer 3D-Koordinate im gedachten 3D-Raum und einer 2D-Koordinate im Texturraum
- Texel, die eine Untermenge der zuvor genannten Punkte bilden
- Vertices, ebenfalls eine Untermenge der Punkte auf dem Polygon
Wenn ich also etwas abklappern soll, muss das eines von diesen sein. Und wenn es dann noch was zum interpolieren geben soll, braucht es zum einen (mindestens) zwei Stützstellen, an denen die zu interpolierende Größe bekannt ist, und als drittes einen Samplepunkt zwischen den Stützstellen.
Bei Texturen wird perspektivisch korrekt interpoliert, dafür brauchst du Samplepunkte auf dem Polygon. Die bekommst du woher?
Achja, für Texturfilterung zieht man die Texturkoordinaten der benachbarten Pixel (oder besser die Änderungsrate dahin) heran.das glaube ich dir nicht. Ich glaube eher, man bestimmt des Samplepunkt des zu färbenden Bildschirmpixels auf dem Polygon, und zieht dann die Farbwerte der diesem Samplepunkt benachbarten Texel heran.
das glaube ich dir nicht. Ich glaube eher, man bestimmt des Samplepunkt des zu färbenden Bildschirmpixels auf dem Polygon, und zieht dann die Farbwerte der diesem Samplepunkt benachbarten Texel heran.
Das kannst du ihm ruhig glauben, weil es stimmt. Genau aus dem Grund wird auch bei GPUs mindestens seit es Shader gibt immer in 2x2 Quads gerendert, damit man auch bei dynamisch errechneten Texturkoordinaten sofort die Screen-Space-Derivates zur LOD-Bestimmung und für's AF hat.
Da könnte man jetzt nen Roman drüber schreiben... Ein Rasterizer rastert (deshalb der Name ;)) auf jeden Fall Polygone, ganz recht, und das tut er, indem er Strahlen durch die Bildschirmpixel auf der Bildschirmfläche auf das Polygon schießt. Rastern bedeutet, dass eine gerasterte, also aus Pixeln bestehende 2D-Grafik erzeugt wird. Soll von so einer 2D-Rastergrafik eine 3D-Szene dargestellt werden, muss für jeden Pixel der Rastergrafik bestimmt werden, welcher Teil der 3D-Szene von diesem Pixel dargestellt wird. Dies ist bestimmt durch eine Gerade, die von der Kamera ausgeht, eine gedachte 2D-Fläche in der 3D-Szene, die für die 2D-Grafik steht, durchstößt und auf ein Objekt in der 3D-Szene trifft.
ganz recht, und das tut er, indem er Strahlen durch die Bildschirmpixel auf der Bildschirmfläche auf das Polygon schießt.
Nein. Das tut er in dem er völlig simpel die Derivate berechnet, dafür braucht er keine Strahlen. Du hast schwere Denkfehler. Die Verdeckung wird durch den Z-Buffer bestimmt falls du das meinst. Dafür braucht man auch keine Strahlen bei einem Rasterizer.
Es werden einfach Dreiecke gezeichnet im Screenspace. Der Rest lässt sich entsprechend perspektivisch interpolieren. Die Projektion wird durch eine Matrix und mittels homogenen Koordinaten vorher erledigt.
Das kannst du ihm ruhig glauben, weil es stimmt. glauben tue ich grundsätzlich nichts was ich nicht verstehe. Und was Krishty da erklärt hat, verstehe ich nunmal nicht. Zumal meine Ansicht hier bestätigt wird:
http://alt.3dcenter.org/artikel/grafikfilter/index4.php
Man betrachte die ersten beiden Grafiken. Die 4 Flächen auf der linken Seite, in den Farben orange, rot, grün und blau (im Uhrzeigersinn) sind die Texel. Der Kreuzungspunkt der senkrechten und waagerechten weißen Linie ist der Samplepunkt auf dem Polygon, in dem der durch den Bildschirmpixel geschossene Strahl auf das Polygon trifft. Das weiß umrandete Quadrat um den Kreuzungspunkt herum das sog. Pixelurbild im Texturraum.
http://alt.3dcenter.org/images/grafikfilter/bild10.png
Wie man sieht, wird zur Färbung des Pixels ein Gemisch der Farben der vier Texel, die teilweise im Pixelurbild liegen, verwendet. Das ist die Interpolation.
Genau aus dem Grund wird auch bei GPUs mindestens seit es Shader gibt immer in 2x2 Quads gerendert, damit man auch bei dynamisch errechneten Texturkoordinaten sofort die Screen-Space-Derivates zur LOD-Bestimmung und für's AF hat.kann natürlich sein, dass es da diverse Optimierungen gibt, die ganze Prinzip etwas modifizieren.
Mein lieber Herr Gast, ich habe schon selber Rasterizer geschrieben und weiß sehr genau was ich schreibe. Es werden dabei keine Strahlen verwendet. Die Pixelmittelpunkte kennt man und durch die Screen-Space-Derivate kann man mittels des durch r1 = (du/dx,du/dx) und r2 = (dv/dx, dv/dy) aufgespannten Parallelogramms die Projektion der Textur auf das Pixel auch so berechnen. Das LOD-Level ist dann der Logarithmus der maximalen Seitenlänge dieses Parallelogramms, und die Line-Of-Anisotropy ist die größere Mitteldiagonale davon.
Der trilineare Filter bezieht sich einfach auf den "Komma-Teil" des LOD-Levels und der Texturkoordinaten.
Es täte dir gut mal die Grundlagen zu erarbeiten.
Nein. Das tut er in dem er völlig simpel die Derivate berechnet, dafür braucht er keine Strahlen.was sind Derivate?
Du hast schwere Denkfehler. Die Verdeckung wird durch den Z-Buffer bestimmt falls du das meinst. meine ich nicht. Ich sprach vom Rasterizen eines Einzelpolygons, ohne Berücksichtigung von Verdeckungen.
Wobei der Z-Buffer da natürlich auch mit zu tun hat. Der Z-Buffer speichert für jeden Bildschirmpixel, welche z-Koordinate der Schnittpunkt des Strahls mit dem zuletzt gerasterizeten Polygon hat. Rasterized man dann ein weiteres Polygon, wird wieder die z-Koordinate des Schnittpunktes bestimmt. Ist sie höher die gespeicherte, wird das weitere Rendern des Pixels für das aktuelle Polygon gestoppt, und die vom vorherigen Polygon ermittelten Farbwerte beibehalten.
Es werden einfach Dreiecke gezeichnet im Screenspace. Screenspace = 2D-Bildschirmfläche?
Der Rest lässt sich entsprechend perspektivisch interpolieren.zum interpolieren braucht's Samplepunkte. Wo kommen die her?
was sind Derivate?
Die Veränderung pro Pixel in x und y. da/dx und da/dy für beliebiges a einfach.
Wobei der Z-Buffer da natürlich auch mit zu tun hat. Der Z-Buffer speichert für jeden Bildschirmpixel, welche z-Koordinate der Schnittpunkt des Strahls mit dem zuletzt gerasterizeten Polygon hat.
Es gibt keine Strahlen. Der Z-Wert wird perspektivisch korrekt über das Dreieck interpoliert. Und an den Eckpunkten kommt er aus dem Vertex-Shader.
Screenspace = 2D-Bildschirmfläche?
Ja. Das rastern am Ende ist eine reine 2D-Operation.
zum interpolieren braucht's Samplepunkte. Wo kommen die her?
Vom Rasterizer. Das sind die Pixelmittelpunkte, bzw. bei Supersampling auch Sub-Samples in diesen.
Mein lieber Herr Gast, ich habe schon selber Rasterizer geschrieben und weiß sehr genau was ich schreibe. Es werden dabei keine Strahlen verwendet. Die Pixelmittelpunkte kennt man du meinst die auf der Bildschirmfläche?
und durch die Screen-Space-DerivateScreen = 2D-Bildschirmfläche, Space = 3D-Raum der Szenerie?
kann man mittels des durch r1 = (du/dx,du/dx) und r2 = (dv/dx, dv/dy) (u,v) = 2D-Koordinaten auf dem Polygon, (x,y) = 2D-Koordinaten auf der Bildschirmfläche? Man bestimmt also Funktionen u(x,y) und v(x,y)? Und ermittelt somit die Samplepunkte auf dem Polygon, indem man Pixel für Pixel die beiden Funktionen ausrechnet?
Dann bleibt noch die Frage, wie die beiden Funktionen bestimmt werden, vielleicht basiert das ja auf Strahlen?
aufgespannten Parallelogramms Parallelogramm? Vielleicht sind ja eine oder mehrere von dessen Kanten die Strahlen von denen ich sprach. Was sind denn dessen Eckpunkte?
Das LOD-Level ist dann der Logarithmus der maximalen Seitenlänge dieses Parallelogramms, und die Line-Of-Anisotropy ist die größere Mitteldiagonale davon.da der LOD nicht für das Polygon einheitlich ist, sondern per Pixel zu bestimmen ist, ist dieses Parallelogramm dann auch per Pixel?
Der trilineare Filter bezieht sich einfach auf den "Komma-Teil" des LOD-Levelsschon klar, die Frage war, wie der Kommateil zu bestimmen ist.
Die Veränderung pro Pixel in x und y. da/dx und da/dy für beliebiges a einfach.gut. Also stellt sich die Frage, wie die Funktionen u(x,y) und v(x,y) bestimmt werden.
Es gibt keine Strahlen.dass du diese Ansicht vertrittst, habe ich durchaus schon mitgekriegt.
Der Z-Wert wird perspektivisch korrekt über das Dreieck interpoliert. zum interpolieren braucht's Samplepunkte. Die werden mittels Strahlen durch die Bildschirmpixel hindurch zum Polygon hin bestimmt.
Ja. Das rastern am Ende ist eine reine 2D-Operation.das kann es allein schon deswegen nicht sein, weil eine 3D-Szenerie dargestellt werden soll.
Vom Rasterizer. Das sind die Pixelmittelpunkterichtig, und der Rasterizer macht dies mit Strahlen.
du meinst die auf der Bildschirmfläche?
Selbstverständlich.
Screen = 2D-Bildschirmfläche, Space = 3D-Raum der Szenerie?
Nein. Screen-Space = 2D Bildschirmraum.
(u,v) = 2D-Koordinaten auf dem Polygon
u und v sind die interpolierten Texturkoordinaten. Die kommen auch aus dem Vertexshader an den Eckpunkten des Dreiecks.
Dann bleibt noch die Frage, wie die beiden Funktionen bestimmt werden, vielleicht basiert das ja auf Strahlen?
Die Interpolation basiert auf einem einfachen linearen Gleichungssystem:
Z.B. für v
A*x1 + B*y1 + C = v1/w1
A*x2 + B*y2 + C = v2/w2
A*x3 + B*y3 + C = v3/w3
Das kann man so auflösen, dass man die Änderungen in x- und y- Richtung hat und kann diese dann inkrementell beim rastern des Dreiecks mitführen.
Man interpoliert zusätzlich auch noch immer 1/w mit und kann dann mittels w = 1/(1/w') den w-Wert an jedem Punkt ausrechnen. Den multipliziert man dann noch mit den anderen interpolierten Werten (da diese ja durch w geteilt wurden) und hat die korrekten Ergebnisse.
Parallelogramm? Vielleicht sind ja eine oder mehrere von dessen Kanten die Strahlen von denen ich sprach. Was sind denn dessen Eckpunkte?
Das sind die Eckpunkte des projezierten Texturelements mit Seitenlänge 1 im Texturraum. Keine Strahlen.
da der LOD nicht für das Polygon einheitlich ist, sondern per Pixel zu bestimmen ist, ist dieses Parallelogramm dann auch per Pixel?
Das Parallelogramm ist nur eine Rechnung um das LOD zu bestimmen. Der LOD-Wert wird immer pro Quad bestimmt.
dass du diese Ansicht vertrittst, habe ich durchaus schon mitgekriegt.
Fakten mein Freund. Keine Ansicht.
das kann es allein schon deswegen nicht sein, weil eine 3D-Szenerie dargestellt werden soll.
Das kann sehr wohl sein, da 1/w im Screenspace linear ist. Die interpolierten Werte haben zwar eine Z-Komponente, aber das war's auch schon. W ist die "echte" Entfernung der Punkte von der Kamera, also der ursprüngliche Z-Wert vor der perspektivischen Matrix.
richtig, und der Rasterizer macht dies mit Strahlen.
Nein *seufz*
u und v sind die interpolierten Texturkoordinaten. ist das was anderes als die 2D-Koordinaten auf dem Polygon? Sollte eigentlich dasselbe sein. Jeder Punkt auf dem Polygon hat eine u- und eine v-Koordinate.
Die Interpolation basiert auf einem einfachen linearen Gleichungssystem:
Z.B. für v
A*x1 + B*y1 + C = v1/w1
A*x2 + B*y2 + C = v2/w2
A*x3 + B*y3 + C = v3/w3
ich nehme an, die Indices an x, y und v stehen für die Vertices?
D.h. man kennt für jeden Vertix u_i und v_i, und bestimmt die x_i und y_i. Daraus kann man dann durch Lösen deines Gleichungssystems die Größen A, B und C bestimmen, und die Funktion u(x,y) und v(x,y) haben dann die Form
v(x,y) = A x + B y + C
Richtig?
Das hätte aber den fatalen Fehler, dass u und v lineare Funktionen von x und y wären, was zu perspektivischen Verfälschungen führen würde. Ich zitiere aus:
http://alt.3dcenter.org/artikel/grafikfilter/index2.php
"Für die Textur reicht es leider nicht, einfach die (nun korrigierten) Eckpunkt-Daten je für X und Y linear zu interpolieren. Diese Berechnung muss noch um die perspektivische Verzerrung korrigiert werden. Denn nahe Objekte erscheinen größer als ferne. Wenn man von schräg oben auf eine quadratische Platte sieht, nimmt die erste Hälfte mehr im Sichtfeld ein, als die zweite. Der Mittelpunkt ist also etwas nach hinten verschoben."
Man interpoliert zusätzlich auch noch immer 1/w mit und kann dann mittels w = 1/(1/w') den w-Wert an jedem Punkt ausrechnen. Den multipliziert man dann noch mit den anderen interpolierten Werten (da diese ja durch w geteilt wurden) und hat die korrekten Ergebnisse.ich habe leider noch nie verstanden, was dieses w eigentlich sein soll. Ist das wichtig? Oder sollte das vielleicht was mit der perspektivischen Korrektur zu tun haben?
Das sind die Eckpunkte des projezierten Texturelements mit Seitenlänge 1 im Texturraum. du meinst ein Quadrat im Texturraum auf die Bildschirmfläche projeziert? Ist das nicht eher ein Trapez als ein Parallelogramm?
Das Parallelogramm ist nur eine Rechnung um das LOD zu bestimmen. Der LOD-Wert wird immer pro Quad bestimmt.wenn aber das Parallelogramm (so es denn kein Trapez ist) nur einmal por Polygon bestimmt wird, kommt dann nicht immer der gleiche LOD raus?
Fakten mein Freund. Keine Ansicht.dass du deine eigene Ansicht für ein Faktum hältst, ist trivial.
Das kann sehr wohl sein, da 1/w im Screenspace linear ist. Die interpolierten Werte haben zwar eine Z-Komponente, aber das war's auch schon. W ist die "echte" Entfernung der Punkte von der Kamera, also der ursprüngliche Z-Wert vor der perspektivischen Matrix.keine Ahnung, was du mir sagen willst. Wie gesagt, was w ist habe ich noch nie verstanden. Die Entfernung von der Kamera ist allerdings nicht z, sondern sqrt(x^2 + y^2 + z^2), sofern die Kamera bei (0,0,0) ist.
Das hätte aber den fatalen Fehler, dass u und v lineare Funktionen von x und y wären, was zu perspektivischen Verfälschungen führen würde. Ich zitiere aus:
Deshalb interpoliert man durch w geteilt. Das ist dann linear im Bildschirmraum. Habe ich aber schon hinreichend erklärt.
ich habe leider noch nie verstanden, was dieses w eigentlich sein soll.
Das merkt man.
Ist das wichtig? Oder sollte das vielleicht was mit der perspektivischen Korrektur zu tun haben?
Das ist die perspektivische Korrektur.
wenn aber das Parallelogramm (so es denn kein Trapez ist) nur einmal por Polygon bestimmt wird, kommt dann nicht immer der gleiche LOD raus?
Nicht pro Polygon, sondern pro Quad, also 2x2 Pixel, da man dann einfach die Derivate bestimmen kann. Siehe oben.
du meinst ein Quadrat im Texturraum auf die Bildschirmfläche projeziert? Ist das nicht eher ein Trapez als ein Parallelogramm?
Kann sein. Wie gesagt ist das nur eine Rechenhilfe für das LOD-Level. Pro Quad wird das nicht viel Unterschied machen.
dass du deine eigene Ansicht für ein Faktum hältst, ist trivial.
Das ist nicht nur in meiner Welt ein Faktum. Das kannst du in jedem Fachbuch genau so nachlesen wie ich es dir erklärt habe.
keine Ahnung, was du mir sagen willst. Wie gesagt, was w ist habe ich noch nie verstanden. Die Entfernung von der Kamera ist allerdings nicht z, sondern sqrt(x^2 + y^2 + z^2), sofern die Kamera bei (0,0,0) ist.
Ich meinte natürlich Entfernung von der Projektionsebene. Mea culpa.
Also bei der Rasterung werden einfach keine Strahlen benötigt. Durch verschiedene Abbildungen projeziert man schon vor der Rasterung die gesamte 3D Szene auf eine 2D Ebene, die man so auf dem Bildschirm darstellen möchte. Die Dreieckseckpunkte bekommen zwar noch einen z-Wert, der ist aber erstmal völlig unerheblich für die Rasterung, denn dann werden im naiven Fall einfach die 2D Dreiecke der Reihe nach auf den Bildschirm gemalt, siehe z.B. http://de.wikipedia.org/wiki/Rasterung_von_Linien (man malt den Umriss des Dreiecks und füllt es dann aus). Wie man dort sieht, braucht man dafür keine Strahlen.
Und w bz. 1/w brauchst du, weil du für einige Abbildungen (z.B. Verschiebung) im projektiven Raum rechnen musst, damit du sie einfach über eine Matrixmultiplikation darstellen kannst. Da steckt dann auch wieder ne Menge Theorie dahinter (algebraische Geometrie), aber fürs Rechnen muss man es einfach nur als mitzuschleppende 4. Komponente sehen ;)
Deshalb interpoliert man durch w geteilt. Das ist dann linear im Bildschirmraum. [...]
Das ist die perspektivische Korrektur.aha. Nett dass mir das auch mal jemand erklärt. :)
Aber Krishty's Statement zur Texturfilterung ist trotzdem falsch:
man bestimmt für den Pixel (x,y) den Samplepunkt (u(x,y),v(x,y)), und interpoliert die Farben der Nachbartexel bei (u_i,v_i), (u_i+1,v_i), (u_i+1,v_i+1), (u_i,v_i+1). Von den Nachparpixeln geht da rein gar nichts ein ;)
Das ist nicht nur in meiner Welt ein Faktum. Das kannst du in jedem Fachbuch genau so nachlesen wie ich es dir erklärt habe.kannst du mir eins nennen? Ich hab schon mehfach versucht im Netz was über die Unterschiede zwischen Rasterizer und Raytracer zu finden, hab aber außer Seiten, wo immer nur stand dass Raytracing doch viel toller sei, nichts gefunden.
Also bei der Rasterung werden einfach keine Strahlen benötigt. Durch verschiedene Abbildungen projeziert man schon vor der Rasterung die gesamte 3D Szene auf eine 2D Ebene, die man so auf dem Bildschirm darstellen möchte. Die Dreieckseckpunkte bekommen zwar noch einen z-Wert, der ist aber erstmal völlig unerheblich für die Rasterung, denn dann werden im naiven Fall einfach die 2D Dreiecke der Reihe nach auf den Bildschirm gemalt, siehe z.B. http://de.wikipedia.org/wiki/Rasterung_von_Linien (man malt den Umriss des Dreiecks und füllt es dann aus). Wie man dort sieht, braucht man dafür keine Strahlen.dass man zum Zeichnen der Umrisslinien eines Polygons keine Strahlen braucht, war schon von vorneherein klar und zu keiner Zeit Gegenstand dieser Diskussion. Selbiges für monochromatisch ausgefüllte Polygone.
Das Thema waren pixelspezifische Strukturen innerhalb des Polygons (z.B. Farb- oder Helligkeitsverläufe).
dllfreak2001
2008-10-27, 14:53:30
dass man zum Zeichnen der Umrisslinien eines Polygons keine Strahlen braucht, war schon von vorneherein klar und zu keiner Zeit Gegenstand dieser Diskussion. Selbiges für monochromatisch ausgefüllte Polygone.
Das Thema waren pixelspezifische Strukturen innerhalb des Polygons (z.B. Farb- oder Helligkeitsverläufe).
Ich denke, wenn man die Textur mit Strahlen ermitteln würde, könnte man sich auch gleich die Ermittlung der Eckkoordinaten eines Polygons mittels perspektivischer Verzehrung ersparen. Ich meine dann wäre das einfach überflüssig, denn letztenendes will man ja nur das bemalte Polygon Abbilden.
(doppelt gemoppelt)
Das Thema waren pixelspezifische Strukturen innerhalb des Polygons (z.B. Farb- oder Helligkeitsverläufe).
Naja, das Dreieck wird auch mit Linien gefüllt und besteht halt im Endeffekt aus Interpolation der Daten zu den 3 Eckpunkten, wie auch die Umrisslinien (Farb- und Helligkeitswerte im gesamten Polygon werden aus den Eckpunkten interpoliert). Daher sind auch dafür keine Strahlen nötig.
Uns weiter oben ging es sehrwohl darum, ob irgendwelche Strahlen genutzt werden um zu bestimmen, was zu sehen ist. Ich wollte zeigen, dass das nicht nötig ist, weil man nach der Projektion nur noch 2D Dreiecke malen muss, und das ohne Strahlen. Wenn man erstmal weiß, welche Pixel "angemalt" werden müssen, dann ist die Bestimmung der Helligkeit/Farbe nicht mehr schwer, nämlich einfach mit linearer Interpolation.
Naja, das Dreieck wird auch mit Linien gefüllt seit wann denn das? Gefüllt werden Polygone mit Farbwerten, und das pixelweise.
und besteht halt im Endeffekt aus Interpolation der Daten zu den 3 Eckpunkten, und damit man was interpolieren kann, braucht man Samplepunkte. Damit jeder im Polygon liegende Pixel korrekt gefärbt wird, sollten das tunlichst die Positionen der Pixelmittelpunkte im Polygon sein. Es ging also darum, zu einem Pixel (x,y) auf der Bildschirmfläche den entsprechenden Punkt (u,v) auf dem Polygon zu finden.
Uns weiter oben ging es sehrwohl darum, ob irgendwelche Strahlen genutzt werden um zu bestimmen, was zu sehen ist. Ich wollte zeigen, dass das nicht nötig ist, weil man nach der Projektion nur noch 2D Dreiecke malen muss, und das ohne Strahlen. Wenn man erstmal weiß, welche Pixel "angemalt" werden müssen, dann ist die Bestimmung der Helligkeit/Farbe nicht mehr schwer, nämlich einfach mit linearer Interpolation.das Problem ist, dass man für jeden Bildschirmpixel wissen muss, wo er auf dem Polygon liegt.
und damit man was interpolieren kann, braucht man Samplepunkte. Damit jeder im Polygon liegende Pixel korrekt gefärbt wird, sollten das tunlichst die Positionen der Pixelmittelpunkte im Polygon sein. Es ging also darum, zu einem Pixel (x,y) auf der Bildschirmfläche den entsprechenden Punkt (u,v) auf dem Polygon zu finden.
(u,v) ist der entsprechende Punkt auf der Textur, nicht auf dem Polygon.
(u,v) ist der entsprechende Punkt auf der Textur, nicht auf dem Polygon.die Textur ist doch auf dem Polygon?
Es wird ja die Textur gesampled und nicht das Polygon. Außerdem sind ja auch mehrere Texturen möglich. Der Punkt auf dem Dreieck ist (x,y) in Bildschirmkoordinaten.
das Problem ist, dass man für jeden Bildschirmpixel wissen muss, wo er auf dem Polygon liegt.
Es ist schon länger her, dass ich nen Rasterisierer an der Uni schreiben musste, aber das weiß man doch schon vorher, oder nicht? Man macht ja die Transformationen, damit man "einfach" nur noch das Pixelraster drüberlegen muss, d.h. die Koordinaten stimmen mit den Bildschirkoordinaten überein. Wenn ich Pixel (3,3) färben muss, dann liegt er auch in der projezierten Ebene auf (3,3) (oder (3,5, 3,5), wenn man so samplen will).
Es ist schon länger her, dass ich nen Rasterisierer an der Uni schreiben musste, aber das weiß man doch schon vorher, oder nicht? ahja, und zwar woher?
Man macht ja die Transformationen, damit man "einfach" nur noch das Pixelraster drüberlegen muss, d.h. die Koordinaten stimmen mit den Bildschirkoordinaten überein. transformieren kann man nur einzelne Punkte. Man muss also entweder Punkte (x,y) von der Bildschirmfläche in Punkte (u,v) auf dem Polygon transformieren (also für jeden Pixel bestimmen, wo er auf dem Polygon liegt), oder umgekehrt Punkte vom Polygon auf die Bildschirmfläche. Würde man letzteres machen, hätte man das Problem, dass man dazu wissen müsste, welche Punkte man da nehmen muss. Einfach alle geht nicht, da auf dem Polygon überabzählbar unendlich viele sind (das Polygon ist ein Kontinuum von Punkten).
Wenn ich Pixel (3,3) färben muss, dann liegt er auch in der projezierten Ebene auf (3,3) der Bildschirmpixel und die projizierte Ebene liegen beide auf der Bildschirmfläche. Will man aber wissen, wie man einen Bildschirmpixel zu färben hat, muss man wissen, wo sein Mittelpunkt auf dem Polygon liegt.
transformieren kann man nur einzelne Punkte.
Ja, das stimmt, aber da ein Dreieck durch seine 3 Eckpunkte eindeutig definiert ist, reicht es, die 3 Punkte abzubilden. Es werden einmal pro Bild die Abbildungsmatrizen zu einer zusammengefasst und mit der werden sämtliche Dreieckpunkte über Matrixmultiplikation abgebildet.
Will man aber wissen, wie man einen Bildschirmpixel zu färben hat, muss man wissen, wo sein Mittelpunkt auf dem Polygon liegt.
Ja, wenn man weiß, dass der Pixel (5,4) durch ein Polygon gefärbt wird, dann nimmt man als Mittelpunkt zur Berechnung einfach (5,5 , 4,5). Einfach so, ohne irgendeine Berechnung.
roidal
2008-10-27, 16:59:40
Hier gibts einige interessante Infos: http://wiki.delphigl.com/index.php/Feste_Funktionspipeline ;)
Ja, das stimmt, aber da ein Dreieck durch seine 3 Eckpunkte eindeutig definiert ist, reicht es, die 3 Punkte abzubilden. du brauchst für jeden Bildschirmpixel einen Farbwert, also muss sichergestellt sein, dass für jeden Bildschirmpixel was transformiert wird.
Es werden einmal pro Bild die Abbildungsmatrizen zu einer zusammengefasst und mit der werden sämtliche Dreieckpunkte über Matrixmultiplikation abgebildet.das Dreieck hat überabzählbar unendlich viele Punkte, die alle zu transformieren wird ziemlich lange dauern.
Ja, wenn man weiß, dass der Pixel (5,4) durch ein Polygon gefärbt wird, dann nimmt man als Mittelpunkt zur Berechnung einfach (5,5 , 4,5). will man den Bildschirmpixel (x,y) = (5,4) färben, muss man seine Koordinaten (u(5,4),v(5,4)) auf dem Polygon kennen.
Welche Berechnung soll denn einen Mittelpunkt haben, und in welchem Koordinatenraum ((x,y)? (u,v)?) soll dieser Mittelpunkt ein Mittelpunkt sein?
Es wird ja die Textur gesampled und nicht das Polygon. Außerdem sind ja auch mehrere Texturen möglich. die aber alle auf dem gleichen Polygon liegen, so dass ihre Koordinatenräume komplanar sind.
Der Punkt auf dem Dreieck ist (x,y) in Bildschirmkoordinaten.das Dreieck ist ein Objekt im gedachten 3D-Raum, die Punkte des Dreiecks besitzen keine Koordinaten auf der Bildschirmfläche.
Es gibt:
- den gedachten 3D-Raum
- die 2D-Bildschirmfläche, ein 2D-Unterraum des 3D-Raumes
- das Polygon, ebenfalls ein 2D-Unterraum des 3D-Raumes
Der 3D-Raum hat 3D-Koordinaten (x,y,z). Die Bildschirmfläche hat 2D-Koordinaten (x',y'), die man zweckmäßigerweise mit den 3D-Koordinaten für z=0 idenfifiziert: x'=x, y'=y, so dass die Bildschirmfläche durch einen Ausschnitt der Ebene z=0 definiert ist. Die Punkte auf dem Polygon haben 3D-Koordinaten im 3D-Raum sowie 2D-Koordinaten (u,v) auf der Polygonfläche.
Krishty
2008-10-27, 18:31:54
Schade dass ich weg musste und die Diskussion verpasst habe :( Ich wollte doch noch die Rasterization Rules (http://msdn.microsoft.com/en-us/library/bb147314.aspx) einwerfen.
die aber alle auf dem gleichen Polygon liegen, so dass ihre Koordinatenräume komplanar sind.
He? Man kann mit D3D10 bis zu 32 verschiedene Texturkoordinaten interpolieren.
das Dreieck ist ein Objekt im gedachten 3D-Raum, die Punkte des Dreiecks besitzen keine Koordinaten auf der Bildschirmfläche.
Die Weltkoordinaten brauchst du zum rastern auch nicht. Wenn du sie haben willst kannst du sie aber vom Vertexshader ausspucken lassen und dann werden sie auch entsprechend korrekt interpoliert.
Mit (u,v) bezeichnet man Texturkoordinaten. Das was du meinst sind einfach die Bildschirmkoordinaten des Dreiecks. Die nennt man x' oder wie auch immer aber nicht u oder v.
He? Man kann mit D3D10 bis zu 32 verschiedene Texturkoordinaten interpolieren.wo widerspricht das meinem Argument?
Die Weltkoordinaten brauchst du zum rastern auch nicht. war auch keine Rede von. Eher davon, dass ich, wenn ich Polygon sage, ein Objekt im 3D-Raum meine, nicht einen Ausschnitt der Bildschirmfläche.
Mit (u,v) bezeichnet man Texturkoordinaten. und da Texturen auf dem Polygon liegen, ist das mit den Koordinaten auf dem Polygon identisch, von Verschiebungen des Koordinatenursprung auf dem Polygon einmal abgesehen.
Das was du meinst sind einfach die Bildschirmkoordinaten des Dreiecks. da das was ich meine gar nicht auf der Bildschirmfläche existiert, kann es dort auch keine Koordinaten haben.
Nochmal: es existiert ein 3D-Raum mit Koordinaten x,y,z. Die Bildschirmfläche ist ein Ausschnitt der Ebene z=0, mit z.B. x \in [-4,4], y \in [-3,3]. Das Polygon ist ein Ausschnitt einer Ebene
E_Poly: (x,y,z) = (x0,y0,z0) + u (e_ux,e_uy,e_uz) + v (e_vx,e_vy,e_vz)
im 3D-Raum. Das Polygon hat i.a. keine Schnittpunkte mit der Bildschirmfläche, deswegen haben die Punkte des Polygons keine Bildschirmkoordinaten.
Schon klar, aber die Projektion davon hat sehr wohl Bildschirmkoordinaten. Und da die Rasterung eine 2D-Operation ist, ist der Rest völlig egal. Das was du gerade machst ist einfach nur Klugscheißen. Es tut überhaupt nichts zur Sache.
und da Texturen auf dem Polygon liegen, ist das mit den Koordinaten auf dem Polygon identisch, von Verschiebungen des Koordinatenursprung auf dem Polygon einmal abgesehen.
Es ergibt keinen Sinn sich Texturkoordinaten auf dem Dreieck vorzustellen, denn sie sind nunmal Indizes auf die Textur, nicht auf das Dreieck. Einen anderen Zweck haben sie nicht.
Schon klar, aber die Projektion davon hat sehr wohl Bildschirmkoordinaten. von der habe ich aber nicht gesprochen.
Es ergibt keinen Sinn sich Texturkoordinaten auf dem Dreieck vorzustellen, denn sie sind nunmal Indizes auf die Textur, nicht auf das Dreieck. die Textur liegt aber auf dem Dreieck, ihr 2D-Raum ist mit dem des Dreiecks (das Objekt im 3D-Raum, nicht die Projektion auf die Bildschirmfläche) identisch. Ein Punkt im Texturraum ist daher immer ein Punkt auf der Polygonebene.
Nicht immer, da man Texturen auch dynamisch adressieren kann. Texturen können z.B. auch Blickwinkelabhängig sein oder sonstiges. Sogar völlig zufällig verteilte Samples wären möglich, oder das Pixel mal die eine und mal die andere Textur oder gar keine adressieren.
Deshalb finde ich diese Vorstellung hinderlich.
Krishty
2008-10-28, 19:08:54
Entschuldige, hatte ich überlesen:
Aber Krishty's Statement zur Texturfilterung ist trotzdem falsch:
man bestimmt für den Pixel (x,y) den Samplepunkt (u(x,y),v(x,y)), und interpoliert die Farben der Nachbartexel bei (u_i,v_i), (u_i+1,v_i), (u_i+1,v_i+1), (u_i,v_i+1). Von den Nachparpixeln geht da rein gar nichts ein ;)Dann erklär mir mal, woher der Rasterizer weiß, wieviel von der Farbe der Nachbartexel er hineininterpolieren muss. Aus der einen Texturkoordinate kann er nämlich nicht darauf schließen, ob sich die Textur innerhalb des Pixels (dem auf dem Bildschirm) 0.001-fach oder 10-fach wiederholt. Geschweige denn in welche Richtung.
Die Koordinaten werden im Pixelshader – also, wie Coda schon sagte, unabhängig vom Polygon – berechnet. Die Nachbarpixel sind die einzige Möglichkeit für den Sampler, die Änderungsrate zu finden, die er für die Filterung so dringend braucht. Und genau deshalb ist Texturfilterung innerhalb eines if-Statements unmöglich.
Noch was: Du hast jetzt so oft hier gepostet, dass du dich langsam mal anmelden kannst ;)
Entschuldige, hatte ich überlesen:
Dann erklär mir mal, woher der Rasterizer weiß, wieviel von der Farbe der Nachbartexel er hineininterpolieren muss. der zu färbende Bildschirmpixel hat auf den Bildschirm die Koordinaten (x,y). Wie von Coda und mir ausgiebig diskutiert, wird daraus die Lage des Pixelmittelpunktes (u,v) auf den Polygon / der Textur bestimmt, anhand der Funktionen u(x,y), v(x,y). Jetzt wird geguckt, wie weit die Mittelpunkte der vier nächsten Texel,
(u_i,v_i), (u_i,v_i+1), (u_i+1,v_i+1), (u_i+1,v_i), mit u_i < u < u_i+1, v_i < v < v_i+1
entfernt liegen, und entsprechend der unterschiedlichen Entfernungen aus den Farben der vier Texel die Farbe für den Bildschirmpixel zusammengemischt.
Aus der einen Texturkoordinate kann er nämlich nicht darauf schließen, ob sich die Textur innerhalb des Pixels (dem auf dem Bildschirm) 0.001-fach oder 10-fach wiederholt. Geschweige denn in welche Richtung.du meinst, wenn das Polygon sehr weit weg ist, so dass das Urbild des Pixels im Texturraum sehr viele Texel umfasst? Nun, dann hat der von mir beschriebene bilineare Filter ein Problem, dann tritt ohne sonstige Maßnahmen das sogenannten Texturflimmern auf. Dagegen behilft man sich entweder mit MIP-Mapping, so dass die Texel größer sind, oder mit anisotropem Filtern, wo in einer Richtung eine größere Zahl an Texeln berücksichtigt werden.
Und genau deshalb ist Texturfilterung innerhalb eines if-Statements unmöglich.sollte mir das irgendetwas sagen?
Krishty
2008-10-28, 22:52:17
Du redest vom einfachen Filter. Der funktioniert tatsächlich so. Ich spreche von höheren Filtermethoden, insbesondere von den anisotropischen. Da werden gerade nicht einfach nur „mehr“ Texel berücksichtigt, sondern die Projektion des Bildschirmpixels auf die Textur.
Meine Frage also nochmal konkretisiert: Du hast einen anisotropischen Filter auszuführen. Nach deiner Formulierung bekommst du genau eine Texturkoordinate. Mehr nicht, denn von den umliegenden Pixeln hast du, wie du sagst, ja keine Ahnung.
Jetzt erklär mir, wie du den Footprint (die Projektion des Pixels auf den Texel) berechnest. Vor allem wie du berechnest, in welche Richtung sich die Samples ändern. Und komm mir nicht mit Polygonen, denn die Textur wird auf einem flachen Rechteck gerendert und die Texturkoordinaten werden im Pixel-Shader berechnet um dem ganzen einen, sagen wir, Wirbeleffekt zu verleihen.
du meinst, wenn das Polygon sehr weit weg ist, so dass das Urbild des Pixels im Texturraum sehr viele Texel umfasst? Nun, dann hat der von mir beschriebene bilineare Filter ein Problem, dann tritt ohne sonstige Maßnahmen das sogenannten Texturflimmern auf. Dagegen behilft man sich entweder mit MIP-Mapping…Genauso gut. Erklär mir, wie du aus den 2D-Texturkoordinaten berechnest, welche Mip-Map gesampled werden soll (oder, wie du korrekt sagtest, ob „das Urbild des Pixels im Texturraum sehr viele Texel umfasst“). Raten?
sollte mir das irgendetwas sagen?Genau das ist das Problem. Du hast vielleicht vor Jahren mal an der Uni einen Rasterizer mit bilinearem Texturfilter implementiert und – nimm es mir nicht übel, aber – das gibt dir weder Verständnis von Hardware noch vom heutigen Stand der Render-Methoden.
Du redest vom einfachen Filter. sagte ich gegenteiliges?
Meine Frage also nochmal konkretisiert: Du hast einen anisotropischen Filter auszuführen. Nach deiner Formulierungnach meiner Formulierung habe ich einen bilinearen Filter auszuführen, nichts anderes.
Genauso gut. Erklär mir, wie du aus den 2D-Texturkoordinaten berechnest, welche Mip-Map gesampled werden sollergibt sich aus dem z-Wert.
Genau das ist das Problem. Du hast vielleicht vor Jahren mal an der Uni einen Rasterizer mit bilinearem Texturfilter implementiertinteressant, was du so alles über mich zu wissen glaubst.
das gibt dir weder Verständnis von Hardware noch vom heutigen Stand der Render-Methoden.da war ja auch keine Rede von.
Krishty
2008-10-28, 23:34:13
Genauso gut. Erklär mir, wie du aus den 2D-Texturkoordinaten berechnest, welche Mip-Map gesampled werden sollergibt sich aus dem z-Wert.
Troll dich. Für mich hat sich der Thread damit erledigt.
nach Codas Erläuterung ist für jeden Punkt (u,v) der z-Wert bekannt. Kennt man also u und v für einen Bildschirmpixel, weiß man auch den z-Wert, und kann daraus die Mipmap-Stufe entnehmen.
Die Mipmap-Stufe errechnet man nicht aus dem Z-Wert, sondern wird aus den Derivaten der Texturkoordinaten in einem Pixel und damit der ungefähren Fläche eines Texels in einem Pixel. Man braucht kein Z dafür, und es wäre auch nicht möglich es daraus effizient zu berechnen. Deshalb berechnet man pro 2x2 Quad die Änderungsraten. Das hab ich jetzt auch schon 10x geschrieben.
Die LOD-Level wandern deshalb auch mit steigender Auflösung nach "hinten".
Die Mipmap-Stufe errechnet man nicht aus dem Z-Wert, sondern wird aus den Derivaten der Texturkoordinaten in einem Pixel und damit der ungefähren Fläche eines Texels in einem Pixel. Man braucht kein Z dafür, und es wäre auch nicht möglich es daraus effizient zu berechnen. Deshalb berechnet man pro 2x2 Quad die Änderungsraten. Das hab ich jetzt auch schon 10x geschrieben. nochmal: wir sprechen hier nicht davon, wie das auf heutigen Grafikkarten konkret realisiert ist, sondern von den grundlegenden Prinzipien. Krishty's Frage war, wie der Mipmap-Level bestimmt wird, wenn ein bilinearer Filter in der von mir beschriebenen Weise arbeitet, nicht wie es moderne Grafikkarten machen.
Deswegen haben der Threadersteller und sein Kollege auch beide gleichermaßen recht: eine sehr einfache Rasterizer-Methode arbeitet wie Raytracing mit Strahlen, diese wird halt nur auf modernen Grafikkarten nicht eingesetzt.
nochmal: wir sprechen hier nicht davon, wie das auf heutigen Grafikkarten konkret realisiert ist, sondern von den grundlegenden Prinzipien.
Es ist auch so das Prinzip das aus der Änderungsrate zu bestimmen. Auch in Software. Kannst dir gerne jeglichen Sourcecode dazu anschauen. Wenn man keine dependent Lookups hat macht man das aber pro Pixel und nicht aus den Quads. Das ändert aber auch nichts am Prinzip.
Deswegen haben der Threadersteller und sein Kollege auch beide gleichermaßen recht: eine sehr einfache Rasterizer-Methode arbeitet wie Raytracing mit Strahlen, diese wird halt nur auf modernen Grafikkarten nicht eingesetzt.
Kein Rasterizer arbeitet mit Strahlen sonst wäre er keiner. Das ist völlig unnötig und ineffizient und habe ich auch noch nie irgendwo gehört.
insbesondere von den anisotropischen.
anisotrop, ohne -isch.
Kein Rasterizer arbeitet mit Strahlen sonst wäre er keiner. dann nenne mir doch mal die Definiion eines Rasterizers. Nach meinem Verständnis erstellt ein Rasterizer Rastergrafiken, also Grafiken, die aus Pixeln bestehen.
So gesehen wäre im Prinzip auch ein Raytracer ein Rasterizer, da er ja auch Rastergrafiken erstellt. Der Unterschied ist aber, dass ein Rasterizer "passiv" arbeitet, er fragt nur den Farbwert ab, den das Objekt, das den aktuellen Pixel ausfüllt, besitzt. Der Raytracer dagegen ist "aktiv", er bestimmt erst noch den Farbwert, durch fortgesetzte Strahlverfolgung.
Das ist völlig unnötig und ineffizient wieso ist das ineffizient? Da wird einfach der Schnittpunkt einer Geraden (von der Kamera aus durch den Pixel gehend) mit einer Ebene (von der das Polygon ein Ausschnitt ist) bestimmt.
dann nenne mir doch mal die Definiion eines Rasterizers. Nach meinem Verständnis erstellt ein Rasterizer Rastergrafiken, also Grafiken, die aus Pixeln bestehen.
Alle "Rasteralgorithmen" die ich kenne sind 2D-Operationen. Das ist der Konsensus.
wieso ist das ineffizient? Da wird einfach der Schnittpunkt einer Geraden (von der Kamera aus durch den Pixel gehend) mit einer Ebene (von der das Polygon ein Ausschnitt ist) bestimmt.
Was bringt der der Schnittpunkt? Dann müsstest du immer noch den Rest berechnen (LOD-Level, Line-Of-Anisotropy, Texturkoordinaten etc.), und das geht im 2D-Fall viel einfacher und vor allem inkrementell.
Was bringt der der Schnittpunkt? Dann müsstest du immer noch den Rest berechnen (LOD-Level, Line-Of-Anisotropy, Texturkoordinaten etc.), der Schnittpunkt ist der Samplepunkt auf dem Polygon, mit dem habe ich die Texturkoordinaten. Anisotropy interessiert nicht, wir filtern ja bilinear. LOD ergibt sich aus der z-Koordinate des Schnittpunktes.
Der von dir beschrieben Algorithmus macht im Prinzip das gleiche, er benutzt nur ein paar Tricks, um die Rechnung zu beschleunigen, indem er die Funktion u(x,y) und v(x,y) benutzt um die Schnittpunkte mit den Geraden zu berechnen.
der Schnittpunkt ist der Samplepunkt auf dem Polygon, mit dem habe ich die Texturkoordinaten.
Die musst du dann aber auch erst noch berechnen aus der Plane-Equation der Texturkoordinaten. Das ist sehr viel teurer als die Inkremente zu bestimmen.
LOD ergibt sich aus der z-Koordinate des Schnittpunktes.
Nein tut es nicht. LOD ist völlig unabhängig von Z und hat rein etwas damit zu tun wie groß die Texel auf dem Polygon sind. Da spielen noch die Auflösung und die Texturkoordinaten mit rein.
Hab ich auch schon 10x erklärt. Mir geht langsam echt die Lust aus.
Nein tut es nicht. LOD ist völlig unabhängig von Z und hat rein etwas damit zu tun wie groß die Texel auf dem Polygon sind. die Rede war davon, wie man es machen kann, nicht wie es heutzutage i.d.R. realisiert ist.
die Rede war davon, wie man es machen kann, nicht wie es heutzutage i.d.R. realisiert ist.
Es macht niemand so. Es ergibt einfach keinen Sinn.
Es kam ein Kollege ins Forum der behauptet, dass das Rasterizerverfahren
wie es in aktuellen Spielen genutzt wird nur eine abgespeckte Version
von Raytracing ist. So soll der Strahl nur bis zur ersten Kollision laufen und so eine einfache Projektion auf des jeweilige Pixel als Ursprungspunkt durchgeführt (so hab ich das verstanden).
Er sagt der Rasterizer ist eine Unterform des Raytracing.
Ich dagegen behaupte, dass beim Rasterizerverfahren Polygone einfach perspektivisch verzehrt werden und es somit bis auf den gleichen Zweck keine direkte verwandschaft hat.
ja dein freund hat recht. Es bassiert darauf zu testen ob und wo der Strahl das Dreieck trifft, deswegen geht es so massiv parallel.
das ganze hat dabei viele optimierungen,
-z.b. dadurch dass du die projektion von 3d in 2d machst, weisst du sehr genau in welchem bereich die pixel sein koennen, also min und max in jeder achse, du musst also nicht den ganzen bildschirm 'raytracen.
- dadurch dass es eine 2d projektion auf den bildschirm ist, ist der richtungsvector immer 0|0|1, also in die tiefe gehend und der ursprungsvector BildschirmX|BildschirmY|z-egal, du musst also erstmal keinen schnitttest mit der ebene machen die der bildschirm ist, du kannst direkt pruefen ob der ursprung vom strahl (also BildschirmX|BildschirmY|z-egal) im dreieck ist.
- eine gaengige methode ist es pro seite eines dreiecks eine ebene aufzuziehen und die entfernung zur ebene zu berechnen, bzw ob der punkt davor oder dahinter ist, und wieder, weil du in 2d bist, kannst du das sehr sehr vereinfachen. aus ebenen werden geraden (das nennt man dann halfspace test).
- eine andere moeglichkeit ist eine matrix aufzuziehen mittels zwei schenkel des dreiecks und einer normalen. mit einer matrix kannst du dann aus dem 'normalen' koordinatensystem einen punkt ins koordinatensystem des dreiecks transformieren. nimmst du die inverse, kannst du die punkte die du testest ins 'normale' coordinatensystem bringen, wenn der punkt der dabei rauskommt die bedingung erfuellt: x>=0 und y>=0 und x+y<1.f bist du im dreieck. eine optimierte variante davon wird der moeller triangle intersection test genannt.
weil du in 2d bist, hast du wieder viele optimierungsmoeglichkeiten, aus der 3*3 matrix, wird eine 2*2 matrix. die determinante die du fuer die inverse berechnest ist zufaellig das was man auch fuer backfaceculling benutzt, usw usw usw.
also ja, es ist seit etwa RivaTNT so.
aus patentgruenden benutzen dabei alle was anderes (es gibt ja unzaehlige meglichkeiten zu testen ob ein punkt im dreieck ist).
intel kann das mit 3d matrizen -> kein clipping -> aufwendig pro pixel
nvidia kann das mit 2d halfspaces machen -> nearplane clipping -> weniger pro pixel kosten
ati macht es recht trivial mit pixeln -> muss komplett clippen -> sehr einfaches pro pixel testen (vielleicht der grund fuer 6MSAA(?))
mein wissen hab ich nur aus deren papern und patenten, falls die in hardware doch komplett pixel fuer pixel rasterisieren wie es oldschool ist, sorry.
roidal
2008-10-31, 09:53:25
dann nenne mir doch mal die Definiion eines Rasterizers. Nach meinem Verständnis erstellt ein Rasterizer Rastergrafiken, also Grafiken, die aus Pixeln bestehen.
So gesehen wäre im Prinzip auch ein Raytracer ein Rasterizer, da er ja auch Rastergrafiken erstellt. Der Unterschied ist aber, dass ein Rasterizer "passiv" arbeitet, er fragt nur den Farbwert ab, den das Objekt, das den aktuellen Pixel ausfüllt, besitzt. Der Raytracer dagegen ist "aktiv", er bestimmt erst noch den Farbwert, durch fortgesetzte Strahlverfolgung.
wieso ist das ineffizient? Da wird einfach der Schnittpunkt einer Geraden (von der Kamera aus durch den Pixel gehend) mit einer Ebene (von der das Polygon ein Ausschnitt ist) bestimmt.
Der Unterschied liegt darin das ein Raytracer die komplette Szene kennt und somit über Strahlverfolgung bestimmen kann welcher Teil der Geometrie auf den Pixel sichtbar ist. Ein Rasterizer rendert Dreieck für Dreieck, er kennt niemals die ganze Szene, und nach dem Projezieren des Dreiecks an dem er gerade Rendert ist es wesentlich effizienter auszurechnen welchen Pixelbereich es überdeckt um es zu Rasterizieren, als die ganze sichtbare Fläche dafür abzutasten.
ja dein freund hat recht. Es bassiert darauf zu testen ob und wo der Strahl das Dreieck trifft
Nein? Es basiert darauf zu testen, ob ein PIXEL innerhalb eines Dreiecks ist. In all den Verfahren die du beschrieben hast kommt kein Strahl zum Einsatz.
Das mit den Geraden pro Seite aufziehen ist z.B. der Algorithmus von Pineda, da wird nirgends auch nur irgendwo was mit Strahlen berechnet. Rasterisierung ist eine 2D-Operation. Es muss schlicht und ergreifend getestet werden welche Pixel innerhalb der 2D-Kanten des Dreiecks liegen.
ATI macht inzwischen übrigens auch kein normales Clipping mehr. Die Performance bricht nicht mehr ein wenn man sehr viele Dreiecke an den Bildschirmkanten malt ;)
Es ist auf jeden Fall nicht so, dass pro Pixel alle Dreiecke getestet werden ob sie eine Ray-Intersection haben. Es wird immer ein Dreieck nach dem anderen gemalt. Man berechnet auch nicht irgendwie das LOD aus dem Z-Wert. Die Interpolation ist eine reine 2D-Operation. Falls irgendjemand dabei wirklich was mit einer Strahlengleichung aufstellen sollte in Hardware, dann um gleich Clipping usw. durchzuführen.
Krishty
2008-10-31, 14:05:46
Du redest gegen eine Wand… seit drei Seiten schon.
Nein? Es basiert darauf zu testen, ob ein PIXEL innerhalb eines Dreiecks ist. In all den Verfahren die du beschrieben hast kommt kein Strahl zum Einsatz.
ich hatte lediglich gesagt wie man es herleitet.
Das mit den Geraden pro Seite aufziehen ist z.B. der Algorithmus von Pineda, da wird nirgends auch nur irgendwo was mit Strahlen berechnet. Rasterisierung ist eine 2D-Operation. Es muss schlicht und ergreifend getestet werden welche Pixel innerhalb der 2D-Kanten des Dreiecks liegen.
wie ich schon sagte, das ist was am ende Rauskommt.
Es ist auf jeden Fall nicht so, dass pro Pixel alle Dreiecke getestet werden ob sie eine Ray-Intersection haben.
und es wird auch nicht halfspace getestet, sondern nur ein boundscheck gemacht... wenn man die Herleitung weglaesst und nur noch das als richtig ansieht was in hardware gegossen wurde.
Es wird immer ein Dreieck nach dem anderen gemalt.
Jedes dreieck wird gegen alle potentiellen hits getestet, gibt einige raytracer die mehr als nur einen strahl auf einmal testen, manche fangen mit packeten von 256 strahlen an, das sagt noch nicht aus, ob eine unterart von raytracing verwendet wird.
Man berechnet auch nicht irgendwie das LOD aus dem Z-Wert.
bitte? ich sehe keinen zusammenhang.
Die Interpolation ist eine reine 2D-Operation.nur affine rasterisierung.
das meiste ist 3d, weil der raum nach der projektion nicht linear ist und deswegen die schlussendliche projektion pro pixel gemacht wird (bzw kompensiert, wie man es sehen will).
Falls irgendjemand dabei wirklich was mit einer Strahlengleichung aufstellen sollte in Hardware, dann um gleich Clipping usw. durchzuführen.
das haengt vom verwendeten hit-test algorithmus ab. nutzt man z.b. den von mir erwaehnten mit matrizen, kann man das resultierende x und y nutzen um die per-pixel daten auszurechnen, dabei kann man um einiges effizienter sein als 'halfspace', weil es im ganzen algorithmus nur einen einzigen punkt mit division gibt und dieser wird auch nur ein einziges mal pro pixel (und nicht pro pixel * pro interpolator) durchgefuehrt.
Der Unterschied liegt darin das ein Raytracer die komplette Szene kennt und somit über Strahlverfolgung bestimmen kann welcher Teil der Geometrie auf den Pixel sichtbar ist.
hier wird nur die schlussendliche pixelfindung besprochen. die scenenrepresentation muss nicht unterschiedlich sein, ein raytracer kann genau so nur ein array von tris halten und jedes einzeln testen.
Ein Rasterizer rendert Dreieck für Dreieck, er kennt niemals die ganze Szene, und nach dem Projezieren des Dreiecks an dem er gerade Rendert ist es wesentlich effizienter auszurechnen welchen Pixelbereich es überdeckt um es zu Rasterizieren, als die ganze sichtbare Fläche dafür abzutasten.
da hast du recht, deswegen machen das manche raytracer auch, sie merken sich das zuletzt getroffene poly und verwenden es wieder, das ist z.b. beim schattenberechnen oft sehr effizient. manche raytracer projezieren ebenfalls die dreiecke in ebenen, so kann man z.b. weit entfernte schattenwerfer in eine ebene von der lichtquelle aus gesehen kollabieren, muss dann nur einmal pro ebene eine division machen und dann nur noch schauen ob der punkt auf der ebene in einem der dreiecke ist.
Das ist eine gaengie optimierung bei (non-solid)bsp-trees und kann KD-trees manchmal um faktoren outperformen.
Es wird immer ein Dreieck nach dem anderen gemalt. Man berechnet auch nicht irgendwie das LOD aus dem Z-Wert.
Du redest gegen eine Wand… seit drei Seiten schon.
ähm... ihr seid euch hoffentlich bewusst, dass der Gast, der die Postings #59 und #63 erstellt hat, nicht derselbe Gast ist, der die Postings #43, #45, #47 oder #49 erstellt hat.
Schon der Schreibstil ist ein ganz anderer.
dllfreak2001
2008-10-31, 19:14:12
ja dein freund hat recht. Es bassiert darauf zu testen ob und wo der Strahl das Dreieck trifft, deswegen geht es so massiv parallel.
das ganze hat dabei viele optimierungen,
-z.b. dadurch dass du die projektion von 3d in 2d machst, weisst du sehr genau in welchem bereich die pixel sein koennen, also min und max in jeder achse, du musst also nicht den ganzen bildschirm 'raytracen.
- dadurch dass es eine 2d projektion auf den bildschirm ist, ist der richtungsvector immer 0|0|1, also in die tiefe gehend und der ursprungsvector BildschirmX|BildschirmY|z-egal, du musst also erstmal keinen schnitttest mit der ebene machen die der bildschirm ist, du kannst direkt pruefen ob der ursprung vom strahl (also BildschirmX|BildschirmY|z-egal) im dreieck ist.
- eine gaengige methode ist es pro seite eines dreiecks eine ebene aufzuziehen und die entfernung zur ebene zu berechnen, bzw ob der punkt davor oder dahinter ist, und wieder, weil du in 2d bist, kannst du das sehr sehr vereinfachen. aus ebenen werden geraden (das nennt man dann halfspace test).
- eine andere moeglichkeit ist eine matrix aufzuziehen mittels zwei schenkel des dreiecks und einer normalen. mit einer matrix kannst du dann aus dem 'normalen' koordinatensystem einen punkt ins koordinatensystem des dreiecks transformieren. nimmst du die inverse, kannst du die punkte die du testest ins 'normale' coordinatensystem bringen, wenn der punkt der dabei rauskommt die bedingung erfuellt: x>=0 und y>=0 und x+y<1.f bist du im dreieck. eine optimierte variante davon wird der moeller triangle intersection test genannt.
weil du in 2d bist, hast du wieder viele optimierungsmoeglichkeiten, aus der 3*3 matrix, wird eine 2*2 matrix. die determinante die du fuer die inverse berechnest ist zufaellig das was man auch fuer backfaceculling benutzt, usw usw usw.
also ja, es ist seit etwa RivaTNT so.
aus patentgruenden benutzen dabei alle was anderes (es gibt ja unzaehlige meglichkeiten zu testen ob ein punkt im dreieck ist).
intel kann das mit 3d matrizen -> kein clipping -> aufwendig pro pixel
nvidia kann das mit 2d halfspaces machen -> nearplane clipping -> weniger pro pixel kosten
ati macht es recht trivial mit pixeln -> muss komplett clippen -> sehr einfaches pro pixel testen (vielleicht der grund fuer 6MSAA(?))
mein wissen hab ich nur aus deren papern und patenten, falls die in hardware doch komplett pixel fuer pixel rasterisieren wie es oldschool ist, sorry.
;D
Ich glaub ich dreh am Rad.
Ich meine hochgradigen Quatsch rauszulesen.
;D
Ich glaub ich dreh am Rad.
Ich meine hochgradigen Quatsch rauszulesen.
danke sehr freundlich, ich habe mir gerne die zeit genommen fuer den versuch es dir zu eklaeren.
roidal
2008-11-05, 09:06:14
danke sehr freundlich, ich habe mir gerne die zeit genommen fuer den versuch es dir zu eklaeren.
ja dein freund hat recht. Es bassiert darauf zu testen ob und wo der Strahl das Dreieck trifft, deswegen geht es so massiv parallel...
Es geht hier doch darum, das es eben so NICHT funktioniert.
Liszca
2008-11-10, 14:08:35
Es kam ein Kollege ins Forum der behauptet, dass das Rasterizerverfahren
wie es in aktuellen Spielen genutzt wird nur eine abgespeckte Version
von Raytracing ist. So soll der Strahl nur bis zur ersten Kollision laufen und so eine einfache Projektion auf des jeweilige Pixel als Ursprungspunkt durchgeführt (so hab ich das verstanden).
Er sagt der Rasterizer ist eine Unterform des Raytracing.
Ich dagegen behaupte, dass beim Rasterizerverfahren Polygone einfach perspektivisch verzehrt werden und es somit bis auf den gleichen Zweck keine direkte verwandschaft hat.
also ich habe irgendwie das gefühl daß ihr da von zwei verschiedenen sache redet:
einmal der kollision, raycasting und einmal dem rendern eines bildes mit hilfe der rastertechnik.
dllfreak2001
2008-11-12, 10:41:49
Es ging mir nur um das reine rendern und weder um Collision noch Raycasting.
Ein paar Indizien dafür, dass das Rasterizer keine Strahlen verwendet:
Ich meine es ist unlogisch das beim Rasterizer Strahlen verwendet werden.
Zum einen gibt es das Problem, das man bei massiven Overdraw, mit der Strahlentechnologie keine solchen Performance Einbrüche hätte wie es in normalen Spielen geschieht.
Zum anderen würden Grafikkarten schon heute prima raytracingtauglich sein und müssten nicht erst über spezielle Shaderprogramme á la Firestream und Cuda zum Raytracing bewegt werden.
Ein paar Indizien dafür das Raytracing keine Strahlen verwendet:
Du wahrscheinlich meinst Rasterizer?
Ich meine es ist unlogisch das beim Rasterizer Strahlen verwendet werden.
Zum einen gibt es das Problem, das man bei massiven Overdraw, mit der Strahlentechnologie keine solchen Performance Einbrüche hätte wie es in normalen Spielen geschieht.
Zum anderen würden Grafikkarten schon heute prima raytracingtauglich sein und müssten nicht erst über spezielle Shaderprogramme á la Firestream und Cuda zum Raytracing bewegt werden.
Vom Ergebnis her gesehen, könnte man Rasterizer damit beschreiben, dass für das aktuell bearbeitete Dreieck die Intersections mit allen Strahlen von der Kamera aus berechnet werden. Insoweit ist die Aussage nicht völlig verkehrt, dass beide das selbe machen...
Allerdings sind Raycasting und Rasterisierung Bezeichnungen für Algorithmen (mit der selben Aufgabe). Und bei letzterem sind Strahlen einfach nicht vorhanden. Das kann in jeder Beschreibung nachgelesen werden. Warum man nun über Seiten darüber diskutiert ist schwer ersichtlich.
dllfreak2001
2008-11-12, 11:03:44
Ja, sorry... Ich meinte natürlich Rasterizer habs jetzt abgeändert.
Voxel und Elipsoid-Engines zaubern auch 3D-Welten auf den Bildschirm und verwenden keine Strahlen.
roidal
2008-11-13, 10:10:40
Ja, sorry... Ich meinte natürlich Rasterizer habs jetzt abgeändert.
Voxel und Elipsoid-Engines zaubern auch 3D-Welten auf den Bildschirm und verwenden keine Strahlen.
Wie rendert eine Voxel-Engine das Bild? Ich dachte in diesem Fall wird (vorzugsweiße) Raytracing verwendet?
Könnte man machen, aber die ganzen Comanche-Spiele rastern soweit ich weiß von vorne nach hinten.
Hier ist das erklärt: http://www.codermind.com/articles/Voxel-terrain-engine-visibility-occlusion.html
Ein paar Indizien dafür, dass das Rasterizer keine Strahlen verwendet:
Ich meine es ist unlogisch das beim Rasterizer Strahlen verwendet werden.
Zum einen gibt es das Problem, das man bei massiven Overdraw, mit der Strahlentechnologie keine solchen Performance Einbrüche hätte wie es in normalen Spielen geschieht. warum? Ein strahlenbasierter Rasterizer, wie er hier diskutiert wurde, würde ja immer noch Polygone verwenden und Polygon für Polygon einzeln durchgehen. Bei hohem Overdraw, wenn also viele Polygone hintereinander sind, würde jedes Polygon einzeln behandelt werden, was gerade zum Performanceeinbruch führt.
Es war ja keine Rede davon, dass ein strahlenbasierter Rasterizer die Szene als ganzes verarbeiten würde. Und auch nicht davon, dass die Strahlen zum Detektieren von Verdeckungen benutzt würden.
Zum anderen würden Grafikkarten schon heute prima raytracingtauglich sein nicht wirklich. Zum einen bestünde immer noch der Unterschied, dass ein Raytracer die Szene als ganzes verarbeitet, ein strahlenbasierter Rasterizer aber nur Polygon für Polygon.
Zum zweiten würde der strahlenbasierter Rasterizer ja nur den Schnittpunkt jedes Strahls mit dem Polygon berechnen, keine Reflexion des Strahls am Polygon. Zur Erweiterung zum Raytracer müsste man also erstmal Reflexion implementieren.
Allerdings sind Raycasting und Rasterisierung Bezeichnungen für Algorithmen (mit der selben Aufgabe). Und bei letzterem sind Strahlen einfach nicht vorhanden. Das kann in jeder Beschreibung nachgelesen werden. z.B. in welcher?
Warum man nun über Seiten darüber diskutiert ist schwer ersichtlich.vielleicht deswegen:
Vom Ergebnis her gesehen, könnte man Rasterizer damit beschreiben, dass für das aktuell bearbeitete Dreieck die Intersections mit allen Strahlen von der Kamera aus berechnet werden. Insoweit ist die Aussage nicht völlig verkehrt, dass beide das selbe machen...
Es geht hier doch darum, das es eben so NICHT funktioniert.
ich hab es eben deswegen detailiert eklaert wie man die formeln fuer das rasterisieren herleitet, es basiert auf schnitt-tests. es hat sich niemand hingesetzt und gesagt, hey lass uns doch die oder die gleichung nehmen, die muste man irgendwo herleiten. dass es am ende so simpel ist, ist nur noch das resultat, und klar ist es einfacher zu sagen "wir haben hier eine gerade und berechnen auf welcher seite der punkt ist", aber das ist schon das ende der geschichte.
wenn du dir die mathe grundlagen lang genug reinziehst, siehst du dass das ein und das selbe ist.
z.B. in welcher?
Beispiele findet du mit Googlesuche nach "Rasterisierung" oder "Rasterizer".
Alternativ in Grundlagebüchern wie "Realtime Rendering".
vielleicht deswegen:
Ein Rasterizer und ein Raytracer der keine Reflektionen (also nur Primary Rays) berechnet kommen potenziell zum selben Ergebnis. Trotzdem ist es sinnvoll, die Algorithmen zu unterscheiden. Deswegen ist es eher hinderlich beim Rasterizer von Strahlen zu reden, selbst wenn die mathematischen Grundlagen dieselben sind.
Die mathematischen Grundlagen sind eben nicht identisch, nur das Ergebnis
ist ca. das gleiche. Rasterizer sind eine primitive Abstraktion zur Darstellung
dreidimensionalen Contents auf einer 2D-Fläche. Raytracer sind eine iterative
Methode zur Simulation und Darstellung des selbigen Materials auf auf der 2D-Fläche.
Raytracing ist so als ob man bei einer Physikengine versuchen würde ein Kiste
für jedes Atom einzeln zu bewegen, Rasterizer ist eher sowas wie eine boundingbox die die kollision der Kiste definiert.
Raytracing ist also eine Form der Simulation, weniger der Illusion.
Ein Raytracer kann auch mit Polygonen umgehen (tun überdies die meisten),
POV-Ray ist mal ein Gegenbeispiel.
Natürlich sind die mathematischen Grundlagen identisch, es geht um eine Projektion von 3D-Körpern auf ein zweidimensionales Raster (nochmal: ich rede nur von Primary Rays).
Auch Rasterizer sind nicht grundsätzlich auf Dreiecke beschränkt, siehe NV1.
Beispiele findet du mit Googlesuche nach "Rasterisierung" oder "Rasterizer".nein, finde ich nicht. Derartiges hatte ich früher schon versucht, ohne Erfolg. Quellen, wo die Unterschiede zwischen Raytracing und Rasterizing (in fundierter Form, nicht in oberflächlichem Rasterizing-Bash-Stil) dargestellt werden, sind einfach nicht zu finden.
Die mathematischen Grundlagen sind eben nicht identisch, nur das Ergebnis
ist ca. das gleiche. Rasterizer sind eine primitive Abstraktion zur Darstellung
dreidimensionalen Contents auf einer 2D-Fläche. Raytracer sind eine iterative
Methode zur Simulation und Darstellung des selbigen Materials auf auf der 2D-Fläche. XMas sprach von den mathematischen Grundlagen von Strahlen, nicht von Raytracing. Der Einsatz von Strahlen zum Ermitteln der Lage der Bildschirmpixel im Texturraum (in diesem Thread strahlenbasiertes Rasterizen genannt) hat nichts mit der Simulation und Darstellung des Materials zu tun.
Ein Raytracer kann auch mit Polygonen umgehen (tun überdies die meisten),hat jemand gegenteiliges gesagt?
Auch Rasterizer sind nicht grundsätzlich auf Dreiecke beschränkt, siehe NV1.was ist denn mit dem NV1?
NV1 war Rasterizer-Hardware die auf quadratischen Freiformflächen statt auf Dreiecken basierte.
vBulletin®, Copyright ©2000-2024, Jelsoft Enterprises Ltd.