[Projekt] StoneQuest lebt noch!

[Zudomon]

Also ich hatte vorher jedes Material eines Objektes per Bounding geprüft, ist natürlich langsamer, als wenn ich das ganze Objekt prüfe. Außerdem lass ich für Objekte jetzt erstmal das Occlusion Culling weg, welches eh nur für nahe Patches vernünftig berechnet wird.
Außerdem habe ich für die entfernten Objekte nun noch ein zusätzliches LOD eingebaut... sauber ist das alles nicht, muss da sowieso nochmal an den Baumgenerator ran später. Aber auf Ultra komme ich so auf etwa 20 FPS. Auf High sind es immerhin schon 30-60.

Aber ich wollte dann doch die Screenshots lieber auf Ultra :D

Die Shadowmap reicht allerdings gar nicht bis zu den hinteren Bäumen. Und auch wenn das schon nicht so verkehrt aussieht, da ist noch gar keine Form von GI drin. Selbst für die Landschaft ist da kein AO berechnet.

[Zudomon]

[Schrompf]

Immer noch sehr begeistert. Mal gucken, ob ich mir das mal wieder runterlade, um mal durchzulaufen.

[xq]

Hast du was an der Farbabstimmung zwischen Hintergrund und Vordergrund gemacht? Mit den Bäumen sieht es jetzt auf jeden Fall schon massiv besser aus!

[Zudomon]

Immer noch sehr begeistert. Mal gucken, ob ich mir das mal wieder runterlade, um mal durchzulaufen.

Ja, gönne deiner Internet Leitung die 12 Megabyte :D
Man muss sich auch schon ewig nicht mehr über ein Forum registrieren... nur Name und Passwort direkt da eingeben. Allerdings kann man auch noch keine EMail oder so hinterlegen, falls der Acc verloren geht. Wird aber eh später wieder alles zurückgesetzt.
Die neue View-Distanz ist aber noch nicht released, der Fels allerdings. Werde das erst releasen, wenn die Baumverteilung klappt und es noch optimierter ist.

Hast du was an der Farbabstimmung zwischen Hintergrund und Vordergrund gemacht? Mit den Bäumen sieht es jetzt auf jeden Fall schon massiv besser aus!

Die Shadowmap hat den Hintergrundbereich nicht abgedeckt gehabt. Dadurch wirkten da die Bäume wesentlich unrealistischer.

[Zudomon]

Weitsicht ich kommmmmeeeeee! :lol:

Zumindest bald... die Bäume springen noch rum, weil sie noch nicht deterministisch erstellt werden. Ein bisschen haut das auch noch ins Memory. Und trotz bereits einiger Optimierungen läuft es auf High bei mir mit etwa 15 FPS.

Die Landschaft ist nun wesentlich größer...
Die Shadowmaps wurden ein bisschen angepasst, sind aber auch noch nicht optimal.

[DerAlbi]

Hihi, weißt du, was komplett ironisch ist? Jetzt, wo überall Bäume sind, wünscht man sich tatsächlich mal Abwechslung - sowas wie Lichtungen.. oder je nach dem wie man es nennen mag: "Biome".
Aber wenn du das so in den Griff bekommst ist das schon extrem was wert.. es wär cool, wenn du mal nen Video machst..

[Zudomon]

Wenn das hinterher vernünftig läuft, mach ich ein Video... und ja, freie Stellen muss es später auch geben... aber das ist auch gar nicht so einfach, da nen Landschaftsgenerator für zu machen... zumal der auch noch extrem überarbeitet werden müsste, da der viel zu langsam ist.

[marcgfx]

Auf die Gefahr hin, dass ich mich wiederhole: Ich bin begeistert :) die Performance bekommst du auch noch in den Griff!

[Zudomon]

Also auf weite Distanz ersetze ich nun die Bäume durch Imposter. Wobei aktuell nur ein Imposter pro Baumtyp genutzt wird. Dadurch wird es doch um einiges schneller.
Die Bäume springen immer noch. Und es scheint, als ob der Schatten doch sehr langsam ist. An beidem muss ich mich später nochmal ran setzen.

[Raphael]

Ich bin eher einer stiller Mitleser, aber aktuell warte ich gespannt auf neue Screenshots von dir. Du scheinst die Fernsicht wirklich in den Griff zu bekommen, das empfand ich immer als hauptsächliche Herausforderung :o Vorallem im Zusammenspiel mit deinen dynamischen Wolken ist es sehr hübsch. Natürlich muss ich auch noch ein unqualifziertes Kommentar abgeben: Ich denke es würde "realistischer" aussehen, wenn das Terrain insgesamt weicher wäre, es aber auch harte Klippen geben würde. Aktuell erscheint es eher wellig.

[starcow]

Wow!
Es wäre toll, das ganze mal in Bewegung zu sehen. Z. B. in einem Video! :D

Gruss starcow

[DerAlbi]

VideoWunsch++.

[xq]

Schließe mich dem Videowunsch an!

Ansonsten: Sehr geile Arbeit, die Details im Hintergrund füllen das ganze mit wesentlich mehr Leben als vorher! Mit gefällt auch der Orange-Stich des einen Screenshots sehr

[Zudomon]

Vielen Dank euch allen! Ich freue mich immer, wenn ihr hier schreibt! :D

Die Landschaftgenerierung muss sowieso noch stark überarbeitet werden.

Video würde ich super gerne machen, aber solange die Bäume da hin und her hüpfen ist das einfach nur grottig. Das muss ich vorher noch in den Griff bekommen. Außerdem habe ich noch das Problem mit den Schatten bzw. vor allen mit den Bäumen. Egal ob der Hintergrund aktiv ist oder nicht, der Vordergrund, wenn da zu viele Bäume sind und Schatten aktiviert ist, ist viel zu langsam. Da komme ich auf High auch nur auf 30 FPS. Wenn ich davon ein Video machen würde, wäre das nur am ruckeln.
Das Problem ist, dass durch die ganzen Blätter der Bäume viel zu viel Overdraw entsteht. Naja, ich schaue mal einfach, dass ich dafür noch Lösungen finde. Und dann mache ich ein Video, versprochen. Wollt ihr denn irgendwas besonderes in dem Video, oder nur ein bisschen durch die Gegend laufen?

Hier sieht man die wenigen FPS: Zu viele Polys, zu viel Overdraw der Bäume.

[Schrompf]

Ich find's enorm, wie sich das entwickelt hat. Ich mag diese Schwaden von Bodennebel, die bauen unglaublich viel Atmosphäre auf. Die Tiefenunschärfe sieht auf Bildern geil aus, aber die hauen Dir die Spieler dann um die Ohren. Auf dem letzten Bild sieht man dann auch, welches nächste Langzeitproblem sich am Horizont abzeichnet: sinnvolle indirekte Beleuchtung, damit z.b. die Bäume nicht so "reingemalt" aussehen.

[Jonathan]

Egal ob der Hintergrund aktiv ist oder nicht, der Vordergrund, wenn da zu viele Bäume sind und Schatten aktiviert ist, ist viel zu langsam. Da komme ich auf High auch nur auf 30 FPS. Wenn ich davon ein Video machen würde, wäre das nur am ruckeln.

Wie ist denn Schatten derzeit implementiert?

[Zudomon]

Ist ne eigene Shadowmap Variante. Aber das Problem ist letztendlich das gleiche wie bei ner normalen Implementation. Die Baumblätter erzeugen viel Overdraw. Und die Anzahl an (unnötigen) polygone gekoppelt mit nem langen vertexshader geben dem Ganzen den Rest.
Deswegen überarbeite ich nun erstmal die Bäume.

[Zudomon]

Okay... also Ziel ist ja, Overdraw der Bäume zu minimieren und Polygone.
Ob ersteres geklappt hat, weiß ich nicht... aber bei letzterem bin ich hart gefailed.
Irgendwie sind es doch ein paar mehr Polygone geworden als gedacht. Da ich momentan auch noch kein LOD bis auf die Imposter drin habe, bin ich jetzt gerade beim test bei 300 Millionen Dreiecke pro Frame, bei etwa 3-4 FPS.
Aber zeigen muss ich es trotzdem... :lol:

[marcgfx]

Was hast du denn versucht zu machen? Wurde aus deinem Post nicht schlau... LOD für die Blätter ist sicher eine gute Idee, ich vermute das war ein Ziel?
Oder Imposter Blättergruppen, die nach und nach durch LOD-Blättern ersetzt werden. Gibt sicher viele Möglichkeiten, aber es ist bestimmt nicht einfach :mrgreen:

[Zudomon]

Also ich bastel an einem neuen Baumgenerator rum. Aber statt Sprites für die letzten Blätter zu benutzen, werden diese nun auch wirklich einzeln generiert und haben sogar eine Form. Das verursacht eine menge mehr Polygone.
Die Bäume haben noch kein LOD, deswegen wird es doch sehr langsam, wenn man mehrere Bäume rendert. Auf den Bildern sieht man einige gleich hoch skalierte Bäume. Und ich dachte mir, davon kann man ruhig mal Screenshots zeigen.
Den Baum selbst gibt es dann später zu sehen. Aber da will ich erstmal noch ein paar Sachen schaffen.

[Zudomon]

Der neue Baum hat momentan jetzt 2,1 Millionen Dreiecke... dabei ist der Hauptstamm aber noch sehr low poly. Extrem viele Dreiecke werden bei dem kleinen Geäst vor den Blättern verpulvert.
Die Blätter sind nicht einfach flach, sondern haben auch eine Form.
Der Wind funktioniert auf dem Baum auch schon und wirkt besser als auf den alten. Vielleicht sollte ich davon auch nochmal ein Video machen :D

[scheichs]

Vllt. solltest du wirklich überlegen die Rendermethode zu wechseln. Statt Pathtracing würde ich erstmal nur einfach normales Raytracing nutzen. Da Du ja eigentlich alles prozedural und trotzdem das meiste statisch oder nur begrentzt dynamisch ist, könntest Du dann noch viel mehr Polygone benutzen. Würde ja z.B. auch Dein Schattenproblem lösen(da könnte man für nahe Schatten z.b. ja auch paar mehr Samples verballern um weiche Schatten zu machen).
Das wäre bestimmt ein uniquer Ansatz.

EDIT:
Nur zur Klarstellung, "Raytracing statt Pathtracing" bezieht sich auf Deine Aussagen in Deinem Pathtracing Projekt, wo Du meintest, Du überlegst auf Pathtracing auch bei Stonequest umzustellen.

[Schrompf]

Raytracing? Pathtracing? Hab ich was nicht mitbekommen? Zudo haut doch einfach nur Aber-Millionen Flächen auf den Rasterizer.

[scheichs]

Raytracing? Pathtracing? Hab ich was nicht mitbekommen?

Hmm komisch. Du hast doch sein Pathtracing Projekt verfolgt. Dort schrieb er, dass er überlegt auch in Stonequest auf Pathtracing zu gehen. Davon würde ich abraten, wegen der bekannten Performance. Raytracing hingegen wäre im Einsatzfall "Stonequest" wohl schnell genug.
Dazu hätte er noch Reflektionen und Brechungen on top. Das haben wir ja -dynamisch- glaube ich noch nicht gesehen in Stonequest.
Ich bin normalerweise absolut kein Befürworter von Raytracing, aber ich finde hier, und bei seiner Expertise mit der Thematik zwängt es sich förmlich auf!

Zudo haut doch einfach nur Aber-Millionen Flächen auf den Rasterizer.

Ja. >1Mrd Polys/s, Probleme mit Shadows, Occlusion und Overdraw. Ideal für Raytracer, scheisse für Rasterizer.
Zugegeben die Materialshader wären in der momentanen Form wohl ein Bottleneck. Das müsste er mal schnell exemplarisch prototypen.

Ich befürchte jetzt geht wieder eine Rasterizer vs. Raytracing Diskussion los... :roll:

EDIT:

Wie gesagt, Ray Tracing kann ab einer gewissen Menge von Geometrie effizienter sein, wobei es da eher um die bereits angesprochene Dichte (Polygone pro (Sub-)Pixel) geht, als die Gesamtmenge von Polygonen, bzw. Größe der Szene. Problematisch ist dann, dass das so mehr oder weniger nur für statische Geometrie gilt. Sobald in jedem Frame erstmal Beschleunigungsstrukturen aktualisiert werden müssen, damit man effizient Strahlen testen kann, ist rein von der Komplexität her der Vorteil praktisch direkt dahin. Ob das in der Praxis dann insgesamt noch effizienter ist, hängt wohl stark vom Einzelfall ab, insbesondere der Menge zu aktualisierender Geometrie.

Ich würde mal sagen, das haben wir hier gegeben.

[Schrompf]

Für den PolyCount wäre RayTracing evtl. nicht mehr so enorm benachteilt wie in Echtzeit-Szenarien. Das mag sein. Ich bezog mich auf das hier:

Statt Pathtracing würde ich erstmal nur einfach normales Raytracing nutzen.

Das klang für mich, als denkst Du, dass Zudo aktuell PathTracing benutzt, und Du ihm den Wechsel auf RayTracing empfiehlst.

[marcgfx]

Durch die Blätter nach oben sieht richtig krass aus Zudo :)

[scheichs]

Das klang für mich, als denkst Du, dass Zudo aktuell PathTracing benutzt, und Du ihm den Wechsel auf RayTracing empfiehlst.

Stimmt... ich hab da wohl was vornedran rausgelöscht. :D

[Zudomon]

Was ist hier los? Da ist man mal kurz dreieinhalb Std. schlafen und der Thread wird richtig aktiv, aber das freut mich! :D

Also das ganze ist Rasterizing. Mit dem Pathtracing war experimentell und ich hoffe, mal irgendwann die Erfahrung von da mit ins Spiel einfließen lassen zu können.
Aber Pathtracing sehe ich in erster Linie sinnvoll an wegen dem GI. Einen Durchsatz von einer Milliarde Polygone pro Sekunde habe ich schon mal damals auf der GTX 460 geschafft. Das sind dermaßen viel, dass man bei FullHD bei 60 FPS 13 Dreiecke pro Pixel verwenden kann. Ich mag die grundlegende Idee und Einfachheit hinter Raytracing, aber ich glaube, nur um viele Polygone zu benutzen bringt das nicht wirklich was. Denn wie hier schon erwähnt wurde, muss man pro Frame die Beschleunigungstrukturen aktualisieren. Da sehe ich ein großes Problem, wenn man z.B. Wind für Gras und Bäume haben möchte. Vielleicht kann man da auch tricksen, z.B. durch Instanzing. Also ich meine, wenn für den Baum jetzt eine Beschleunigungstruktur aufgebaut wird, dann kann man die ja wieder verwenden bei der nächsten Instanz des Baumes. Sehe hier aber das Problem, dass jeder Baum durch den Wind anders beeinflusst wird. Also kann man eigentlich doch nicht die Struktur wieder verwenden.

Ich sehe das Hauptproblem bei dem hohen Polygondurchsatz und der Szene eigentlich darin, dass man die Dreiecke gut verteilen muss, die man zur Verfügung hat.
Nutzt man für die Bäume nur LOD für den gesamten Baum hat dieser entweder viele oder wenig Polygone, je nachdem wie weit man weg ist. Was man da eigentlich braucht ist, hierarchisches LOD. Wenn man an der einen Baumseite steht, dann können im hinteren Teil die Zweige und Blätter schon bereits Detailloser sein.
Bei dem Schatten sollte man eigentlich noch aggressiver LOD anwenden können. Da dieser eh geblurred wird, machen da Polygone im Subpixelbereich noch weniger Sinn.

Also ich hoffe, ich bin da nicht zu optimistisch, aber eigentlich sollten diese Bäume in dem Detail auf High End Rechnern flüssig dargestellt werden können, wenn es richtig optimiert ist.

[scheichs]

Ich mag die grundlegende Idee und Einfachheit hinter Raytracing, aber ich glaube, nur um viele Polygone zu benutzen bringt das nicht wirklich was. Denn wie hier schon erwähnt wurde, muss man pro Frame die Beschleunigungstrukturen aktualisieren. Da sehe ich ein großes Problem, wenn man z.B. Wind für Gras und Bäume haben möchte. Vielleicht kann man da auch tricksen, z.B. durch Instanzing. Also ich meine, wenn für den Baum jetzt eine Beschleunigungstruktur aufgebaut wird, dann kann man die ja wieder verwenden bei der nächsten Instanz des Baumes. Sehe hier aber das Problem, dass jeder Baum durch den Wind anders beeinflusst wird. Also kann man eigentlich doch nicht die Struktur wieder verwenden.

Ja deswegen schrieb ich oben begrenzt dynamisch (z.B. weiss man aufgrund der Windstärke und der Baumparameter wie maximal sich die Boundingbox aufweiten kann). Mein Wissen über Raytracing ist schon relativ angestaubt, ich würde aber mal vermuten, dass es für solche Fälle optimierte Beschleunigungsstrukturen gibt oder man sie für Stonequest mit überschaubarem Aufwand entwickeln/anpassen kann.
Wegen GI würde ich mir da überlegen die Idee von VoxelGI, aka SVOGI aus dem Rendering zu klauen. Vielleicht lässt sich das sogar mit dem Update der Beschleunigungsstruktur kombinieren. Dann hättest Du auch diffuse Reflektion "umsonst".
Ich sehe grad, jemand hat das schon bei Minecraft ähnlich gemacht (das SVOGI ist ein anderes Video)
[youtube]6ocHnD_LsEI[/youtube]
Das ganze jetzt mit dem Content von Stonequest könnte dann zum nie dagewesenen Überflieger mutieren. Vielleicht seh' ich's aber auch zu blauäugig. Wie gesagt, man müsste es halt mal prototypen.