Files |  Tutorials |  Articles |  Links |  Home |  Team |  Forum |  Wiki |  Impressum

Aktuelle Zeit: Do Mär 28, 2024 20:38

Foren-Übersicht » DGL » News
Unbeantwortete Themen | Aktive Themen



Ein neues Thema erstellen Auf das Thema antworten  [ 14 Beiträge ] 
Autor Nachricht
BeitragVerfasst: Fr Apr 03, 2009 10:05 
Offline
DGL Member
Benutzeravatar

Registriert: Mo Sep 23, 2002 19:27
Beiträge: 5812
Programmiersprache: C++
Vor einiger Zeit ist exklusiv für die Playstation 3 der Egoshooter Killzone 2 erschienen, der im Konsolenbereich die momentane technische Speersitze darstellt (und auch sehr viel Spaß macht, ich besitze das Spiel selbst). An sich keine wirklich passende Meldung für die DGL, aber Guerilla, die Macher hinter Killlzone 2 haben im Playstation Network eine sehr interessante "Technologiedemo" veröffentlicht, namentlich "Killzone 4D". Diese Techdemo zeigt den in Echtzeit gerenderten TV-Werbespot für das Spiel, mit der schönen Möglichkeit (neben einer Pause- und Kamerarotationsfunktion) auf der einen Hälfte des Bildes einen Debugmodus zu aktivieren der aufzeigt wie das Gesamtbild zusammengesetzt wird. Leider gibt es die Demo (wohl aus Jugendschutzgründen) nur im US-Store, aber auf seiner PS3 kann man ja unendlich viele Accounts anlegen ;)

Bild

Im Zusammenhang mit dieser Techdemo sollten technisch interessierte auch mal einen Blick in dieses Dokument von Guerilla von der Develop Conference 2007 werfen, welches detailliert auf den Grafikmotor hinter Killzone 2 eingeht, denn der entspricht neusten Standards und macht u.a. Gebrauch von einem sog. G-Buffer (Geometrie Puffer, der alle wichtigen Bildinformationen beinhaltet). Der G-Buffer in KZ2 sieht dabei wie folgt aus :
Bild
(mehr Infos in obigem PDF-Dokument)

Auch sehr interessant ist ein Diagramm das aufzeigt wie ein Teil der Last, die z.B. am PC auf der GPU liegen würde, bei der PS von den SPUs übernommen wird (Synergistic Processing Unit). Die GPU der PS3 ist relativ schwach (ein stark angepasster
G70, aber mit schmalem Datenbus), dafür hat man als Entwickler aber 6 nutzbare SPUs (einer ist Supervisor, einer für bessere Ausbeute deaktiviert/nicht funktional) und eine PPU (Power Processor Unit) mit zwei Threads, allesamt mit "schlappen" 3.2 Ghz. Da die GPU aber einen direkten Rückkanal zu den CPUs hat (mit vollen ~ 20 GB/s) kann man durch Lastverschiebung viel rausholen :
Bild


Ich hoffe das Ganze klingt nicht zu sehr nach Werbung, aber ich fand sowohl die Techdemo als auch (v.a.) den Artikel so interessant dass ich diese den DGL-Usern nicht vorenthalten wollte.


Hinweis : Killzone 2 besitzt keine Jugendfreigabe, evtl. sind also Techdemo (obwohl man dort nichts sieht) sowie das Spiel selbst nichts für Jugendliche unter 18 jahren!

_________________
www.SaschaWillems.de | GitHub | Twitter | GPU Datenbanken (Vulkan, GL, GLES)


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Fr Apr 03, 2009 14:01 
Offline
DGL Member
Benutzeravatar

Registriert: Di Sep 03, 2002 15:08
Beiträge: 662
Wohnort: Hamburg
Programmiersprache: Java, C# (,PhP)
Interessant, aber die PS3 und auch KZ2 überzeugen mich überhaupt nicht. Nen Kumpel hat auch eine PS3 und viele Spiele die ich bisher dort gesehen habe hatten störende Mikroruckler und richtiges Dauerruckeln.

Zu KZ2 will ich als GoW2 Fan lieber nichts sagen ;)

_________________
(\__/)
(='.'=)
(")_(")


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Fr Apr 03, 2009 15:40 
Offline
DGL Member
Benutzeravatar

Registriert: Mi Aug 13, 2008 12:39
Beiträge: 26
Wohnort: Berlin
sehr schön, sehr schön, auch wenn ich von dem Ganzen recht wenig verstehe, wie kann ich mir denn jetzt nun diesen tollen g-buffer vorstellen? Ein bisschen Off-topic, aber ich verstehe nicht, warum Sony ihre Konsolen immer so extravagant aufbaut. Cell-Chip mit irgendwelchen Komischen SPU's die dann die Arbeit von der Grafikkarte übernehmen (wie AntiAliasing) und dann hier super tollen schnellen RAM, aber mit wenig Speicher. Verstehe ich nicht, warum nicht einfach wie MS nen PC nehmen, bisschen umbauen und als Konsole verkaufen, dürfte doch vorallem für die Entwickler sehr viel einfacher sein, oder täusch eich mich da?

_________________
Der frühe Wurm wird vom Vogel gefangen.


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Fr Apr 03, 2009 15:56 
Offline
DGL Member
Benutzeravatar

Registriert: Do Dez 05, 2002 10:35
Beiträge: 4234
Wohnort: Dortmund
G-Buffer: Nun ja. Der schematische Aufbau den hatte Sasche oben schon gepostet. Aber normal ist das nur ein FrameBufferObject. Bei FBOs hast du ein Objekt und kannst verschiedene Texturen als Buffer hinzufügen. Unter anderem auch eine RGBA8 Textur (4x8Bit). Oder einen Textur mit 2x 16 Bit Floats. Mit neueren Erweiterungen ist es glaube ich möglich ein mal eine Szene zu zeichnen und gleichzeitig zwei von diesen Texturen befüllen zu lassen. Wenn du später per Shader auf die Daten zugreifen möchtest geht das sehr einfach, da sich alle Daten bereits in Texturen befinden. Somit entfällt Kopieraufwand.


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Fr Apr 03, 2009 16:13 
Offline
DGL Member
Benutzeravatar

Registriert: Di Sep 03, 2002 15:08
Beiträge: 662
Wohnort: Hamburg
Programmiersprache: Java, C# (,PhP)
MarvDasSchaf hat geschrieben:
Cell-Chip mit irgendwelchen Komischen SPU's die dann die Arbeit von der Grafikkarte übernehmen (wie AntiAliasing) und dann hier super tollen schnellen RAM, aber mit wenig Speicher.

Vor allem da die PS3 nicht einmal hardwareseitiges AA hat. AA muss vom Entwickler implementiert werden ansonsten hat man den ungewünschten Treppchen-Effekt.

_________________
(\__/)
(='.'=)
(")_(")


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Fr Apr 03, 2009 16:20 
Offline
DGL Member
Benutzeravatar

Registriert: Mi Aug 13, 2008 12:39
Beiträge: 26
Wohnort: Berlin
Ja das meinte ich ja. Ich glaube irgendwo gelesen zu haben, dass das AntiAliasing auf die SPU's ausgelagert wird. Das finde ich doch schon ein wenig sehr merkwürdig und garnicht nextgen.

_________________
Der frühe Wurm wird vom Vogel gefangen.


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Fr Apr 03, 2009 16:26 
Offline
DGL Member
Benutzeravatar

Registriert: Di Dez 03, 2002 22:12
Beiträge: 2105
Wohnort: Vancouver, Canada
Programmiersprache: C++, Python
Lossy eX hat geschrieben:
G-Buffer: Nun ja. Der schematische Aufbau den hatte Sasche oben schon gepostet. Aber normal ist das nur ein FrameBufferObject. Bei FBOs hast du ein Objekt und kannst verschiedene Texturen als Buffer hinzufügen. Unter anderem auch eine RGBA8 Textur (4x8Bit). Oder einen Textur mit 2x 16 Bit Floats. Mit neueren Erweiterungen ist es glaube ich möglich ein mal eine Szene zu zeichnen und gleichzeitig zwei von diesen Texturen befüllen zu lassen. Wenn du später per Shader auf die Daten zugreifen möchtest geht das sehr einfach, da sich alle Daten bereits in Texturen befinden. Somit entfällt Kopieraufwand.


Jein, nicht ganz :)

Der G-Buffer ist wie Lossy schon sagt einfach nur ein FBO. An den werden in der regel 4 Texturen gehängt, sprich 4 texturen mit je 4x8byte =16 farb kanäle.
Per shader ist es jetzt möglich in nur einem renderdurchgang alle 16 kanäle gleichzeitig zu befüllen, man zeichnet also die Scene nur einmal und bekommt und schreibt in die Texturen informationen wie die normale, diffuse, specular infos etc (sie das diagram oben).

Jetzt kann man in einem zweiten renderschritt ganz leicht und sehr performant die beleuchtung berechnen, indem man die textur einfach bildschirmfüllend darstellt und die shader nur auf dieses eine Quad anwendet. Die normals etc stehen ja alle in der Textur, es wird als nur das mit licht geshaded was auch wirklich sichtbar ist (also in der textur ist).

Großer vorteil ist halt, das es kaum einen unterschied macht ob man jetzt ein licht oder fünf hat.. es wird nur ein paar fps langsamer werden. Dafür ist das erstellen und befüllen der FBOs relativ langsam. Man hat also von anfang an, selbst mit nur einem cube eher eine niedrige framerate (sagen wir mal 100fps) statt auf normalem wege (sagen wir 1500fps), dafür wird diese fps zahl aber auch mit 10 lichtern nur auf 80fps runtergehen, wohingegen das bei normalem renderning schon im stark ruckelnden bereich enden dürfte.. ;)

Aya


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Fr Apr 03, 2009 16:40 
Offline
DGL Member
Benutzeravatar

Registriert: Mo Sep 23, 2002 19:27
Beiträge: 5812
Programmiersprache: C++
Evil-Devil hat geschrieben:
MarvDasSchaf hat geschrieben:
Cell-Chip mit irgendwelchen Komischen SPU's die dann die Arbeit von der Grafikkarte übernehmen (wie AntiAliasing) und dann hier super tollen schnellen RAM, aber mit wenig Speicher.

Vor allem da die PS3 nicht einmal hardwareseitiges AA hat. AA muss vom Entwickler implementiert werden ansonsten hat man den ungewünschten Treppchen-Effekt.


Die PS3 kann sehr wohl AA in Hardware. Allerdings nur das sog. Quincunx Muster, welches leider das komplette Bild verwaschen lässt. Aber die SPUs können ja mit voller Bandbreite auf den VRAM zugreifen und Entwickler können so theoretisch diverse eigene AA-Modi implementieren. Aber natürlich nur wenn die Rechenleistung der SPUs nicht andersweitig benötigt wird. Aber ja, eine bessere GPU hätte der PS3 gut getan, genauso wie ein Hardwarescaler.

_________________
www.SaschaWillems.de | GitHub | Twitter | GPU Datenbanken (Vulkan, GL, GLES)


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Fr Apr 03, 2009 17:04 
Offline
DGL Member
Benutzeravatar

Registriert: Di Sep 03, 2002 15:08
Beiträge: 662
Wohnort: Hamburg
Programmiersprache: Java, C# (,PhP)
Sascha, was nützt einem denn bitte "verwaschenes AA"? Das will doch kein Endkunde sehen. Ok, für eine Nebelwerfer Anwendung vllt. zu gebrauchen x_X

Mich hat die PS3 bisher jedenfalls nicht überzeugt. Es gibt zwar das ein oder andere Spiel das ich gerne spielen würde, aber zur Zeit überwiegen noch immer die Nachteile. Mal davon abgesehen bekommt man eine PS3 ganz leicht zum krepieren ^^

_________________
(\__/)
(='.'=)
(")_(")


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Sa Apr 04, 2009 02:42 
Offline
DGL Member
Benutzeravatar

Registriert: Fr Jan 04, 2008 21:29
Beiträge: 419
Wohnort: Lübeck
Also ich muss jetzt sagen, das mich das überhaupt nicht vom Hocker haut. Was ich damit meine ist, dass es seit der Erfindung des deffered shading nichts neues mehr ist, dass man meherere Datensätze in mehreren Ebenen in ein FBO klatscht um sich so für diverse Grafikeffekte alle nötigen Daten direkt vorzureservieren und bereitstellen zu können. Ich halte ein solche Tabelle für ziemlich unaussagekräftig, was mich viel eher interessieren würde ist, wenn mal jemand nen expliziten Weg beschreiben würde, wie man ein solches FBO programmiert, das diese Daten so hält UND auch so beschreiben und lesen kann mit einem Shader.
Nahe zu alle FBO Beispiele die ich bisher gefunden haben missbrauchen dieses wunderbare Gebilde meistens als RTT-ersatz dementsprechend ist man also nicht gerade mit tiefgreifenden Informationen übersäht. Desweiteren stellen sich mir immer wieder die Fragen wie: Wenn ich ein Buffer aus 2x16bit float erstelle, wie sorge ich dafür dass die Daten auch tatsächlich als 2x16float ankommen. Wie sorge ich dafür, dass ich die Daten auch so lesen kann?
Das größte Problem habe ich bisher immer mit Depthbuffern gehabt, die ich immer noch nicht gelöst habe, was wahrscheinlich daran liegt, dass in jedem Tutorial mit den shadow und proj Datentypen aus glsl gearbeitet wird, ich aber nirgends ein Dokument gefunden habe in dem ausgiebig beschrieben wird, was genau diese Datentypen machen und wie welche Daten darin verarbeitet werden. Einzige Information die ich dazu finde ist :"man kann damit wunderbar shadow Maps in die Engine bringen" , na klasse. Das hilft beim implementieren viel.

Wenn jemand solche informationen mal gezielt auf den Punkt bringen kann, oder eine solche Quelle findet, dann wäre einem mal wirklich geholfen (ich gehe davon aus, dass solche Dinge bei mehreren Leuten interesse wecken), statt dessen kann man sich dann von irgendwelchen "langeweileshooter/mmorpg"-Firmen techdemos angucken in denen sie lediglich so viel von ihrer Grafikengine preisgeben, um damit dem 08/15 User das Produkt zu verkaufen. Denn im Endeffekt scheitert es, zumindest bei mir, nicht am fehlenden Einfallsreichtum was die Techniken angeht, sonder viel mehr an den nötigen Information um mit dem nötigen Material vernünftig arbeiten zu können.

Nichts desto trotz find ich es trotzdem klasse, dass zumindest die Idee hinter den Grafiksystemen gezeigt wird und das du (@Sascha) dir die mühe machst das auch direkt an den Mann zu bringen, denn interessiert daran sind wir ja trotzdem alle und geil siehts schließlich auch aus :)

//Offtopic: muss man für ein solches System eigentlich immer Texturen an das FBO binden, oder reichen auch normale Renderbuffer, die Daten sollen ja eigentlich garnicht auf dem Bildschirm landen sondern nur im Speicher!?

_________________
Klar Soweit?


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: So Apr 05, 2009 08:48 
Offline
DGL Member

Registriert: Di Mai 24, 2005 16:43
Beiträge: 710
Motion Blur wird scheinbar über Texturen gehandhabt bei denen die Farbe die Geschwindigkeit des Pixels darstellt. Weiß jemand genau wie dieser Ansatz funktioniert oder gibt es sogar irgendwelche Quellen dazu?

mfg


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: So Apr 05, 2009 12:01 
Offline
DGL Member
Benutzeravatar

Registriert: Mo Sep 23, 2002 19:27
Beiträge: 5812
Programmiersprache: C++
In Killzone 2 wird afaik objektbasierendes Motionblur benutzt, neben Crysis das einzige Spiel bei dem diese Technik Verwendung findet. Das sieht im Spiel richtig genial aus wenn schnelle Objekte wie Transportpods etc. damit versehen wird. Von NVidia gibts die Ogre-Demo in der das auch gezeigt wird, aber Paper gibt es nicht wikrlich. In GPU Gems 3 ist ein Artikel zum Thema Motion Blur als Post-Process Effekt, siehe hier. Weiter unten in dem Artikel wird auch kurz was zur Velocitymap für dynamische Objekte gesagt.

_________________
www.SaschaWillems.de | GitHub | Twitter | GPU Datenbanken (Vulkan, GL, GLES)


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: So Apr 05, 2009 14:22 
Offline
DGL Member
Benutzeravatar

Registriert: Di Mai 18, 2004 16:45
Beiträge: 2621
Wohnort: Berlin
Programmiersprache: Go, C/C++
Das einzige Manko an der PS3 war die Grafikkarte, da man in der Orginal Revision eigentlich keine vorgesehen hatte, hat man sich kurzzeitig entschieden eine einzubauen und NV die Lösung überlassen. Dabei kam eine gf7800 mit aufgebohrten Design zum Einsatz. Diese kann neben den standard 7800 fähigen Karten noch einige zusätzliche Extensions aus dem gf8 und gf9 Karten eingebaut. Die wahl der 2 Speicher hat Vor- und Nachteile, so ist der nutzbare Speicher recht klein, in Anbetracht von Full-HD Content(2x 256MB) aber dafür sind diese unterschiedlich getaktet, so ist der XRam(Arbeitspeicher) direkt an der Cell gebunden und der schnellste Speicher auf dem Markt(8 lese/schreibzugriffe pro flanke und ein sehr hohen Taktung). Der Grafikspeicher ist ebenfalls sehr schnell aber mit 256MB halt recht klein, wenn man z.B. deferred shading mit 1960x1080 Auflösung betreiben will, dann ist wenig Texturspeicher und Meshspeicher da.
Ein wesentlicher Vorteil gegenüber der XBox ist z.B. die Serienmässige Festplatte, welche das Speicherproblem auf CPU seite aufhebt, da die Spiele ein Swapfile auf der HDD ablegen können. Bei XBox360 wird dieses von einigen Spielen auch gemacht und diese sind dann auch extra gekennzeichnet, da sie auf den Classic Versionen nicht laufen bzw. stark eingeschränkt. Ein weiterer Vorteil ist das Blue-Ray Laufwerk, welches wesentlich performanter als das DVD-Laufwerk ist. Der durchsatzt und die Größe der Layer machen viel aus, wenn es um den Spurwechsel und seektime geht(stark notwendig für streaming).
Daher ist die PS3 ein sehr gut durchdachtes und sehr wohl für kommende Spiele gerüstet.

Auf der PS3 lohnt sich die verwendung von Deffered Shadern, da die SPUs sehr einfach und schnell die boundingboxen für eine Lichtquelle ausmachen können, man viele Lichtquellen benötigt und die Anzahl an der Texel, die durch die Shader Pipeline rauschen stark reduziert wird.
Ein Problem ist natürlich das AA auf der PS3, wenn man Deffered Shading benutzt, da es keine FBOs mit AA unterstützt gibt.
Hierfür gibt es dann einige möglichkeiten, dass selber zu machen. Kantenerkennung und einfacher gauß blur, das target größer zeichnen und per hardware verkleinern und noch einige weitere. Da die Kantenerkennung in der Regel eh benötigt wird, um z.B. Schatten und Motion-Blur zu verbessern, ist der mehraufwand für AA eigentlich kaum größer.

Wie Sascha Willems schon erwähnt hatte, war die bekanntmachung des Technischen Hintergrundes von KillZone2 schon 2007.
Dem entsprechend ist da auch nichts neues zu bewundern aber halt ein fertiges Spiel was mal die ganzen Technologien verwendet.

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: So Mai 10, 2009 21:20 
Offline
DGL Member
Benutzeravatar

Registriert: Di Jul 29, 2003 00:11
Beiträge: 436
Ein Interview mit den Entwicklern, was sie so daraus gelernt haben. :)
http://www.gamasutra.com/view/feature/4 ... hp?print=1


Nach oben
 Profil  
Mit Zitat antworten  
Beiträge der letzten Zeit anzeigen:  Sortiere nach  
Ein neues Thema erstellen Auf das Thema antworten  [ 14 Beiträge ] 
Foren-Übersicht » DGL » News


Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 26 Gäste


Du darfst keine neuen Themen in diesem Forum erstellen.
Du darfst keine Antworten zu Themen in diesem Forum erstellen.
Du darfst deine Beiträge in diesem Forum nicht ändern.
Du darfst deine Beiträge in diesem Forum nicht löschen.
Du darfst keine Dateianhänge in diesem Forum erstellen.

Suche nach:
Gehe zu:  
cron
  Powered by phpBB® Forum Software © phpBB Group
Deutsche Übersetzung durch phpBB.de
[ Time : 0.044s | 17 Queries | GZIP : On ]