Geometry Shader - ja was tun die nun genau?

[MadManniMan]

...um ein für alle Mal die Verwirrung aus der Welt zu schaffen, würde ich Euch bitten, mir und all den anderen un-, bzw. nicht allumfassend Wissenden aufzuzeigen, was es nun genau mit den GS auf sich hat.
Und wenn wir schonmal dabei sind, könnten wir ja auch gleich noch Pixel und Vertex Shader nebenher erklären, damit alles gehäuft zu finden ist, nich?

*über seinen Idee nickend* MFG, Manni

[RLZ]

Der Geometry Shader nimmt ein Grundprimitiv (Line, Dreieck, Dreieck mit Zugriff auf Nachbardreiecke,...) aus dem Vertexshader als Eingabe, darf alles machen was er will und gibt als Ausgabe einen Stream von Primitiven heraus, der entweder gleich gerendert oder in den Speicher gestreamt wird.
Momentan ist der Ausgabestream afaik aus 1024 Werte (nicht Primitive!) beschränkt.

[Monger]

Der Vertexshader kann nur Vertices (=Knoten) manipulieren. Er kann sie zwar verschieben, aber nicht löschen oder neu erzeugen.

Der Geometry Shader dagegen kann Geometrie in der Laufzeit gegen eine andere austauschen. Er kann also z.B. einen Würfel mit zusätzlichen Knoten zur Laufzeit ausstatten, und ihn so in mehrere Teile zerlegen.

Ich denke, physikalische Spielereien werden damit nochmal eine gute Spur spannender. Wie eine Wand bei einer Explosion physikalisch zerbirst, konnte man ja schon vorher berechnen, aber jetzt kann man es auch darstellen.

[MadManniMan]

Danke schonmal! Ja an Physik habe ich auch gleich gedacht - man wäre extrem flexibel und müßte keine Sollbruchstellen mehr festlegen =)

[Monger]

Oder denk an sich verändernde Objekte, z.B. wachsende Bäume. Wenn man vorher sowas machen wollte, musste man im vorneherein eine ausreichende Anzahl an Vertices anlegen, damit man über die Vertexshader das ganze Gebilde quasi "aufblasen" kann.
Mit Geometry Shader kann man tatsächlich bei ganz einfachen Objekten anfangen, und diese nach und nach komplexer machen.
Ich bin mal gespannt, was Spiele daraus in zwei, drei Jahren machen werden.

[MadManniMan]

Aber über die CPU konnte man das doch schon lange machen, oder nicht? Also übern Proz an den VS die neuen Primitive übergeben?

[Monger]

Aber über die CPU konnte man das doch schon lange machen, oder nicht? Also übern Proz an den VS die neuen Primitive übergeben?

Ging schon...

Aber ich glaube, ständig neue Geometrie über die CPU zu erzeugen und zu zerstören, ist ziemlich rechenintensiv.

[RLZ]

Aber über die CPU konnte man das doch schon lange machen, oder nicht? Also übern Proz an den VS die neuen Primitive übergeben?
Ja. Auch wenn die CPU nicht so schnell ist bei entsprechenden Algorithmen.
Ich glaube auch nicht, dass wir mittelfristig viel in der Richtung sehen.
Hauptsächlich wird er wohl für die Beschleunigung und kleinere Effekte genutzt. Der Geometry Shader ist zB in der Lage Dreiecke einzelnen Rendertargets zuzuordnen. So kann man zB eine Cubemap in einem Pass berechnen (=Reduzierung des CPU-Overheads um den Faktor 6).
Microsoft gibt folgendes an:
Algorithms that can be implemented in the geometry shader include:

Point Sprite Expansion
Dynamic Particle Systems
Fur/Fin Generation
Shadow Volume Generation
Single Pass Render-to-Cubemap
Per-Primitive Material Swapping
Per-Primitive Material Setup - Including generation of barycentric coordinates as primitive data so that a pixel shader can perform custom attribute interpolation.

Allerdings befindet sich in der SDK auch schon ein Beispiel für Object-MotionBlur über den Geoshader.

Ich glaube man muss erstmal abwarten, was den Leuten alles für den GS einfällt. ;)

[Simon]

Aber über die CPU konnte man das doch schon lange machen, oder nicht? Also übern Proz an den VS die neuen Primitive übergeben?
Sicher geht das =)

Nur wird ein spezialisierter DSP sowas schneller können als ein General Purpose DSP. Dazu kommt, dass die neue Geometrie dann ja noch aus dem System RAM in den VRAM kopiert werden muss, was auch etwas dauert.
Sehr schön lässt sich das bei den Implementierungen von Particle Systems über die GPU sehen: Soviele Particle könntest du mit einer CPU nicht verwalten (und die hat ja noch mehr zu tun als nur das ;) ).





Ach ja: :uwave:

[MadManniMan]

Ach ja: :uwave:

Mein Spamfilter hat bis heut Nacht(Zitat mein Kopf "Ach da kann man Absender generell zulassen?" nach "Bitte was? 3DCenter als Spam...") dann und wann Benachrichtigungen vom Forum verschluckt - auch alle PM-Nachrichten...

Ergo: ich schreib Dir nachher :D

[Gast]

könnte man damit nicht endlich mal curved-surfaces in hardware realisieren.

[Demirug]

könnte man damit nicht endlich mal curved-surfaces in hardware realisieren.

Das sollte möglich sein.

[Gast]

Das sollte möglich sein.

wird auch mal zeit, schließlich haben wir jetzt schon einige zeit glatte kanten und (mehr oder weniger) scharfe texturen bis in die entfernung, aber noch immer ist das war rund sein soll eckig.

[Coda]

Naja, der kann auch nur Polygone hinten ausspucken, dass heißt es wird auch nur bis zu einer bestimmten Entfernung runder aussehen.

[Gast]

Naja, der kann auch nur Polygone hinten ausspucken, dass heißt es wird auch nur bis zu einer bestimmten Entfernung runder aussehen.

aber es wird doch wohl auch eine art geometrie-lod möglich sein, so dass eine rundung mehr polygone bekommt je näher man herangeht.

außerdem sehen auch texturen nur bis zu einer gewissen entfernung ordentlich aus, wenn man mal rundungen so hinbekommen würde dass sie ab einer ähnlichen entfernung wie bei texturen gut aussehen wäre das ja schon mal nicht so schlecht.

[Coda]

aber es wird doch wohl auch eine art geometrie-lod möglich sein, so dass eine rundung mehr polygone bekommt je näher man herangeht.Hmm. Ja müsste gehen. Der Geo-Shader ist eigentlich schon ziemlich mächtig :)

[Nerothos]

Is' vll ne doofe Frage, aber macht der Geometrie Shader irgendwelche Einheiten "überflüssig", bzw. ersetzt er irgendwelche Einheiten eines heutigen Grafikprozessors? Oder kommt er "hinzu"?
Ich hoffe, es ist verständlich, was ich meine :)

[Coda]

Er kommt hinzu. Sitzt zwischen Vertex- und Pixelshader.

[3d]

ich dachte der vertexshader ist der geometryshader.
sind das zwei verschiedene sachen?
der vertexshader ist doch für geometry zuständig oder nicht?

[Coda]

Ja. Aber nur für Eckpunkte. Der Geometry Shader in DX10 "sieht" das ganze Primitive und kann auch welche entfernen und hinzufügen.

[Benedikt]

Und das, was der Geometry Shader dereinst in GPU-Hardware machen soll, macht jetzt die CPU?
Was sind denn zum Beispiel in derzeitigen Spielen sichtbare Effekte, die der Geometry Shader machen kann und was momentan die CPU machen muss? Konkrete Beispiele?

[ScottManDeath]

Z.b. Generierung der Shadow Volumes bei VertexShader animierten Meshes.

Jeder Cycle, den die GPU der CPU abnimmt, wird von den Devs gierig gleich wieder verbraten :)

[Coda]

Da gibts eigentlich genug. Single-Pass-Cubemap-Rendering, Fur/Fin-Generation, usw.

Es ist halt endlich möglich eine Animation auszuführen und trotzdem danach noch die Geometry zu verändern ohne die CPU für alles in Anspruch zu nehmen.

[eXistence]

Benötigt man einen Geometry Shader nicht auch für Displacement Mapping?
Da müssen ja auch Polygone quasi on-the-fly erzeugt werden...

[Asmodeus]

Benötigt man einen Geometry Shader nicht auch für Displacement Mapping?
Da müssen ja auch Polygone quasi on-the-fly erzeugt werden...

Ja, echtes Displacement Mapping wäre damit dann auch endlich möglich. Außerdem kann der GS sicher für einige nette BRDF- und TangentSpace-Spielereien benutzt werden, da die benötigten Vektoren dann on the fly berechnet werden können.

Gruss, Carsten.

[Gast]

Ja. Aber nur für Eckpunkte. Der Geometry Shader in DX10 "sieht" das ganze Primitive und kann auch welche entfernen und hinzufügen.

dann müsste er doch eigentlich logisch vor dem VS sitzen oder?

wenn der VS nur vertices sieht können doch am output auch nur vertices rauskommen, oder können diese wieder zu primitiven zusammengesetzt werden?

[Coda]

Ja. Ist ja auch korrekt, das aus dem Vertexshader nur Eckpunkte rauskommen. Der Geometryshader berarbeitet dann immer diejenigen die zu einem Primitive zusammengehören nachdem sie aus dem Vertexshader kommen.

[MadManniMan]

Ja. Ist ja auch korrekt, das aus dem Vertexshader nur Eckpunkte rauskommen. Der Geometryshader berarbeitet dann immer diejenigen die zu einem Primitive zusammengehören nachdem sie aus dem Vertexshader kommen.

Summa summarum ist der GS quasi der nächste Schritt vom HW-TnL, hm? Gäbe es nicht sowieso die Entwicklung gen US, würden GS und VS wohl über kurz oder lang zusammenfallen, oder wie?

Nebenbei: was ist eigentlich aus dem "C" von TLC geworden?

[Coda]

Summa summarum ist der GS quasi der nächste Schritt vom HW-TnL, hm?Sozusagen.

Gäbe es nicht sowieso die Entwicklung gen US, würden GS und VS wohl über kurz oder lang zusammenfallen, oder wie?Öh nein. Die API trennt das.

Nebenbei: was ist eigentlich aus dem "C" von TLC geworden?Was ist TLC?

[MadManniMan]

Öh nein. Die API trennt das.

Hm, laß mich raten: GS sind mächtiger als VS, gleichzeitig aber natürlich weniger auf VS-Sachen spezialisiert und dabei langsamer, weswegen spezielle VS natürlich noch Sinn machen?

Was ist TLC?

Der große T&L Hype '99 entwickelte sich aus dem Schlagwort "TLC" - Transform Lighting Clipping ... irgendwann erwähnte das "C" keiner mehr *kopfkratz*

[mapel110]

ehm, irgendwo hab ich aber vor ein paar Tagen gelesen, dass es sehr wohl Sinn macht, VS und GS unified zu bauen, weils sonst zuviele Transistoren kosten würde. Wie die API es sieht, ist ja schnurz.

[zeckensack]

Ja. Ist ja auch korrekt, das aus dem Vertexshader nur Eckpunkte rauskommen. Der Geometryshader berarbeitet dann immer diejenigen die zu einem Primitive zusammengehören nachdem sie aus dem Vertexshader kommen.Das ist nicht unbedingt der einzig wahre Ansatz. Wird ein bisserl schwierig das Ergebnis deterministisch zu kriegen wenn man erst nach Kameratransformation uä ansetzt.
Bei manchen Sachen (LOD durch dynamische "tesselation" [deutscher Begriff?]) will man das, bei anderen (Fraktale ...) eher nicht.

[Coda]

Nein natürlich nicht. Ich weiß auch noch nicht so ganz genau, warum MS den Vertexshader nicht komplett durch den Geoshader ersetzt hat. Im Prinzip müsste er nämlich sämtliche Aufgaben übernehmen können und wenn die Architektur sowieso US wäre es eh Jacke wie Hose.

Der große T&L Hype '99 entwickelte sich aus dem Schlagwort "TLC" - Transform Lighting Clipping ... irgendwann erwähnte das "C" keiner mehr *kopfkratz*Clipping? Das kann jede 3D-Hardware seit Urzeiten.

[zeckensack]

Summa summarum ist der GS quasi der nächste Schritt vom HW-TnL, hm? Gäbe es nicht sowieso die Entwicklung gen US, würden GS und VS wohl über kurz oder lang zusammenfallen, oder wie?IMO nein. VS und PS sind echte Stream-Prozessoren. Für jedes Datum das reingeht kommt immer auch exakt ein Datum raus. Das erlaubt einen ganzen Haufen an Vereinfachungen, und das wird man sicher nicht mal eben über Bord schmeißen.

Bei einem "Geometry Shader" sieht's nämlich ganz anders aus.

*hust*

"Speaking of "every vertex", for every vertex that's coming in, exactly one vertex is going out. Every incoming vertex "triggers" the execution of the vertex shader program, once. The vertex shader can neither create nor discard vertices. It can however output vertex attributes that weren't present in the input data (like adding the color in our lighting example), or output fewer attributes (our second example would only require outputting one resulting position per vertex, even though the vertex shader initially received them in pairs)."

"We'd like to note that the current "fixed function" primitive assembly models are already more flexible than they might look at first glance: these units can discard triangles (for backface culling and zero area triangles) and, in some implementations, create multiple output triangles at once (to support clipping). Most other parts of the graphics pipeline follow the rule "one in, one out", while primitive assembly does not.

In the future we can expect this processing stage to become much more flexible. We're talking about the ominous programmable primitive processor (PPP). This would allow applications to create or remove vertices and triangles, depending on some form of programming, in turn enabling flexible tesselation and geometry compression schemes."

Nebenbei: was ist eigentlich aus dem "C" von TLC geworden?Nur ATI-Chips machen echtes Clipping. Dumme Idee eigentlich, weil schrecklich ineffizient.
http://www.forum-3dcenter.org/vbulletin/showthread.php?p=3882474#post3882474

[Coda]

Anmerkung: Guard-Band-Clipping zähle ich auch zu Clipping.

Und das Patent dafür ist eine Sauerei falls es dieses wirklich gibt. Zecke, hast du auch einen R5xx schonmal gemessen? Immer noch "echtes" Clipping?

[zeckensack]

Anmerkung: Guard-Band-Clipping zähle ich auch zu Clipping.Das kannst du gerne tun, es erfüllt ja auch den gleichen Zweck, nur die Implementation ist eben völlig anders.
Und das Patent dafür ist eine Sauerei falls es dieses wirklich gibt. Zecke, hast du auch einen R5xx schonmal gemessen? Immer noch "echtes" Clipping?Stefans x1300 (http://www.forum-3dcenter.org/vbulletin/showthread.php?p=3882656#post3882656) und Crushis x1600 (http://www.forum-3dcenter.org/vbulletin/showthread.php?p=4001769#post4001769) zeigen Ergebnisse die typisch für geometrisches Clipping sind.

[Coda]

Ich hätte wirklich nicht gedacht, dass das heute noch jemand so macht. Anscheinend sind aber die FIFOS zwischen Vertex- und Pixelshadern groß genug um das nicht zum Bottleneck werden zu lassen.

[Demirug]

Das ist nicht unbedingt der einzig wahre Ansatz. Wird ein bisserl schwierig das Ergebnis deterministisch zu kriegen wenn man erst nach Kameratransformation uä ansetzt.
Bei manchen Sachen (LOD durch dynamische "tesselation" [deutscher Begriff?]) will man das, bei anderen (Fraktale ...) eher nicht.

Man kann im GS ohne Probleme auf die erzeugten Verticen noch ein Vertex Shader "programm" anwenden bevor sie ausgegeben werden. Ursprünglich war ja noch ein zweiter VS nach dem GS vorgesehen. Das hat man dann aber wieder verworfen nachdem der GS zu einem vollwertigen Shader geworden ist.

[Demirug]

Ich hätte wirklich nicht gedacht, dass das heute noch jemand so macht. Anscheinend sind aber die FIFOS zwischen Vertex- und Pixelshadern groß genug um das nicht zum Bottleneck werden zu lassen.

ATI hat IMHO immer noch einen Linewalker Rasterisierer. Das Verfahren funktiontiert nicht so ohne weiteres mit unlimitierten Guardbands.

[Corrail]

kurze Frage, hat der Geometry Shader Zugriff auf Texturen?

[Demirug]

kurze Frage, hat der Geometry Shader Zugriff auf Texturen?

Ja natürlich.

[MechWOLLIer]

Wird dadurch VTF nicht unnötig oder verdrehe ich da was?

[Neomi]

Wird dadurch VTF nicht unnötig oder verdrehe ich da was?

VTF wird durch den Texture Fetch im Geometry Shader nicht unnötig, weil dieser Texture Fetch ebenfalls VTF ist.

[Coda]

Wenn nVIDIA keinen Unified Shader bringt bin ich ja mal gespannt ob wenigstens die TMUs gemeinsam verwendet werden.

[Gast]

kurze Frage, hat der Geometry Shader Zugriff auf Texturen?Sollte er, ja. Bei D3D10 kann ATI hier wohl auch kaum Transistoren sparen, wie sie es beim R520/R580 mit dem Texturzugriff für den Vertexshader gemacht haben.

[Gast]

Oops, hab ich doch glatt übersehen, dass der Thread schon eine Seite mehr hat und die Frage schon beantwortet wurde. Sorry.

[Coda]

Sollte er, ja. Bei D3D10 kann ATI hier wohl auch kaum Transistoren sparen, wie sie es beim R520/R580 mit dem Texturzugriff für den Vertexshader gemacht haben.Das brauchen sie auch nicht, weil R600 sehr sehr wahrscheinlich ein Unified Shader wird und damit haben alle Shader automatisch die Möglichkeit eines Texturzugriffs.

[Gast]

Das brauchen sie auch nicht, weil R600 sehr sehr wahrscheinlich ein Unified Shader wird und damit haben alle Shader automatisch die Möglichkeit eines Texturzugriffs.Ah ja, das leuchtet ein. :)

[MechWOLLIer]

VTF wird durch den Texture Fetch im Geometry Shader nicht unnötig, weil dieser Texture Fetch ebenfalls VTF ist.
Die Frage habe ich wohl etwas undeutig formuliert.
Ich meinte, ob man generell noch VTF im Vertex-Shader braucht, wenn man einen Geometry-Shader hat, der das selbe kann.
Ok, ATi kann das egal sein, aber nVidia...

[Coda]

nVIDIA wird Geo- und Vertexshader zusammenlegen, da bin ich mir 90% sicher. Alles andere wäre eine wahnsinnige Transistorverschwendung.

[Neomi]

Die Frage habe ich wohl etwas undeutig formuliert.
Ich meinte, ob man generell noch VTF im Vertex-Shader braucht, wenn man einen Geometry-Shader hat, der das selbe kann.
Ok, ATi kann das egal sein, aber nVidia...

Das wäre wohl extrem ineffizient. Stell dir einfach mal ein Gitter vor, das aus 10*10 Quads besteht.

10*10 Quads = 200 Dreiecke
11*11 Vertices = 121

Was man im Vertex Shader berechnen kann, muß man einmal pro Vertex machen, da das Ergebnis dann (je nachdem, wie die Dreiecke optimiert wurden) evtl. aus dem Vertex Cache kommt. Im Optimalfall hier also 121x VTF (1x pro Vertex). Der Geometry Shader müßte das dann für alle drei Eckpunkte jedes Dreiecks ausführen, er kann keine Zwischenergebnisse von anderen Dreiecken wiederverwenden. In dem Fall wäre das also 600x VTF, knapp 5 mal so viel wie nötig. Deshalb sollte man tunlichst vermeiden, etwas im GS zu berechnen, was man auch schon im VS erledigen kann.

[Demirug]

Die Frage habe ich wohl etwas undeutig formuliert.
Ich meinte, ob man generell noch VTF im Vertex-Shader braucht, wenn man einen Geometry-Shader hat, der das selbe kann.
Ok, ATi kann das egal sein, aber nVidia...

Die Spec schreibt vor das alle 3 Shader funktional gleich sind. Man VTF wobei das bei D3D10 eher VMF ist unterstützen. Zudem wenn man nur einen Wert pro Vertex braucht und keine zusätzliche Geometrie erzeugen will barucht man ja auch keinen GS.

[Xmas]

Nein natürlich nicht. Ich weiß auch noch nicht so ganz genau, warum MS den Vertexshader nicht komplett durch den Geoshader ersetzt hat. Im Prinzip müsste er nämlich sämtliche Aufgaben übernehmen können und wenn die Architektur sowieso US wäre es eh Jacke wie Hose.
Hier gilt sowohl das von Neomi gesagte (wieso sollte man Eckpunkte mehrfach transformieren?) als auch der Kommentar von zeckensack: Die variable Anzahl an Outputs des GS, die aber trotzdem in ihrer logischen Reihenfolge bleiben müssen, bringt gewisse Probleme bei der Parallelisierung der Berechnung.

Clipping? Das kann jede 3D-Hardware seit Urzeiten.
Voodoo 1/2/Banshee konnten es nicht. Der Versuch, mit Glide Dreiecke zu malen die teilweise außerhalb des Bildschirms lagen, führte bei meiner Banshee unweigerlich zum Absturz.

[betasilie]

Benötigt man einen Geometry Shader nicht auch für Displacement Mapping?
Da müssen ja auch Polygone quasi on-the-fly erzeugt werden...
Die Frage kam mir bei dem Thema auch sofort in den Kopf. ... und wurde ja geklärt. :)

P.S.
Thx @ Manni für den Thread. (y)

[betasilie]

nVIDIA wird Geo- und Vertexshader zusammenlegen, da bin ich mir 90% sicher. Alles andere wäre eine wahnsinnige Transistorverschwendung.
Die Trennung in der API wird hoffentlich in Hardware nicht vollzogen, von keinem IHV. Aber wer weiß, wie weit die IHVs sind, einen GS effizient zu machen, der GS und VS vereint. Vielleicht gibt es da ja Probleme, zumindest bei einem der großen IHVs.

[The_Silent_One]

Man VTF wobei das bei D3D10 eher VMF ist unterstützen.
Bitte nicht haun, wenn diese frage doof erscheint. aber was ist vtf und vmf?

[Demirug]

VTF steht für Vertex Texture Fetch und bedeutete das man im Vertex Shader auf Texturen zugreifen kann.

VMF steht für Vertex Memory Fetch. Das ist eine allgemeinere Form des VTF da man hier nicht zwingend auf Texturen begrenzt ist.

[Gast]

*Thread raukram*

Habe mir gerade mal meine Gedanken zum Geometry-Shader gemacht und ich verstehe irgenwie die Aussage nicht, dass das tolle am Geometry-Shader ist, dass man endlich auch Geometrie hinzufügen oder eliminieren kann.

Dank der Direct3D10 API verfügen doch alle Shader über den gleichen Befehlsatz, oder nicht? Dann müsste doch der Vertex-Shader mit D3D10 auch in der Lage sein Geometrie hinzuzufügen und zu eliminieren. Dann wäre das ja kein Punkt dem man den GS zurschreiben müsste sondern eher der D3D10-API. Oder steh ich hier grad voll auf dem Schlauch?

Unterscheiden sich die Shader auf Software-Basis eigentlich dann nur noch durch den Input? Der Befehlssatz ist ja gleich, weiß irgendwie nicht was sich sonst noch unterscheiden sollte...

[Xmas]

Dank der Direct3D10 API verfügen doch alle Shader über den gleichen Befehlsatz, oder nicht? Dann müsste doch der Vertex-Shader mit D3D10 auch in der Lage sein Geometrie hinzuzufügen und zu eliminieren. Dann wäre das ja kein Punkt dem man den GS zurschreiben müsste sondern eher der D3D10-API. Oder steh ich hier grad voll auf dem Schlauch?

Unterscheiden sich die Shader auf Software-Basis eigentlich dann nur noch durch den Input? Der Befehlssatz ist ja gleich, weiß irgendwie nicht was sich sonst noch unterscheiden sollte...
Der Befehlssatz ist eben doch nicht wirklich gleich. Nur der GS kann Primitive Streams erzeugen, nur der Pixelshader kann ddx/ddy und Texturen ohne LOD/Gradienten samplen. Und natürlich sind auch die Inputs und Outputs anders.

[fl_li@work]

VTF steht für Vertex Texture Fetch und bedeutete das man im Vertex Shader auf Texturen zugreifen kann.

VMF steht für Vertex Memory Fetch. Das ist eine allgemeinere Form des VTF da man hier nicht zwingend auf Texturen begrenzt ist.

Wieso müssen VS und GS zugriff auf die Textur haben? Wird die nicht erst später darüber "geglätet"? (ich bin ein unwissender, ich weiss :'( )

[Gast]

Das ist "neu". Damit kannst du zum Beispiel Geometrie mithilfe einer Height-Map verändern (Displacement Mapping) und solche Dinge.

[fl_li]

Der VS kann ja Eckpunkte nur verschieben, der GS kann welche erzeugen und entfernen. Soweit richtig, oder?

Meine frage ist aber, wieso muss der GS zugriff auf eine Textur haben? Die Textr wird doch dann später über die Polygone "gezogen". (oder? :| )

[Gast]

Texturen können auch einfach Eingabedaten für beliebige Operationen sein.

[Gast]

Wieso müssen VS und GS zugriff auf die Textur haben? Wird die nicht erst später darüber "geglätet"? (ich bin ein unwissender, ich weiss :'( )

eine textur ist nicht zwangsweise ein bild, sondern im prinzip nur ein 2-dimensionales array mit vektorelementen.

diese vektorelemente können alles mögliche repräsentieren und auch als look-up-table dienen.

[fl_li]

eine textur ist nicht zwangsweise ein bild, sondern im prinzip nur ein 2-dimensionales array mit vektorelementen.

diese vektorelemente können alles mögliche repräsentieren und auch als look-up-table dienen.

Danke, jetzt ist der Euro gefallen. =)

[Gast]

Was mir gerade noch einfiehl:

Truform konnte ja auch schon Eckpunkte erzeugen.

Könnte man also Truform als einen (beschränkten) Vorgänger des Geometrie Sharders sehen?

[fl_li]

Was mir gerade noch einfiehl:

Truform konnte ja auch schon Eckpunkte erzeugen.

Könnte man also Truform als einen (beschränkten) Vorgänger des Geometrie Sharders sehen?

Diese Überlegung stammt von mir, hatte keinen Keks...:redface:

[Coda]

Schlechter Vergleich, da Truform nicht programmierbar war. Der GS kann aber sowas wie Truform erzeugen, falls gewünscht.