Archiv verlassen und diese Seite im Standarddesign anzeigen : Ganz grundlegende Frage zu Texturen
Wenn ich das richtig verstehe, werden bei den heute üblichen 3D Graphiken alle Objekte aus Dreiecken zusammengesetzt. Diese Dreiecke sind natürlich durch ihre Eckpunkte definiert. Wenn man sich nun durch eine Szenerie bewegt, die Objekte bewegt oder gedreht werden, berechnet man die neuen Koordinaten der Eckpunkte (wobei man diese 3D Koordinaten dann auf eine Fläche projizieren muss, um ein perspektivisches Bild für den Monitor zu erhalten), verbindet sie wieder und hat das neue Bild.
Und dann werden - wie es immer heißt - die Texturen draufgelegt. Doch diese Texturen müssen ja wohl auch entsprechend gedreht etc. worden sein, damit es paßt. Wieso wird hier also in zwei Schritten vorgegangen: Zuerst Bild ohne Texturen berechnen, dann "drüberlegen". Ich verstehe die Grundidee nicht so ganz.
Könnt ihre eine Seite oder besser noch ein Buch empfehlen, dass die Grundlagen der 3D Graphik - incl. den ganzen Begriffen wie Bump Mapping, Vertex/Pixel Shader etc. - ausführlich erklärt?
x-dragon
2003-08-13, 15:01:07
Vorübergehen erst mal ein paar Links:
Infos zu Pixel- und Vertexshader:
http://www.forum-3dcenter.org/vbulletin/showthread.php?s=&threadid=69559
und hier gibts auch noch einige Infos und Links:
http://www.forum-3dcenter.org/vbulletin/showthread.php?s=&threadid=85817
Es wird "bald" einen 3DC-Artikel geben, der sich mit Texturing genauer beschäftigt (allerdings mit dem Schwerpunkt auf einige Filter, wie BF, TF, 16 sample single clock Fast TF, und AF — alle diese Filter haben schwere Unzulänglichkeiten, was deutlich gemacht werden soll.)
Für Bump Mapping / Pixelshader ist auch was geplant :naughty: aber das dürfte noch ein Weilchen dauern.
Original geschrieben von aths
16 sample single clock Fast TF
nicht 8 sample Fast TF? Für was benötigt man die zusätzlichen Samples? Um die zweite MipMap-Stufe zu "emulieren"?
Quote "repariert".
Original geschrieben von Gast
nicht 8 sample Fast TF? Für was benötigt man die zusätzlichen Samples? Um die zweite MipMap-Stufe zu "emulieren"? U.a. auch, ja, aber nicht nur. Selbst für reines BF würde ich 16 samples vorschlagen :naughty: (wobei es natürlich sinnvoll ist, dann gleich auch TF zu machen. Zumal sich hier TF erzwingen lassen dürfte, ohne dass die Anwendung das unterstützt.)
Original geschrieben von aths
U.a. auch, ja, aber nicht nur. Selbst für reines BF würde ich 16 samples vorschlagen :naughty: (wobei es natürlich sinnvoll ist, dann gleich auch TF zu machen. Zumal sich hier TF erzwingen lassen dürfte, ohne dass die Anwendung das unterstützt.)
Dann aber bitte mit einem besserem Filter als nur einem Box-filter.
Hier ist mal ein Quote von SA :
Once you have enough samples and a good sample pattern, the next source of AA improvement is a better filter.
Using a simple Bartlett filter instead of box filter will offer a good amount of improvement. You get two benefits, more gradations for the same number of samples, and a more correct filter shape. Of course as soon as you go to a wider weighted filter (involving surrounding pixels) you might as well make the weights programmable.
One mistake that many make when they create weighted filter shapes such as Gaussian filters is that they make the weights circularly symmetric around the pixel. This causes the sum of the weights for any particular sample point not to sum to 1/n. This creates uneven sampling which results in such artifacts as wavey edges. To solve the problem, Gaussian filters, windowed sync filters, etc. should not use circularly symmetric weights but should use weights that sum to 1/n for all samples. This results in a 4 sided tent shaped filter with horizontal and vertical silhouettes that are the desired Gaussian or windowed sync shape. Note that box filters and Bartlett filters do not have this problem, all sample weights sum to 1/n since they are not circularly symmetric but are 4 sided.
Ordered grids and staggered grids are easy to use weighted filters with. Programmable sparsely sampled grids are also fairly easy to weight using programmable weights. In this case you have 9 weights per sample in the grid lookup table (1 weight for the center pixel and 8 weights for the adjacent pixels).
When using a broad area filter, its best to apply the filter after the frame buffer is complete so that all the final colors are in the frame buffer. Some of the filter-as-you-go techniques are harder to implement.
hier ist auch noch ein Link :
http://ise.stanford.edu/class/psych221/99/pccchien/800x600/sld008.htm
Demirug
2003-08-14, 10:59:34
Bilinear ist aber ein Tent und kein Box-Filter.
Original geschrieben von Demirug
Bilinear ist aber ein Tent und kein Box-Filter.
ahh.. wusste ich nicht.
Savini
2003-08-15, 00:17:38
Original geschrieben von aths
Es wird "bald" einen 3DC-Artikel geben, der sich mit Texturing genauer beschäftigt (allerdings mit dem Schwerpunkt auf einige Filter, wie BF, TF, 16 sample single clock Fast TF, und AF — alle diese Filter haben schwere Unzulänglichkeiten, was deutlich gemacht werden soll.)
Für Bump Mapping / Pixelshader ist auch was geplant :naughty: aber das dürfte noch ein Weilchen dauern.
Kannst Du dann ein Buch oder Websites empfehlen, die sich mit den Grundlagen der 3D Graphik befassen? Irgendwie bringt es mir nichts, wenn ich spezielle Fragen stelle und das alles nicht im Zusammenhang nachlesen kann.
zeckensack
2003-08-15, 00:45:47
Original geschrieben von Gast
Wenn ich das richtig verstehe, werden bei den heute üblichen 3D Graphiken alle Objekte aus Dreiecken zusammengesetzt. Diese Dreiecke sind natürlich durch ihre Eckpunkte definiert. Wenn man sich nun durch eine Szenerie bewegt, die Objekte bewegt oder gedreht werden, berechnet man die neuen Koordinaten der Eckpunkte (wobei man diese 3D Koordinaten dann auf eine Fläche projizieren muss, um ein perspektivisches Bild für den Monitor zu erhalten), verbindet sie wieder und hat das neue Bild.
Und dann werden - wie es immer heißt - die Texturen draufgelegt. Doch diese Texturen müssen ja wohl auch entsprechend gedreht etc. worden sein, damit es paßt. Wieso wird hier also in zwei Schritten vorgegangen: Zuerst Bild ohne Texturen berechnen, dann "drüberlegen". Ich verstehe die Grundidee nicht so ganz.Stop! :)
Die beiden Schritte laufen eben nicht getrennt ab. Die Eckpunkte enthalten sog Texturkoordinaten, die angeben welche Position der Textur zu dem Eckpunkt gehört. Die Texturkoordinate kannst du dir als Nagel feststellen, der einen Punkt der Textur auf den Eckpunkt nagelt, ganz egal wo der Eckpunkt hingeht.
Texturkoordinaten haben ihren eigenen Koordinatenraum, nämlich die dazugehörige Textur ;)
(0;0) ist zB die linke untere Ecke, (1;1) die rechte obere Ecke. Wenn die Textur unten links schwarz ist, dann kriegt auch ein Eckpunkt, der die Texturkoordinate (0;0) zugewiesen bekommen hat, ein schwarzes Textursample.
Wird das Dreieck nun gedreht oder gestreckt, bleiben die Texturkoordinaten unangetastet. Der schwarze Fleck Textur bleibt also an seinem Eckpunkt hängen, ganz egal wohin dieser sich bewegt. Da auch der Abstand der Eckpunkte voneinander variabel ist, können sich die Texturen 'zwischen den Eckpunkten' natürlich auch strecken und anderweitig deformieren. Das geht dann (in etwa) so:
Die Texturkoordinaten werden über's Dreieck interpoliert, also wenn sagen wir mal Eckpunkt A eine Texturkoordinate von (0 ; 1) und Eckpunkt B eine Texturkoordinate von (0.5 ; 0) hat, dann kriegt der Punkt der in der Mitte zwischen A und B liegt die Texturkoordinate (0.25 ; 0.5).
Das ist nicht ganz richtig, weil die Interpolation perspektivisch korrekt ausgeführt werden muß (und wird), aber für's erste sollte das reichen.
Aber eben: Texturierte Pixel werden nicht in zwei Schritten erzeugt (obwohl man das natürlich machen kann, wenn man denn will, aber ... ... :bäh: ). Der Chip rechnet sich aus, welche Pixel vom Dreieck bedeckt sind, rechnet dann für diese Pixel entsprechend der Interpolation die 'passenden' Texturkoordinaten und erzeugt die zugehörigen Textursamples. Die werden dann im einfachsten Fall direkt als die fertige Pixelfarbe benutzt und erst dann wird der Pixel überhaupt erst rausgeschrieben.
HTH :)
Original geschrieben von Savini
Kannst Du dann ein Buch oder Websites empfehlen, die sich mit den Grundlagen der 3D Graphik befassen? Irgendwie bringt es mir nichts, wenn ich spezielle Fragen stelle und das alles nicht im Zusammenhang nachlesen kann. Es gibt bestimmt gute Bücher, leider kenne ich keins. Was den Zusammenhang angeht, verfolge ich mit den Artikeln die Strategie, dass sie teilweise aufeinander aufbauen. Beispielsweise sind im Filter-Artikel einige der Grundprinzipien zur Texturierung in vereinfachter Form dargelegt http://www.3dcenter.de/artikel/grafikfilter/ Das Problem ist der Spagat zwischen Mathe und Verständnis. So überlege ich ernsthaft, ob ich im neuen Artikel vorrechnen soll, inwieweit MIP-Mapping den Kontrast einer Textur senken kann, oder ob sich der Leser mit der Behauptung abspeisen lässt, das sei tatsächlich so. Jedenfalls, meine früheren Artikel enstanden mit deutlich weniger Wissen meinerseits, dafür sind sie vielleicht leichter zu verstehen (wenn auch an der einen oder anderen Ecke dafür Ungenauigkeiten inkauf genommen werden müssen :sulkoff: )
Abe Ghiran
2003-08-15, 12:04:01
Spontan fällt mir noch ein Artikel von Chris Hecker aus dem Game Developer Magazine ein. Der ist von 1995 und beschreibt en detail wie man texturing in Software macht, enthält also auch die ganze Mathematik die man dafür braucht.
Den Artikel kann man als pdf von Chris Homepage (http://www.d6.com/users/checker/) runterladen, genauer hier (http://www.d6.com/users/checker/misctech.htm).
Vielleicht ist das ja auch noch eine Hilfe.
Grüße, Jan
Savini
2003-08-15, 16:39:39
Original geschrieben von zeckensack
Stop! :)
Die beiden Schritte laufen eben nicht getrennt ab. Die Eckpunkte enthalten sog Texturkoordinaten, die angeben welche Position der Textur zu dem Eckpunkt gehört. Die Texturkoordinate kannst du dir als Nagel feststellen, der einen Punkt der Textur auf den Eckpunkt nagelt, ganz egal wo der Eckpunkt hingeht.
Texturkoordinaten haben ihren eigenen Koordinatenraum, nämlich die dazugehörige Textur ;)
(0;0) ist zB die linke untere Ecke, (1;1) die rechte obere Ecke. Wenn die Textur unten links schwarz ist, dann kriegt auch ein Eckpunkt, der die Texturkoordinate (0;0) zugewiesen bekommen hat, ein schwarzes Textursample.
Wird das Dreieck nun gedreht oder gestreckt, bleiben die Texturkoordinaten unangetastet. Der schwarze Fleck Textur bleibt also an seinem Eckpunkt hängen, ganz egal wohin dieser sich bewegt. Da auch der Abstand der Eckpunkte voneinander variabel ist, können sich die Texturen 'zwischen den Eckpunkten' natürlich auch strecken und anderweitig deformieren. Das geht dann (in etwa) so:
Die Texturkoordinaten werden über's Dreieck interpoliert, also wenn sagen wir mal Eckpunkt A eine Texturkoordinate von (0 ; 1) und Eckpunkt B eine Texturkoordinate von (0.5 ; 0) hat, dann kriegt der Punkt der in der Mitte zwischen A und B liegt die Texturkoordinate (0.25 ; 0.5).
Das ist nicht ganz richtig, weil die Interpolation perspektivisch korrekt ausgeführt werden muß (und wird), aber für's erste sollte das reichen.
Aber eben: Texturierte Pixel werden nicht in zwei Schritten erzeugt (obwohl man das natürlich machen kann, wenn man denn will, aber ... ... :bäh: ). Der Chip rechnet sich aus, welche Pixel vom Dreieck bedeckt sind, rechnet dann für diese Pixel entsprechend der Interpolation die 'passenden' Texturkoordinaten und erzeugt die zugehörigen Textursamples. Die werden dann im einfachsten Fall direkt als die fertige Pixelfarbe benutzt und erst dann wird der Pixel überhaupt erst rausgeschrieben.
HTH :)
Danke! Das hat einiges klarer gemacht. Die Idee hinter den Texturen ist somit, dass man, wenn man z.B. ein bunt gemustertes Dreieck einfach nur um einen bestimmten Winkel drehen will, man die Drehmatritzen lediglich auf die Eckpunkte losläßt und so die Koordinaten des gedrehten Dreiecks bekommt. Die Punkte des Musters müssen aber nicht mit Hilfe von Drehmatritzen transformiert werden, was ja auch enorm viel Rechenaufwand wäre, sondern man geht so vor, dass jeder Punkt des Dreiecks einen Punkt der Textur zugeordnet bekommt und die restlichen dazwischen interpoliert werden. Dies spart dann Rechenzeit en masse, da die Interpolation weniger Aufwand als Matritzenmultiplikation ist.
Stimmt das so?
zeckensack
2003-08-15, 16:48:42
Original geschrieben von Savini
Danke! Das hat einiges klarer gemacht. Die Idee hinter den Texturen ist somit, dass man, wenn man z.B. ein bunt gemustertes Dreieck einfach nur um einen bestimmten Winkel drehen will, man die Drehmatritzen lediglich auf die Eckpunkte losläßt und so die Koordinaten des gedrehten Dreiecks bekommt. Die Punkte des Musters müssen aber nicht mit Hilfe von Drehmatritzen transformiert werden, was ja auch enorm viel Rechenaufwand wäre, sondern man geht so vor, dass jeder Punkt des Dreiecks einen Punkt der Textur zugeordnet bekommt und die restlichen dazwischen interpoliert werden. Dies spart dann Rechenzeit en masse, da die Interpolation weniger Aufwand als Matritzenmultiplikation ist.
Stimmt das so? Japp =)
Zusatz1: Auch die Texturkoordinaten kann man ab erstmal pro Eckpunkt durch eine Matrix jagen, zusätzlich zur Interpolation - jede Textureinheit hat ihre eigene Texturmatrix. Die wenigsten Engines machen aber davon Gebrauch, und wenn, dann nur für Spezialfälle (Projektoren, Shadow Mapping).
Zusatz2: Die Interpolation macht man nicht, weil sie 'billiger' ist als eine Matrixtransformation. Letztere würde erlaubt nur Anpassung der Koordinaten pro Eckpunkt. Irgendeine Form von Interpolation ist vielmehr zwingend erforderlich, um mehr als drei Textursamples auf ein Dreieck zu bekommen. Matrizen hin oder her ;)
Aber ich denke du hast's verstanden :)
Was mir noch eingefallen ist :
was haltet ihr, Aths und Demirug den eigentlich von Forward Image Mapping?
Link : http://www-users.cs.umn.edu/~baoquan/fim/
Das ganze soll eine "billige" Version von AF möglich machen. Billig im Sinne von Hardware und Bandbreite.
vBulletin®, Copyright ©2000-2024, Jelsoft Enterprises Ltd.