ZFX + Developia

Der Ambient Occlusion-Kernel fällt wieder auf, aber davon ab ist es nun viiiiel schärfer. Woran lag’s?

Zudomon hat geschrieben:

Der Screenshot gefällt mir besonders gut, die Stimmung ist etwas trüb, das DoF kaschiert aber wunderbar den Hintergrund und zeigt eine interessante Welt

Ich muss mal Kirshty widersprechen, da ich den Vorteil habe kompletter Laie zu sein :-)
Ich sehe da überhaupt keine Artifakte, die irgendwie negativ auffallen(,weil ich nicht weiß worauf ich zu achten hätte)
Das, was seit jeher auffällt ist dass die Schönheit in 20m aufzuhören scheint. Das haut seit jeher dermaßen rein.. hmmh.
Ich frage mich ob du die Chunks der entfernten Landschaft nicht niederfrequent in Billboard-Texturen oder etwas ähnlichem rendern könntest, die ungefähr die hochdetailierte Sicht aus der jetzigen Position widergeben.. da wäre das alles nicht so nackt.

@Krishty
Immer noch 4 Samples für das SSAO... das schierige ist, ein Pattern zu finden, was dann über mehrere Frames hinweg nicht so flimmert... mit dem neuen Pattern ist es schon etwas besser geworden.
Das Vignetting und CA ist nun einstellbar und zwar nicht nur ob oder ob nicht, sondern auch die Stärke. In den Screens ist es aus, wenn ich mich nicht täusche.
Und ich hab ja, um Alphablending zu haben, gedithert über die Frames hinweg, was durch das TAA ja dann gemittelt wird. Aber die Ränder fransen dann ein wenig aus bei den ganzen Alphatexturen. Wenn man aber eh kaum einen Saum sieht und der sowieso eher ausgefranst ist, kann man eigentlich auch direkt Alphatesting machen. Könnte sein, dass es dadurch schärfer ist.
Ich wollte erst hier fragen, was eure Meinung dazu ist, aber für mich war es eigentlich dann doch recht klar, wofür ich mich entscheide...
@MasterQ32
Ich mache eigentlich immer nur Bilder im Sonnenlicht und schaue mir viel zu selten auch andere Tageszeiten an. Dabei finde ich, sind diese auch, wie du schon sagst, sehr Stimmungsvoll. Das Licht beim ImageBasedLighting noch nicht ganz korrekt... das fällt vor allem Nachts aus, wenn der Planet die Welt beleuchtet, dadurch wirkt es dann alles sehr metallern. Naja, mal sehen, wann ich da mal was mache.


@DerAlbi
Das was Krishty meint liegt vor allem daran, dass das SSAO (sowie auch der andere Schatten) nicht so detailliert berechnet werden. Dadurch kommen da Muster ins Bild. Aber ich denke, den meisten Spielern wird es wichtiger sein, dass mehr FPS da sind.
An die Chunks per Billboard rendern hatte ich schon vor Jahren mal gedacht, aber ich bin mir sicher, das würde auffallen. Das Problem ist auch weniger das Rendern an sich, sondern überhaupt erstmal die entfernten Chunks zu berechnen. Bei mir ist es ja so, dass entferntere Chunks einen größeren Bereich abdecken. Und momentan so, dass die Objekte erst beim höchsten Detail platziert werden. Eigentlich würde es reichen, wenn zumindest schon mal die Bäume auch in groberen Chunks korrekt verteilt werden könnten. Das kommt auch noch. Ich schiebe es auch nur vor mir her... was nicht heißt, dass ich nicht schon experimentelle Versuche gemacht habe. Leider ist da dann das Rendern doch ein Problem, weil ich für die Bäume noch kein sehr niedriges LOD habe. Blöd ist auch, dass die Landschaft in Wirklichkeit gar nicht so groß skaliert ist, wie sie im kahlen Zustand scheint. Wenn da Bäume drauf sind, sieht man erstmal, wie klein alles ist.

Der mit den Bäumen sieht schon weeeesentlich hübscher aus. Ich finde aber, gerade auf mittlere entfernung dürfen auch die Büsche nicht fehlen. ich denke sogar, dass man irgendwie eine lösung für die Grastextur finden müsste. In naher Umgebung hast du so viel Abwechslung, in der Entfernung ists einfach nur grün. Wenn du wüsstest wie dein Grünzeug verteilt ist könnte kan da vllt noch was rausholen. In der Entfernung sind solche Details ja nicht nur Textursache, sondern auch ein Ding der Beleuchtungs. Also was ich meine ist, dass Grasflächen anders reflektieren als Kleeblätter z.B... da du alles Prozedural machst, solltest du die Information dafür eigentlich haben... Aber ich stell mir das auch grade nur so vor. Keine Ahnung, wie man das wirklich implementieren sollte.

DerAlbi hat geschrieben:Der mit den Bäumen sieht schon weeeesentlich hübscher aus. Ich finde aber, gerade auf mittlere entfernung dürfen auch die Büsche nicht fehlen. ich denke sogar, dass man irgendwie eine lösung für die Grastextur finden müsste. In naher Umgebung hast du so viel Abwechslung, in der Entfernung ists einfach nur grün. Wenn du wüsstest wie dein Grünzeug verteilt ist könnte kan da vllt noch was rausholen. In der Entfernung sind solche Details ja nicht nur Textursache, sondern auch ein Ding der Beleuchtungs. Also was ich meine ist, dass Grasflächen anders reflektieren als Kleeblätter z.B... da du alles Prozedural machst, solltest du die Information dafür eigentlich haben... Aber ich stell mir das auch grade nur so vor. Keine Ahnung, wie man das wirklich implementieren sollte.

Da hast du Recht! Es sind auch Dinge, die mir ja bewusst sind. Und sobald ich vernünftige Lösungen dafür habe, werde ich das auch umsetzen.
Mit der mittleren Entfernung ist es das gleiche wie oben beschrieben... es wird halt erst alles wirklich berechnet, wenn es nah dran ist.

Ich liebe dieses virtuelle Sonnenlicht! <3

53 FPS auf High

Jau, das ist wirklich beeindruckend. :)

Ich arbeite derweil wieder an einer Occlusion Culling Lösung.
In der Vergangenheit hab ich immer Occlusion Querries verwendet. Aber die hatten den Nachteil, dass man oft einfach sieht, wie Dinge mit einmal erscheinen. Außerdem war es nicht wirklich schön, ein Querie zu setzen und dann ein paar Frames später zu wissen, wie viel davon gezeichnet wurde. Jedenfalls wollte ich mal irgendwas anderes probieren. Ein Software Z-Buffer finde ich allerdings auch extrem. Ich glaube nicht, dass CPU Rendering effektiv zu bekommen und hätte halt irgendwie lieber eine analytische Lösung, am besten schon im Worldspace. Bisher hat mich davon aber abgehalten, dass ich mir nicht wirklich vorstellen konnte, das praktikabel zu machen. Aber wenn im Startgebiet sehe, wie viel overdraw da zustande kommt, denke ich, dass eine schlechte Lösung immer noch besser ist als gar keine Lösung. Selbst wenn nicht wirklich Geschwindigkeit dadurch eingespart werden könnte, so müssen zumindest für die Flächen, die nicht gerendert werden, auch keine Texturen erstellt und gehandelt werden. So könnte ich zumindest GPU Speicher sparen. Da bin ich zur Zeit bei 1,6 GB allein für Texturen auf HIGH. Von daher würde ein Occlusion Culling auf jeden Fall was bringen.

Erstmal kam mir nun in den Sinn, wenn ich einen Occluder habe und die 4 Punkte eines Voxelpatches zur Kamera verfolge und alle Punkte den Occluder schneiden, sollte dieses vom Occluder verdeckt sein. Hat auch funktioniert... ist ja ähnlich zum Raytracing. Wenn ein Voxelpatch aber z.B. dann auch (man muss ja schon ein weiter denken) bewachsen ist, würde ich auch gerne nicht nur den Patch aus den 4 Punkten bestehend, sondern eher ein Würfel testen. Außerdem habe ich mich gefragt, ob es nicht schneller ist, die Planes, die ein Occluder aufspannt, zum testen gegen den Würfel zu nehmen. Damit ist es dann eigentlich ein Portalsystem, aber statt sichtbar zu machen, wird unsichtbar gemacht. Das ist auch fast doppelt so schnell als der Raytracing Ansatz. Da ich als Occluder Boxen nehme, muss ich im Extremfall allerdings 9 Planes aufspannen. Da ich eigentlich sowieso eher Wände als Occluder haben möchte, sollten also Quads als Occluder reichen, was dann in 5 Planes resultieren sollte.

Jedenfalls bin ich vorerst mit dem Ergebnis zufrieden. Am Ende hatte ich es bis auf 7,7 ms für etwa 550k Patches für das OC testen gebracht... das ist dann später sicher noch optimierbar. Man könnte dann schauen, ob Occluder sich gegenseitig occluden und dann entsprechend einsparen. Denn jeder Patch muss ja prinzipiell gegen jeden Occluder getestet werden. Auch sollte man vielleicht erst gegen die großen Occluder testen, denn wenn eine Fläche ausgeschlossen ist, braucht diese nicht mehr getestet werden.
Als nächstes will ich aber schauen, dass ein paar Occluder sinnvoll und automatisch in der Welt verteilt werden. Eine wirkliche Idee, wie man das anstellen könnte, hab ich aber noch nicht...

Guter Grundgedanke, aber ich weiß nicht, ob das so funktionieren wird. Ich meine: die Occluder funktionieren, und das allein ist gute Arbeit! Aber was machst Du dann mit diesen Occlusion-Infos? Um einzelne Patches occluden zu können, müsstest Du ja jeden einzelnen davon als einzelnen DrawCall behandeln. Das erscheint mir ziemlich verschwenderisch, auch wenn's bei Deinem Polycount wahrscheinlich trotzdem eher an der GPU hängt als am CPU-Overhead. Und die Texturerstellung... ist die so schnell, dass Du das innerhalb von ein paar ms nachholen kannst, wenn ein Patch in Sicht kommt?

Es wird jedenfalls noch knifflig werden, das System mit all seinen Implikationen zu vervollständigen.

Also es ist schon so, dass in jedem Frame jeder Patch auf Backface Culling überprüft wird, sogar mehrmals pro Frame (einmal fürs Rendering an sich und einmal, zumindest für die nahesten für die Sonnenshadowmap). Es werden dann nur für die sichtbaren Patches (nicht für die Shadowmap, da braucht man ja keine Texturen) die Texturen erstellt, die noch nicht existieren. Im Moment wird das auch nicht Asynchron gemacht, also es muss dann wirklich per Mikrolag gewartet werden, bis die Textur für einen Patch fertig ist. Durch das OC sollten diese Mikrolags dann sogar reduziert werden.

Also von daher war es jetzt eigentlich keine große Sache, im Vorfeld nochmal Patches auszuschließen.
Allerdings werden die Patches dann als Batch zusammengefasst und gerendert, nur die vordersten landen einzeln auf der Grafikkarte, denn da hat eine Fläche schon über 32k Dreiecke.

Hier sieht man seitlich in den Stats, wie sich das Occlusion auswirkt auf die Anzahl der Patches und die Drawcalls. Dabei sind es aber dann alle Drawcalls, die für das Frame genutzt werden, also auch das Deferred am Ende und der Text an sich.
Prüfen werde ich aber hinterher eventuell nicht mehr jeden einzelnen Patch. Ich denke, da reicht es dann vollkommen, wenn man ein paar gemeinsam prüft.

Also es geht voran... aber momentan weiß ich noch nicht so richtig weiter...

das finden der Occluder Rechtecke in einem Slice geht schon extrem schnell...
Es gibt nun 2 Optionen. Die eine wäre, das ganze 2D zu machen, also alle Slices in allen Achsen... resultiert für einen Chunk in etwa 1000 Rechtecke. Die zweite Option wäre 3D Boxen zu erstellen. Auch das klappt, das erstellen braucht ein bisschen länger. Daraus resultieren so um die 150 Occluder. Allerdings gefällt mir die 2D Variante besser, weil ich ansonsten ziemliche Probleme mit der gesmoothen Welt habe... zunächst hatte ich das gesmoothte einfach nicht beachtet. Wenn dann also eine runde Säule da steht, dann wird hinter den Rändern auch weg gecullt. Nicht so toll... da kommt mir gerade die Idee, dass man statt einfach nur so die Bounding Box zu inflated, das mit dem Abstand zur Kamera, dann könnte ich das vielleicht sogar zuverlässig umgehen. Wie einem immer beim Schreiben die Einfälle kommen. Eigentlich wollte ich jetzt schreiben, dass ich eine Erosion angewendet habe, um dann quasi eine Schicht der gesmoothten Voxe abzutragen und den Rest als Occluder zu nehmen. Allerdings ist der Boden und das Dach bei meinem Testchunk genau einen Voxel dick, und somit geht mir genau der effektive Occluder verloren.
Deswegen wollte ich mich eher auf die 2D Variante konzentrieren. Da weiß ich allerdings auch noch nicht, wie ich die effektiven Occluder filtern kann. Das testen könnte man allerdings dann bei denen vereinfachen. Eine 2D Rechteck resultiert in maximal 5 Planes zum Occludertest. Eine Box hingegen in bis zu 6 (Rand projizierten Box) + 3 (Boxseiten).
Dass das ganze aktuell extremst langsam ist, brauch ich hoffentlich nicht erwähnen :D

Weil das Auge immer mit isst...
Die FPS haben hier überhaupt gar keine Aussagekraft... aber Anzahl der Occluder vielleicht. Habe die Sichtweite der Detailflächen hoch gestellt, damit man viel von der Struktur sieht.

2D: Rechtecke mit einer Ausdehnung von 1 in einer Achse werden nicht beachtet, außerdem werden die Rechtecke anschließend vergrößert um überlappende Flächen zu haben...
3D: Quader werden noch ohne Border erstellt...

Also genau weiß ich noch nicht, ob ich lieber 2D oder 3D machen werde. 3D sieht um einiges aufgeräumter aus... bei 2D müsste ich wissen, wie man am besten die effektiven Occluder filtert. Mal schauen ob mir noch was einfällt...

Fast wäre es die 2D Variante geworden, aber da hab ich dann doch noch diverse Probleme mehr gesehen. Also doch 3D... anstatt die PatchBoxen dann auf Abstand zu vergrößern wie mir beim schreiben gestrigen Posts in den Sinn gekommen ist, bin ich den umgekehrten Weg gegangen. Einfach die Occluder schrumpfen, das spart dann doch Rechenzeit. Dadurch kann ich nun auch Artefaktfrei cullen. Und es kostet mich auf High nur noch die hälfte der FPS. Damit bin ich ehrlich gesagt schon sehr zufrieden.
Auf Knopfdruck lassen sich nun zu einigen Clustern in der Umgebung ein paar Occluder erstellen. Zum Beispiel sind das dann 1000... die werden erstmal nach Abstand gefiltert, dann per Frustum gecullt und dann nochmal gegenseitig. Das kostet mich schon ne halbe ms. Aber dafür bleiben dann nur noch etwa 100 Occluder übrig. Eigentlich finde ich das noch zu viel. Ich glaube, wenn man den Chunk noch irgendwie vorbereitet kann man vielleicht noch was sparen. Es wird noch jeder Patch gegen jeden Occluder geprüft, was entsprechend Geschwindigkeit zieht.
Prinzipiell werden nicht nur die Patches, sondern auch schon Cluster im Hintergrund (bringt aber nichts, weil die BBox meist größer ist als der Occluder) und Objekte gecullt. Die Mikrogeometrie wird mit den Patches zusammen verwaltet, also wenn diese gecullt werden, wird die Mikrogeometrie auch nicht gerendert.

Richtig cool sieht das in Bewegung aus, wenn auf einmal alles hinter einem Occluder verschwindet. Ich weiß nicht seit wie vielen Jahren ich mir das Wireframe ansehe und denke, wäre das geil, wenn jetzt dass da hinter nicht mehr beachtet würde. Dass das auf einmal so funktioniert ist unglaublich. Da ist auch kein verspätetes einblenden wie mit den mistigen Occlusion Queries. Und klein flackern wegen zu kleinem Software Z-Buffer! :D

Auf den Screenshots sind nur die Patches, auf den ersten drein auch noch die Objekte aktiviert. Außerdem ohne Tesselation, damit man auch was sehen kann und nicht das Wireframe jeden dritten Pixel verdeckt.

Sehr cool. Wieviel hat das denn gebracht?

Ich hab dadurch etwa noch die hälfte bis ein drittel der ursprünglichen FPS. Aber das heißt noch nichts. :D

Vielleicht findest Du dafür ja ne schicke Lösung. Ich weiß noch aus Splitterwelten-Zeiten, dass Blocker und Portale ne empfindliche Sache sind, die wir mit viel Augenmaß und Feingefühl von Hand platziert haben, damit sie was bringen. Sobald es nur ein paar zuviele werden, kostete es mehr, als es brachte. Du hast zusätzlich das Problem, dass Du auf nahezu beliebigen Raumstrukturen arbeiten musst.

Wobei mir jetzt nach all den Jahren einfällt, dass ich wahrscheinlich auch ein paar 2D-projezierte Testpunkte gegen die 2D-Projektionen aller Occluder hätte testen können. Ich habe damals Silhouetten-Kanten identifiziert, daraus Grenzebenen extrudiert und dann gegen die getestet. Das System war extrem empfindlich gegen "innere" Kanten z.b. zwischen zwei Occludern mit Kontakt zueinander. Man hat z.B. zwei Occluder-Würfel aneinander gesetzt und musste sorgfältig manuell die Kanten markieren, damit die Kante dazwischen keinen schmalen Spalt Sichtbarkeit produziert.

Silhouetten-Kanten suche ich bei mir auch für die Occluder-Würfel.
Also in der aktuellen Einstellung im Screen (ohne das Debug rendering usw.) komme ich auf 235 FPS. Mit Occlusion Culling sind es (noch) 135 FPS. In dem Frame sind 98 Occluder aktiv.
Ohne Occlusion sind es etwa 3490 Patches im Frame, mit dann 1710. Das große Problem ist die Menge der Occluder. Weil diese sich ja mit der Anzahl der Patches quadrieren.
Resultiert in 342.020 Tests (Brush gegen Box) für den Frame.


Ich sehe zur Zeit noch 3 große Optimierungsfelder:

1. Reduzieren und verbessern der Occluder
2. Statt gegen einzelne Patches dann ganze Gruppen zu prüfen
3. Auf mehrere Frames verteilen. Da das ganze im Worldspace stattfindet könnte man eventuell sogar im Vorfeld ringsrum schon occluden

Vielleicht gibt es ja auch noch einen Weg, Occluder zu kombinieren, aber ohne die in einen Z-Buffer zu rendern, fällt mir da momentan nichts ein.

Ich bin mir ziemlich sicher, dass der Overhead durch 1-3 extrem reduziert werden kann. Aber selbst wenn die FPS sich nicht ändern sollten, bringt mir das Occlusion Culling den Vorteil, dass es die Anzahl der Patches erheblich reduziert. Da ja jeder Patch eine eigene Textur verwendet, die auch gemanaged und upgedated werden muss, würde zumindest Speicher und Mikrolags reduziert.

EDIT: 2. könnte man sogar noch zu einer umgekehrten Form erweitern... nicht nur die Patches gruppieren, sondern auch die Occluder.

Ich hatte nun mit dem zusammenfassen von Occludern begonnen... zu jedem eine Art Screen Boundingbox, wobei ich nicht wirklich im Screenspace umgerechnet habe, nur das dot Produkt der Kamera X und Y Achse. Dann habe ich den Screen in 3x4 Felder aufgeteilt und die Cluster, die da rein fallen benutzt. Durch die Größe hat sich die Menge der Occluder letztendlich aber nur 1/3 bis 1/2. Das gleicht gerade so den Overhead aus. Da hatte ich mir wesentlich mehr versprochen.
Wenn man nun den Screen noch weiter unterteilt, dann könnte man schon fast für jedes kleine Feld schauen, welche Occluder da drin liegen. Wenn man statt das äußere das innere nimmt. Jedenfalls würde das dann doch zu einer Art Z-Buffer mutieren und da ist dann die Frage, ob man es nicht doch probieren sollte. Z-Buffer würde ja bedeuten, dass man im ersten Schritt alle Occluder da rein rendert, im zweiten diesen abtastet. Die Occluder wären kombiniert und was mich eigentlich dann doch motiviert in diese Richtung zu gehen ist, dass man das Occluder * Patches auflöst in Occluder + Patches. Mal gucken...

Joa, ein heftiges Thema. Viel Erfolg.

Schrompf hat geschrieben:Joa, ein heftiges Thema. Viel Erfolg.

Danke!
Ja, vor allem ist die Vorarbeit irgendwie wieder nervig. Bevor ich überhaupt rasterizieren kann, muss ich irgendwie Pixel in einen Buffer bekommen. Damit das nicht ganz blind passiert, und ich vor allem auch sehen kann, ob die Boxen auch die richtige Stelle im Buffer treffen, ist es sinnvoll, diesen auch anzuzeigen.
Der Einfachheit halber also erstmal eine Textur genommen und Fullscreen drüber gerendert. Die wird auch schon per Frame mit einem Zufallsrauschen aktualisiert. Hört sich jetzt eigentlich gar nicht nach so viel Vorarbeit an. :lol: Aber man muss ja erst immer dahin kommen. Zuerst hatte ich "einfach" eine Box als Pixel malen wollen, und hab dann ewig gebraucht, weil ich nicht gesehen habe, dass nach dem Kamerakonstanten setzen die View/Projektionmatrix überschrieben werden, um da noch ein paar andere Dinge zu machen. Und weil ich den Punkt nicht transformiert bekomme habe, dachte ich zunächst, es läge am transposen... so probiert man sich dann tot. Hatte dann die Idee, dass direkt über eine Textur zu lösen und just in diesem Moment klappte es dann endlich, die Box mit den Koordinaten 0 0 0 mit der Inversen zu multiplizieren, damit sie anschließend in den Bildschirmmittelpunkt transformiert wurde. Mir wäre aber da auch nicht ganz klar, wie ich nun das ganze als Pixel skalieren müsste. Deswegen ist die Texturvariante auf jeden Fall besser.

Bild mit Zufallsrauschen Overlay... spektakulär! :D

ich muss leider wieder mal zugeben, ich weiss gar nicht was du gerade versuchst zu machen :) . gehe ich recht in der annahme, dass es dir mit der occluder geschichte um die fernsicht geht?

marcgfx hat geschrieben:ich muss leider wieder mal zugeben, ich weiss gar nicht was du gerade versuchst zu machen :) . gehe ich recht in der annahme, dass es dir mit der occluder geschichte um die fernsicht geht?

Die Fernsicht hängt da teilweise mit drin. Eigentlich geht es einfach darum, alles, was hinter einer Wand ist, direkt vorm senden an die Grafikkarte auszuschließen.
Das hab ich zumindest bis gestern schon einigermaßen stabil und provisorisch umgesetzt. Allerdings ist das berechnen, was auszuschließen ist, noch langsamer, als wenn ich den Kram direkt rendern würde. Der Extremfall ist ja, wenn man in einer Höhle sitzt und in Wirklichkeit hinter den Steinwänden trotzdem die Umgebung mit Vegetation usw. gerendert wird.

Vorher habe ich mich Occluder (also Boxen) gesucht, wo ich sagen kann, dass dahinter garantiert nichts mehr zu sehen ist. Der Occluder wurde z.B. von einer Wand extrahiert. Und jetzt möchte ich die ganzen Occluder in eine extra Textur malen, damit ich darauf hinterher schauen kann, ob eine Fläche gebraucht wird oder nicht. Hab aber heute noch nicht viel daran gemacht.

Auf dem Bild hier siehst du zwei von Hand gesetzte Boxen... die dann später die Occluder repräsentieren. Ist halt einfacher, als wenn da 100 Boxen das Bild zumalen. Die grünen Linien sind die Silhouhetten der Boxen (mit kleinen Normalenpinn der nach innen zeigen muss).
In rot und blau male ich nun anschließend über das Bild. Dieses drüber malen ist in wirklichkeit der Software-Z-Buffer. Er hat eine geringe Auflösung, die später sogar noch geringer wird, damit das schnell geht. Wie man sieht erwische ich schon die Linien und Punkte der grünen Boxen per Software.

Noch eine kleine Frage zwischendurch, vielleicht ist noch jemand von euch wach und kann mir das schnell beantworten :D

Wenn ich die Vertices umrechne in Screenspacekoordinaten, dann kann es ja sein, dass die Polygone die Screengrenze oder die Nearplane überschreiten... wie clipt man das am besten? Wird das vorher mit dem Screen gecuted oder transformiert das einfach und clipt das ganze dann im Screenspace?

Ich vermute, sowas wird rasterisiert und dann verworfen -- weil 1. es beim Clipping typische Z-Artefakte gibt, und 2. ab D3D 10 Depth Clipping optional ist.

Krishty hat geschrieben:Ich vermute, sowas wird rasterisiert und dann verworfen -- weil 1. es beim Clipping typische Z-Artefakte gibt, und 2. ab D3D 10 Depth Clipping optional ist.

Okay, danke für den schnellen Tipp! :D

Wichtig ist bei mir ja eigentlich auch nur das schnelle hinklatschen der Boxen, statt akurat zu berechnen. Da will ich dann mal schauen. Die beiden Seiten der Silhouetten zu extrahieren, damit ich dann dazwischen später scanlinen kann.

Mir wird gerade empfohlen, fürs Polygonmalen die GDI zu benutzen, die auf WinAPI aufsetzt. Die soll wohl dafür schon optimiert sein. Nun weiß ich nicht, nicht selbst implementieren oder GDI? Hmmm... :?

Ich mach mal erstmal Schluss für heute. Also das Rasterizieren klappt eigentlich schon ganz gut, ist aber noch nicht wirklich optimiert.
Was mir derbe Probleme macht ist dann doch das Clipping, insbesondere wenn ein Vertex hinter die Kameraebene fällt. Ich habe so ein bisschen Sorge, dass ich das vielleicht nicht so einfach hinbekomme, weil ich ja nicht auf Dreiecke, sondern Boxen arbeite.
Man sollte das clippen wohl noch Homogenen Space machen, also vor der Perspektivenprojektion. Aber so ganz blicke ich das nicht. Genau aus diesen Gründen, wollte ich eigentlich ein Softwarerasterizer vermeiden... mist.
http://www.gamasutra.com/view/news/1685 ... p#comments
Wenn man die Box einfach skippen würde, dann verliert man viel an späteren Culling. Denn wenn man nah an einer Wand steht und sich dann tangential zur Wand dreht, dann hat man einen solchen Clipping Fall.

Mit der w-Koordinate verstehe ich irgendwie auch nicht so wirklich. Es wird ja am Ende durch w geteilt... das hatte ich bei mir allerdings vernachlässigt und trotzdem stimmen die Software Boxen mit den GPU Boxen überein. Kann ja eigentlich gar nicht sein, wenn w nicht 1 ist und man x und y damit teilt, dann sollten die Punkte doch nicht übereinander liegen. Aber bei mir multipliziere ich einfach den 3D Vertex mit der ViewProjection, multiplizere mit 0,5, addiere 0,5, spiegel die Y Achse und multipliziere mit der Buffer Auflösung. Seltsam.

Hier die wohlgerasterte Box:
Und wie das aussieht, wenn es mangels Clipping failed:

Nach einer kleinen Essenspause hatte ich dann doch Motivation nochmal weiter zu machen.

Mir ist zumindest schon mal ein viel einfacherer Renderalgo eingefallen.
Vorher hatte ich den obersten und untersten Punkt der Silhouette ausgemacht und dann vom obersten Punkt alle Kanten lang gegangen und mich bis zu dem untersten Punkt gehangelt... damit hab ich dann die linke und rechte Seite ausgemacht... dann die Kanten in einen linken und rechten Zeilenbuffer geschrieben.
Ist natürlich doof, wenn die Kanten jetzt irgendwo landen wegen dem fehlenden clipping.
Die Artefakte liesen sich zumindest auch schon gut reduzieren, indem ich einfach die X und Y Werte gespiegelt habe, wenn Z < 0 ist.

Die Idee dann war, wenn ich diesen Zeilenbuffer als min und max werte betrachte, dann könnte ich doch direkt jede Kante in diesen min und max buffer rendern. Da brauch ich gar nicht erst Kanten detektieren und eine "geschlossene" Verbindung finden.

EDIT: Wenn ich dann längere Occluder habe, muss ich mich doch auf jeden Fall um ein vernünftiges clipping kümmern, sonst klappt das nicht.

Langsam verstehe ich was du machen willst :D . Du renderst die Occluder in eine Textur, auf der du dann überprüfen kannst ob etwas versteckt ist. Hinter den Occludern wird die Geometrie gecullt und muss somit nicht verarbeitet werden, macht Sinn. Was ich noch nicht verstehe ist wie du die Occluder festlegst. Mein naiver Ansatz wäre ein Umkreis in der alles gerendert wird. Dann wird der Umkreis erhöht und dort wo bereits gerendert wurde, wird die Geometrie gecullt. Vermutlich ist das zu stark vereinfacht :oops: ?

Ja, hast du richtig verstanden.
Wie ich die Occluder Berechne: https://zfx.info/viewtopic.php?f=10&t=3 ... 540#p54360
Hier war das ganze noch auf einer 2D Ebene: https://zfx.info/viewtopic.php?f=7&t=41 ... 346#p54344
Also ein naiver Ansatz wäre, einfach alle ausgefüllten Voxel im Chunk als Occluder nutzen. Aber wenn zwei Voxel nebeneinander liegen, die ausgefüllt sind, dann kannst die ja mergen. So hab ich da versucht, die größten zusammenhängenden Voxel zu finden.