Rasterizer vs Shader

[Digidi]

Ich habe mir noch mal die Nanite Engine anschaut und frage mich immer warum wir auf Shader effekt so abfahren. Etwas was dem Spiel wirklich tiefe und grafischen Vorteil gibt sind fein aufgelöste Geometrien mit schönen Rundungen und Kanten. Richtig aufgefallen ist mir das als die Beleuchtung in der Nanite Engine nicht so Super war (Siehe Bild) Das Bild aber immer noch 1000 mal besser aussah als in anderen Spielen mit gute beleuchtung. Deshalb meine Frage warum entwickelt man Shader Power immer weiter, lässt die Rasterizer aber verhungern mittlerweile?

Quelle und in 4k siehts noch besser aus ;)
https://youtu.be/qC5KtatMcUw?t=180

[Digidi]

Auch bei Ghost of Tshushima zeigt das viel Geometrie viel wichtiger ist als Beleuchtung. Die Beleuchtung ist nicht immer sehr kompel, die Geometrie macht das aber alles mehr als weg.

Niq889DFbkA

[Opprobrium]

BlingBling verkauft sich eben besser als konturiertes, detailverliebtes Design mit Ecken und Kanten. Ist auch weniger aufwändig in der Herstellung :tongue:

[AffenJack]

Ich habe mir noch mal die Nanite Engine anschaut und frage mich immer warum wir auf Shader effekt so abfahren. Etwas was dem Spiel wirklich tiefe und grafischen Vorteil gibt sind fein aufgelöste Geometrien mit schönen Rundungen und Kanten. Richtig aufgefallen ist mir das als die Beleuchtung in der Nanite Engine nicht so Super war (Siehe Bild) Das Bild aber immer noch 1000 mal besser aussah als in anderen Spielen mit gute beleuchtung. Deshalb meine Frage warum entwickelt man Shader Power immer weiter, lässt die Rasterizer aber verhungern mittlerweile?


Erstens sieht die Geometrie auch nur gut aus, da die Beleuchtung durch Lumen ziemlich gut ist. Sonst würdest du die Details der Geometrie gar nicht sehen, da alles im Schatten verschwimmen würde.
Zweitens, weil man den Rasterizer immer weniger braucht. Der Großteil der Geometrie ist Shaderbasiert.

"The vast majority of triangles are software rasterised using hyper-optimised compute shaders specifically designed for the advantages we can exploit," explains Brian Karis. "As a result, we've been able to leave hardware rasterisers in the dust at this specific task. Software rasterisation is a core component of Nanite that allows it to achieve what it does. We can't beat hardware rasterisers in all cases though so we'll use hardware when we've determined it's the faster path. On PlayStation 5 we use primitive shaders for that path which is considerably faster than using the old pipeline we had before with vertex shaders."
https://www.eurogamer.net/articles/digitalfoundry-2020-unreal-engine-5-playstation-5-tech-demo-analysis

Im Moment nutzt man den Rasterizer noch mit, wenn er eh vorhanden ist und kann sich damit etwas Shaderpower sparen. Auf Dauer könnte das auf Pure Compute hinauslaufen.

[RLZ]

Geometrie ist nichts ohne Beleuchtung.

Was ist dann an der Beleuchtung in der Demo nicht besonders gut?

[Digidi]

Man braucht aber für ein Spiel keine komplexe Beleuchtung um es gut aussehen zu lassen. Gerade in Szenen wo Beleuchtung eine untergeordnete Rolle spielt holt die Geometrie einfach mehr raus.

Zudem Verstärkt Geometrie auch einfache Beleuchtungseffekte recht stark.

Nehmen wir mal Fortnite alls krasse Gegenbeispiel. Da kannst du noch so viel Raytracing drauf werfen. Das Spiel sieht dadruch nicht besser aus.
Schau dir dann Ghos of Zushima an, das hat kein Raytracing aber sehr schöne Geometrie. Das sieht immer Top aus.

[starfish]

Hm, natuerlich gibt es ein Wechselspiel zwischen Geometrie und Licht.

Allerdings wundert mich gerade etwas, wieso @Digidi, du denkst, dass Raytracing automatisch etwas mit der Schoenheit eines Spiels zu tun hat. (Ich schliesse das aus den begriffen "Top" und "besser aussehen".)

Generell, glaube ich, gibt es hier auch ein Missverstaendnis.
Der grosse Unterschied szwischen deinen zwei Beispielen, Ghost of Tsushima und der Lumen/Nanite Demo, zumindest in dem Shot auf den du dich beziehst, ist ja, dass der eine Shot, vor allem das Preview Bild des Youtube Videos, sehr viele direkte Highlights hat.

Der Nanite/Lumen Shot lebt aber nahezu zu 100% von indirekter Beleuchtung.

Meine Vermutung ist also, du missinterpretierst das und denkst, das hat etwas mit dem Geometrielevel ansich zu tun.

Aber natuerlich gehe ich absolut nicht mit dieser Aussage hier mit:


Man braucht aber für ein Spiel keine komplexe Beleuchtung um es gut aussehen zu lassen.

Wie gesagt, es ist ein Wechselspiel.

(Sorry, englische Tastatur.)


Edit: Und wenn du denkst, Fortnite haette kein komplexes Beleuchtungssystem, bist du auch auf dem Holzweg. :)

[mboeller]

ich glaube das mit dem Rasterizer vs. Shader solltest du noch mal überdenken. Was haben die ROPs damit zu tun? ;)

Was du meinst ist Polygone <-> Texturen, oder?

Wenn ja, naja das ist historisch so gewachsen.

Polygone =

benötigen vergleichsweise viel Speicherplatz pro Vertex
brauchen viele FLOPs für die Berechnung

Texturen =

sind billig zu speichern, mit S3TC und VQ wurde es dann noch einmal billiger
sind vergleichsweise einfach zu berechnen, und können in 4er Gruppen berechnet werden


Dazu kommt, dass Polygone sehr lange von der CPU berechnet wurden, erst die Geforce 256 hatte dann eine (AFAIR fixed function-) T&L Einheit.

Zuvor wurden Polygone eigentlich immer in der CPU berechnet. Eine Dreamcast zB. hatte dafür extra eine Vectoreinheit mit 1.4 GFlops in der CPU die AFAIR für theoretisch 50Mio, praktisch 5-7Mio Polygone pro Sekunde ausgereicht hat. Bei Micropolygonen wären dass dann 5-7Mio Pixel pro Sekunde. Die GPU schaffte aber 100Mio Pixel pro Sekunde. Bei der PS2 war das Verhältnis sogar noch viel krasser zugunsten der TMUs verschoben.

Erst als die Shader für alles zuständig waren wurde die GPU leistungsfähig genug auch sehr große Mengen an Polygonen zu verarbeiten. Ich denke aber dass die Kompression bei Polygonen immer noch nicht so effizient ist wie bei Texturen, da bin ich mir aber unsicher... man liest auch nahezu nichts darüber.

Ergo basieren viele Rendertechniken aufgrund der Historie auf Texturen und Textur-Ops (Bump-Mapping, Gourad-Shading etc... ) und nicht so sehr auf Polygon-Ops.

Bei den großen Renderfarmen sah es dagegen schon immer anders aus. Stichwort Reyes Rendering bei Lucasfilms/Pixar

[Gipsel]

ich glaube das mit dem Rasterizer vs. Shader solltest du noch mal überdenken. Was haben die ROPs damit zu tun? ;)ROPs haben erstmal nicht viel damit zu tun, weil Digidi ja von Rasterizer geredet hat. Das Rastern (oder auch "scan[line] conversion", ganz old school) machen nicht die ROPs (AMDs Bezeichnung als "Render Backend" ist da eventuell verständlicher [die machen den z-test nach den Shaden und schreiben das Resultat in den Framebuffer], der Rasterizer ist praktisch das Frontend). ;)

Dazwischen regieren die Shader (bzw. kann man den Rasterizer auch rauslassen) und die Nanite Engine macht ja angeblich extrem viel in Compute Shadern, also ohne Rasterizer. Da zählt also vor Allem Shaderleistung (und Speicherdurchsätze und so). Was genau man in Shadern macht (also ob man auf Geometrie oder Pixeldaten rumrechnet), ist der GPU ziemlich egal. Die kümmert primär die Anforderungen an Rechenleistung, Bandbreite, die Zugriffsmuster und Ähnliches.

Und um die Verwirrung komplett zu machen, speichert Nanite die Geometrie nicht in großen Texturen als Datenformat (statt z.B. einem Vertexbuffer, zumindest für die Umgebung, Charaktere werden wohl "klassisch" gerendert)? Die Computeshader lesen die ein, machen ihr Ding und dann geht das zum (Pixel-)Shaden.

===================

@Digidi:
Neuere HighEnd-GPUs, können etliche Milliarden Dreiecke pro Sekunde rastern. Man kann theoretisch in 4K (~8 Millionen Pixel) mehrere Dreiecke pro Pixel mit etlichen hundert Hertz Framerate durch die Rasterizer schleusen. Macht nur keiner, weil dann andere Bottlenecks zuschlagen, wenn man auch noch ein ansprechendes Ergebnis als Bild haben will. ;)

[Digidi]

@Mboller
Ist so wie Gipsel es schreibt

@Gipsel
Es ist ja das lustige das die Nanite Engine einige Aufgaben die eigentlich Predeistiniert sein sollten für das Frontend in die Shader einfach verlagert hat. Das Problem ist, dass das Frontend nicht gut ausgelegt ist für Polygonen die kleiner sind als ein Pixel.

Deshalb auch meine Frage warum man nicht das Frontend noch weiter aufbohrt um noch mehr Polygonen bearbeiten zu können. Statdessen kommen immer mehr Shader hinzu ohne das man von den Shadereffekten einen Grafik Gewinn hat. Statdessen nutzt man die Shader um noch mehr Polygonen bearbeiten zu können?

Da Shader Universell sind und sie wohl mehr Die Fläche einnehmen verschenkt man so wertvollen Platz.

[TheAntitheist]

Auch bei Ghost of Tshushima zeigt das viel Geometrie viel wichtiger ist als Beleuchtung. Die Beleuchtung ist nicht immer sehr kompel, die Geometrie macht das aber alles mehr als weg.

https://youtu.be/Niq889DFbkA
oh mein Yoda, geometrie wichtiger als Licht... Naja wer sowas sagt.

Erst durch gute Beleuchtung wird die Geometrie auch sichtbar und details verschwinden. Wenn nix schatten wirft, siehst du gar gar keine details mehr weil wie in diesem Beispiel die Steine fast einfarbig sind.
In jedem Thread schreibst du echt viel Müll ohne irgendein Wissen über die Themen zu besitzen.
Benenn dich einfach in Jesus um, soviel Glaube wie du hier im Forum versprühst. Mit Wissen hat das echt nix mehr zu tun.

[Digidi]

@TheAntiheist

:facepalm:

Wenn die Geometrie schlecht ist kannst du noch so viele Lichteffekte drauf werfen es sieht immer noch schlecht aus. Siehe Fortnite dem man jetzt Ray Tracin verpasst hat. Statdessen sehen Spiele wie Ghost of Tsushima die viele Geometrie haben aber noch kein Ray Tracing echt bombe aus. Woran das wohl liegen mag?

Auch Filmstudios wie im Nanite Video gesagt hoffen auf viel mehr Geometrie. Geometrie bringt Kontur welche es erst möglich macht Komplexe Shatten zu werfen.

Man Sieht es auch an der neuen PS5 stats mehr Shaderleistung macht man lieber höhren Takt somit erhöht man die Polygonen-Leistung und veringert gleichzeitig die Shaderleistung. PS5 setzt also mehr auf Polygonen als auf Shader...

Ich habe auch nie gesagt das ich alles wissen tue. Ich wollte eine Interssante Diskussion beginnen!

[Rooter]

Ich denke aber dass die Kompression bei Polygonen immer noch nicht so effizient ist wie bei Texturen, da bin ich mir aber unsicher... man liest auch nahezu nichts darüber.Aus der Demoscene kenne ich es so von 64k oder 8k Demos: Komprimierte Polygon-Meshes sind drin aber Texturen müssen procedural berechnet werden.

MfG
Rooter

[Digidi]

@Digidi:
Neuere HighEnd-GPUs, können etliche Milliarden Dreiecke pro Sekunde rastern. Man kann theoretisch in 4K (~8 Millionen Pixel) mehrere Dreiecke pro Pixel mit etlichen hundert Hertz Framerate durch die Rasterizer schleusen. Macht nur keiner, weil dann andere Bottlenecks zuschlagen, wenn man auch noch ein ansprechendes Ergebnis als Bild haben will. ;)

Es gibt aber eine wesentliche Einschränkung. Die Polygonen müssen deutlich größer sein als ein Pixel, dass dies gut Funktioniert und man den Peak erreicht und genau das ist das Problem weshalb Nanite auf Shader schwenkt weil die Polygonen kleienr als Pixel sind und das Frontend hierfür nicht gemacht wurde. Trozdem verwendet man noch das Frontend für die Polygonen die größer sind als ein Pixel. Ist also ein Hybrid.

[Gipsel]

Es ist ja das lustige das die Nanite Engine einige Aufgaben die eigentlich Predeistiniert sein sollten für das Frontend in die Shader einfach verlagert hat. Das Problem ist, dass das Frontend nicht gut ausgelegt ist für Polygonen die kleiner sind als ein Pixel.

Deshalb auch meine Frage warum man nicht das Frontend noch weiter aufbohrt um noch mehr Polygonen bearbeiten zu können. Statdessen kommen immer mehr Shader hinzu ohne das man von den Shadereffekten einen Grafik Gewinn hat. Statdessen nutzt man die Shader um noch mehr Polygonen bearbeiten zu können?

Da Shader Universell sind und sie wohl mehr Die Fläche einnehmen verschenkt man so wertvollen Platz.Auch mit Nanite werden Teile des Bildes weiter klassisch gerendert. Nanite nutzt Computeshader, um aus den extrem hoch aufgelösten Modellen die zu rendernde Geometrie zu erzeugen (praktisch eine Art inverse Tessellation ;)). Man schmeißt nicht einfach Alles blind auf die Hardware (dann würde Shaderleistung[!] und Bandbreite nicht reichen) sondern versucht clever zu sein und das auszuwählen, was man auch sieht. Und wenn man die Daten schon mal in der Hand hat, kann es vom Datenaufwand vermutlich effizienter sein, gleich einen Software-Rasterizer in den Shadern laufen zu lassen und so unnötiges Daten-hin-und-her-Schieben zu vermeiden.
Für die Fläche, die sie einnehmen, sind die Rasterizer schon sehr effizient. Die lohnen sich selbst in Nanite noch für bestimmte Aufgaben (z.B. Charaktere). Intels Larrabee wollte mal komplett in Software rastern. Wir wissen, was draus geworden ist ;). Aber einen Teil der dahinter stehenden Philosophie ist ja nicht falsch. Nur ist das kein Entweder-Oder sondern man sollte situationsabhängig das richtige Verfahren wählen.

Kurz: Hardware-Rasterizer werden uns noch eine Weile erhalten bleiben. Die aber auf Kosten der Shaderleistung unnötig weit auszubauen, bringt auch nicht viel, denn je mehr Dreiecke gerastert werden, desto mehr müssen auch durch die Pixelshader. Sprich, es steigt auch die Anforderung an die Shaderleistung (und an die ROPs und die Bandbreite und so).

[Gipsel]

Es gibt aber eine wesentliche Einschränkung. Die Polygonen müssen deutlich größer sein als ein Pixel,Nein, ein Rasterizer von nV oder AMD kann 1 Dreieck pro Takt rastern (und es gibt mehrere Rasterizer pro GPU), solange es kleiner ist als 8 oder 16 Pixel (und es muß in genau einem Rasterizer-Screen-Tile liegen, was bei sehr kleinen Dreiecken praktisch immer der Fall ist). Größere benötigen mehr Takte. Subpixel-Dreiecke gehen in 1 Takt pro Dreieck durch. Sie belegen aber sozusagen im Pixelshader immer mindestens "Slots" für 4 Pixel (auch bei Subpixelgröße), da kommt die Ineffizienz rein (und man sollte die Datenmenge von Geometrie nicht unterschätzen, für jeden Vertex fällt da eine ganze Menge an, die dann hin und her geschoben werden muß [die Pixelshader brauchen die], bei "fetten" Vertices also mit vielen verknüpften Daten [irgendwo wichtig für ein gutes Renderergebnis], begrenzt das die Rasterleistung).

[pixeljetstream]

Mboeller und Gipsel sprechen die Kernthemen schon gut an.

Es gibt in der Tat nix standardisiertes für Geometrie Kompression (und auch kein equivalent zu mipmaps). Mit den Mesh Shadern ermöglichen wir es den Entwicklern da nun selbst was zu basteln (wie compute arbeitet eine Gruppe von Threads zusammen also kann man eigene Block Kompression sich ausdenken), aber da Epic eine generische Lösung Brauch liegt es nahe direkt in compute auch zu rastern als nochmal Daten zum rasterizer zu schicken.

Ein anderer Punkt der noch nicht genannt wurde ist die Freiheit. Der Hardware rasterizer muss bestimmte Regeln und Präzision exakt einhalten, wenn ich das selbst mache, kann ich domain spezifisch/an mein Problem/meine Daten angepasste Lösung basteln die sich nicht an Standards halten muss. Wie der Pixel entsteht ist komplett in Entwicklerhand, insbesondere kann man approximieren wie man lustig ist, am Ende hat man das temporale AA und die Texturen darüber...

Epic hat mit seinen Tools, dem Editor/Assett Baking... alles in der Hand um end to end die Daten für sich zu optimieren. So eine Infrastruktur gibt es nur bei den großen engine Herstellern.

Ein bisschen ist das beim Hardware raytracing ähnlich. Hier hat man auch den Herstellern in den APIs ermöglicht die Geometrie zu hinterlegen wie immer sie es für nützlich halten. Aber sie müssen immer noch regeln erfüllen (Wasserdicht, Präzision etc.).

Ich empfehle den Vortrag zu Dreams auf der ps4 um zu sehen wie man so Pixel selbst erzeugen kann und was das für Freiheiten in den Ansätzen ermöglicht.

Mich wundert nach all der Zeit noch, warum Du nicht selbst mit OpenGL, webGL etc. mal was umsetzt. Es würde Dir viel mehr helfen als das Pferd von hinten zu zäumen (du gehst gefühlt rückwärts von GPU Architektur papern zu den "einfacheren" Grundlagen von 3D). Dann werden die Zusammenhänge einfach klarer und offensichtlich interessiert es dich ja genug.

[Digidi]

@Gipsel. Die Einschränkung bezog sich auf die Effizienz. Wenn der Rasterizer also ein Polygon bekommt das so groß ist wie ein Pixel, dann spuckt der Rasterizer nicht 16 Pixel aus sonder nur 1 Pixel. Das heißt um den gleichen Pixeldurchsatz zu bekommen bräuchtest du für diesen Fall nun 16 Rasterizer.

[Gipsel]

@Gipsel. Die Einschränkung bezog sich auf die Effizienz. Wenn der Rasterizer also ein Polygon bekommt das so groß ist wie ein Pixel, dann spuckt der Rasterizer nicht 16 Pixel aus sonder nur 1 Pixel. Das heißt um den gleichen Pixeldurchsatz zu bekommen bräuchtest du für diesen Fall nun 16 Rasterizer.Wie gesagt, ist der Rasterdurchsatz prinzipiell ausreichend für mehrere Dreiecke pro Pixel in 4K mit mehren hundert Hertz. Was diese kleinen Dreiecke verursachen, ist eine Verringerung der Shader-Effizienz. Dir geht also irgendwann die Shaderleistung aus und eventuell begrenzt schon vorher wieviel Daten man überhaupt durch die GPU schleusen kann (an jedem Vertex hängen z.B. Daten zum Material, Orientierung im Raum usw., die für die Beleuchtung und damit das Gesamtbild entscheidend sind).
Die Rasterleistung auszubauen ohne daß die Shader quasi proportional mitziehen (wie von Dir vorgeschlagen), bringt also nicht viel.
Oder anders: Deine Prämisse, daß heutige GPUs zu wenig Rasterleistung haben, kann man nicht so ganz stehenlassen.

[Digidi]

@Gipsel
Die Shaderleistung bleibt doch gleich? Ob ich jetzt 1 Pixel ausgebe ober 16 Pixel die zu einem Polygon gehören oder verstehe ich das was falsch? Für das 1 Pixel auch wenn es dann etwas andere Werte für die Gleichung hat muss doch die gleiche Berechnung durchgeführt werden wie für die 16 anderen Pixel? Oder wird für die 16 anderen Pixel das Ergebniss nur 1 mal großflächig berechnet und dann der Wert auf jedes Pixel übertragen?

Zu den kleine Polygonen. Bei mir ist auch noch die Frage offen wie Inneffizent der Rasterizer wird wenn es sich Umdreht und nun mehre Polygonen ein Pixel befeuern. Das dürfte doch auch die Effizienz nochmals erheblich senken?

@Pixeljetstream
Danke für die Info. Aber leider habe ich nicht die Zeit noch die Muse mich da noch tiefer einzuarbeiten. Ich müsste mir hier erst mal 1000 Seiten zu Programmierung von OpenGl etc durchlesen + die Mathematik genau verstehen. Da gehen jahre dafür ins Land nicht umsonst studieren das Leute ;) Ich bin ja sehr Dankbar für das Forum und den Teilnehmern hier welche es packen komplexe Sachverhalten in wenigen Sätzen gut Darzustellen. Also ein Großes Lob and Dich Gipsel und RLZ die hier versuchen komplexes wissen einfach zu vermitteln.

P.s. Das ist so ein bisschen mein Hobby dem nachzugehen und es gibt halt manchmal Fragen die wirklich Offensichtlich sind. Ich Frage mich z.B. Warum man in Fornite RT integriert hat. Das Spiel sah vorher schon wie Grüze aus und jetzt immer noch, weil halt dem Spiel auch offensichtlich Geometrie fehlt. Da fragt man sich halt ob sich das nicht alles in die Falsche Richtung entwickelt....

[Gipsel]

Die Shaderleistung bleibt doch gleich? Ob ich jetzt 1 Pixel ausgebe ober 16 Pixel die zu einem Polygon gehören oder verstehe ich das was falsch? Für das 1 Pixel auch wenn es dann etwas andere Werte für die Gleichung hat muss doch die gleiche Berechnung durchgeführt werden wie für die 16 anderen Pixel? Oder wird für die 16 anderen Pixel das Ergebniss nur 1 mal großflächig berechnet und dann der Wert auf jedes Pixel übertragen?Die erforderliche Shaderleistung pro "Fragment" im Pixelshader bleibt gleich. Aber die Anzahl der Fragments skaliert mit der Anzahl der Dreiecke.
Für große Dreiecke ist Fragment=Pixel fast gültig (außer an den Kanten). Für kleine Dreiecke aber nicht mehr. Kleine Dreiecke erzeugen relativ gesehen mehr Fragments (Minimum 4 pro Dreieck). Hast Du 4 Dreiecke pro Pixel, muß man also (mindestens) 16 Fragments im Pixelshader für einen einzigen Pixel berechnen. Für etwas größere Dreiecke liegt man vielleicht bei 2-3 Fragments pro Pixel (und bei einem bildschirmfüllendem [Postprocessing, heute oft über CS statt PS, aber egal] liegt man bei 1 Fragment pro Pixel). Die benötigte Shaderleistung skaliert also im Grenzfall kleiner Dreiecke exakt linear mit der Anzahl der Dreiecke. Deswegen benötigt mehr Geometrie auch mehr Shaderleistung (nach dem Rasterizer, davor ja sowieso).
Zu den kleine Polygonen. Bei mir ist auch noch die Frage offen wie Inneffizent der Rasterizer wird wenn es sich Umdreht und nun mehre Polygonen ein Pixel befeuern. Das dürfte doch auch die Effizienz nochmals erheblich senken?Der Rasterizer selbst hat eine recht konstante Effizienz pro Dreieck/Vertex (bis zu 8/16 Fragments pro Takt [große Dreiecke] oder 1 Vertex pro Takt [kleine Dreiecke], es limitiert bei kleinen Dreiecken nur irgendwann eventuell die interne Bandbreite wegen der schieren Menge an Vertexdaten [abhängig von deren Menge/Größe], aber nicht der Rasterizer an sich). Das Shading aber nicht. Das wird ineffizient, weswegen man da nach Ansätzen sucht, Mikropolygon-Rendering effizienter zu gestalten (z.B. Verlagerung von Berechnungen aus der Fragmentebene auf die Vertexebene, skaliert dann aber natürlich auch mit der Menge an Geometrie, nur mit anderem Vorfaktor; oder auch Ansätzen ähnlich dem schon erwähnten REYES). Oder man geht auf Raytracing. Das skaliert linear mit der Anzahl der Pixel auf dem Schirm und nur logarithmisch (statt linear) mit der Menge der Geometrie. :lol:

[Digidi]

@Gipsel Danke für die Erklärung macht natürlich Sinn.

Meine frage war etwas unverständlich, sie hätte eher so lauten sollen:
Wenn ich mehre Micropolygonen habe die sich ein Pixel teilen, wie entscheidet denn da der Rasterizer welches Polygon den jetzt ausschlaggeben ist für den Pixel? Oder wird dann ein Mittleres Ergebniss aus den Polygonen gebildet?

[Gipsel]

Meine frage war etwas unverständlich, sie hätte eher so lauten sollen:
Wenn ich mehre Micropolygonen habe die sich ein Pixel teilen, wie entscheidet denn da der Rasterizer welches Polygon den jetzt ausschlaggeben ist für den Pixel? Oder wird dann ein Mittleres Ergebniss aus den Polygonen gebildet?Ohne MSAA gibt es exakt einen Punkt, den ein Dreieck abdecken muß, damit es die Farbe eines Pixels beeinflussen kann (mit MSAA gibt es mehrere Subpixelpositionen, für die das äquivalent gilt). Neuere GPUs können Dreiecke unter Umständen direkt verwerfen, die keinen Einfluß auf die Pixelfarbe haben können (und schaffen dann eventuell gar 2 Dreiecke pro Takt und Rasterizer, wenn die verworfen werden), sonst passiert das erst in den ROPs. Außer man verwendet Features wie conservative rasterization, dann kann man alle Dreiecke/Fragments mitnehmen, die Teil eines Pixels sind, auch wenn sie nicht das Zentrum abdecken (und muß dann z.B. im Shader entscheiden, was man jetzt damit anfängt). Alle Micropolygone nach abgedeckter Fläche gewichtet zusammenzurechnen wäre ganz nett aus Sicht des Antialiasings, aber das gibt die Hardware direkt erstmal nicht her und wäre auch nicht unbedingt kompatibel mit der Funktionalität der ROPs (müßte man sich aber selbst in Software zusammenbauen können, Performance könnte ein Problem werden). Aber AA-Algorithmen versuchen dies zumindest näherungsweise zu tun.

[Digidi]

@Gipsel Danke ich habe es jetzt wohl verstanden ;)

Was ich mich halt immer noch Frage. Warum beginnt man jetzt schon mit Raytracing wenn wir jetzt noch nicht mal Einfach Geometrie simpel beleuchten können?

Müssten wir nicht erst einmal versuchen noch Komplexere Geometrien zu erzeugen?

Egal ob Ray Tracing oder Beleuchtung über Shader die etwas ähnliches simulieren, kann die Beleuchtung ja nie besser sein als die Geometrie, welche ja die Randbedingungen für die Beleuchtung vorgibt.

Die Nanite Engine nutzt ja hauptsächlich alte Light Shading techniken ohne RT und kommt trozdem zu schönen Ergebnissen, weil sie gerade wegen der Geometriinformation auch kleinere Schatten werfen können, wie hier an der Wand (Min 3.42 oder 222 Sekunden)

qC5KtatMcUw

Hier noch ein Video wie die Beleuchtung funktioniert in Nanite (Minute: 4,38 oder 278 Sekunen):
iIDzZJpDlpA

[RLZ]

Egal ob Ray Traing oder Beleuchtung über Shader die etwas ähnliches simulieren, kann die Beleuchtung ja nie besser sein als die Geometrie, welche ja die Randbedingungen für die Beleuchtung vorgibt.
Natürlich kann man mit einfacher Geometrie mit besserer Beleuchtung tolle Grafik bekommen. Was in der Magicavoxel Community (https://twitter.com/hashtag/magicavoxel) gebaut wird, ist für mich teilweise nur mit mindblowing zu beschreiben.

Aber ich schließe mich dem Tenor an, dass du (wie viele andere) das Problem von der falschen Seite anfängst. Es hilft die die Grundkonzepte von der Computergrafik zu verstehen bevor man sich über Hardware Implementierungen Gedanken macht. Richtig gute Erklärungen sind leider sehr rah. Da momentan ja alle Vorlesungen ja könntest du versuchen dir mal eine Grundlagen Vorlesung (https://www.youtube.com/channel/UCS9CFdjdEcq_NhaSFb_P-yA/videos?view=0&sort=da&flow=grid) anzuschauen. Über Mathe, die du nicht verstehst, kann man ja drüberhören, aber meistens gibt es ja eine einfache Erklärung dafür. Besonders die Rendering Gleichung (https://www.youtube.com/watch?v=07cOcFR8rY0) sollte man in Ansätzen verstanden haben.

Die Nanite Engine nutzt ja hauptsächlich alte Light Shading techniken ohne RT und kommt trozdem zu schönen Ergebnissen, weil sie gerade wegen der Geometriinformation auch kleinere Schatten werfen können, wie hier an der Wand (Min 3.42 oder 222 Sekunden)
"Alt". Raytracing auf Dreiecksrepräsentation ist nur eine Möglichkeit für Szenenabfragen. Die kleinen Schatten entstehen aber durch Screenspace Raytracing.

[Digidi]

@RLZ Ich verstehe zwar die Details nicht, aber so ein paar Grundlagen sind selbst leute ohne Studium klar. Z.B. das je komplexer die Geometrie ist, der Schattenwurf komplexer wird. Die ganzen Beleuchtungsgleichungen werden ja mit Variablen aus der Geometrie gefüttert. Die Variablen die von der Geoemtrie kommen haben einen großen Anteil am Endergebniss. Wenn man hier nur Simple Geometrie hat fällt auch das Ende der Beleuchtung simpel aus.

Danke auch den link zu den Vorlesungen (liegt bei mir nun in den Favoriten ;) ) und den Magicavoxel Community aber keine Ahnung ob es an mir liegt aber auch hier finde ich die Voxelreichen Bilder viel schöner wie hier z.B.

https://pbs.twimg.com/media/EiHFsw6WoAIvDz9?format=jpg&name=large
Quelle: https://twitter.com/knosvoxel/status/1306542882615066625

[Gauß]

Einzelne Dreiecke werden bei diesen Techniken in Volumen-Hierarchien in hoher Aufloesung hierarchisch organisiert, sodass Dinge wie Beleuchtung viel genauer erfolgen kann. Ich vermute dass sie da signed distance fields benutzen.

Auch Rasterisierung basiert auf Raycasting/Raytracing der Dreieck-Eckpunkte. Da gibt es keine klare Trennung.

[RLZ]

Ich vermute dass sie da signed distance fields benutzen.
Die Aussage von Epic war: short range im Screenspace, medium Range in Distance Fields, Long Range Voxel (das ist mir etwas zu unspezifisch)

Die ganzen Beleuchtungsgleichungen werden ja mit Variablen aus der Geometrie gefüttert.
Nein.

[Digidi]

Nein.

Nicht? Du brauchst doch die Lage der Fläche(Polygons) um zu wissen wohin der Lichtstrahl wandert?

[RLZ]

Nicht? Du brauchst doch die Lage der Fläche(Polygons) um zu wissen wohin der Lichtstrahl wandert?
Schon, aber es stammt sehr wenig von der Geometrie. Natürlich kann man dann noch mit UVs und so argumentieren, aber für mich sind die nur wieder ein "unwichtiges" Implementierungsdetail.

[pixeljetstream]

Manchmal habe ich das Gefühl eine discord session mit paar interessierten wäre vielleicht was, dann könnte man interaktiv auf fragen mit Zeichnungen eingehen.

Die Beleuchtungskomplexität (was man berechnet) an sich ist unabhängig von der Geometrie. Allerdings helfen gewisse Geometrie Repräsentation verschiedene Berechnungen zu beschleunigen. Die Ansätze die gipsel erwähnt sind wie mip Maps bei 2d Texturen dazu da sowohl Cache effizient zu sein als auch anti aliasing gleich mitzuliefern.

Digidi, deine Aussage “warum macht man raytracing wenn man nicht mal rasterisierung im Griff hat”, ist eher andersrum zu sehen. Man bringt raytracing ins Spiel weil es einige der bekannten Schwächen von Raster umgeht. So ist raytracing schneller als raster wenn es um Micro Polygons geht. Der Aufwand den man betreibt um Raster schnell zu kriegen ist ja auch nicht umsonst. Und es gab ja schon diverse Versuche per hw Beschleunigung voxelisieren etc. es ist also nicht so dass das nicht passiert. Aber bisher kristallisierte sich nix konkretes weiter.

Raytracing mit den Dreiecken zielt darauf ab, mit den gleichen Eingangsdaten wie bei Raster umgehen zu können. Weil wie gesagt auf diese simple Repräsentation aus Index und vertex buffer hat man sich schon einigen können.

Zur Raster Pipeline bei NV (teilweise vereinfacht)

+ Ff Index buffer scannen (PD primitive Distributor)
+ Ff Dreiecksbatches erzeugen
+ hw scheduler verteilt batch an SM (vertex batch braucht freien Speicher im L1 für seine Outputs)

+ Vertex shader warp/wavefront bearbeitet die vertices des batch (ein thread ist ein einzigartiger vertex innerhalb des batch)
+ Ff viewport clipping / culling etc. (VPC viewport clip/cull unit) Feststellen oben Dreieck außerhalb viewport, backfacing oder kleiner als das sampling Grid (die meisten Microtriangles werden hier gekillt)
+ Ff surviving vertex outputs wandern in L2

+ Ff coarse rasterizer in 16x16 granularität, verteilt große Dreiecke (Decken mehrere tiles ab) an N GPCs.
+ Ff zcull oder hiz genannt, verwirft dreieckstile wenn Konservativ nicht sichtbar
+ Ff fine raster, erzeugt pixel Fragmente des Dreiecks ( in 2x2 quads) innerhalb des tiles
+ Ff earlyZ wenn pixel shader z nicht verändert oder per keyword Optin macht, Teste fragment depth, und ignoriere Pixel shader wenn möglich
+ Ff sammle quads für warp/wavefront (Quads können von unterschiedlichen Dreiecken sein)
+ pixel shader warp/wavefront Ausführung. Die helferthreads (quad pixel ohne Dreiecks Abdeckung/coverage) rechnen mit aber Schreiben nicht in Speicher
+ Ff lateZ wenn relevant (zrop)
+ Ff blending/pixel Ausgabe in framebuffer (crop)

Crop und zrop sehen die Pixel tiles daher können die lossless komprimieren und Bandbreite bei Ausgabe sparen. Nach rasterization rules müssen die Operationen mit dem framebuffer in primitive order passieren. Vorher ist Reihenfolge egal.

Die meisten fixed function units haben Kleine FIFO Puffer um immer genug Arbeit zu haben und mehrere Elemente per clock zu schaffen. Sind die Puffer voll können die Units darüber nicht weiter produzieren. Das kann sich immer weiter fortpflanzen. Im Normalfall ist man bei hohen Auflösungen immer pixel shader bound. Ihr seht auch dass der L2 dazu da ist einige Daten zu halten die wegen des dynamischen load balancing später von ein oder mehreren SMs gelesen werden. Auch das lässt sich adaptiv anpassen. Es sind als gefühlt tausende Stellschrauben an denen man drehen kann. Manche halt mehr manche weniger.

Bei tile caching ist die Besonderheit dass wir größere Mengen an Geometriedaten im L2 halten und dann diese Geometrie tile mäßig flushen statt sie direkt über alle tiles im Bild zu verteilen, das erhöht die Wahrscheinlichkeit der Lokalität der Daten. Wie groß das flush tile oder der geometripuffer ist, ist frei Konfigurierbar (das was die Gameready Treiber zum Beispiel nach Spiel optimieren).

Micropolygons sorgen also schon vor der rasterisierung für Probleme. Erstmal scannen und transformieren wir unnötig Dinge die wegfallen. Weil das alles in batches passiert müssen wir aber dennoch für den best case (alle Dreiecke sichtbar) Daten reservieren.
Dann später das Problem was gipsel mit den quads erwähnte. Nur 1 thread von 4 leistet wirklich was.

[no.this.is.patrick!]

https://media.tenor.com/images/27b0cecb0d1f332f75975f3a465fbc7d/tenor.gif

[Digidi]

@Pixeljetstream WoW Danke für die Details und den tiefen einblick.

Als halb Laie ist man halt verwundert. Da kommt Epic mit der UE5 Engine daher und präsentiert eine wirklich Astreine Demo mit vielen Details (Wie gesagt ich liebe schöne Geometrie, das ist mein fable noch vor Beleuchtungseffekten) die auf einer mageren PS5 in 1440p und 30fps(zukunft 60fps) läuft und dann sagt Epic: Wir nutzen das Frontend nicht wir nutzen RT nicht. Da frag ich mich alt warum werfen wir nicht alles über Bord einigen uns auf den UE5 Engine als Standard und bauen nur noch Chips mit massig Shadern.

[pixeljetstream]

@Pixeljetstream WoW Danke für die Details und den tiefen einblick.

Als halb Laie ist man halt verwundert. Da kommt Epic mit der UE5 Engine daher und präsentiert eine wirklich Astreine Demo mit vielen Details (Wie gesagt ich liebe schöne Geometrie, das ist mein fable noch vor Beleuchtungseffekten) die auf einer mageren PS5 in 1440p und 30fps(zukunft 60fps) läuft und dann sagt Epic: Wir nutzen das Frontend nicht wir nutzen RT nicht. Da frag ich mich alt warum werfen wir nicht alles über Bord einigen uns auf den UE5 Engine als Standard und bauen nur noch Chips mit massig Shadern.

Alles ist ein trade-off, das was Epic macht ist auch nicht frei von Problemen. Standards sind halt ein Kompromiss. Und es ist nicht so dass sie gar nicht mehr die Raster Pipeline nutzen.

Ich hab in den anderen Threads dazu schon gesagt, es ist schon ein Sieg der existierenden Fähigkeiten, dass sie das so umsetzen können. Das ist kein Zeichen das was schief läuft. Aber wie ich schon angesprochen habe sie können das weil sie selbst alles in der Hand haben (Content Pipeline etc.) und ihre Kompromisse selbst definieren. Das ist nicht zu vergleichen mit Standards die "atomarer" sind und viele Entwickler mit unterschiedlichen Anforderungen dienen sollen.

Und wir bauen doch eh Chips mit massig Cores, caches etc.

[Badesalz]

Man braucht aber für ein Spiel keine komplexe Beleuchtung um es gut aussehen zu lassen. Gerade in Szenen wo Beleuchtung eine untergeordnete Rolle spielt holt die Geometrie einfach mehr raus.Bin jetzt hin und her gerissen, ob ich die bisherige RT-Beleuchtung als "Effekthascherei" oder "Klappern gehört zum Handwerk" bezeichnen soll.

Allgemein sollte man jede spezielle Funktionseinheit (oder die Fülle derer) die man fortlaufend braucht und die andere Funktionseinheiten entlastet, als gut befinden. RT wird also bleiben und sollte imho weiter Leistungsstärker werden. Und das wird irgendwann auch gut sein, wenn man die Effekte zurückfährt. Auf ein realistisches, natürliches Maß.

Komplexe Ausleuchtung hat aber nicht zwangsläufig etwas mit viel wahrnehmbare Ausleuchtung zu tun. Komplexe Beleuchtung sollte beim Spielen nicht auffallen. Erst bei einer Frameanalyse ;)

Ich mag eigentlich auch nicht, wenn Sachen ZU fotorealistisch aussehen. Der Look eines superben CGI der vergangenen Tage ist mir lieber als quasi interaktiver Film (wenn ihr wisst was ich meine...) Beleuchtung dagegen kann sich ruhig immer mehr dem RL nähern. Das verschlimmbessert nichts, wenn man damit nicht gleich rumhausiert.

[seaFs]

Aus der Demoscene kenne ich es so von 64k oder 8k Demos: Komprimierte Polygon-Meshes sind drin aber Texturen müssen procedural berechnet werden.

MfG
Rooter
Hmm, nicht ganz, denn meistens werden die Meshes auch während der Laufzeit (das Pre-Compute der Demos) erstellt und deformiert. Besonders gut zu sehen bei älteren Intros (64k): hier sind viele Objekte symmetrisch und wiederholen sich oft, was sich leicht in Algorithmen beschreiben lässt.

fr-043: Rove von Farbrausch hat tolle, detaillierte, unterschiedliche Meshes, die allerdings wirklich nur komprimiert, aber nicht zur Laufzeit erstellt wurden, weshalb die Demo "aussieht" wie 64k, in Wahrheit aber über 80MB (hauptsächlich 3D-Modelle) groß ist. Farbrausch selbst sagte, dass es absolut unpraktisch ist, organische, natürlich wirkende Meshes prozedural zu erstellen. Klar, es geht, ist den Aufwand und vor allem den unmenschlichen Zeiteinsatz nicht wert.

[mboeller]

Richtig gute Erklärungen sind leider sehr rah. Da momentan ja alle Vorlesungen ja könntest du versuchen dir mal eine Grundlagen Vorlesung (https://www.youtube.com/channel/UCS9CFdjdEcq_NhaSFb_P-yA/videos?view=0&sort=da&flow=grid) anzuschauen.

ich habe mir gestern den ersten Teil über die BVH-Trees angeschaut.

Eine Frage habe ich aber dazu:
muss der BVH-Tree für jedes Frame neu aufgebaut werden? Oder nur hin-und-wieder?
Oder reicht es, den Sehstrahl-Test (Ray-Intersection) für jedes Frame zu machen?

Wie schnell geht das mit der Erstellung von dem BVH-Tree?

[Gipsel]

ich habe mir gestern den ersten Teil über die BVH-Trees angeschaut.

Eine Frage habe ich aber dazu:
muss der BVH-Tree für jedes Frame neu aufgebaut werden? Oder nur hin-und-wieder?
Oder reicht es, den Sehstrahl-Test (Ray-Intersection) für jedes Frame zu machen?Bei statischer Geometrie (Umgebung) muß man den nicht ändern. Für sich bewegende Dinge muß man den aber natürlich updaten. Auch deswegen dürften z.B. in einigen PS5-Demos einige Objekte gefehlt haben. Alternative für Performanceoptimierung wäre z.B. den für bestimmte Objekte nur jedes zweite Frame oder so zu aktualisieren, womit dann Raytracing für diese Objekte ein wenig Lag hat. Bei bestimmten Sachen fällt das nicht so sehr auf, bei anderen schon.

[pixeljetstream]

Die APIs benutzen zwei Level BVH.
Einer beschreibt die Szene (top Level). Der andere eine Geometrie (bottom level). Im top level sind die Blattknoten Instanzen der bottom level (mit Matrix). Im bottom level die Dreiecke oder Bboxen.

Du kannst also unabhängig updaten und es gibt Updates die ein refit sind und kein voller rebuild.

Paar mehr Infos zu Strategien https://developer.nvidia.com/blog/best-practices-using-nvidia-rtx-ray-tracing/

Mehr aber besser im RT thread
PS: 10 Jahre heute :)

[Digidi]

Hier ein Interessante Beitrag von der PS5 Vorstelltung.

Hier wurde gesagt das dichte/komplexe Geometrie weniger Rechenintensive ist als simple/einfache Geometrie.

Als Beispiel wurde Horizon Zero Dawn genannt, welches nur wenige Polygonen für die Map anscheinend hat, aber die PS4 an den Rand des Powerbudgets bringt.

https://youtu.be/thP02FeGbnU?t=819

[RLZ]

Hier wurde gesagt das dichte/komplexe Geometrie weniger Rechenintensive ist als simple/einfache Geometrie.
Power != "rechenintensiv"

Simple statische Geometrie = CPU Limit komplett weg + GPU kann voll aufdrehen.

[Digidi]

Power != "rechenintensiv"

Simple statische Geometrie = CPU Limit komplett weg + GPU kann voll aufdrehen.
Höhr dir es nochmal genau an es geht um das Layout und warum die PS5 nur 36 Shader aber darfür ein hohne Tackt hat. Man geht auf keinere Polygonen die weniger Shaderefeke bekommen.

https://youtu.be/thP02FeGbnU?t=690

[Gast]

Höhr dir es nochmal genau an es geht um das Layout und warum die PS5 nur 36 Shader aber darfür ein hohne Tackt hat. Man geht auf keinere Polygonen die weniger Shaderefeke bekommen.


Marketingaussage weil man irgendwie erklären muss warum man so viel weniger Leistung als die Xbox hat.

[RLZ]

Man geht auf keinere Polygonen die weniger Shaderefeke bekommen.
Das sagt er auch wieder nicht. Die Hauptaussage ist, dass die Gesamtperformance/Auslastung bei weniger CUs mit höherem Takt besser ist als bei vielen CUs mit wenig Takt und gleichen TFLOPS. Das ist auch der Grund warum es soviel Skepsis gegen die perfekte Skalierung von BigNavi gibt.

[Digidi]

Das sagt er auch wieder nicht. Die Hauptaussage ist, dass die Gesamtperformance/Auslastung bei weniger CUs mit höherem Takt besser ist als bei vielen CUs mit wenig Takt und gleichen TFLOPS. Das ist auch der Grund warum es soviel Skepsis gegen die perfekte Skalierung von BigNavi gibt.

Dann schau dir mal die Specks von Big Navi an das liest sich wie PS5 x2 ;D

[Digidi]

Im übrigen was Marc Cerny gesagt hat nochmals im Text:

But power isn't simply about engine quality it's about the minutiae of what's being displayed and how. its counterintuitive but processing dense geometry typically consumes less power than processing simple geometry which is I suspect why horizons map screen with its low triangle count makes my ps5 pro heat up so much

https://youtu.be/thP02FeGbnU?t=690

Und dann setzt man das noch mit Nanite in Verbindung :rolleyes: Ich bin auf den Power Draw von der Nanite Engine gespannt.

[Digidi]

Was Mark Cerny auch sagt das kleinere Polygonen die CUs gar nicht auslasten und man deshalb auf die geringe CU Zahl gegangen ist:

https://youtu.be/ph8LyNIT9sg?t=1976

Also rechnet Sony in Zukunft mit vielen kleinen Polygonen und wenig Shaderarbeit.

[RLZ]

Wiederholung macht es nicht korrekter. :freak:

[pixeljetstream]

Wiederholung macht es nicht korrekter. :freak:
+1
Die CUs machen ja alles shading (compute etc.) ergo sinkt auch der Peak was man sonst so berechnet. Könnte man ja auch sagen am desktop brauch wir die vielen SMs und CUs nicht ;)
Und gerade nanite was in compute arbeitet würde ja von den Nachteilen kleiner Geometrie in fixed function nicht betroffen.

IMO ist das alles sehr ungünstig ausgedrückt Marketing um ihre Entscheidung mit weniger cus als Xbox zu untermauern. Sie werden für sich und ihre Studios festgelegt haben dass hi clock Design der bessere Kompromiss für sie war und gut. Das ist im Prinzip auch okay aber so pseudo technisches Marketing dazu ist IMO nicht fördernd.

Einfach gesunde Logik, die Berechnungen für die Spiele im ganzen werden nicht weniger... gleichzeitig haben sie im Vergleich zur Xbox in allen fixed Units bei gleicher Anzahl durch den höheren clock nen Vorteil.

[Digidi]

Das Lustrige ist, ich bin ja mal die Patente durchgegangen. AMD hällt ein Patent auf eine Pipline die zwei Rasterizertypen enthält. Eine fürß große Polygonen und eine für Micropolygonen:

https://www.freepatentsonline.com/y2018/0061124.html

Was man so ein bischen rauslesen kann ist das die Shader wohl unnötige Arbeit machen wenn ein normaler Rasterzier Micropolygonen rendert.

Ich bin mir deshlab nicht so sicher ob die Berechnung mit Micropolygonen nicht weniger bzw. Effizienter werden. Durch detallierte Geometrie fällt ja auch Schaderaufwand weg. Der Schatten an den Rändern muss dann viellecht nicht mehr interpoliert werden und hochauflösende Texturen fallen auch weg.

[Ailuros]

Das Lustrige ist, ich bin ja mal die Patente durchgegangen. AMD hällt ein Patent auf eine Pipline die zwei Rasterizertypen enthält. Eine fürß große Polygonen und eine für Micropolygonen:

https://www.freepatentsonline.com/y2018/0061124.html

Was man so ein bischen rauslesen kann ist das die Shader wohl unnötige Arbeit machen wenn ein normaler Rasterzier Micropolygonen rendert.

Ich bin mir deshlab nicht so sicher ob die Berechnung mit Micropolygonen nicht weniger bzw. Effizienter werden. Durch detallierte Geometrie fällt ja auch Schaderaufwand weg. Der Schatten an den Rändern muss dann viellecht nicht mehr interpoliert werden und hochauflösende Texturen fallen auch weg.

Ist zwar eine weitere interessante Idee aber loest IMHO langfristig nichts.

https://forum.beyond3d.com/posts/2138763/

The future is computational pipelines and raytracing, for that it works just fine.

Bis zum Punkt wo wir solche Architekturen sehen, waere eine Moeglichkeit an Geometrie basierendes tiling zu denken.