Project Octopath Traveler

Hier könnt ihr über Nintendos neue Konsole diskutieren.

Moderatoren: Moderatoren, Redakteure

Benutzeravatar
yopparai
Beiträge: 10703
Registriert: 02.03.2014 09:49
Persönliche Nachricht:

Re: Project Octopath Traveler

Beitrag von yopparai » 20.01.2017 16:18

Ich glaub so ganz ohne Hintergrund, was die GPU da treibt wird das nichts. Denn im Prinzip ist alles was du in einem Spiel siehst irgendwann durch einen Pixelshader gelaufen. Du kannst nichtmal ne Textur ohne Shader darstellen. Das ist nämlich schlicht das Programm, das letztendlich den Farbwert bestimmt und damit eine ganz zentrale Komponente der Grafikpipeline. Ich setz mich nachher mal ran und versuche das posttauglich mit ein paar vernachlässigbaren Vereinfachungen einzudampfen.

@Levi: Nope. Das ist Post Processing.
Zuletzt geändert von yopparai am 20.01.2017 16:18, insgesamt 1-mal geändert.

Benutzeravatar
Levi 
Beiträge: 38525
Registriert: 18.03.2009 15:38
Persönliche Nachricht:

Re: Project Octopath Traveler

Beitrag von Levi  » 20.01.2017 16:18

Ach ficken... Mist. Verwechselt...
forever NYAN~~ |||||| Hihi
Bild

Benutzeravatar
yopparai
Beiträge: 10703
Registriert: 02.03.2014 09:49
Persönliche Nachricht:

Re: Project Octopath Traveler

Beitrag von yopparai » 20.01.2017 19:13

Der Chris hat geschrieben:Dann muss ich direkt fragen...was machen Pixelshader technisch gesehen?
Ich habe ihn angedroht, hier ist er: Der sehr lange und langweilige Shader-Post.

Eine kleine Vorwarnung: Ich hab das schon Jahre lang nicht mehr gemacht und auch damals schon nicht so intensiv, wie ich das wollte, kann also gut sein, dass ich ein paar Begriffe verwechsle und die Reihenfolge in der Pipeline irgendwo vertausche. Generell fehlen hier 90% von dem was sonst noch alles gemacht wird, aber ich hoffe, das bietet trotzdem einen Überblick.

Zu Beginn der Renderpipeline hat die CPU einen Haufen Objekte mit ihren Koordinaten und Raumlagen und die Kamera auf Grundlage der Spielmechanik, Physik und KI berechnet und in den Speicher gelegt. Der GPU fällt jetzt die Aufgabe zu, aus diesen Daten ein Bild zu rendern.

Diese Objekte sind zu diesem Zeitpunkt noch in verschiedenen Koordinatensystemen angegeben. Zum Beispiel könnte das Koordinatensystem des Dorfes, durch das man in einem RPG rennt, im Brunnen seinen Ursprung haben. Das Haus vom Dorfchef hat ein eigenes Koordinatensystem das an einer der Ecken den Nullpunkt hat. Und die Spielfigur hat ihr Koordinatensystem vielleicht zu ihren Füssen. Der erste Schritt ist, alle Vertices (Punkte/Knoten) dieser Objekte von ihrem eigenen Koordinatensystem über die Positionierungen der Objekte in ein Weltkoordinatensystem umzurechnen. Das geht tatsächlich einfacher als man denkt über Matrizenmultiplikationen. Ich kann diesen Schritt gerne noch erläutern, falls es interessiert, für die Erklärung von Shadern ist er nicht zwingend nötig, daher blende ich ihn hier aus. Die Weltkoordinaten können irgendwo definiert sein, z.B. auch wieder im Dorfbrunnen.

Am Ende habe ich also sämtliche Vertices der dargestellten Szene ausgerechnet als Punkte im 3D-Raum im Speicher. Während dieses Schrittes werden noch viele Optimierungen vorgenommen, z.B. schmeiß ich hier alles raus, was ich eh hinterher nicht sehe, weil es gar nicht im Sichtbereich liegt.

Als nächstes benötige ich mehr Infos über die Flächen der Polygone, und zwar genauer über ihre Ausrichtung im Raum. Diese Ausrichtungen nennt man Normalenvektoren. Ihre Berechnung ist ebenfalls recht einfach, man benutzt hier zu das Kreuzprodukt zwischen zwei der immer drei Polygonkanten. Die Polygonkanten kann man als Vektoren auffassen, indem man bei den drei Punkten a, b, und c z.B. a von b abzieht und dann a von c abzieht. Die dadurch erhaltenen Vektoren v1 und v2 bilden jetzt zwei Kanten des Polygons. Das Kreuzprodukt zweier Vektoren ist wieder ein Vektor und hat die originelle Eigenschaft, immer senkrecht auf den multiplizierten Vektoren zu stehen. Das heißt, v1 x v2 = v3 steht senkrecht auf dem ursprünglichen Polygon. Die Länge ist hier für uns uninteressant (sie gibt den doppelten Flächeninhalt des Polygons wieder), sie wird auf die Länge 1 gekürzt (normalisiert). Was wir erhalten ist der Normalenvektor des Polygons. Diesen Schritt wiederholen wir für alle Polygone.
Weil wir das später noch brauchen, berechnen wir an den Knoten zwischen mehreren Polygonen auch die Vertexnormalen. Das sind mehr oder weniger die gemittelten Normalen der angrenzenden Polygone.

Wir haben jetzt also alle Knoten und alle Normalen in einem gemeinsamen Koordinatensystem. Nächster Schritt.

Die Normalen haben wir mit gutem Grund berechnet. Wir benötigen die Information über die "Richtung der Oberflächen", weil wir die Schattierung berechnen können möchten.

Hier kommen jetzt zum ersten Mal Shader ins Spiel, nämlich die Vertex-Shader. Beim Begriff Shader muss man etwas aufpassen. Oft wird er sowohl für das Programm verwendet, das er darstellt, als auch für das Hardwarebauteil, das dieses Programm ausführt. Redet man von einer GPU wie dem X1 mit 256 Shadern bedeutet das, dass 256 Hardwareeinheiten zur Verfügung stehen, die unabhängig voneinander und gleichzeitig Shaderprogramme ausführen. (Diese Programme werden in Shadersprachen geschrieben und direkt als Text an den Grafiktreiber geschickt. Die Shadersprachen werden durch das verwendete API definiert, bei Open GL heißt die Shadersprache GLSL. Meist sehen die aus wie C.)

Vertex-Shader haben eine einfach Aufgabe. Sie berechnen Werte, die den Vertices zugeordnet werden, und meistens (!) haben die was mit Licht und Schatten zu tun. Sie könnten aber auch ein Farbwert sein, das darf der Programmierer entscheiden. Wir gehen mal vom einfachen Fall aus und schattieren ein paar Polygone. Jedenfalls werden in dieser Phase die den Vertices zugeordneten Shaderprogramme auf diese und ihre Normalen losgelassen.

Die Schattierung einer Fläche hängt ab von der Position der Lichtquelle (bei einem Punktlicht) bzw. der Richtung der Lichtstrahlen bei einer global definierten Licht-Richtung (Sonne z.B.) und der Richtung der Fläche. Man könnte sagen, ich berechne „wie schief“ der Lichtstrahl auf die Fläche trifft. Ist das ein sehr flacher Winkel, dann ist am Ende der Helligkeitsanteil, den die Fläche durch die Lichtquelle gewinnt sehr klein. Ist er spitz (also steht die Lichtquelle fast in Richtung der Flächennormalen), dann ist die Helligkeit hoch. Berechnet wird das noch einfacher als die Normalen, mit dem Skalarprodukt. Das Ergebnis des Skalarprodukts spiegelt genau diesen Anteil wieder.

Ein Vertex-Shaderprogramm könnte jetzt genau diese Helligkeitswerte alle berechnen und jedem Vertex in einer Szene zuordnen. Diese Helligkeits- oder Farbwerte je Knoten werden gespeichert.

Jetzt wird die komplette Szene, bzw. der Sichtbereich den meine Kamera umfasst in einen Würfel von Kantenlänge 1 gequetscht. Also verzerrt und zwar mitsamt der ganzen Normalen. Das heißt, ich transformiere in ein neues Koordinatensystem, das im Wesentlichen meinen Bildschirm darstellt. Das Koordinatensystem könnte zum Beispiel unten links in der Ecke liegen mit Achsen entlang der Bildschirmkanten. Die Z-Achse würde dann aus dem Bildschirm heraus zeigen. Damit kann man jetzt jeden Pixel des Bildschirms einem Satz Koordinaten zuordnen.

Dann kommen die Pixelshader ins Spiel. Sie werden für jeden Pixel einzeln ausgeführt. Zunächst wird bestimmt, welches Polygon unter dem Pixel liegt und welche Shaderprogramme und Daten (Vektoren, Vertices und zugeordnete Ergebnisse aus den Vertexshadern) diesem Polygon zugeordnet sind. Das heißt, die Vertex-Shader liefern zum Teil die Eingangsdaten für die Pixelshader.

Ein Pixelshader kann jetzt etwas ganz einfaches tun und den Helligkeitswert, den meine Vertex-Shader hinterlassen haben, einfach interpolieren. Also salopp gesagt per Dreisatz einen Zwischenwert aus den Helligkeitswerten der drei zum unterliegenden Polygon gehörenden Punkte berechnen. Das Ergebnis sieht aus wie Marios Nase in Mario 64. Das N64 hatte zwar keine frei programmierbaren Shader, aber genau diese Funktion in Hardware gegossen.
Der Shader kann aber auch mit Hilfe einer Textur den richtigen Farbwert aus den Koordinaten innerhalb der Textur berechnen. Oder er kann ganz tolle Sachen mit Dingen wie Normal Maps anstellen, die eigentlich auch nichts anderes als Texturen sind, nur dass da keine Farbwerte drin stehen sondern eben Flächennormalen. Das heißt, der Shader kann zu diesen Normalen mit der gleichen Mathematik wie eben unser Vertex Shader die Lage zum Licht berechnen um auf einen Farbwert zu kommen, obwohl diese Normalen eigentlich gar nicht in der Geometrie existieren, sondern eben nur in der Map. Das ist ein ziemlich billiger, aber höchst effektiver Trick. Doom 3 hat damals genau damit etliche Unterkiefer tiefergelegt. http://www.opengl-tutorial.org/intermed ... l-mapping/

Etwas anderes was er tun könnte: Er könnte auf die Helligkeitswerte der Vertexshader pfeifen (bzw. die würden ihm dann die Daten gar nicht liefern) und für jeden Pixel einzeln das berechnen, was vorher der Vertexshader für den ganzen Knoten gemacht hat. Das Ergebnis wäre per-Pixel-Lighting und sieht gleich viel besser aus. Frisst aber halt Leistung, vor allem bei großen Polygonen: http://www.lighthouse3d.com/tutorials/g ... per-pixel/

Oder er könnte irgendwie seinen Farbwert berechnen und dann entscheiden „so genau wollen wir’s gar nicht“ und den Wert klassieren/diskretisieren. Also z.B. so:

Code: Alles auswählen

// The pixel shader that does cel shading.  Basically, it calculates
// the color like is should, and then it discretizes the color into
// one of four colors.
float4 CelPixelShader(VertexToPixel input) : COLOR0
{
    // Calculate diffuse light amount
    float intensity = dot(normalize(DiffuseLightDirection), input.Normal);
    if(intensity < 0)
        intensity = 0;
 
    // Calculate what would normally be the final color, including texturing and diffuse lighting
    float4 color = tex2D(textureSampler, input.TextureCoordinate) * DiffuseColor * DiffuseIntensity;
    color.a = 1;
 
    // Discretize the intensity, based on a few cutoff points
    if (intensity > 0.95)
        color = float4(1.0,1,1,1.0) * color;
    else if (intensity > 0.5)
        color = float4(0.7,0.7,0.7,1.0) * color;
    else if (intensity > 0.05)
        color = float4(0.35,0.35,0.35,1.0) * color;
    else
        color = float4(0.1,0.1,0.1,1.0) * color;
 
    return color;
}
aus http://rbwhitaker.wikidot.com/toon-shader

Wir hätten damit einen einfachen Cel-Shader geschaffen. Der Shader rechnet einfach eine Intensität zwischen 0 und 1 aus und ordnet dann abhängig vom Wert eine von wenigen festen Farben zu.

Was genau der Shader tut ist völlig Sache des Programmierers. Im einfachsten Fall gibt er nur eine dem Polygon zugeordnete Farbe wieder aus. Das ist dann langweilig, aber das ist seine Aufgabe.

Jedenfalls sind die Shaderprogramme somit praktisch die wichtigsten Bestandteile im ganzen Prozess und sie werden immer für alles sichtbare ausgeführt, auch bei den einfachsten Szenen.

Benutzeravatar
Der Chris
Beiträge: 7136
Registriert: 13.04.2007 18:06
Persönliche Nachricht:

Re: Project Octopath Traveler

Beitrag von Der Chris » 20.01.2017 20:36

Vielen Dank für die ausführliche Erklärung. Da bekomm ich direkt Flashbacks von der "Grundlagen Computergrafik" Vorlesung. :mrgreen: Aber so hab ich ganz gut folgen können. Jetzt frag ich mich mit diesem Wissen nur was der Herr Jesus damit meinte, dass in dem Spiel die Umgebung nicht 3dimensional modelliert wäre sondern Pixelshader die Räumlichkeit erzeugen würden. So wie ich das verstehe sind die Pixelshader doch trotzdem darauf angewiesen dass Dinge mit Polygonen modelliert sind...der Einfluss auf die Räumlichkeit besteht also primär in der Art und Weise wie Farb- und Helligkeitswerte auf den Modellen berechnet werden. Seh ich das etwa so richtig?
Zuletzt geändert von Der Chris am 20.01.2017 22:52, insgesamt 1-mal geändert.
"Naughty Dog ruined gaming."
- Rich Evans, Previously Recorded/Red Letter Media

Im Moment...
PS4: NieR: Automata, Odin Sphere, Dark Souls 3
Switch: Doom, Bayonetta 1 & 2

Benutzeravatar
yopparai
Beiträge: 10703
Registriert: 02.03.2014 09:49
Persönliche Nachricht:

Re: Project Octopath Traveler

Beitrag von yopparai » 20.01.2017 20:51

Genau. Für meine Begriffe ist das Spiel auch ganz klar räumlich modelliert. Es sind allerdings mehr "Pappaufsteller" im Pixellook, die durch eine recht einfache und genau so pixelige Kulisse geschoben werden. Ich nehme an, dass die Charaktere einfach aus zwei Dreiecken mit animierten Texturen bestehen. Da die Charaktere selbst nicht eckig sind, besitzen diese Texturen einen Alphakanal (Transparenzwert für jeden Pixel). Da wo der Alphakanal Transparenz vorschreibt, rendert der Shader nichts und überschreibt damit auch nicht den Hintergrund. Ähnliche Vorgehensweisen findet man oft bei Blattwerk von Bäumen, die meist etwas verwaschen und unscharf aussehen. Hier in diesem Fall hat man das verwischen der Texel (Textur-Pixel) abgestellt bzw. nicht im Shader implementiert, deswegen sind die Kanten scharf. Zusätzlich werden diese Polygone zu einem anderen Zeitpunkt in die Koordinatentransformation einbezogen, weshalb sie immer streng zur Kamera gerichtet sind -> siehe Karts in MarioKart 64.

Die Shader zur Beleuchtung gehen trotzdem drüber. Auch der Schattenwuf zeigt, dass das echte 3D-Objekte sind. Wenn auch sehr einfache aus zwei Dreiecken.

Insgesamt empfinde ich das Shading auch als relativ aufwendig, was einen hübschen Kontrast zur 16bit-Optik bietet. Das Post Processing ist auch recht heftig, vor allem die Unschärfe- und Bloom-Effekte.

Btw... wenn du in einer halbwegs modernen Engine wie Unity ein 2D-Spiel entwickelst, dann ist das nur 2D wegen der Kameraausrichtung. Im Editor kannst du die Perspektive drehen und das ganze ist 3D. Sieht dann oft aus wie ein Kasperltheater...

johndoe1871471
Beiträge: 1260
Registriert: 19.12.2016 16:47
Persönliche Nachricht:

Re: Project Octopath Traveler

Beitrag von johndoe1871471 » 20.01.2017 21:48

ohhh...so viel Technick gerede... :lol:

Freu mich aber drauf, bin gespannt wie lange wir darauf warten müssen, hoffe nicht all zulange.

Benutzeravatar
yopparai
Beiträge: 10703
Registriert: 02.03.2014 09:49
Persönliche Nachricht:

Re: Project Octopath Traveler

Beitrag von yopparai » 20.01.2017 22:31

Dem, der Fragen hat, soll Antwort zuteil werden.

Davon ab ich freu mich auch sehr über und auf das Spiel. Einmal wegen seiner originellen Optik, aber vor allem, weil es ein Spiel ist, wie es einige von uns ja schon erhofft hatten. Mittelgroße halbnischen-Spiele japanischer Thirds, vielleicht sogar Exklusivtitel, die sonst wohl auf dem 3DS gelandet wären.

johndoe1871471
Beiträge: 1260
Registriert: 19.12.2016 16:47
Persönliche Nachricht:

Re: Project Octopath Traveler

Beitrag von johndoe1871471 » 20.01.2017 22:32

Stimmt, das ist tatsächlich einer der wenigen Titel die man so eher auf einem 3DS erwarten würde.

2018 Handheld flut confirmed <3

Benutzeravatar
Krulemuk
Beiträge: 2361
Registriert: 28.11.2014 21:42
Persönliche Nachricht:

Re: Project Octopath Traveler

Beitrag von Krulemuk » 20.01.2017 22:51

Ich hoffe insbesondere auf einen ähnlich guten Soundtrack. So etwas kann für mein Spielerlebnis extrem wichtig sein. Der Gesamtsoundtrack von Bravely Default ist meines Erachtens auf Augenhöhe mit solchen Titeln wie Zelda, Xenoblade oder Final Fantasy...

johndoe1871471
Beiträge: 1260
Registriert: 19.12.2016 16:47
Persönliche Nachricht:

Re: Project Octopath Traveler

Beitrag von johndoe1871471 » 20.01.2017 22:53

Ich gehe davon aus das er gut ist, auch wenn für mich persönlich Bravely default mit keinen von deinen komplett mithalten kann, gerade Zelda und Final Fantasy ist für mich dann noch mal ne stufe höher.

Benutzeravatar
yopparai
Beiträge: 10703
Registriert: 02.03.2014 09:49
Persönliche Nachricht:

Re: Project Octopath Traveler

Beitrag von yopparai » 20.01.2017 22:54

@Krulemuk: Ist er! Ist auch einer von denen, die ich importiert habe. Bzw. die Squex in London mir importiert hat.

(Falls das übrigens mal wer macht: Nicht an Packstationen schicken lassen, das kapieren die nicht. Achja, und die 8 stündige FFXIV ARR OST-Bluray auch gleich mitbestellen :ugly:)

Benutzeravatar
JesusOfCool
Beiträge: 32188
Registriert: 27.11.2009 09:55
Persönliche Nachricht:

Re: Project Octopath Traveler

Beitrag von JesusOfCool » 23.01.2017 08:53

yopparai hat geschrieben: Btw... wenn du in einer halbwegs modernen Engine wie Unity ein 2D-Spiel entwickelst, dann ist das nur 2D wegen der Kameraausrichtung. Im Editor kannst du die Perspektive drehen und das ganze ist 3D. Sieht dann oft aus wie ein Kasperltheater...
und genau so stell ich mir dieses spiel vor ^^
nur manche objekte dürften neben der frontwand auch seitenwände haben. und die charaktere sehe ich auch nur als 2 dreiecke mit teilweise transparenten animierten texturen. also nichts weiter als ein pappaufsteller. dass man niemals die schmale kante sieht macht man ganz einfach mit dem was man als billboarding bezeichnet.
Bild

Benutzeravatar
yopparai
Beiträge: 10703
Registriert: 02.03.2014 09:49
Persönliche Nachricht:

Re: Project Octopath Traveler

Beitrag von yopparai » 23.01.2017 09:19

Ja. Genau das, was ich drei Posts weiter oben erklärt hab. Trotzdem isses technisch gesehen 3D-Grafik, wie heute alles 3D-Grafik ist. Es sind halt durch die 3D-Pipeline gezoomte Pappaufsteller aus zwei Polygonen, keine echten Sprites im klassischen Sinne der 80er/90er.

Benutzeravatar
JesusOfCool
Beiträge: 32188
Registriert: 27.11.2009 09:55
Persönliche Nachricht:

Re: Project Octopath Traveler

Beitrag von JesusOfCool » 23.01.2017 11:05

ich bin trotzdem der meinung es wäre besser HD sprites zu verwenden statt diese pixeldinger.
Bild

Benutzeravatar
Levi 
Beiträge: 38525
Registriert: 18.03.2009 15:38
Persönliche Nachricht:

Re: Project Octopath Traveler

Beitrag von Levi  » 23.01.2017 11:17

Nein.
forever NYAN~~ |||||| Hihi
Bild

Antworten

Wer ist online?

Mitglieder in diesem Forum: E-G und 10 Gäste