Zombie-Shooter

Spiel zu Halloween, Abgabe bis 31.10.2021
Benutzeravatar
Schrompf
Moderator
Beiträge: 4392
Registriert: 26.02.2009, 00:44
Benutzertext: Lernt nur selten dazu
Echter Name: Thomas Ziegenhagen
Wohnort: Dresden
Kontaktdaten:

Re: Zombie-Shooter

Beitrag von Schrompf »

Vielen Dank für die Erklärung!
Häuptling von Dreamworlds. Baut an was Neuem. Hilft nebenbei nur höchst selten an der Open Asset Import Library mit.
Benutzeravatar
grinseengel
Establishment
Beiträge: 393
Registriert: 29.03.2011, 13:47
Echter Name: Andreas

Re: Zombie-Shooter

Beitrag von grinseengel »

Aber was würde sich denn für eine Mission anbieten? Die Sache ist, ich würde glaube ich keine riesigen Maps bauen wollen. Zum einen, weil es Aufwand ist, zum anderen, weil ich mir ein klein wenig Sorge mache, was die effiziente Verwaltung angeht - aktuell habe ich nur sehr rudimentäres View-Frustum Culling, fast nichts was in Richtung LOD geht, und auch sonst nicht so viele Optimierungen. Braucht halt alles Zeit, die ich dann bisher meist eher ins Spiel gesteckt habe. Vielleicht müsste man einfach mal einen Stress-Test machen und ein großes Level bauen und gucken, was passiert.
Natürlich sind diese Spielen Open World, somit wird es dann wohl in der Art nicht funktionieren. Aber du könntest ja die Welt in kleine Regionen aufteilen, je nach Infektionsgrad der Zombies und dort eine abgeschlossene Mission kreieren. Am Ende hast du dann die Welt gerettet, indem überall ein Heilmittel existiert (Corona lässt grüßen...=).....
joggel
Establishment
Beiträge: 1636
Registriert: 06.11.2007, 19:06

Re: Zombie-Shooter

Beitrag von joggel »

Ja, danke für die Erklärung!
Ich habe da ja nicht so viel Ahnung was PBR betrifft (fällt diese/deine RenderTechnik eigentlich unter PBR?)
Ich muss mich ja damit auch langsam beschäftigen, denn ich will auch in meinem Tool (remember? CSG-Editor!) vlt auch PBR-Texturierung unterstützen...
Benutzeravatar
Jonathan
Establishment
Beiträge: 1824
Registriert: 04.08.2004, 20:06
Kontaktdaten:

Re: Zombie-Shooter

Beitrag von Jonathan »

joggel hat geschrieben:
08.11.2021, 17:40
fällt diese/deine RenderTechnik eigentlich unter PBR?
Hm, ein bisschen. Es ist halt das Standard-Frostbite-BRDF Modell, welches Metallicity und Roughness als Parameter unterstützt und dafür ein Microfacetten-Modell approximiert und den Fresnel-Term benutzt, und so weiter. Außerdem ist es im Gegensatz zu Phong (was ich vorher hatte) energieerhaltend, d.h. es wird nie mehr Licht reflektiert, als das Objekt auch tatsächlich erreicht hat. Für mich bedeutet das aber eigentlich nur, dass ich mehr Materialparameter habe und die Übergänge schöner aussehen.
Der zweite wichtige Aspekt von PBR wäre dann aber wohl noch, dass man tatsächlich physikalische Werte benutzt. Entfernungen in Metern, Lichstärke in Watt (oder Lux, oder Lumen, oder was weiß ich was), und wenn du ein Level baust, das einem echten Raum nachempfunden ist und du gemessene Materialparameter nimmst und Kalibrierte Lichtquellen, dann sieht dein Rendering auch genau so aus, wie ein Foto dieses Raums. Außerdem hat man Objekte vernünftig von ihrer Umgebung getrennt, ich hab gelesen, dass es früher wohl ein Problem war, dass Assets die für ein Level gebaut wurden, in einem anderen dann sehr schlecht aussahen, weil man vielleicht statt die Lichtfarbe zu ändern die Materialfarbe geändert hat, oder die Reflektivität erhöht anstatt das Licht heller zu machen oder so Dinge. Wenn man konsequent auf PBR setzt, kann der Artist also seine Lichtquelle einfach auf den richtigen Wert (gemessen an einer echten Lampe) setzen und dann tut das auch, und alles kann miteinander kombiniert werden und stimmt dann immer. Das mache ich aber nicht, ich stecke einfach irgendwelche Werte in die Formeln, ich hab nichtmal einen Fließkomma-Buffer mit Tonemapping sondern erzeuge im Pixelshader direkt die finale Farbe. Aber für kleinere Projekte funktioniert so ein vorgehen halt eigentlich ganz gut. Wie gesagt, ich hab die neue BRDF primär eingebaut, damit die Helligkeitsverläufe hübscher sind :D
Lieber dumm fragen, als dumm bleiben!
Benutzeravatar
Jonathan
Establishment
Beiträge: 1824
Registriert: 04.08.2004, 20:06
Kontaktdaten:

Re: Zombie-Shooter

Beitrag von Jonathan »

Nach langem Hacken hab ich jetzt sowohl Blending zwischen Animationsframes (bisher wurde immer der nächste genommen, weswegen die Animationen mit ~24 fps liefen und ruckelig aussahen), als auch fließende Übergänge zwischen den Animationen:
2021-11-13_00-44-33 Animation Blending .mp4
(1.62 MiB) 46-mal heruntergeladen
Teile des Blending-System sind bereits für mehr ausgelegt, so das auch komplexere Blends möglich sein sollten. Etwa nur bestimmte Teile des Skeletts zu animieren, wodurch die Angriffsanimation unabhängig von der Laufanimation wäre oder auch Trefferanimationen (ein Nach-hinten-rucken) über gerade spielende Animationen gelegt werden können.

Kurz zur Technik: Es gibt jetzt eine Liste aller Animationen die gleichzeitig abgespielt werden. Diese Playbackobjekte haben eine GetWeight Funktion, die das Grundgewicht (Geh-Animation: 20%, Lauf-Animation: 80%) noch mit einer Fading-Kurve multiplizieren (Gewicht nimmt über einen Zeitraum linear zu oder ab). Spiel man eine neue Animation ab, wird für diese ein Fade-In erzeugt, alle alten Loops bekommen ein Fade-Out. Das ganze geschieht dann aber pro Bone, d.h. wenn ein Teil des Skeletts nur von einer Animation beeinflusst wird, hat diese automatisch Gewicht 1.
Aktuell können pro Bone nur 2 Animationen geblendet werden, weil das gewichtete Mitteln von Quaternionen erstaunlich kompliziert ist. Ich schau mal, wann ich das brauche und was ich dann mache.
Lieber dumm fragen, als dumm bleiben!
Benutzeravatar
Schrompf
Moderator
Beiträge: 4392
Registriert: 26.02.2009, 00:44
Benutzertext: Lernt nur selten dazu
Echter Name: Thomas Ziegenhagen
Wohnort: Dresden
Kontaktdaten:

Re: Zombie-Shooter

Beitrag von Schrompf »

Sehr cool!
Häuptling von Dreamworlds. Baut an was Neuem. Hilft nebenbei nur höchst selten an der Open Asset Import Library mit.
Mirror
Establishment
Beiträge: 144
Registriert: 25.08.2019, 05:00
Alter Benutzername: gdsWizard
Kontaktdaten:

Re: Zombie-Shooter

Beitrag von Mirror »

Sieht sehr natürlich aus. Wieder was gelernt, danke.
ehemals gdsWizard, http://www.mirrorcad.com
Benutzeravatar
Jonathan
Establishment
Beiträge: 1824
Registriert: 04.08.2004, 20:06
Kontaktdaten:

Re: Zombie-Shooter

Beitrag von Jonathan »

Ich hatte ja neulich anderswo schon ein wenig gejammert, dass Überblenden von Animationen auch kompliziert werden kann. Außerdem brauchte ich ein paar mehr Features und so hab ich die letzten Tage das Animationssystem nochmal zu großen Teilen umgeschrieben. Ist jetzt Node-basiert, weil da ja heute alle coolen Kinder so machen.

Der Plan ist ja, dass man das Charaktermodell des Spielers in der Spielwelt sieht. Also nicht nur die Hände mit der aktuellen Waffe, sondern auch den Körper und die Beine (wenn man nach unten schaut). Damit man auch zugucken kann, wie man von Zombies gefressen wird und so, ihr versteht schon. Was ich bei dem Plan ein wenig übersehen hatte war, wie viele Animationen man braucht: Rumstehen, gehen, rückwärts gehen, springen, Waffen halten, angreifen, getroffen werden, usw.. Und das Problem ist dann ja natürlich, dass man nicht nur im Stehen Waffen halten können will, sondern auch beim Rumlaufen. Also eine extra Laufanimation für jede Waffe? Jetzt will man aber auch angreifen können. Also für jede Waffe eine Angriffsanimation im Laufen und im Stehen? Aber was, wenn man langsame Waffen wie den Baseballschläger hat und während dem Angriff stehenbleiben oder loslaufen will?
Viel einfacher ist es da natürlich, unterschiedliche Teile des Charakters getrennt zu animieren, so kann man beliebige Animationen miteinander kombinieren. Diese Idee ist allerdings gar nicht so alternativlos, wie man jetzt vielleicht glaubt, schließlich macht es total viel Sinn, den Baseballschläger anders zu schwingen, wenn man auf einen Zombie zurennt, als wenn man im Stehen ausholt. Und mit einer schweren Waffe in der Hand müssen sich durchaus auch die Beine anders bewegen.
In gewisser Hinsicht hat man also ein Budget-Problem: Die gute Lösung wäre, die ganze kombinatorische Explosion an Animationskombinationen einzeln angepasst zu animieren. Das mag am Anfang noch gehen, nur würde das sicherlich dazu führen, dass man z.B. nicht doch noch die 5te Waffe einbauen würde, weil man dafür auf einmal 12 neue Animationen bräuchte anstatt 2. Ich will entkopelte Features, damit ich es mir leisten kann, mein Spiel zu erweitern. Und Zweitens soll man natürlich z.B. auch zu jedem Zeitpunkt eines Angriffs loslaufen können. Irgendwie kombinieren muss man die Animationen also doch.

Also entschied ich mich für die Lösung, die statt einem halben Jahr Arbeit bloß eine Woche Arbeit bedeutet (d.h. ein paar Stunden, weil man ja nur nebenbei dran tüftelt). Doch dafür war mein System nicht cool genug, denn: Ich will die Arme unabhängig von den Beinen bewegen können und zusätzlich auf äußere Einflüsse reagieren können. Zombies sollen z.B. bei Treffern irgendwie nach hinten zucken oder zumindest sichtlich reagieren, und dann gibt es noch so Dinge wie Sterbeanimationen, die alle anderen Animationen überlagern. Es kann also vorkommen, dass ich gerade zwischen Laufen und Stehenbleiben interpoliere, während die Arme angreifen und ich gleichzeitig getroffen werde. Und das alles soll irgendwie weich und nett überblenden, damit nix zuckelig aussieht.

Also habe ich jetzt einen Graphen mit verschiedenen Nodes: Statische Pose, einzelne Animation abspielen, Animationen aneinander reihen (und dazwischen kurz überblenden) und Animationen überlagern (eine Animation, die nur einen Teil des Skeletts bewegt überlagert eine andere Animation). Die kann ich jetzt zu einen Graphen zusammenstöpseln und an den unterschiedlichen Nodes jeweils die passende Animation einspielen und somit korrekt die Hierarchie abbilden. Später kann das dann noch erweitert werde, z.b. durch generative Animationen, die eine feste Pose vorgeben (um den Kopf in eine bestimmte Richtung zu drehen), oder gar durch Inverse Kinematik (um Objekte zu greifen oder die Füße exakt auf den Boden / Treppenstufen zu setzen). Letzteres werde ich aber sicherlich noch etwas vor mir herschieben.

Die Rohfassung ist vorhin fertig geworden, in Bewegung sieht dass dann so aus:
2021-12-06_23-57-05_animation_nodes.mp4
(707.57 KiB) 43-mal heruntergeladen
(Blabla, Testmodelle und Animationen und so, außerdem hat der Spielercharakter keinen Kopf. Das ist nützlich, um dort die Kamera zu positionieren, alternativ haben Zombies halt das Gehirn gefressen)
Lieber dumm fragen, als dumm bleiben!
Benutzeravatar
Schrompf
Moderator
Beiträge: 4392
Registriert: 26.02.2009, 00:44
Benutzertext: Lernt nur selten dazu
Echter Name: Thomas Ziegenhagen
Wohnort: Dresden
Kontaktdaten:

Re: Zombie-Shooter

Beitrag von Schrompf »

Technisch nice! Sieht auch irgendwie glaubwürdiger aus, wenn die Arme mit den Schritten mitwippen, aber sich getrennt bewegen können. Aber die Testanims sehen echt fies aus :-) Wie der Char die Waffe hält, ist ein Fall für den Orthopäden.
Häuptling von Dreamworlds. Baut an was Neuem. Hilft nebenbei nur höchst selten an der Open Asset Import Library mit.
Benutzeravatar
Jonathan
Establishment
Beiträge: 1824
Registriert: 04.08.2004, 20:06
Kontaktdaten:

Re: Zombie-Shooter

Beitrag von Jonathan »

Schrompf hat geschrieben:
07.12.2021, 08:35
Aber die Testanims sehen echt fies aus :-) Wie der Char die Waffe hält, ist ein Fall für den Orthopäden.
Jaaaaaaaaa. Also, das war so: Kai hat den Charakter modelliert und rigged (wie heißt das in Alman-Sprech? Geknöchelt? Ich hab mir jedenfalls vorgenommen, Spawn-Punkte als Laichplätze zu bezeichnen, hihi) und zum testen eine schnelle Laufanimation erstellt. Ich brauchte die Waffen-Halte-Animation und hab selbst versucht, die Pose irgendwie hinzubiegen - und bin mit dem Rigg absolut nicht klargenommen. Aber unser abgesprochener Workflow ist, dass ich rumbastel, bis technisch alles drin ist und funktioniert, dann Kai sage, worauf er achten muss, und er dann die finalen Animationen machen kann. Weil man will ja nicht schöne fertige Animationen wegschmeißen, weil man eine Woche später merkt, dass es technisch ganz anders sein muss.
Lieber dumm fragen, als dumm bleiben!
Benutzeravatar
Schrompf
Moderator
Beiträge: 4392
Registriert: 26.02.2009, 00:44
Benutzertext: Lernt nur selten dazu
Echter Name: Thomas Ziegenhagen
Wohnort: Dresden
Kontaktdaten:

Re: Zombie-Shooter

Beitrag von Schrompf »

"Laichpunkte". Gnihihihi. Viel Spaß jedenfalls noch bei der Knochenbewegung und dem dazu nötigen Mit-Schnüren-Versehen.
Häuptling von Dreamworlds. Baut an was Neuem. Hilft nebenbei nur höchst selten an der Open Asset Import Library mit.
Benutzeravatar
Jonathan
Establishment
Beiträge: 1824
Registriert: 04.08.2004, 20:06
Kontaktdaten:

Re: Zombie-Shooter

Beitrag von Jonathan »

Oh wow, nach wirklich viel weiterer Arbeit sind die technischen Arbeiten an den Animationen nun quasi abgeschlossen. Das Animation-Node-System funktioniert soweit ganz gut und ich habe das Gefühl, damit recht leicht auch komplexere Dinge umsetzen zu können. Besonders diese Overlay-Nodes sind nett, denn so muss man sich z.B. bei einer Treffer-Animation nicht merken, zu welcher Animation man zurückgehen muss, da die Lauf-Animation im Hintergrund die ganze Zeit weiter lief oder sogar "heimlich" durch die Steh-Animation ersetzt wurde. Man kann tatsächlich in der einen Stelle im Code sagen "halte jetzt diese Waffe" in der nächsten "laufe rum und springe dann" und wieder woanders "zucke, weil du getroffen wurdest" und alles wird automatisch und robust sinnvoll kombiniert. Klar, eigentlich würde man für das perfekte Ergebnis tatsächlich viel mehr Variationen, die auch von anderen gleichzeitigen Zuständen abhängen, animieren wollen, aber aktuell hab ich quasi eine 20:80-Budget Lösung, die einfach ist und schon recht gut aussieht.

Der nächste Punkt, der viel schwerer war als erwartet: Waffen in die Hände drücken. Man kann ja runter gucken und seinen Körper sehen, und das macht alles schwerer, weil man weniger faken kann. Hier erstmal das Ergebnis:
Zombie_2021-12-28_00-10-36.jpg
Die einfachste Variante ist es, die Waffe direkt als Submesh in das Spielermodell zu packen. Aber vielleicht will man 5 verschiedene Charaktermodelle haben und vielleicht will man die Waffe eher separat haben, weil sie auch in der Spielwelt rumliegen soll und so. Meh.

Die nächste Idee war, die Waffe separat zu laden und an den Handknochen zu packen (indem man explizit Weights mit Stärke 1 für diesen Knochen generiert - ich will ja kein Constraint-System nachprogrammieren, pfff). Bloß steckt die dann dumm in der Hand. Man könnte einen Offset speichern, bloß ist der Handknochen in der Default-T-Pose einfach irgendwo und auch überhaupt nicht nett Achsen-ausgerichtet. Die Position könnte man notfalls von Hand anpassen, bei der Rotation will man das wirklich nicht. Zumal man diese zusätzliche Transformation prinzipiell für jede Kombination aus Gegenstand und Spielermodell benötigt - für viele ist sie vielleicht gleich, aber für sehr komische Gegenstände oder sehr komische Charaktermodelle braucht man die Möglichkeit das anzupassen schon irgendwie.

Die nächste Idee war, die Hand vom Mesh abzuschneiden und einmal manuell in den Ursprung zu transformieren. Diese Transformation wollte ich pro Charakter speichern, man kann die Hand dann in Blender in die Item-Dateien reinladen und in den Hintergrund legen und dann die Item-Position nur leicht anpassen, so dass das Item gut in der Hand liegt - man kann quasi einmal die komplizierte Transformation rausgerechnet und muss danach nur noch fein-justieren. Diese Grundtransformation wird von Hand rausgeschrieben was nervig ist, aber halt nur einmal pro Charaktermodell gemacht werden muss, das geht also schon.

Ich war nicht super happy aber zumindest hatte ich eine fertige Lösung bis, nun, bis es klar wurde, dass man viele Waffen ja mit zwei Händen benutzt, man muss also beim animieren sehen, wie die Waffe genau in der Hand liegt. In einer anderen Datei den Offset anpassen reicht da nicht. Oh. Letztendlich hab ich mich mit Kai verabredet (die meiste Kommunikation geht per Chat, aber hierfür mussten wir dann mal länger telefonieren), und wir haben eine neue Lösung erarbeitet: Das Skelett wird um einen "Waffen-Bone" erweitert:
blender_2021-12-28_00-01-23.png
Den kann man jetzt für jede Animation anpassen, für die "Schläger-Halten" Animation ist er entsprechend woanders als für die "Gewehr-Halten" Animation, ansonsten bewegt er sich in der Regel aber nicht. Könnte er natürlich, falls man mal cool seinen Revolver durch die Luft schleudern will, oder so. Alle Gegenstände können dadurch in externen Dateien mit einem sinnvollen Mittelpunkt modelliert werden und so auch in der Spielwelt verwendet werden, für das Player-Modell kann man sie dann rein-linken und als Vorschau an den Waffen-Bone binden. Für ähnliche Waffen (Schläger / Schaufel) reicht dann eine Animation, bei bedarf könnte man die aber auch komplett anpassen.

Ich hab bei all dem jetzt immernoch eine Menge Details weggelassen, das alles in Blender passend einzurichten und korrekt zu exportieren war natürlich wieder nervig, aber jetzt geht es. Als nächstes kommen dann orthopädisch-vertretbare Animationen, aber das ist nicht mehr meine Zuständigkeit. Ich kann mich jetzt noch um so Dinge wie "Der Schuss kommt auch wirklich aus der Waffe und nicht aus dem Bauch" kümmern, dank explizitem Waffen-Bone hab ich jetzt ja einen einfachen Weg den Startpunkt direkt aus der Animation korrekt extrahieren zu können.

Insgesamt sieht das Level noch fast gleich aus und es gibt jetzt 3 statt 2 Waffen, aber trotzdem ist seit Oktober super viel passiert und alles fühlt sich jetzt viel viel runder und netter an. Der ganze Kram macht dann doch immer viel mehr Arbeit als man denkt, aber so langsam wird es :)
Lieber dumm fragen, als dumm bleiben!
Benutzeravatar
Jonathan
Establishment
Beiträge: 1824
Registriert: 04.08.2004, 20:06
Kontaktdaten:

Re: Zombie-Shooter

Beitrag von Jonathan »

Weitere neue Features:

- Zombies drehen sich 'langsam', d.h. springen nicht mehr von eine Richtung in die andere. Das sah komisch aus.
- Zombies reagieren auf Angriffe und Laufen dann richtung Spieler
- Zombies haben Treffer-Animationen und zucken zusammen, wenn man sie trifft. Das macht das Verprügeln so unfassbar viel vergnüglicher als wenn sie einfach stumm alles ertragen.
- Zombies können durch Angriffe unterbrochen und kurz betäubt werden. Das ist nett fürs Gameplay: Aktuell macht der Spaten z.B. super wenig Schaden, kann aber Angriffe unterbrechen und die Gegner für 1.5 Sekunden dumm rumstehen lassen. Man kann dann einen einzelnen Gegner recht gefahrlos tot-knüppeln, hat aber Probleme, wenn mehrere kommen. Alternativ kann man sehr gut einmal zuhauen und dann weglaufen. Das Gewehr macht zwar viel Schaden, betäubt aber nicht, d.h. im Nahkampf kriegt man da leicht trotzdem Treffer ab. Macht natürlich wenig Sinn, dass Starke angriffe weniger betäuben als schwache, aber mit diesem System wird man sicherlich was nettes bauen können.
- Es gibt Schalter in der Spielwelt, die man umlegen kann, diese können dann Skripte auslösen (z.B. mehr Zombies laichen). Als nächstes soll es interaktive Türen geben, Gegenstände die man aufsammeln kann (Schlüssel, Artefakte für Rituale, etc.) und vielleicht Dinge wie Umgebungsfallen, mit denen man Monster töten kann, wenn man sie auslöst. Ich freue mich schon darauf, damit dann Missionen und Story umzusetzen.

Es fehlt aber leider auch noch viel:
- dynamische Lichtquellen wie etwa Fackeln. Braucht man halt für dunkle Spiele...
- Trefferzonen und noch viel komplexere Zombies. Mehr KI, mehr Interaktionsmöglichkeiten. Im Idealfall hätte ich gerne Dinge wie "Arm abschießen, damit der Zombie nicht mehr so stark angreifen kann", "Bein abschießen, damit der Zombie kriechen muss und super langsam ist", "Kopf abschießen, damit der Zombie einen nicht mehr sehen kann". Uff
- Splatter-Effekte wie Partikel und Decals.
Lieber dumm fragen, als dumm bleiben!
Benutzeravatar
Schrompf
Moderator
Beiträge: 4392
Registriert: 26.02.2009, 00:44
Benutzertext: Lernt nur selten dazu
Echter Name: Thomas Ziegenhagen
Wohnort: Dresden
Kontaktdaten:

Re: Zombie-Shooter

Beitrag von Schrompf »

Interessante Erzählung zum Animsystem. Wir hatten bei den Splitterwelten damals quasi das Gleiche erfunden: einen "Griff"-Bone als Child der Hand, der Position und Orientierung relativ zur Hand angibt. Bei uns waren damals alle Bones gleichzeitig auch Nodes im SceneGraph, da konnte man dann einfach die Waffe (bzw. bei uns Fackel, essbares Kraut, Elixier, YouNameIt) als Child des Griff-Bones einfügen und es ist mit jeder Pose des Chars mitgewandert.

Heutzutage isses ne subclevere Idee, alles in den SceneGraph zu schmeißen. Genauer gesagt ist ein SceneGraph schon ne dumme Idee. Und ein komplette BaseObject zu spawnen, nur um eine RotPos-Matrix relativ zum Hand-Bone zu speichern, geht auch effizienter. Heutzutage würde ich wahrscheinlich der Waffe eine Komponente "Bewegt sich mit BoneXY des Skeletts ABC mit" geben und fertig.

Je älter ich werde, desto mehr weiß ich diese simple imperative Programmierung eines ECS zu schätzen. Array aus "Mit Bone mitbewegen"-Strukturen, einfacher Pass relativ am Ende des Updatens updateTransformFromBone(std::span<TackToBoneComponent>) und glücklich sein. Bleibt natürlich nicht lange so simpel. Einen Charakter Dinge aufheben zu lassen oder etwas von CharA zu CharB weitergeben zu lassen ist heutzutage immer noch ein ungelöstes Rätsel selbst in AAA-Produktionen.
Häuptling von Dreamworlds. Baut an was Neuem. Hilft nebenbei nur höchst selten an der Open Asset Import Library mit.
Benutzeravatar
Jonathan
Establishment
Beiträge: 1824
Registriert: 04.08.2004, 20:06
Kontaktdaten:

Re: Zombie-Shooter

Beitrag von Jonathan »

Ja ich meine ich wollte den Weapon-Bone nicht als großartige Errungenschaft darstellen, im Prinzip meinte Kai "in einem Unity-Projekt haben wir das mal soundso gemacht" und das haben wir dann zusammen auf unsere Engine übertragen. Ich glaube das Problem ist hauptsächlich, dass es halt schwierige Probleme gibt (Wie rendert man effizient Schatten ohne Artefakte?), wo man dann Artikel zu ließt und einfache Probleme (wie können Charaktere Gegenstände halten), die so 'offensichtlich' und vlt. auch Engine-spezifisch sind, dass ich gar nicht auf die Idee kam zu gucken, wie andere es gemacht haben.
Lieber dumm fragen, als dumm bleiben!
Benutzeravatar
Jonathan
Establishment
Beiträge: 1824
Registriert: 04.08.2004, 20:06
Kontaktdaten:

Re: Zombie-Shooter

Beitrag von Jonathan »

Zombie_2022-01-09_01-19-50.jpg
Nachdem am Animationssystem viel gemacht wurde, haben wir ein wenig am Level gearbeitet. Die Welt ist jetzt größer und sinnvoller, es gibt endlich Multi-Texturing auf dem Terrain (das letzte Level hatte eine einzige gekachelte Grastextur...), und mehr Instancing-Objekte. Außerdem wird es dynamische Lichtquellen geben, im Bild oben sieht man einen Zombie der von der Spielerfackel hell erleuchtet ist.
Aktuell alles nur technische Tests, nachdem alles implementiert ist geht es dann an die Feinabstimmung. Aber schon jetzt gefällt es mir, der hell erleuchtete Zombie sieht schon viel gruseliger aus und es ist cool, wenn man im Hintergrund nur sieht, dass sich dort irgendwas bewegt, ohne dass man zu genau ausmachen kann, was eigentlich passiert.

Es wird dann auch eine kleine Mission geben, so dass man über die Karte laufen muss und Gegenstände finden und Schalter umlegen muss.Ein bisschen wie die Grusellevel aus dem ersten Thief.
Lieber dumm fragen, als dumm bleiben!
Benutzeravatar
Schrompf
Moderator
Beiträge: 4392
Registriert: 26.02.2009, 00:44
Benutzertext: Lernt nur selten dazu
Echter Name: Thomas Ziegenhagen
Wohnort: Dresden
Kontaktdaten:

Re: Zombie-Shooter

Beitrag von Schrompf »

Uuuh, das Typ sieht fies aus.
Häuptling von Dreamworlds. Baut an was Neuem. Hilft nebenbei nur höchst selten an der Open Asset Import Library mit.
bruebaker
Establishment
Beiträge: 267
Registriert: 08.12.2015, 11:42
Benutzertext: Sven Rahn
Echter Name: Sven Rahn

Re: Zombie-Shooter

Beitrag von bruebaker »

Schaut echt grusselig aus
mtorc1
Beiträge: 41
Registriert: 20.02.2021, 17:24

Re: Zombie-Shooter

Beitrag von mtorc1 »

Sehr schön zu sehen, das du/ihr das Projekt auch nach der Aktion noch weiterentwickelt. Das Bild macht definitiv Lust auf mehr.
Letztes Projekt: Grave of the Pumpkin (ZFX Halloween Action 2021)
Benutzeravatar
scheichs
Establishment
Beiträge: 678
Registriert: 28.07.2010, 20:18

Re: Zombie-Shooter

Beitrag von scheichs »

Find's auch super atmosphärisch. Vor allem Landschaft im Hintergrund, mit der geschwungenen Strasse.
Da fragt man sich direkt schon: Wo könnte es da weitergehen?
Benutzeravatar
grinseengel
Establishment
Beiträge: 393
Registriert: 29.03.2011, 13:47
Echter Name: Andreas

Re: Zombie-Shooter

Beitrag von grinseengel »

Ich freue mich auch das du daran weiterarbeitest. Hast du schon eine Idee bezüglich deiner ersten Mission? Evtl. musst du ja auch taktisch vorgehen und nicht immer jeden Zombie abknallen. Ich denke da evtl. an Kisten, Container etc. über die der Spieler dann an bestimmten Punkten den Zombies aus dem Weg oder umgehen kann. Spricht jetzt etwas gegen Shooter aber fände ich recht intessant. Soll es evlt. auch so in die Richtung Survival gehen, mit Loots und Bauen von Gegenständen und Waffen?
Endgegner
Beiträge: 2
Registriert: 19.12.2020, 19:43

Re: Zombie-Shooter

Beitrag von Endgegner »

Es wird dann auch eine kleine Mission geben, so dass man über die Karte laufen muss und Gegenstände finden und Schalter umlegen muss.Ein bisschen wie die Grusellevel aus dem ersten Thief.
Thief klingt gut! Passend dazu könntest du noch ein paar gas-rülpsende Zombies einbauen. ;) Oder ganz allgemein Zombies, die aus der Distanz angreifen können – ob sie Gift auf den Spieler speien oder mit ihren Eingeweiden herumwerfen, sei mal dahingestellt.

Und wo ist der Bodennebel? ;) In einer Szene mit Nachthimmel, Kapelle und Zombies würde sich etwas Nebel richtig gut machen, finde ich. Also falls sich das mit deiner Engine bereits bewerkstelligen lässt, wäre es sicherlich eine Überlegung wert. Es geht doch nichts über Untote, die im bleichen Licht des Mondes und von Nebel umhüllt aus ihren Gräbern steigen.

Gefällt mir jedenfalls, auch wie du mit diesem Spiel die Entwicklung neuer Features für den Landvogt vorantreibst.
Benutzeravatar
Jonathan
Establishment
Beiträge: 1824
Registriert: 04.08.2004, 20:06
Kontaktdaten:

Re: Zombie-Shooter

Beitrag von Jonathan »

Habe heute mal den Blender 3 Asset-Browser ausprobiert. Leider kann der noch nicht alles, was ich gerne hätte (z.B. Collections als Assets importieren), aber gerade was das ausgestalten von Levelgeometrie angeht, könnte man damit schon einen ganz coolen Workflow hinbekommen:
blender_2022-01-09_17-53-46.jpg
Video:
2022-01-09_17-59-42_asset_browser.mp4
(6.18 MiB) 12-mal heruntergeladen
Lieber dumm fragen, als dumm bleiben!
mtorc1
Beiträge: 41
Registriert: 20.02.2021, 17:24

Re: Zombie-Shooter

Beitrag von mtorc1 »

Jonathan hat geschrieben:
09.01.2022, 22:54
Habe heute mal den Blender 3 Asset-Browser ausprobiert. Leider kann der noch nicht alles, was ich gerne hätte (z.B. Collections als Assets importieren), aber gerade was das ausgestalten von Levelgeometrie angeht, könnte man damit schon einen ganz coolen Workflow hinbekommen:
Das ist cool zu sehen. Mal aus Neugier: werden beim Exportieren aus Blender die Prefabs mit dem Terrain zu einem einzelnen Model zusammengeführt oder bleiben die Objekte getrennt?
Letztes Projekt: Grave of the Pumpkin (ZFX Halloween Action 2021)
Benutzeravatar
Jonathan
Establishment
Beiträge: 1824
Registriert: 04.08.2004, 20:06
Kontaktdaten:

Re: Zombie-Shooter

Beitrag von Jonathan »

grinseengel hat geschrieben:
09.01.2022, 17:41
Ich freue mich auch das du daran weiterarbeitest. Hast du schon eine Idee bezüglich deiner ersten Mission? Evtl. musst du ja auch taktisch vorgehen und nicht immer jeden Zombie abknallen. Ich denke da evtl. an Kisten, Container etc. über die der Spieler dann an bestimmten Punkten den Zombies aus dem Weg oder umgehen kann. Spricht jetzt etwas gegen Shooter aber fände ich recht intessant. Soll es evlt. auch so in die Richtung Survival gehen, mit Loots und Bauen von Gegenständen und Waffen?
Die Idee ist tatsächlich ein eher kleines Level zu bauen und dann mit der Engine in eine leicht andere Richtung zu gehen (to be revealed :D). Aber zumindest ein Friedhof-Zombie-Level musste jetzt sein, sonst wären ja auch die Assets umsonst gewesen.
Die konkrete Mission muss ich mir noch ausdenken, vermutlich wird es sowas wie "Auf einem einsamen Friedhof wurde irgendwo ein reicher Mann begraben, stehle seine Schätze". Am Anfang also etwas Erkundung, paar kleine Rätsel, dann kommen irgendwann Zombies, dann muss man etwas ausweichen und Waffen finden und am Ende, bevor man den Friedhof verlassen kann, kommt dann noch eine größere Ballerei. Story wird dann ggf. über Briefe und Itembeschreibungen erzählt, die man in der Spielwelt findet. Nach 20 Minuten ist man dann durch, oder so.


Endgegner hat geschrieben:
09.01.2022, 19:40
Und wo ist der Bodennebel? ;) In einer Szene mit Nachthimmel, Kapelle und Zombies würde sich etwas Nebel richtig gut machen, finde ich. Also falls sich das mit deiner Engine bereits bewerkstelligen lässt, wäre es sicherlich eine Überlegung wert. Es geht doch nichts über Untote, die im bleichen Licht des Mondes und von Nebel umhüllt aus ihren Gräbern steigen.
Argh, ja, ich will auch soo unbedingt animierten Bodennebel haben. Ist auch glaube ich gut möglich, braucht halt nur 1-2 Tage...
Ambient Occlusion wäre auch richtig gut, dann würde z.B. das Gras schon viel besser aussehen. Und auch sonst natürlich alles. Was ist da eigentlich gerade State-of-the-Art? Folgendes Tutorial sieht ziemlich gut aus, aber vielleicht sollte ich es doch anders machen?

https://learnopengl.com/Advanced-Lighting/SSAO
Lieber dumm fragen, als dumm bleiben!
Benutzeravatar
Jonathan
Establishment
Beiträge: 1824
Registriert: 04.08.2004, 20:06
Kontaktdaten:

Re: Zombie-Shooter

Beitrag von Jonathan »

Argh, ich benutze ja Bullet-Physics und jetzt ist mir aufgefallen, dass das ja auch Softbodies kann:

https://www.youtube.com/watch?v=9sh-D0nejUY

Und jetzt will ich das natürlich ganz unbedingt für umherfliegende Gedärme einbauen. Zombies, die in sich zusammensacken, Darmschlingen, die sich um Zaunlatten wickeln, was für großartige Möglichkeiten man damit hätte...
Lieber dumm fragen, als dumm bleiben!
Benutzeravatar
Jonathan
Establishment
Beiträge: 1824
Registriert: 04.08.2004, 20:06
Kontaktdaten:

Re: Zombie-Shooter

Beitrag von Jonathan »

mtorc1 hat geschrieben:
09.01.2022, 23:10
Das ist cool zu sehen. Mal aus Neugier: werden beim Exportieren aus Blender die Prefabs mit dem Terrain zu einem einzelnen Model zusammengeführt oder bleiben die Objekte getrennt?
Tja, der Teil ist, uhm, eher pragmatisch denn elegant. Die ganze Szene wird als ein Modell exportiert. Dabei wird für jedes Blender-Objekt und für jedes Material ein Submesh in der gltf-Datei angelegt. Beim Laden optimiert da Assimp einmal drüber, d.h. Objekte mit gleichem Material werden zu einem großen Objekt zusammen gefasst. Das gesamte Level-Mesh wird dann einmal in Bullet geschmissen (das baut ein Triangle-Mesh mit BVH daraus) und dann auch in den renderer. Es wird also immer alles im immergleichen Detailgrad gerendert.
View-Frustum-Culling auf Objektebene hab ich prinzipiell auch drin. Das bringt natürlich nichts, wenn alle Steine einzelne Objekte sind, weil die konvexe Hülle davon natürlich nahezu immer sichtbar ist. Andererseits hat man so auch recht wenig Render-Calls. Und die ganze Szene ist ja ohnehin eher Low-Poly. Gerade für große Level fehlt da also eigentlich dringend ein LOD und Visibility-System. Natürlich am besten irgendwas automatisches, so dass man wirklich wie gehabt eine große detaillierte Szene in Blender bauen kann und reinschmeißen kann. Für View-Frustum-Culling gibt es ja auch extra Middleware, man kann da also potentiell sehr sehr viel Arbeit rein stecken und ich weiß nicht, wie motiviert ich dazu bin. Aktuell sorgt bei mir "schnelle Grafikkarte"+"kleine Map"+"nicht so viele Details" für sehr vertretbare Frameraten, gerade stolz sein kann man darauf aber irgendwie nicht. Aber hey, Spiel + Engine parallel in seiner Freizeit entwickeln erfordert halt einfach viele Kompromisse...
Lieber dumm fragen, als dumm bleiben!
Matthias Gubisch
Establishment
Beiträge: 335
Registriert: 01.03.2009, 20:09

Re: Zombie-Shooter

Beitrag von Matthias Gubisch »

Hmm dein Link zeigt eine Middleware für Occlusion Culling, das ist etwas anders als View-Frustrum-Culling ;)
*klugscheissmodus aus*

Meine Einschätzung nachdem ich das für meinen Renderer implementiert habe:
Occlusion Culling ist relativ komplex und welches Konzept man dafür wählt hängt sehr eng mit der Arbeitsweise des Renderers allgemein zusammen. Ohne die Middleware zu kennen, gehe ich davon aus dass man entweder Glück braucht oder den Renderer anpassen muss will man eine solche verwenden.

Vorteil wenn man funktionierendes OcclusionCulling hat: es scheint relativ trivial zu sein da noch LOD auf Mesh- bzw Submeshbasis einzubauen.
Werd ich mal angehen sobald ich meine AssetPipeline überarbeitet habe.


Das wichtigste fast vergessen:
Der Zombie sieht ziemlich cool aus, und das Gras im Hintergrund auch sehr stimmig.
Bevor man den Kopf schüttelt, sollte man sich vergewissern einen zu haben
Benutzeravatar
Jonathan
Establishment
Beiträge: 1824
Registriert: 04.08.2004, 20:06
Kontaktdaten:

Re: Zombie-Shooter

Beitrag von Jonathan »

Matthias Gubisch hat geschrieben:
12.01.2022, 21:22
Das wichtigste fast vergessen:
Der Zombie sieht ziemlich cool aus, und das Gras im Hintergrund auch sehr stimmig.
thx :)
Matthias Gubisch hat geschrieben:
12.01.2022, 21:22
Hmm dein Link zeigt eine Middleware für Occlusion Culling, das ist etwas anders als View-Frustrum-Culling ;)
*klugscheissmodus aus*

Meine Einschätzung nachdem ich das für meinen Renderer implementiert habe:
Occlusion Culling ist relativ komplex und welches Konzept man dafür wählt hängt sehr eng mit der Arbeitsweise des Renderers allgemein zusammen. Ohne die Middleware zu kennen, gehe ich davon aus dass man entweder Glück braucht oder den Renderer anpassen muss will man eine solche verwenden.

Vorteil wenn man funktionierendes OcclusionCulling hat: es scheint relativ trivial zu sein da noch LOD auf Mesh- bzw Submeshbasis einzubauen.
Werd ich mal angehen sobald ich meine AssetPipeline überarbeitet habe.
Gut, vielleicht war ich mit den Begriffen nicht ganz präzise, aber letztendlich löst ja beides das selbe Problem.

Wobei, eigentlich ist ja noch alles viel schlimmer :(. Horizon Zero Dawn kann ja Landschaften mit Wälder und Pflanzen und Bäumen die alle zur Laufzeit auf der GPU erzeugt werden. D.h. die Entscheidung wo welche Meshs generiert werden müssen wird schon auf der GPU getroffen, massiv parallel, und für jeden Frame aktualisiert. Früher (auf dem Stand, mit dem ich auch arbeite) hast du ja das prinzipielle Problem, dass feingranulares Culling immer auch viele Render-Jobs bedingt, was die Sache wieder langsam macht. Und überhaupt hat man ja mit Vulkan einfach weniger Overhead und kann viel eher mal ganz viel Brute-Force rendern. Aber wenn ich jetzt alles auf Vulkan portiere brauche ich vermutlich ein Jahr bis ich wieder auf dem aktuellen Stand bin. Das will ich mir eigentlich nicht leisten.

Für offene Level (wie die gezeigten) ist Occlusion Culling natürlich sau schwer, ein Baum verdeckt halt erstens nicht viel und hat zweitens eine sau-komplizierte Form, da ist schon fast fraglich ob man sich überhaupt die Mühe machen will zu überlegen, was der jetzt verdecken könnte. Wenn du andererseits betretbare Gebäude in der Landschaft hast, würde sich fast wieder sowas wie Portal-Rendering anbieten, weil Räume ja wirklich echt sehr gut Dinge verstecken. Außer du hast so einen Bretterverschlag, wo man zwischen den Latten durchschauen kann, dann kannste Portale auch wieder vergessen.

Das Gegenteil von dem was ich ja gerade mache ist ja eigentlich irgendwie Unreals Nanite, wo du einfachmal gesculptete Objekte mit Millionen Dreiecken ohne drüber nachzudenken wild in der Szene verteilst und es läuft flüssig. Schraub die Komplexität hoch wie du willst, die Engine kümmert sich um effizientes LOD, Culling und sogar Streaming weil ja nichtmal das ganze Level auf einmal in den Speicher passt. Wirklich beeindruckend, eine ganz neue Art Spiele zu machen, aber das kannste halt nicht alleine zuhause nachcoden. Ist dann fast nochmal trauriger wenn man selber viel vom State-of-the-Art kennt und zumindest eine grobe Idee hat, wie das wohl funktioniert, aber gar nicht erst anfängt mit dem Gedanken zu spielen, sowas mal selber zu machen. Nunja...
Lieber dumm fragen, als dumm bleiben!
Matthias Gubisch
Establishment
Beiträge: 335
Registriert: 01.03.2009, 20:09

Re: Zombie-Shooter

Beitrag von Matthias Gubisch »

Ja beide haben das selbe Ziel, man kann sie aber ganz gut in Kombination einsetzen.
Ich kann mal grob skizzieren wie das bei mir aussieht:

Meine Engine baut ja auf Vulkan auf, und ich verwende das DrawIndirect Zeugs, grundsätzlich sollte das aber auch mit OpenGL möglich sein, nur dass man evtl den ein oder anderen RoundTrip zu CPU zusätzlich braucht.

Das erlaubt mir das Culling komplett auf der GPU zu machen, und reduziert ausserdem grundsätzlich die Drawcalls, da ich damit genau einen DrawCall pro Pipeline (Shader) machen muss.

Für das Culling läuft ein ComputeShader der am Ende des Tages nur den Buffer mit den DrawCommands füllt.
In diesem Shader wird zuerst Frustrum Culling ausgeführt, ganz einfach straight forward wie man es kennt.
Alles was jetzt noch sichtbar ist wird dann noch durch den Occlusion Algorithmus gejagt.
Alles was da noch übrig bleibt landet dann im DrawCommandBuffer und wird anschliesend gerendert.

Das Kernstück beim OcclusionCulling macht ganz grob folgendes:
Man nehme den DepthBuffer des vorherigen Frames und erzeuge daraus eine DepthPyramid (im Prinzip eine MipMapChain nur mit Min/Max Sampler anstatt zu averagen). Das läuft noch vor dem CullShader, bzw könnte man auch am Ende des vorherigen Frames machen, je nachdem ob das Postprozessing mehr Fragment oder mehr Compute Shader ist, liese sich das evtl ganz gut mit AsyncCompute verstecken.

Im CullShader wird dann die BoundingBox/Sphere auf den ScreenSpace projeziert und dann die DepthPyramid an der LOD-Stufe gesampled an der die projezierte Größe ca. 1 Pixel entspricht.
Hier wäre auch der Punkt das richtige MeshLod auszuwählen.

Tiefer der BoundingSphere und des DepthBuffers vergleichen und fertig ist der Lack.

Durch das verwenden des DepthBuffers des vorangegangen Frames gibt es halt ein paar kleinere Problemchen, vor allem bei niedrigen Framerates fallen gerne mal Objekte raus die eigentlich gerendert werden sollen, und umgekehrt gibt es auch false positives.
Ich hatte noch keine Lust mir da was elagantes zu überlegen und mache einfach die Bounding Spheres ein paar Prozent größer. Das gibt zwar ein paar false positives mehr die zum Rendern kommen obwohl sie verdeckt sind, aber dafür war die Lösung einfach. Btw. das habe nicht ich erfunden, sondern macht die UE4 auch so ähnlich.

Eine 2. Möglichkeit wäre, nach dem 1. Rendern für die im 1. Pass gecullten Objekte das ganze nochmal mit dem DepthBuffer des aktuellen Frames zu machen und die paar fehlenden Objekte noch nachzurendern. Hier kommt es stark auf die Szene und die komplexität der Shader an ob die false Positives in meiner Lösung oder der zusätliche Pass mehr overhead erzeugen, das müsste man vermutlich Profilen, aber ich hatte noch keinen Bock das zu implementieren.

Gibt noch ein paar andere Lösungsmöglichkeiten, aber da erfordern die meisten schon wieder mehr Infos über die Levelgeometrie, wie z.B. was ein ein potenziell großer Occluder sein könnte. Die optimale Lösung bekommt man eh nicht hin, weil dann der Rechenaufwand fürs Culling irgendwann den fürs Rendern übersteigt ;)

Ich möchte bei mir noch LOD und Culling auf SubmeshBasis (Idealerweise gleich Meshlets um für MeshShader vorbereitet zu sein) einbauen und dann muss es auch wieder gut sein. Culling per Triangle, oder gleich IndexBuffer während dem Culling zu erzeugen ist dann doch zu viel für ein Hobbyprojekt, gibt ja noch genügend andere Dinge die ich einbauen will
Bevor man den Kopf schüttelt, sollte man sich vergewissern einen zu haben
Antworten