[Projekt] StoneQuest lebt noch!

Hier könnt ihr euch selbst, eure Homepage, euren Entwicklerstammtisch, Termine oder eure Projekte vorstellen.
Forumsregeln
Bitte Präfixe benutzen. Das Präfix "[Projekt]" bewirkt die Aufnahme von Bildern aus den Beiträgen des Themenerstellers in den Showroom. Alle Bilder aus dem Thema Showroom erscheinen ebenfalls im Showroom auf der Frontpage. Es werden nur Bilder berücksichtigt, die entweder mit dem attachement- oder dem img-BBCode im Beitrag angezeigt werden.

Die Bildersammelfunktion muss manuell ausgeführt werden, die URL dazu und weitere Details zum Showroom sind hier zu finden.

This forum is primarily intended for German-language video game developers. Please don't post promotional information targeted at end users.

Re: [Projekt] StoneQuest lebt noch!

Beitragvon Schrompf » 17.07.2017, 07:57

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.
Häuptling von Dreamworlds. Baut an was Neuem. Hilft nebenbei nur höchst selten an der Open Asset Import Library mit.
Benutzeravatar
Schrompf
Thomas Ziegenhagen
Moderator
 
Beiträge: 3611
Registriert: 26.02.2009, 00:44
Wohnort: Dresden
Benutzertext: Lernt nur selten dazu

Re: [Projekt] StoneQuest lebt noch!

Beitragvon Jonathan » 17.07.2017, 16:26

Zudomon hat geschrieben: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?
Lieber dumm fragen, als dumm bleiben!
Benutzeravatar
Jonathan
 
Beiträge: 1153
Registriert: 04.08.2004, 20:06

Re: [Projekt] StoneQuest lebt noch!

Beitragvon Zudomon » 17.07.2017, 22:23

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.
Bild
Benutzeravatar
Zudomon
 
Beiträge: 2066
Registriert: 25.03.2009, 08:20

Re: [Projekt] StoneQuest lebt noch!

Beitragvon Zudomon » 18.07.2017, 09:11

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:

20170718_12.jpg


20170718_13.jpg
Zuletzt geändert von Zudomon am 18.07.2017, 12:16, insgesamt 1-mal geändert.
Bild
Benutzeravatar
Zudomon
 
Beiträge: 2066
Registriert: 25.03.2009, 08:20

Re: [Projekt] StoneQuest lebt noch!

Beitragvon marcgfx » 18.07.2017, 09:27

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:
Benutzeravatar
marcgfx
 
Beiträge: 1043
Registriert: 18.10.2010, 23:26

Re: [Projekt] StoneQuest lebt noch!

Beitragvon Zudomon » 18.07.2017, 09:45

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.
Bild
Benutzeravatar
Zudomon
 
Beiträge: 2066
Registriert: 25.03.2009, 08:20

Re: [Projekt] StoneQuest lebt noch!

Beitragvon Zudomon » 18.07.2017, 12:23

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

20170718_17.jpg


20170718_18.jpg


20170718_16.jpg


20170718_19.jpg
Zuletzt geändert von Zudomon am 20.07.2017, 07:56, insgesamt 1-mal geändert.
Bild
Benutzeravatar
Zudomon
 
Beiträge: 2066
Registriert: 25.03.2009, 08:20

Re: [Projekt] StoneQuest lebt noch!

Beitragvon scheichs » 18.07.2017, 14:46

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.
Zuletzt geändert von scheichs am 18.07.2017, 18:01, insgesamt 1-mal geändert.
scheichs
 
Beiträge: 213
Registriert: 28.07.2010, 20:18

Re: [Projekt] StoneQuest lebt noch!

Beitragvon Schrompf » 18.07.2017, 14:51

Raytracing? Pathtracing? Hab ich was nicht mitbekommen? Zudo haut doch einfach nur Aber-Millionen Flächen auf den Rasterizer.
Häuptling von Dreamworlds. Baut an was Neuem. Hilft nebenbei nur höchst selten an der Open Asset Import Library mit.
Benutzeravatar
Schrompf
Thomas Ziegenhagen
Moderator
 
Beiträge: 3611
Registriert: 26.02.2009, 00:44
Wohnort: Dresden
Benutzertext: Lernt nur selten dazu

Re: [Projekt] StoneQuest lebt noch!

Beitragvon scheichs » 18.07.2017, 15:53

Schrompf hat geschrieben: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!

Schrompf hat geschrieben: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:
CodingCat hat geschrieben: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.
scheichs
 
Beiträge: 213
Registriert: 28.07.2010, 20:18

Re: [Projekt] StoneQuest lebt noch!

Beitragvon Schrompf » 18.07.2017, 16:07

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:

scheichs hat geschrieben: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.
Häuptling von Dreamworlds. Baut an was Neuem. Hilft nebenbei nur höchst selten an der Open Asset Import Library mit.
Benutzeravatar
Schrompf
Thomas Ziegenhagen
Moderator
 
Beiträge: 3611
Registriert: 26.02.2009, 00:44
Wohnort: Dresden
Benutzertext: Lernt nur selten dazu

Re: [Projekt] StoneQuest lebt noch!

Beitragvon marcgfx » 18.07.2017, 17:08

Durch die Blätter nach oben sieht richtig krass aus Zudo :)
Benutzeravatar
marcgfx
 
Beiträge: 1043
Registriert: 18.10.2010, 23:26

Re: [Projekt] StoneQuest lebt noch!

Beitragvon scheichs » 18.07.2017, 18:00

Schrompf hat geschrieben: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
scheichs
 
Beiträge: 213
Registriert: 28.07.2010, 20:18

Re: [Projekt] StoneQuest lebt noch!

Beitragvon Zudomon » 18.07.2017, 18:20

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.
Bild
Benutzeravatar
Zudomon
 
Beiträge: 2066
Registriert: 25.03.2009, 08:20

Re: [Projekt] StoneQuest lebt noch!

Beitragvon scheichs » 18.07.2017, 19:04

Zudomon hat geschrieben: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)

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.
scheichs
 
Beiträge: 213
Registriert: 28.07.2010, 20:18

VorherigeNächste

Zurück zu Vorstellungsbereich

Wer ist online?

Mitglieder in diesem Forum: Bing [Bot] und 2 Gäste

cron