[Projekt] StoneQuest lebt noch!

[xq]

Auf jeden Fall bei weitem besser als vorher! Gegen Gourad-Shading hilft im normalfall ein Edgesplit, also "einfach" keine Shared Vertices nutzen. Geht das bei dir so einfach oder hast du da ne Restriktion in deiner Modellgeneration?

[Zudomon]

Ich hab smoothgrp per triangle. Mal sehen ob ich das umbaue.

[Zudomon]

Endlich kann ich euch mein neues Wind System zeigen! :D

YouTube kodiert ja alle Videos, die man hoch lädt, dabei hat man dann mit einer bestimmten Bitrate für eine Auflösung vorlieb zu nehmen. Da die Vegetation aber schon extrem hochfrequent und dann noch die Windbewegung mit rein spielt, bleibt am Ende nur noch Matsche übrig. Wenn man nun einfach das 1080p Video auf 1440p hochskaliert, dann gewährt YT am Ende mehr Bitrate. Dadurch sieht das Video auf 1440p doch um einiges besser aus, als die Variante, die ich vorher hochgeladen hatte.

[youtube]uzHaSuAJt8w[/youtube]

[marcgfx]

sieht richtig schön aus! du brauchst keine fernsicht, du brauchst einfach nen fetten wald der dir keine fernsicht ermöglicht. dann nennst du das ganze "into the woods" und bietest es für VR an. Rumlaufen können reicht, vielleicht mit ein paar Checkpoints mit VR Rätseln... Länger als 10 min hält man VR eh nicht aus. Aber das wär doch ne richtig geile VR demo ... just saying.

[Krishty]

Sieht in der Nähe exzellent aus; in der Ferne „nur noch“ gut. Ich schätze der Grund ist:

In der Nähe sind ist der Bildschirm durch die vielen Details und Bewegungen chaotisch genug, um kein Muster erkennen zu können.

Ab mittlerer Distanz (direkt am Anfang des Videos der Baum oben rechts) erkennt man, wie die Zweige als Gesamtes verschoben werden, und nicht einzeln oszillieren. Das flacht den Realitätsgrad ab.

Aber insbesondere das Sommergewitter und der Sonnenschein danach sind wunderbar immersiv.

[Zudomon]

Aber das wär doch ne richtig geile VR demo ... just saying.

Die GearVR wird prinzipiell schon seit Juni experimentell, aber ich will das noch nicht releasen, weil das ohne Motiontracking auch nicht so wirklich pralle rüber kommt...
Nach dem TAA update funktioniert das auch gar nicht mehr.
Aber in VR wirken diese Displacementwände und die Vegetation wesentlich besser, weil man dann auch erkennt, wie 3D das alles ist :D

Aber insbesondere das Sommergewitter und der Sonnenschein danach sind wunderbar immersiv.

Danke! Aber bisher ist es nur Regen... Gewitter habe ich noch nicht :D

[xq]

Das Video ist richtig gut! Der Wind macht das ganze wesentlich dynamischer und es scheint echter. Was mich persönlich gestört hat und was auch Krishty schon angesprochen hat, sind die Bäume am Anfang. Die sollten sich möglichst nie gegenläufig Bewegen, das würde das ganze schon wesentlich realistischer machen.

Ansonsten fand ich die Szene bei 1:58 auch schon sehr gelungen, wäre da nicht dieser eine, matschige Texturblock an dem Fels. Wäre es nicht möglich, die Sichtweite nen Ticken hochzusetzen, sodass man auch den Fels da noch in HD sehen könnte? Ich denke, das würde dem gesamten Spiel gut tun, aber da stellt sich irgendwann die Frage nach der Performance... :)

Aber im gesamten: Der Wind verbessert alles, good work!

[Zudomon]

Die Distanz drückt leider noch sehr auf die Performance. Und ich wollte nicht, dass das Video rumruckelt deswegen hab ich es auf HIGH aufgenommen.

Aber hier mal wie die einzelnen Presets zur Zeit aussehen. Oben links sind die FPS zu sehen... auf der GTX980

LOW

MEDIUM

HIGH

ULTRA

Hier mal ein Video, wie der Wind in Witcher 3 aussieht, zum Vergleich... :D

[youtube]ZLnTjOe0yGU[/youtube]
[/noshowroom]

[NytroX]

Ok, hier noch mal Feedback zu dem Wind.

Also erstmal: Wenn man sich die Gräser und Farne anschaut: super-geil. Ich hab noch nie so einen guten Effekt gesehen.
Bei den ganzen UnrealEngine und Unity Wind-Demos, die ich kenne, kann man immer die Sinus-Wellen sehen, die durch die Landschaft fegen (siehe auch dein Witcher-Beispiel).
Das ist bei dir anders, es ist mehr chaotisch, das macht es viel realistischer. Und irgendwie merkt man trotzdem intuitiv, aus welcher Richtung der Wind kommt.
Ich glaube das kann man so lassen, da wird es wohl die nächsten 5-10 Jahre auch keinen besseren/realistischeren Effekt geben. :D

Jetzt zu dem noch nicht ganz so realistischen Teil, das haben die anderen auch angesprochen: die Bäume.
Sie bewegen sich in deiner Wind-Engine ähnlich wie die Gräser und Farne, leider entspricht das nicht ganz der Realität.
Die "hin-und-her-schwing-Geschwindigkeit" der Bäume hängt maßgeblich von 2 Faktoren ab: der Dicke des Stamms und der Höhe.
Im Klartext: je höher der Baum, desto langsamer reagiert er auf den Einfluss des Windes; sehr hohe Bäume schwingen langsam und weniger "chaotisch", sondern biegen sich fast ausschließlich nur in Richtung des Windes und wieder zurück. Und je dicker der Stamm, desto weniger biegt sich der Baum insgesamt; bei geringen Windgeschwindigkeiten biegen sie sich quasi gar nicht, das Schwingen fängt gefühlt schon zu früh/bei zu wenig Wind an.
Und je dichter die Bäume zusammen-stehen, desto synchroner schwingen sie, weil sie von den gleichen Wind-Böen beeinflusst werden.
[Edit:] Wichtig, das meine ich nur bei den Bäumen/Baumstämmen insgesamt; die Äste und Blätter sind genau richtig so wie sie sind!

Hier mal ein Video was ich meine:
https://www.youtube.com/watch?v=WKcbAiGJy60
Man beachte die eher chaotische Reaktion des Farns unten in der Mitte, und im Vergleich dazu das "Geschwinge" der Bäume links oben im Mittel-/Hintergrund.
Besonders bei 0:20 - 0:24, wo eine starke Böe kommt; der Farn geht ab wie sonstwas, aber die Bäume schwingen trotzdem eher langsam, fast so wie vorher (nur etwas stärker im Ausschlag).

Wenn du das noch in das Wind-System rein-gebacken bekommst, dann wär das der absolute Über-Hammer; das hat nämlich noch niemand so hinbekommen :)

[Chromanoid]

Das sieht echt super aus. Ich wäre ja immer noch dafür, dass Du mal versuchst die Spielfigur kleiner zu machen, alles drumherum etwas größer, die Blöcke etwas kleiner und die Ferne mit extremen DoF wegblurst. Dann steuert man eine Maus oder sowas und Du kannst sofort mit einem Spiel beginnen. Wenn Du es etwas standardmäßiger haben willst, dann mach halt sowas wie die Mäuse von Redwall oder die Leute von Ghost of a Tale nur eben mit richtigen Proportionen. Also anthropomorphe Viecher mit Rüstungen und so.

[Zudomon]

@NytroX
Danke für dein Detailliertes Feedback. Es ist in der Tat schon so, dass ich angeben kann, wie schnell alles schwingt. Dabei ist das aber noch nicht so ganz zugänglich von außen. Also für das Gras usw. kann ich direkt mit angeben, dass die Grashöhe, also auch die Dicke die Schwinggeschwindigkeit beeinflusst. Bei den Objekten wie Bäume usw. spielt zwar etwas die Objektgröße mit rein. Dabei sind die Bäume durch ihre Struktur auch sehr schwierig. Es gibt dazu ja Technikansätze, die jedes Level einzeln berechnen. Dafür bräuchte ich allerdings dann auch bei jedem Vertex im VS den dazugehörigen Parent bzw. sogar mehrere. Das wollte ich vorerst noch vermeiden. Eine noch bessere Lösung wäre, den Bäumen auch Skelette zu verpassen. Dann könnten große Äste wirklich individuell schwingen.
Das Ganze ist ja nach wie vor nur ein VertexShader. Nun hat jeder Vertex nur eine Variable, wie Stark grober Wind diesen beeinflusst (das ist für das wegdrücken und schwingen verantwortlich), eine Variable, wie die Phase verschoben ist. Z.B. hat jedes große Farbblatt eine andere Phase und dadurch schwingt es zeitlich versetzt. Und eine dritte Variable gibt an, wie stark Mikrowind das Ganze beeinflusst. Das sieht man z.B. gut auf den kleinen Brennnessel Blättern.
Also muss ich später mal schauen, wie sich das noch ein bisschen verbessern lässt.
Das Bäume in einer Gruppe synchroner schwingen ist ein guter Tipp, den ich noch nie realisiert habe.

@Chromanoid
Vorerst wird das nichts... :D

Also anthropomorphe Viecher mit Rüstungen und so.

Da bin ich noch am hadern, ob es die allerdings tatsächlich geben wird :D

[Zudomon]

Bin gerade beim rumlaufen auf eine Goldader unterm Nachthimmel gestoßen :D

Hab mal Gamma und Brightness erhöht, damit man auch was sieht, wenn man das nicht Fullscreen vor sich hat.

Ob es wohl reicht, wenn die Bäume hinterher nur an einer Stelle durchtrennbar sind?!

[antisteo]

Ich glaube, ich stoße hier so langsam an meine Grenze...
Weder die scharfen Kanten bekomme hin, noch vernünftige, ich weiß gar nicht wie das heißt, diese Splitter die da raus ragen. Also es ist zwar Ansatzweise zu erkennen was es sein soll, aber weiter komme ich da erstmal nicht. Ich denke, ich lass es dann erstmal so.

20170203_6.jpg

Ich denke, ein Schwachpunkt bei deiner prozeduralen Textur ist momentan noch die dritte Dimension. Du rechnest die Jahresringe schön raus, aber in Richtung Höhe des Baums muss es auch noch irgendeine Struktur geben; sonst sehen die scharf gesägten Kanten einfach nur matschig aus. Ich weiß, dass du das noch besser kannst!

[Zudomon]

Ich glaube, ich stoße hier so langsam an meine Grenze...
Weder die scharfen Kanten bekomme hin, noch vernünftige, ich weiß gar nicht wie das heißt, diese Splitter die da raus ragen. Also es ist zwar Ansatzweise zu erkennen was es sein soll, aber weiter komme ich da erstmal nicht. Ich denke, ich lass es dann erstmal so.

Der Dateianhang 20170203_6.jpg existiert nicht mehr.

Ich denke, ein Schwachpunkt bei deiner prozeduralen Textur ist momentan noch die dritte Dimension. Du rechnest die Jahresringe schön raus, aber in Richtung Höhe des Baums muss es auch noch irgendeine Struktur geben; sonst sehen die scharf gesägten Kanten einfach nur matschig aus. Ich weiß, dass du das noch besser kannst!

Also die Textur an sich wird schon 3D berechnet...

Wie schon gesagt wurde, dass die Kanten nicht scharf sind liegt daran, dass die Normalen Gouraud sind. Aber an den Kanten dürften die nicht gemittelt werden. Das kann ich aber momentan nicht umsetzen.

[Zudomon]

[Krishty]

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

[xq]

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

[DerAlbi]

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.

[Zudomon]

@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...

(gefaktes) Alphablending:

Alphatesting:

@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.

Hier sieht man, wie das SSAO mit 4 Samples ohne TAA aussieht...

Hier dann gemittelt... beim Screenshot fällt es mehr auf, als wenn man es dann Ingame hat, weil sich das Pattern eben schnell verändert... dadurch wirkt es dann wesentlich weicher. Hab das aber auch gerade erst festgestellt, als ich den Screen gemacht habe.

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.

So würde es aussehen, wenn man die Bäume auch im Hintergrund hätte. Der Polycount ist entsprechend hoch und die FPS niedrig. Aber damit man eine Vorstellung hat, in welche Richtung es dann geht.

[DerAlbi]

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.

[Zudomon]

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.

[Zudomon]

Ich liebe dieses virtuelle Sonnenlicht! <3

53 FPS auf High

[Sunroc]

Jau, das ist wirklich beeindruckend. :)

[Zudomon]

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...

[Schrompf]

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.

[Zudomon]

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.

[Zudomon]

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...

[Zudomon]

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.

[Schrompf]

Sehr cool. Wieviel hat das denn gebracht?

[Zudomon]

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