ZFX + Developia

Mühsam ernährt sich das Eichhörnchen...

Ich habe den Renderingalgo nochmal etwas umgestellt und verbessert. Das Clipping geht nun auch, dabei clippe ich nur die Kanten, dessen Vertex unter Z<0.01 fällt. Bisher scheint es gut zu gehen.

Auf dem Bild sieht man 1024 (übereinander) gezeichnete Boxen, die in einen 455x256 gerendert werden. Das ganze läuft in 5 ms ab. Da ich nicht wirklich einen Vergleich habe und ich denke, dass das schon recht schnell ist, belasse ich es erstmal dabei. Allerdings muss ich noch irgendwie die Tiefe mit rein bekommen, die habe ich noch vernachlässigt. Aber auch da reicht ja dann was approximiertes.

Da stellt man dann Byte auf Single um, damit man schon mal in Richtung DepthBuffer gehen kann. Baut nochmal ein paar Checks ein, um ein paar Ausnahmen abzufangen usw. und schon ist man bei dem 10 fachen der Renderingzeit für die Boxen. Und da hab ich noch keine Ahnung, wie man dann letztendlich die tiefe für die Box berechnet... man könnte auch auf Dreiecke umsteigen, aber dann müsste im worst case 6 Dreiecke statt eine Box rastern... ich will gar nicht wissen, was das dann alles für overhead ist.
Wenn man für die Box nur die entfernteste Tiefe oder so nimmt, dann hat man gerade bei den großen bzw. langen Boxen dann das Problem, dass die vieles nicht cullen würden.

Ich hoffe ja mal, dass das wirklich Sinn macht am ende, was ich mir hier zurecht knobel :D

Hier wird nun zu jedem Vertex der Z-Wert im Homogenous-Space über das Y zu jeder Kante Interpoliert... beim rastern der Scanlines dann werden die Werte dann über X interpoliert. Man bekommt quasi dann in etwa die diagonale Plane innerhalb des Würfels. Ist halt sehr getrickst, aber bestimmt schneller, als es in Dreiecke zu splitten. Eigentlich sollte man das auch hinterher auf Bytewerte speichern können, weil die Tiefe ja eh nur ungefähr drin sein muss und für die Occluder aktuell sowieso nur die betrachtet werden, dessen Mittelpunkt < 24 Units Abstand zur Kamera haben.

Sorry, wenn ich noch einmal dumm frage, aber... das was du jetzt machst sind vor allem Tests? Oder machen diese Occluder bereits Sinn? Ich habe deinen Post zum Occluder berechnen noch einmal gelesen und wurde nicht schlau daraus.
Ich habe vom ganzen zu wenig Ahnung, aber ich hätte mir vorgestellt, dass man zuerst den Vordergrund rendert. Dieser Vordergrund könnte ja bereits die Silhouette sein, oder nicht?

Sieht auf alle Fälle kompliziert aus, aber du kriegst das sicher hin!

Huhu! Kein Problem wenn du fragst, ich versuche es gerne zu erklären! :D Ist auch alles nicht so trivial wenn man da nicht so in der Materie ist... und mal abgesehen davon, dass ich sicher auch nicht ganz so optimal erkläre, erschließen sich ja auch manche Zwischenschritte nach außen hin überhaupt nicht, weil ich die eben für mich alleine betrachte.

Also nochmal kurz, worum es beim Occlusion Culling geht:
Am ehesten zu Vergleichen ist das mit dem Frustum Culling. Ganz prinzipiell schickt man Objekte zur Grafikkarte, die dann gerendert werden. Jedes Objekt kostet natürlich Rechenleistung, bestehend aus zumeist tausenden von Dreiecken müssen die alle von 3D nach 2D umgerechnet werden um dann dessen Pixel zu malen. Selbst wenn die dann z.B. hinter der Kamera liegen und gar nicht sichtbar wären. Nun wäre die erste Überlegung zu schauen, ob ein Objekt überhaupt im Viewfrustum der Kamera ist, bevor man die Grafikkarte darauf loslässt. Allerdings ist die Grafikkarte sehr gut in dem, was sie tut, deswegen würde es tausendfach länger dauern, wenn man nun jedes Dreieck vorher per CPU prüft, als wenn man es einfach von der Grafikkarte rendern lässt.
Also wird approximiert. Statt das Objekt wird nur noch dessen Boundingbox betrachtet. Mit relativ weniger Rechenaufwand kann man nun schauen, ist die Objektboundingbox überhaupt im Kamerasichtfeld. Das absurde ist, dass selbst dieser kleine Test oftmals noch langsamer ist, als die Grafikkarte einfach rendern zu lassen... deswegen muss man auf Octrees usw. zurückgreifen. Aber ich möchte es an dieser Stelle dabei belassen, damit das ganze erstmal auf einer einfachen Ebene bleibt.
Das Frustum Culling bedeutet also, dass man das Objekt vorher gegen das Kamerasichtfeld prüft und dann übergeht, wenn es nicht im Sichtfeld ist.
Das Occlusion Culling hingegen soll die Objekte ausschließen, die hinter anderen Objekte liegen. Prinzipiell sieht man sowieso nur das, was am nahesten zur Kamera liegt, das macht der Z-Buffer. Aber der Z-Buffer verarbeitet auf Pixelebene ziemlich am Ende der Renderpipeline, nachdem das Objekt längst von der GPU bearbeitet wurde. Ziel von Occlusion Culling ist, das Objekt noch auszuschließen, bevor es überhaupt zur Grafikkarte geschickt wird.
Das ist allerdings wesentlich schwieriger als beim einfachen Frustum Culling.
Man kann sich die Kamera als Punktlichquelle vorstellen, und jetzt muss man rausfinden, was alles im Schatten liegt.
Ein weg wäre, man rendert das Objekt, zumindest in aproximierter Form und fragt die GPU hinterher, wie viele Pixel davon denn sichtbar waren. Schwierig ist das, weil das ganze nicht sehr zuverlässig funktioniert. Denn das Ergebnis steht erst ein paar Frames später fest. Wenn man sich vorstellt, man straft an einer Tunnelöffnung entlang, wo man dann mit einmal einen langen Gang zu Gesicht bekommt, dann weiß die Engine erst ein paar Frames später, dass dieser Gang auch gerendert werden muss. Das ganz verschlimmert sich dann auch noch, wenn man eben hierarchisch prüft, weil ein solche Occlusion Querrie Test für jede Würfelfläche einzeln wäre eben wieder auch ne Menge overhead.
Eigentlich ist es besser, wenn man schon auf der CPU Seite berechnen könnte, ob etwas sichtbar ist oder nicht.
Mein erster Ansatz war nun, Occluder für einen Chunk zu erzeugen. Da kann man ähnlich wie beim Frustum Culling dann einfach prüfen, ob das aufgespannte Occlusion Frustum eine Box dahinter umschließt. Also zu jeder Würfelfläche wird dann auch eine Bounding Box erstellt und mit dem Occlusion Frustum geprüft.
Problematisch ist, dass man das Objekt nur verwerfen darf, wenn es vollkommen von dem Occluder verdeckt wird. Wenn man nun zwei Occluder nebeneinander hat, die sich nicht überlagern, dann könnte es sein, dass die Würfelfläche von dem einen Occluder teilweise und von dem anderen Occluder auch teilweise verdeckt wird. Insgesamt wäre die Würfelfläche vielleicht komplett verdeckt, aber es wird ja immer nur jeder Occluder einzeln getestet.
Wenn man nun 4000 Würfelflächen prüfen muss, und das mit 100 Occludern resultiert das in 400.000 solche Occlusion Frustum Tests. Das heißt, Würfelfläche (W) wird mit Occluderanzahl (O) multipliziert. Besser wäre es, wenn man erstmal alle Occluder sammeln könnte und dann alle Würfelflächen mit dem Sammelsurrium testen könnte. Aus (W) * (O) würde dadurch (W) + (O).
Nun bedeutet dieses Sammeln eigentlich nichts anderes, als alle Occluder in einen Tiefenbuffer zu rendern. Am trivialsten wäre der Test nun, wenn man nun die Würfelfläche auch in diesen Buffer rendert und schaut, wie viele Pixel davon den Tiefentest bestehen würden. (Man überschreibt die Tiefenwerte im Buffer natürlich nicht mehr, die sind nur noch zum testen da dann)

Was nun auf den letzten Bildern zu sehen ist, ist der Versuch, selbst per Hand Boxen in ein Bild zu zeichnen über CPU.

Wahrscheinlich komme ich nicht drum herum, die Boxen zumindest als Quads zu rendern... weil gerade bei den größeren Boxen dann der Fehler wegen den Depth Werten, die ich irgendwie, aber sicher nicht korrekt erstelle, zu groß wird. Da klappt dann das Occlusion der Flächen kaum noch.

danke für die erklärung zudo! frustum culling kenn ich schon. occlusion scheint von graphik-karten gehandelt zu werden, aber geht wohl in deinem fall nicht (bzw. du willst die daten gar nicht erst schicken).

für die chunks musst du ja auch eine tiefen-reihenfolge finden, oder? 400000 tests hört sich jedenfalls nach verdammt viel an.

evtl die bounding boxes der einzelnen objekte rendern? allerding bräuchte es da wohl eine innere und eine äussere bounding box. die innere verdeckt alles dahinter, die äussere wird benötigt um festzustellen ob das objekt sichtbar sein könnte. ok, auch kompliziert... wie rendert man sowas... äussere halbtransparent? wie findet man anhand vom gerenderten bild raus, was jetzt sichtbar war. ich glaub ich überlass dir das forschen :lol:

Du redest von Occlusion Querries... aber die benutze ich ja nicht.

Ich will quasi in Software rendern, und dann schauen, ob ein Pixel von den Würfelflächen den (Software) Z-Buffer Test besteht. Also bis zu diesem Punkt hat das dann quasi gar nichts mehr mit der Grafikkarte zu tun.
Diese 400.000 Test hätte man auch reduzieren können, indem man entweder weniger Occluder prüft, oder/und die Würfelflächen zu größeren Gruppen zusammen fasst. Aber das ist was für später.
Ich habe die 2 Wochen für dieses Thema bereits überschritten, was extremen Motivationsverlust nach sich zieht... ich schaue jetzt noch, ob ich das irgendwie noch ans laufen bekomme.

Statt Würfel oder Quads ist es wohl erstmal am einfachsten, wenn ich wirklich auch Dreiecke rendere... denn da bedeutet das Clipping mit einer Ebene, dass ich das Dreieck verwerfen und entweder 0 - 2 Subdreiecke rendern muss, je nach Fall.

Dreiecksrendering hab ich auch jetzt fertig, Clipping, hier an der X Ebene scheint auch zu gehen. Jetzt noch die Tiefe und ich hoffe, dann ist das nutzbar und nicht viel zu langsam...

Ich glaube ich verstehe schon was du erzielen willst, nur verstehe ich den Prozess/dein Konzept noch nicht. Lass dich davon nicht abhalten Zudo, ich bin gespannt auf dein Ergebnis und wünsche dir viel Erfolg mit den Dreiecken ;)

Langsam geht es voran.
Das Dreiecksrendering wurde nochmal geändert und nun kann ich zumindest schon mal Vertexfarben interpolieren. Am Ende müssen es zwar nur die Tiefenwerte sein, aber nun will ich schauen, dass es auch vernünftig wird. Eigentlich schade, dass sich dafür später keine Verwendung findet, also fürs Softwarerasterizieren.

Als nächstes möchte ich noch machen, dass eine Textur verwendet wird, damit ich wegen der Perspektivenkorrektur schauen kann.

EDIT: Krass, wenn man schon auf viele Funktionen zurück greifen kann. So hat das samplen aus einer Textur jetzt keine 15 min gekostet.

Es geht vorwärts. Schick. Perspektivkorrektur ist für mich irgendwie immernoch ein Buch mit sieben Siegeln, auch wenn ich vermute, dass man das aus der Dreiecksgleichung und der Perspektivischen Projektion wahrscheinlich relativ einfach herleiten kann.

Schrompf hat geschrieben:Es geht vorwärts. Schick. Perspektivkorrektur ist für mich irgendwie immernoch ein Buch mit sieben Siegeln, auch wenn ich vermute, dass man das aus der Dreiecksgleichung und der Perspektivischen Projektion wahrscheinlich relativ einfach herleiten kann.

Ehrlich gesagt, bin ich beruhigt, dass zu lesen. Ich tue mich da auch schwer, und gäbe es dazu keine Informationen, ich weiß nicht, ob ich da jemals drauf kommen würde.
Soweit ich das verstehe liegt das ganze wohl daran, dass man nicht im Homogenen Space arbeitet, sondern in dieser Perspektivischen interpoliert, wo man quasi alles irgendwie mit 1/Z berechnet.

Exakt das 1/Z ist der Fall. Steht z.B. hier: https://en.wikipedia.org/wiki/Texture_m ... orrectness
Die Interpolation mit 1/Z ist zwar ne teure Sache, aber heutzutage bei weitem nicht mehr so schlimm wie anno dunnemals. Da in Deiner Engine bisher nie die Kamera ge-tilt-et wird, kannst Du sogar den Doom-Trick anwenden und jeweils tiefenstabile Zeilen oder Spalten bestimmen. Oder Du bestimmst nur aller 4 Pixel die neuen Gradienten. Gibt jede Menge Möglichkeiten, falls sich die Divisionen tatsächlich als Problem herausstellen sollten.

Aber wie gesagt: aktuelle CPUs sollten keine Probleme mehr mit so ner Division haben. Die Zyklen dafür verblassen doch völlig gegen den Bedarf eines einzigen Cache Misses. Da waren die Jungs früher schlimmer dran, als jede Division ~30 wertvolle Takte gefressen hat und jedes Frame nur 3 Millionen überhaupt zur Verfügung hatte.

Deinen Beitrag hab ich jetzt zu spät gesehen. Bei Wiki hatte ich aber auch gelesen und dann noch diverse andere Quellen.
Irgendwo stand auch, dass man statt Z, W nehmen müsste. Es funktionierte alles nicht, bis ich mir mal W angeschaut habe, welches immer 1 war nach der ViewProj. Da habe ich erstmal gemerkt, dass da doch noch gehörig was schief läuft. :lol:
Mich hatte schon gewundert, dass ich nirgends / Z teilen muss, so generell... das war nämlich in meiner Matrixmultiplikation schon drin, dadurch bekomme ich nach der ViewProj da weder für Z noch für W sinnvolle Werte.
Hab nun die Matrixmultiplikation für 4D Vektoren drin und nun funktioniert es, wenn ich Z nehme. Muss dafür allerdings auch noch X und Y von Hand teilen. Also um auf ScreenSpace Koordinaten zu kommen.
Ich mache mir jetzt wegen der Perspektivenkorrektur auch gar nicht so den Kopf. Letztendlich möchte ich ja keinen schönen Softwarerenderer sondern hinterher die Tiefenwerte korrekt berechnen. Da habe ich jetzt lieber die Kanone rausgeholt um auf die Spatzen zu schießen, nicht dass da hinterher wieder Probleme sind. Optimieren kann man das dann hinterher noch.

Prrrrima, es geht. Ob Du aber tatsächlich perspektivisch korrekte Tiefenwerte brauchst, ist ne gute Frage. Ohne Perspektivkorrektur werden die Tiefenwerte bisweilen ziemlich danebenliegen. Aber ob das tatsächlich relevant ist für Dich, weil die verdeckten DrawCalls ja doch immer deutlich hinter den Occludern liegen und die sichtbaren DrawCalls zumindest in gewissem Abstand davor, wirst Du wohl ausprobieren müssen.

Das weiß ich nämlich auch nicht so genau.
Dachte ja eigentlich, die Boxvariante würde da schon ausreichen. Aber das Problem war da erstmal, dass ich das Clipping nicht richtig hinbekommen habe... also es ging nur auf Kanten, statt auf Flächen, sofern man die Silhouette einer Box dann als Fläche betrachtet. Da hatte ich ja nur sehr grobe Tiefenwerte, die rein von der Logik her irgendwo durch die Box gehen müssten. Das Problem hier war aber, dass man ja einen Z-Buffer erstellen möchte. Und wenn dann einige große und kleine Boxen übereinander, hintereinander usw. liegen, dann haben die alle so verkorkste Z-Werte, dass manchmal die hinteren Boxen im Z-Buffer drin blieben, wo dann, wenn man den zum Cullen verwenden wollte, manche Flächen sichtbar blieben, die eigentlich hätten verdeckt sein müssen und was noch schlimmer war, dass manche ausgeschlossen wurden, die hätten sichtbar bleiben müssen.
Ein Offset hat das Problem nicht wirklich behoben. Da besondern z.B. bei großen flächigen Occludern die Z-Werte nicht richtig funktioniert haben.

Leider komme ich wohl um Perspektivenkorrekte Z-Werte nicht drum rum. Allerdings nehme ich die Z-Werte aus dem Homogenous Space. Vielleicht ist das auch nicht so ganz richtig.

Jedenfalls sieht man hier, wenn die Occluder aktiviert sein, dass am Boden andere Boxen durchleuchten, wenn die Z-Werte nicht Perspektivenkorrigiert sind.



Beim ersten reaktivieren der anderen Occluder lag ich bei 6 FPS... zum Glück lässt sich da jetzt einiges weg kürzen.

Schrompf hat geschrieben:aktuelle CPUs sollten keine Probleme mehr mit so ner Division haben. Die Zyklen dafür verblassen doch völlig gegen den Bedarf eines einzigen Cache Misses. Da waren die Jungs früher schlimmer dran, als jede Division ~30 wertvolle Takte gefressen hat und jedes Frame nur 3 Millionen überhaupt zur Verfügung hatte.

Du setzt voraus, dass die CPU die Division out-of-order durchführen kann – das geht aber nur, wenn 30 Takte lang keine Abhängigkeiten zu vorherigen Werten bestehen. Außerdem haben CPUs mehrere Einheiten für mul/add, aber nur eine für div/sqrt (Transistorbudget – die Quadratwurzel versemmelst du dir dann gleich mit). Und nicht zuletzt setzt deine Argumentation voraus, dass man für jede 2. oder 3. Division einen Cache Miss zum Ausgleich hat – so lange nicht jeder Pixel als Einzelallokation rumliegt, geht das nicht auf. Aber vielleicht sind meine Ansprüche auch einfach wieder zu hoch :P

Du hast aber recht damit, dass alte Algorithmen zu Software Rasterizing auf heutigen CPUs eher in der Speicherlatenz limitiert sind als damals.

Huhu!
Ich weiß, es ist schon wieder Zeit vergangen... aber nur weil ich nichts poste heißt es nicht, dass ich nicht aktiv bin. Irgendwie muss ich es noch schaffen, regelmäßiger News zu bringen. Aber ist auch schwer, weil vieles einfach unsichtbar ist und ich finde es nicht so spannend, da einfach nur Text zu posten. Habe einige Bugs behoben und auch weiter optimiert. Das Occlusion Culling hab ich auf einen nutzbaren Stand gebracht, aber es ist noch nicht wirklich schneller. Das kommt dann, wenn ich mich wieder daran setze.
Das erstellen der prozeduralen Welt Texturen habe ich optimiert. Z.B. brauchen die Felsen nun noch etwa 1000 statt 3000 Instruktionen. Da ich dann eh diese prozeduralen Texturen nochmal überarbeiten musste, konnte ich sie auch gleich mit verschönern. Außerdem habe ich jetzt letzte Woche mal ein paar neue hinzu gefügt.
Auf der rechten Wand sieht man jeweils die 2D Originaltextur von CG-Textures. Und links bzw. auf dem Boden dann meine prozedurale Textur, mit Höhenkarte/Normalmap und Reflektionsmap. Die Steintexturen, insbesondere diese "Zufallsverteilung" gefällt mir noch nicht. Aber besser erstmal überhaupt eine Basis haben.

Hier die Ergebnisse... leider in mehreren Posts, weil ja nur 5 Screenshots auf einmal gehen:

Krass Zudo was du da mal wieder nur mit Code gezaubert hast... ein paar der Fliesen sind ja schon Fotorealistisch! Freut mich, dass du fleißig an StoneQuest weiter arbeitest, auch wenn du nicht so häufig darüber berichtest :)

Vielen Dank LONy! :D

Hier sind die anderen vier Fliesentexturen. Nun hab ich zumindest alle Fliesen, die ich hatte, prozeduralisiert. Nicht perfekt... aber ich will jetzt erstmal auf breiter Linie voran kommen.

coole sache zudo, baust du damit einen palast, oder was hast du mit den ganzen fliesen vor :) ?
die felsen sehen geil aus!

Hahaha. Ich hatte damals einfach ein paar Texturen geadded. Und nun wollte ich erstmal die die ich habe über Shader erzeugen. Aber wenn du möchtest kannst du ja einen Palast damit bauen :D

Rockt! Weitermachen!

Fein, bin gespannt auf mehr!