ZFX
ZFX Neu
Home
Community
Neueste Posts
Chat
FAQ
IOTW
Tutorials
Bücher
zfxCON
ZFXCE
Mathlib
ASSIMP
NES
Wir über uns
Impressum
Regeln
Suchen
Mitgliederliste
Membername:
Passwort:
Besucher:
4411131
Jetzt (Chat):
15 (0)
Mitglieder:
5239
Themen:
24223
Nachrichten:
234554
Neuestes Mitglied:
-insane-
"Pandora's Box" von Stefan Zerbst (Stefan Zerbst)


Hi,

hier mal ein kleiner Screenshot des Projektes "Pandora's Box" aus dem Kompendium für Markt&Technik. Es handelt sich dabei um einen Testlevel um die Performance der Engine zu evaluieren, und am 5.3.2003 hatte ich schon mal einen kleinen Teil des Levels im Tool "PanBox Edit" gezeigt.

Die im Bild gezeigte Framerate ist so niedrig, weil das Programm im Fenstermodus auf dem Desktop läuft. Im echten Fullscreemodus läuft dieselbe Szene bei einer Auflösung von 1280x1024x32 mit ca. 70 Frames pro Sekunde. Die Framerate ist dabei relativ unabhängig von der Anzahl der gerenderten Polygone, sondern mehr oder weniger linear zu der Anzahl der eingesetzten Lichtquellen. Auf dem obigen Screenshot befinden sich acht voll dynamische Lichtquellen im View Frustum. Voll dynamisch bedeutet dabei, dass die Lichtquellen sämtliche ihrer Attribute wie z.B. Farbe, Helligkeit und Position zur Laufzeit ändern können, was lediglich minimale Neuberechnungen nötig macht.

Ein wenig zum Ablauf des Renderns: Jedes Triangle wird in einem ersten Pass mit ambientem Licht gerendert. Für jede weitere Lichtquellen wird dann jedes Triangle im Einflussbereich des entsprechenden Lichts in einem zusätzlichen, additiven Pass gerendert. Hier ein paar Daten der im Screenshot zu sehenden Szene, wobei zu beachten ist, dass kein per Polygon Culling durchgeführt wird um der CPU Rechenzeit zu ersparen und die GPU schamlos auszunutzen, es ist also nicht die gesamte Geometrie der Szene wirklich am Bildschirm zu sehen:

- 9870 Indices auf 6420 Vertices
- 3290 Triangle in 1561 Polygone
- 8 voll dynamische Lichtquellen
- insgesamt 8 verwendete Texturen

Eine vollwertige Kollisionsabfrage der Kamera ist natürlich bereits implementiert, so dass die Framerate nicht nur die Performance des Renderns widerspiegelt.

Die Vergrösserung des Levels um eine beliebige Menge an Geometrie hat relativ wenig Auswirkung auf die Framerate, so lange die Geometrie nicht sehr offen gebaut wird. Wie bereits erwähnt ist die Anzahl der im View Frustrum befindlichen Lichtquellen der Haupteinflussfaktor für die Framerate. Gerendert wird über je zwei Vertex- und Pixel-Shader der Version 1.1, wobei je ein Shader-Paar für den Ambienten- und den Light-Pass benötigt wird. Statische Relikte aus vergangener Zeit, wie beispielsweise Lightsmaps oder Level-Vorberechnungen sind nicht nötig.







Von mastervc am 30.03.2003, 00:04:06 Uhr
Danke das dein neues Buch eine min 200€ teuere Karte vorraus setzt und jeder gerade mal soviel übrig hat.

Von mastervc am 30.03.2003, 00:04:06 Uhr
Danke das dein neues Buch eine min 200€ teuere Karte vorraus setzt und jeder gerade mal soviel übrig hat.

Von Azrael|jitd am 30.03.2003, 00:09:09 Uhr
sind das da schatten unter diesen rohren ? wenn ja: welche methode benutzt du, sind ja wenns welche sind recht smooth?

was für eine attenuation methode benutzt du ?

und: wann kommt das buch ungefähr raus ?
ist es sehr api abhängig ? ich benutz nämlich lieber ogl.

Von ToyToy am 30.03.2003, 00:11:18 Uhr
Das gebe ich dir Recht, Shader sind genau so ein Teufelsding wie diese "Hardware Beschleunigung". Ich habe immer noch meinen alten Pentium 75 Mhz und bin auch nicht bereit jemals wieder Geld für mein Hobby auszugeben. Alle Spiele die nicht auf einem P75 laufen sind eh scheisse...

Von hWnd am 30.03.2003, 00:37:54 Uhr
1. Das Bild sieht an sich ganz gut aus, nur ist es insgesamt etwas zu dunkel.

2.
Neue Hardware zu kaufen ist grundsätzlich verboten und ich bleibe lieber bei meinem alten 386-Notebook
;D

Von hWnd am 30.03.2003, 00:43:52 Uhr
@ Stefan Zerbst
Ein kleiner Optimierungs-Hinweis:
Wenn du den Ambient-Pass renderst schaltest du den ZWriteEnable an. Bei allen anderen Light-Passes kannst du ZWriteEnable bedenkenlos ausstellen.

Aber wahrscheinlich machst du es ja eh schon so :)

Von ChrisM am 30.03.2003, 00:48:43 Uhr
Wow, sieht sehr gut aus (obwohls etwas dunkel ist). :)

Kann man schon Objekte, die nicht zur Levelgeometrie gehören, also normale 3D-Modelle (in Worldcraft nennen die sich Prefabs) einfügen?

ChrisM

PS: @mastervc: Sorry, aber das Zerbie keine Karten unterstützt, die noch nicht mal Vertex Shader haben, ist ja wohl verständlich, schließlich kommt das Buch in einem halben Jahr raus (oder früher hoff ich :D ) und soll dann ja auch dem aktuellen Maßstab entsprechen. :)

Von Mr.DX am 30.03.2003, 09:11:51 Uhr
Stellt sich das Bild bei mir falsch dar oder ist die untere Hälfte wirklich komplett schwarz

Von Mr.DX am 30.03.2003, 09:12:25 Uhr
@Zerbie:
Welche Graka verwendest du dafür?

Von Eisflamme am 30.03.2003, 09:27:20 Uhr
@nmastervc:
Also das hat er ja schon längst gesagt, außerdem wird man bald sowieso nicht mehr ohne die GF 3 TI (mindestens) oder vergleichbare ATI Karten auskommen.

Also bei dem Screenshot ist IMHO noch nicht viel zu sehen. (mein Bildschirm ist auch dunkler)
Die Engine scheint mir sehr schnell (Ach ne!!!).
Aber mich erstaunt es extrem, dass mit 8 solchen Dynamiklichtern und den ganzen Dreiecken und 8 Texturen eine FPS von 70 zu Stande kommt.
Naja, kennn ich mich da net aus *g*
Muss aber sehr gut optimiert sein, um diese Werte hervorzubringen, also:
Nur weiter so. :

Von Richard Schubert am 30.03.2003, 10:50:09 Uhr
jo nit schlecht... richtig sinn macht das mit der dynamik aber erst wenn die lichter flackern oder sich bewegen... sonst is das ganze Pixelshaden umsonst...

anonsten gefällt mir das ab sofort auch größere bilder als 640 in der breite möglich sind :D

und hab das mal ne tonwertkorrektur vorgenommen... dann kann man auch erkennen was da schönes gemacht wurde..

http://www.devagents.de/tmp/iotw.jpg

Von Stefan Zerbst am 30.03.2003, 11:01:44 Uhr
Hi,

@hWnd
Danke für den Hinweis, aber den Depth-Buffer schreibe ich natürlich auch schon nur einmal ;)

@Mr.DX
Sorry, ich hab die Hardware-Angaben vergessen. Das ganze lief auf einem Pentium IV, 1.5 GHz, 256 MB Ram mit einer Gainward GeForce 4 Ti 4200 128 MB RAM.

Wenn man die Auflösung auf 800x600 runterdreht erreicht dieselbe Szene im echten Fullscreen noch mal einen Performance Schub um ca. 50%, auch wenn es dann aussieht wie Dark Forces. :D

@mastervc
Dazu muss ich nichts sagen oder? Ich ziele schon auf die niedrigst mögliche Hardware ab. Wenn ich Pixel Shader 1.4 und eine echte DirectX 9 kompatible Grafikkarte voraussetzen würde, dann könnte ich Deinen Einwand verstehen. Aber mit Deiner Hardware wirst Du über Quake 1 Niveau nicht hinauskommen.

Ciao,
Stefan

PS: Das Bild war vielleicht ein wenig dunkel, aber so sollte die Szene ja auch sein ;) Schatten werden hier nicht berechnet, die Lichter sind nur geschickt platziert. Der Code ist aber erweiterungsfähig, so dass man ohne weiteres auch einen Shadowvolume für jedes Licht berechnen kann. Aber der Code erscheint mir für ein Buch schon so komplex genug.

EDIT @ChrisM
Klar, Prefabs kann man im Editor speichern und wieder einladen, aber was Du hier siehst ist ja der Game Code, nicht der Editor. Türen gibt es übrigens auch schon :)

Von Godhand am 30.03.2003, 12:39:44 Uhr
Hi,

Sieht schön aus ...

Werden noch Stencil Shadows implementiert?

Und muss man Portale (sofern schon vorhanden) selber im Editor setzten oder werden sie automatisch erstellt? (so wie hier: http://www.gamedev.net/reference/programming/features/apg/)

cu, Godhand.

Von GibsonSG am 30.03.2003, 12:42:34 Uhr
wie kann man denn über 2 vertex- und pixelshader gleichzeitig rendern? regeld das DX je nach verfügbarer hardware?? hab leider nichts in der doku gefunden..

Von Stefan Zerbst am 30.03.2003, 12:47:02 Uhr
Hi,

@Gibson
Man aktiviert den ersten Shader, rendert die Geometrie, aktiviert additives Blending und rendert mit dem zweiten Shader ;)

@godhand
Die Portale werden von Hand gesetzt, da automatische Portalgeneration viel zu viele Portale erzeugt wenn man sie nicht sehr aufwendig nach vielen Restriktionen implementiert. Je mehr Portale, desto kleiner ein Sektor desto langsamer die Darstellung auf modernen Grafikkarten.

Stencil Shadows wird es für die Charaktere im Level geben, für die Level Geometrie selber nicht. Ein bisschen Verbesserungspotenzial möchte ich Euch schon noch lassen :D

Ciao,
Stefan

Von MiracleBoy am 30.03.2003, 12:48:34 Uhr
Ah, so einen Motivationsschub hab ich mal wieder gebraucht!:) So jetzt muss ich aber BandII durchrackern!
Mal eine Frage: Sind diese Rohre Billboards oÄ oder sind die "echt" 3D?
PS.: Du könntest die Screenshots ja mal auf der DetailSeite adden.

Von GibsonSG am 30.03.2003, 12:57:07 Uhr
hmm.. muss eingestehen, dass ich das jetzt nich gleich verstanden hab.. gibts da irgendwelche texte, welche ich lesen könnte?
laut den spezifikationen meiner graka von ati hab ich
Eight parallel rendering pipelines
Four parallel geometry engines
und ich möchte nich, dass eine von denen geschont wird.. :)

oder meinst du, dass du gar nicht parallel renderst...? :)

Von Stefan Zerbst am 30.03.2003, 13:01:52 Uhr
Hi,

welche Rohre meinst Du damit? Die drei metallischen Stützbalken je Seite sind natürlich echte Geometrie. Billboards sind auf dem Bild nirgendwo :)

Hier noch mal ein Screenshot des gesamten Sektors, damit man sehen kann was dort alles ungeculled gerendert wird, schliesslich sieht man auf dem Bild nur einen kleinen Teil.

http://www.zfx.info/Images/OtherStuff/panbox1.jpg

Wie man sehen kann gibt es von dem Level also noch nicht so viel zu sehen. Screenshots kommen auf die Detailseite wenn der Level entsprechend gut ausseiht und spielbar ist :) Die Tür unten links ist übrigens vollwertig einsatzbereit.

Ciao,
Stefan

Von Stefan Zerbst am 30.03.2003, 13:04:23 Uhr
Hi,

@Gibson
Stimmt, ich rendere nicht parallel, sondern nacheinander. Ich möchte ja die Hardwareanforderungen so gering wie möglich halten. Nicht, dass mir noch mehr Klagen kommen :D

ciao,
Stefan

Von GibsonSG am 30.03.2003, 13:07:45 Uhr
auf niedrige hardwareanforderungen nehm ich keine rücksicht! :)
wie kann ich denn nun parallel rendern?

ist pandora's box rein indoor? oder werden wir demnächst au schöne aussenlevels zu sehen bekommen?

Von Torsten Richter am 30.03.2003, 13:34:13 Uhr
Ich dachte du beschreibst in deinen neuen Buch eine Art Portal-Energie. Eigenlich
drüften in deinen Scrennshort nur etwa 50-100 Dreicke wirklich sichtbar sein.
Prüft du das vorher nicht?
Hast du in deinen Leveleditor eine Art BSP-Compiler integriert, der aus
beliebigen Geometriedaten zusammenhängende Sektoren erkennt und die Übergänge
zwischen den Sektoren durch Portale verbindet?

Wie hast du die Kollisionserkennung gelöst? Mit einen BSP-Baum?
Die Kamera oder der Player hat doch ein Volumen und ist nicht nur ein Punkt wie
in deinen Tutorial "Solide BSP Bäume und Kollisionsabfragen".
Dort kann es passieren das diese zur Häfte in die Wand eintaucht. Bei einen
Volumen kann es passieren das sie sich in mehreren Leafs gleichzeitig
befindet. Man könnte mit einen Mindestabstand arbeiten,aber das macht in
Ausnahmefällen auch wieder Probleme!

Ich arbeite zur Zeit an etwas ähnlichen.

Darf man fragen von wo du die Texture ausgeliehen hast?(Quake2,Duke3D..)

Von Stefan Zerbst am 30.03.2003, 13:37:04 Uhr
Hi,

das parallele Rendern kannst Du im Code nicht direkt einstellen, AFAIK musst Du nur die VertexBuffer den verschiedenen Streams zuordnen und dann eifach die Render-Funktionen mit entsprechenden Shadern aufrufen die sich der verschiedenen Streams bedienen.

Die Grafikkarte kehrt dann nach dem Render-Aufruf sofort zurück, während sie noch rendert und wenn Du danach gleich aus einem anderen Stream renderst sollte das parallel laufen. Aber das hab ich noch nie versucht ;)

Was Pandora's Box angeht, so ist das Spiel nur eine Demonstration wie man eine halbwegs nett aussehende Indoor Engine hinbekommt. Für Outdoor muss man noch ganz andere Ansätze implementieren, die man auch in das Spiel einbauen könnte (LOD über Quadtree oder ROAM z.B:), aber das sprengt den Rahmen des Buches.

Wenn ihr das jedoch aufmerksam lest, und vor allem versteht warum man dies nun so und nicht so rendert, dann sollte es kein Problem sein auch ein performantes Terrain in das Spiel zu integrieren ;)

Ciao,
Stefan

Von Stefan Zerbst am 30.03.2003, 13:44:48 Uhr
Hi,

@Torsten
EDIT: Jetzt geht der Link :)

Auf dem Shot sind schon mehr als nur 50 oder 100 Tris zu sehen, ich schätze mal so ca. 500 Stück. Es gibt keinen BSP Baum und keine langsame CPU Abfrage nach dem Culling auf Leaf Basis. Mit einem originären BSP ist das viel zu viel Aufwand. Wie ich oben geschrieben habe stört es die Performance nicht im geringsten, ob man nun 1000 Triangle mehr rendert oder nicht. Einzig und Allein für die Polygon Caches der Lichter mache ich einen Culling Test mit einer AABB, da das Multipass Rendering an der Stelle wirklich Performance frisst. Aber für den ambienten Pass ist es egal, ob ich 500, 1000 oder 2000 Polygone rendere.

Die Kollisionsabfrage mache ich über den Octree und eine Bounding Box um den Spieler. Wenn die Box ein Portal schneidet, dann muss man in beiden betroffenen Sektoren prüfen.

Wie bereits des öfteren erwähnt ist ein echter BSP mit automatischer Portalgeneration eher ein Performance-Killer auf heutiger Hardware, weil dann Deine CPU rotiert und die GPU rumidled. Zudem hast Du das Problem der illegal geometry und musst noch CSG drauf loslassen.

Ciao,
Stefan

PS: Die Texturen sind zum Teil von Duke Nukem 3D geliehen, zum Teil selber mit dem Mega Tool MS Paint erschaffen :)

Von Richard Schubert am 30.03.2003, 14:53:11 Uhr
wenn man aber nen ernsthaftes level baut besteht das doch aber eher aus 100.000 bis 1.000.000 Polygonen... und dann besteht so ein raum nichtmehr aus 1000 Polygonen sondern aus 10000 und dann is das vielleicht doch nen bisserl was andres

nach meinem wissensstand sind die mehreren Pipelines dafür gedacht um mehrere Pixel gleichzeitig zu shaden/rendern
so erreicht man ne simple superskalarität, schwierigkeiten gibts eben nur bei der tiefenunschärfe von ps.2.0

Von Azrael|jitd am 30.03.2003, 15:09:02 Uhr
wann soll das buch den voraussichtlich erscheinen ?

Von Torsten Richter am 30.03.2003, 15:41:47 Uhr
@Stefan
Entschuldige die Dreieckeanzahl,ich hatte am Angang nur den 1. dunklen Scrennshort gesehen.
Ich lasse die Portale bei mir nicht automatisch regenerieren. Flächen mit festgelegter
Texture-Image werden als Portale interpretiert. Den BSP-Baum brauche ich nur beim
Erkennen von zusammenhängenden Sektoren wenn ich meine Leveldatei erzeugen.
Im Game dient er noch dazu den aktuellen Sektor, wo sich die Kamera befindet, zubestimmen und
zu Kollisionserkennung. Die leider noch fehlerhaft arbeitet.
Du hast recht, der BSP-Baum stößt bei krummen Korridoren oder Gängen an seine Grenzen.(starke Zerstücklung)
Solange alles rechtwinklich und in einen Raster angelegt ist geht er problemlos.
Wenn du für den Spieler eine Bounding Box verwendest, kann es dann nicht passieren
das er an kantiger Levelgeometrie öfter hängen bleibt? Wäre ein Kreiszylinder oder Kugel
nicht besser geeignet?


Noch eine Frage, wieso hat jemand der von Direkt3D fasziniert ist noch Duke Nukem 3D
auf der Platte ?

Von Stefan Zerbst am 30.03.2003, 16:50:59 Uhr
Hi,

@Richard Schubert
Zitat:
wenn man aber nen ernsthaftes level baut besteht das doch aber eher aus 100.000 bis 1.000.000 Polygonen... und dann besteht so ein raum nichtmehr aus 1000 Polygonen sondern aus 10000

Wie bereits erwähnt ist der Polycount nicht der Bottleneck, sondern die Anzahl der Lichter bzw. der Polygone die von einem Licht beschienen werden. Und dort wird entsprechend geculled :)

@Azrael|jitd
Das Buch soll bis Ende Juni fertig sein, schätze ich mal :)

@Torsten Richter
Zitat:
Solange alles rechtwinklich und in einen Raster angelegt ist geht er problemlos.

Doom1 lässt grüssen ;)

Zitat:
Wäre ein Kreiszylinder oder Kugel
nicht besser geeignet?

Das zu ändern sind ca. fünf Zeilen Code, da alle Kollisionstest usw. in einer Mathe lib abstrahiert sind. Bisher funktioniert das über die AABB ohne Probleme, aber wenn man Springen, Kriechen, Ducken usw. implementieren würde (nein, ich mache das nicht für das Buch) dann müsste man sicherlich etwas genauer kollidieren.

Zitat:
Noch eine Frage, wieso hat jemand der von Direkt3D fasziniert ist noch Duke Nukem 3D
auf der Platte ?

Duke Nukem 3D war neben Dark Forces das innovativste 3D Spiel was es gab, und für Duke hab ich seinerzeit monatelang Level gebaut. Man könnte also sagen, Duke und ich habe eine recht intensive Beziehung zueinander :D

Ciao,
Stefan


Von Azrael|jitd am 30.03.2003, 21:12:14 Uhr
testest du auch über den octree in welchem sektor man steht ? wenn ja wie machst du das wenn 2 sektoren nah beieinander liegen und die octrees davon sich überschneiden ? den octree immer weiter unterteilen ?

Von Torsten Richter am 30.03.2003, 21:38:37 Uhr
@Stefan Zerbst

Zitat:
Duke Nukem 3D war neben Dark Forces das innovativste 3D Spiel was es gab

Da stimme ich dir zu.
Im Internet schwirren immer noch jede Menge Maps herum mit einer durchschnittliche
Größe von nur 50-100KB!
Mir ist immer noch ein Rätzel wie die die Transparenteffete hinkriegen (per Software)
ohne das die Framerate einbricht wenn die Transparent-Texture den ganzen Screen
ausfüllt. Das Zurücklesen aus dem Videoram ist min. 3 mal langsamer als schreiben.
Über einen extra Screenbuffer im Hauptspeicher? Aber der muß ja dann noch jedesmal
in den Videoram kopierten werden...

Wie ermittels du in deiner Engine den aktuellen Sektor in dem sich die Kamera befindet?

Unterteilst du zum Rendern jeden Sektor mittels Octree noch einmal und prüfst die einzelnen
Nodes-Boxen gegen den Frustum ?

Berechnest du den Frustum zum Rendern der angrenzenden Sektoren neu,verkleinerst ihn
auf die Maße des Verbindungsportals?

@Richard Schubert
Zitat:
wenn man aber nen ernsthaftes level baut besteht das doch aber eher aus 100.000 bis 1.000.000 Polygonen...

Auch bei Quake3 sind Skulpturen oder Wandornamente 3D-Modelle und gehören nicht
direkt zu Levelgeometrie. Das hat den Vorteil das man die Daten einmal im Speicher
hat und mehrfach an verschiedenen Positionen darstellen kann.
Bei 1 Mio Dreiecke pro Level und 3 Eckpunkte pro Dreiecke wäre ein Level größer als 36MB!

Von ChrisM am 30.03.2003, 21:39:07 Uhr
Noch was: Ist es bereits möglich, Treppen/schräge Böden hochzulaufen und falls ja, wie wird das mit der Kollionsabfrage realisiert?

ChrisM

Von Torsten Richter am 30.03.2003, 21:52:33 Uhr
@ChrisM
Funktioniert das nicht automatisch,wenn die Kollisionstestfunktion sauber arbeitet?

Von Stefan Zerbst am 30.03.2003, 23:27:06 Uhr
Hi,

@Azrael
Nein, die Sektoren werden dadurch bestimmt, dass der Spieler ein Portal durchschreitet.

@Torsten Richter
Nein, ich prüfe über die Octree Nodes keine Sichtbarkeiten, die sind rein ausschliesslich für die Kollisionsabfrage da. Aber ja, der Frustum wird durch ein Portal verkleinert. Allerdings werden nur die Polygon Caches der Lichtquellen und andere Portale gegen den Frustum geculled.

Ein Occlusion Culling der Portale innerhalb eines Sektors könnte die Engine aber sicherlich noch weiter beschleunigen.

@ChrisM
Ja, man kann bereits Treppen hochlaufen. In dem Bild des gesamten Levels kann man unten rechts grad noch so mit viel Phantasie die Test-Treppe erkennen :) Allerdings gibt es hier noch ein paar Bugs, komischerweise jedoch nicht auf der Treppe, sondern an der Kreuzung der Gänge wo die Höhe falsch berechnet wird. Aber das wird auch noch gelöst.

Ciao,
Stefan

Von ToyToy am 31.03.2003, 08:06:46 Uhr
Zitat:
Mir ist immer noch ein Rätzel wie die die Transparenteffete hinkriegen (per Software)

Kannst ja selber nachschauen, der Source Code der Build Engine wurde soweit ich weiss freigegeben.

Von Stefan Zerbst am 31.03.2003, 09:04:00 Uhr
Hi,

ich wollte nur mal ein paar neue Zahlen zu dem erweiterten Level loswerden: :D

vorher:
- 9870 Indices auf 6420 Vertices
- 3290 Triangle in 1561 Polygonen
- 8 voll dynamische Lichtquellen
- insgesamt 8 verwendete Texturen
- Framerate minimal 60 fps bei 1280x1024

heute:
- 15036 Indices auf 9782 Vertices
- 5012 Triangle in 2381 Polygonen
- 24 voll dynamische Lichtquellen
- insgesamt 8 verwendete Texturen
- Framerate minimal 58 fps bei 1280x1024

Wie man sehen kann verändert sich die Framerate kaum. Das Hinzufügen von Geometrie beeindruckt die Framerate gar nicht, lediglich die Verdreifachung der Lichtquellen zehrt ein wenig am Speed der Engine :)

Ciao,
Stefan

Von hWnd am 31.03.2003, 19:16:37 Uhr
Jo, die Zahlen schauen recht gut aus, aber kannst du nicht vielleicht mehrere Fallback-Paths machen, so dass z.B bei vs_1_1 1 Licht, bei vs_1_3 2 Lichter, bei vs_1_4 3 Lichter und bei vs_2_0 4 Lichter per Pass gerendert werden ( oder ähnlich) ?
Per Pixel-Lighting wäre auch ganz kultig :) Ab ps_1_4 kann man da schon ganz ordentliche sachen machen (Von ps_2_0 ganz zu schweigen). Und zur vereinfachung kann man auch einfach N.H (blinn) anstatt R.V (phong) ausrechnen.

Schönes paper:
http://www.ati.com/developer/dx9/ATI-DX9_Optimization.pdf

PS: Schreibst du direkt in Assembly oder benutzt du eine High-Level-Language ?

Von BertoSmasher am 31.03.2003, 20:24:32 Uhr
Haste schön gemacht :D
ich freu mich schon auf die bewerbung für betatester

Von Marc7759 am 31.03.2003, 21:24:31 Uhr
Hi,

also ich muss erstmal sagen, dass ich sehr entäuscht bin, dass du keinen BSP-Tree verwendest.
Du sagst zwar, dass er nicht mehr zeitgemäss sein soll, aber wenn ich mir so bekannte Spiele wie Quake3/HalfLife ansehe, dann wird glaube ich einem schnell klar, dass ein BSP-Tree gar nich mal so schlecht ist... Gut, er ist CPU lastig, aber es werden ja auch nich nur die GPUs schneller... Ich finde zumindestens, dass man sich den Vorreitern anschliesen sollte, vorallem wenn der Erfolg dieser 3D Engines klar sichtbar ist. Ich weis jetzt nicht, wie es die Doom3 Engine macht, aber wenn sie auch kein BSP-Tree verwendet und die Portale und Sektoren vom Level-Designer selbst gesetzt werden müssen, dann verstehe ich natürlich deine Entscheidung. Jedoch kann ich im augenblich noch nicht feststellen, dass deine Levelgeometrie im entferntesten der Domm3 Geometrie ähnelt... Deshalb denke ich, dass dann auch ein einfacher BSP-Tree und automatisch generierte Sektoren/Portale wie in der Quake Engine für diese Levelgeometrie ausreichen müssten...

Ich meine dass in bezug auf deine Levelgeometrie natürlich nicht böse (ich könnts bestimmt nicht besser), ich habe einfach nur Angst, das zu wenige und nicht weitreichende Kentnisse der Indoor-Render Technik vermittelt werden.
Aber wenn man später Doom3 Levels in deine Engine laden und mit einer akzeptablen Framerate rendern, dann bin ich zufrieden... :)

Nein, ich hab halt einfach nur Angst, dass uns die Grossen davonrennen und wir nicht mehr hinterherkommen und uns immer noch an Duke Nukem 3D festklammern...*g*

Von Stefan Zerbst am 31.03.2003, 21:47:55 Uhr
Hi,

@hWnd
Das ist per Pixel Lighting ;) Was mehrere Passes in einem Shader angeht und verschiedene Pathes für verschiedene Shader Versionen: Natürlich braucht man das für ein _echtes_ Produkt, aber es geht mir nicht darum hier alles zu implementieren was in eine Engine gehört, sondern einen guten ersten Ansatz zu liefern den man ausbauen kann. Sonst bräuchte ich eine Reihe mit zehn Bänden und ihr keine Gehirne mehr ;)

@Marc
Zitat:
also ich muss erstmal sagen, dass ich sehr entäuscht bin, dass du keinen BSP-Tree verwendest.

Es tut mir sehr leid, wenn ich Dich enttäusche. Aber warum um alles in der Welt soll ich einen BSP integrieren, wenn es dafür absolut keinen Grund gibt? By the way, Doom 3 verwendet auch keinen BSP wenn Dich das beruhigt, und selbst wenn wäre das noch lange kein Grund, dass das jeder tun muss. Wenn ich mich recht entsinne kam Unreal auch ganz gut ohne aus.

Und davon mal abgesehen, es gibt auf dieser Homepage ein Tutorial, welches Euch die Grundlagen eines BSP vermittelt. Wenn Du unbedingt einen BSP im Game COde haben möchtest so kannst Du ihn dort selbst integrieren und dann beide Varianten vergleichen, dann können wir uns weiter über Sinn und Unsinn eines BSP unterhalten ;)

Zitat:
Ich finde zumindestens, dass man sich den Vorreitern anschliesen sollte [...] wie es die Doom3 Engine macht, aber wenn sie auch kein BSP-Tree verwendet [...] dann verstehe ich natürlich deine Entscheidung.

Noch mal die Frage: Warum muss man immer das machen, was ein Entwickler Team macht, oder im Falle von id noch krasser was eine Person macht?

Zitat:
Jedoch kann ich im augenblich noch nicht feststellen, dass deine Levelgeometrie im entferntesten der Domm3 Geometrie ähnelt...

Das stimmt, ich bin kein Level Designer und kein Grafiker. Ich habe aber auch nicht den Anspruch, Doom 3 zu kopieren. Und Du verwechselst hier den optischen Output mit den Fähigkeiten der Engine. Ein professioneller Grafiker würde auf dieselbe Geometrie Texturen legen und ein Level Bauer würde die Geometrie verbiegen, so dass es wie Doom 3 aussehen würde.

Zitat:
Deshalb denke ich, dass dann auch ein einfacher BSP-Tree und automatisch generierte Sektoren/Portale wie in der Quake Engine für diese Levelgeometrie ausreichen müssten...

Was meinst Du mit ausreichen? Und bitte bedenke auch, dass dies Level nur ein erster Ansatz ist. Ich könnte ja auch noch ein paar Wochen investieren um den Level toll aussehen zu lassen. Am Code der Engine würde sich dadurch aber nix verändern.

Zitat:
ich habe einfach nur Angst, das zu wenige und nicht weitreichende Kentnisse der Indoor-Render Technik vermittelt werden.

Da brauchst Du keine Angst zu haben. Dein verkrampftes Festhalten am BSP zeigt, dass Dir das Buch doch einiges an Technik vermitteln kann womit Du dann auch sicher für aktuelle Hardware programmieren kannst, und nicht mehr nur für für die GeForce 2 und abwärst Generation ;)

Zitat:
Aber wenn man später Doom3 Levels in deine Engine laden und mit einer akzeptablen Framerate rendern, dann bin ich zufrieden...

Äh... hallo? In dem Buch geht es darum, Dir Techniken zu vermitteln. Es ist nicht mein Anspruch, Dir eine fertige Engine hinzulegen auf der Du ein paar Level aufsetzt. Es soll Dir als Grundlage dienen, eine eigene Engines daraus zu entwickeln und für eine solche Grundlage bietet die bereits vorhandene Engine mehr als genug, um Deine kleinen grauen Zellen ein paar Wochen rotieren zu lassen. Sei mir nicht böse, aber Dein ganzes Posting liest sich so, als ob Du von mir einen Clone der Doom 3 Engine geschenkt haben möchtest.

Zitat:
[...] und uns immer noch an Duke Nukem 3D festklammern...*g*

Tja, man sollte wie bereits erwähnt nicht von den Texturen auf die Qualität der Engine schliessen, sondern auf die des Grafikers ;) Tausch diese Texturen gegen die eines echten Grafikers aus der sie an der Performance der Engine orientiert (nicht dass mir einer in den Mund legt ich würde schlecht über die Grafiker von Duke Nukem renden, aber damals waren 8 Bit in) und Du würdest den Shot ganz anders beurteilen. Versuch einfach mal zwischen den Zeilen zu schauen...

Ciao,
Stefan

Von hWnd am 31.03.2003, 22:01:54 Uhr
Zitat:
Das ist per Pixel Lighting


Dann kannst du ja auch gleich Bump-Mapping integrieren :)

Von Marc7759 am 31.03.2003, 22:41:42 Uhr
@Stefan Zerbst

Oje, da entläd sich ja so einiges... :)

Also, ich verstehe nich, was so falsch daran ist, erfolgreichen 3D Engines nachzueifern ??? Ich finde man sollte immer ein gewissen Ziel haben, auch wenn dieses Ziel unerreichbar scheint... Ich finde ja einfach nur, dass der Screenshot nicht Geforce3 (und aufwärts) würdig ist... die Quake3 Engine hätte warscheinlich bei gleicher Geometrie und System 200 Fps zu bieten, da ein BSP-Tree verwendet wird... Und ich kann mir auch nur schwer vorstellen, dass soviel Overdraw gut ist...Du sagst sogar in deinem BSP-Tree Zutorial, dass jeglicher Overdraw vermieden werden muss... Und ich finde, dass dies auch bei besseren und schnelleren Grafikkarten geschehen soll. Und ich finde es auch sehr verwunderlich, dass du dich sogar noch freust, dass du bedeutend mehr Polygone zeichnest als man auf dem Screen sieht... Oje, ich sehe schon, ich reite mich immer weiter rein...am besten halt ich jetzt einfach mein vorlautes Maul... ich sehe schon, dass es ein Fehler war, hir zu posten... ;-)

Also, was ich sagen wollte ist, dass es dann vollkommen OK ist, wenn du der Indoor-Render Technik von Doom3 verfolgst... zumindestens für mich... :) Dass kann man ja dann später noch ausbauen :)

Und nein, ich habe keinen Doom3 Fetisch oder ähnliches... Ich möchte einfach nur etwas hervorheben, wonach es sich lohnt hinzuarbeiten.
Warscheinlich siehst du das anders...

MfG, Marc Schiller

Von Stefan Zerbst am 31.03.2003, 23:10:51 Uhr
Hi,

Zitat:
Oje, ich sehe schon, ich reite mich immer weiter rein...am besten halt ich jetzt einfach mein vorlautes Maul... ich sehe schon, dass es ein Fehler war, hir zu posten...

Kein Grund gleich zynisch zu werden ;)

Natürlich ist Overdraw ein Problem, doch die meisten Hobby-Applikationen tendieren dazu, CPU limited zu sein und die Grafikkarte rumidlen zu lassen. Sinnvoller als ein BSP fände ich hier zunächst ein Occlusion Culling der Light Polygon Caches und der Portale.

Es geht mir auch nicht darum, hier etwas zu "entladen" und mich "zu freuen" dass ich so viele nicht sichtbare Polygone rendere. Es geht aber auch darum zu zeigen, dass die Grafikkarte diese nicht sichtbaren Polygone schneller rendern kann, als Du sie auf der CPU cullen könntest.

Jede Struktur wie z.B. ein BSP sorgt dafür, dass nicht nur die CPU rödelt, sondern dass Du Traffic über den Bus erzeugen musst. Über einen BSP zu rendern ist daher keine gute Idee und das wird auch Quake 3 nicht so machen. Du könntest natürlich in den Leaves Indexlisten speichern. Dann müsstest Du aber in jedem Frame eine Indexliste aller sichtbaren Leaves zusammenstellen und über den Bus schicken.

Ein BSP sorgt übrigens auch nicht dafür, dass Du keinen Overdraw hast. Dazu braucht man ein reines Portalsystem und Clipping auf Polygonebene. :)

Ich lerne aber jederzeit gerne dazu, und wir können unsere verschiedenen Ansichten ja einfach durch entsprechende Implementierungen im Life Fire vergleichen wenn Du magst? :)

Versteh meine Kommentare einfach nicht als Angriff, sondern als Vertreten meiner Überzeugung was auf heutiger Hardware sinnvoll ist ;)

Ciao,
Stefan

EDIT
Zitat:
Du sagst sogar in deinem BSP-Tree Zutorial, dass jeglicher Overdraw vermieden werden muss...

Ja, aber das habe ich auf einer ATI Rage Mobile entwickelt und das ist schon ein Weilchen her. Und genau davon rede ich ja. So schnell wie sich die Hardware entwickelt muss man alte Techniken ständig nach deren Existenzberechtigung auf aktueller Hardware hinterfragen. ;)

Wie oben bereits auch erwähnt ist der aktuelle Polygoncount hier nicht ausreichend, um die Performance zu drücken. Klar könnte die Quake Engine das mit 200 fps rendern. Aber ich könnte noch mal dieselbe Anzahl an Polygonen drauflegen und würde dann im Verlgeich zur Quake Engine schon besser dastehen schätze ich mal. Auf die Performance drücken hier insbesondere die Textur Switches und die multiplen Passes für die Lichter, wobei die Framerate steigt, je weiter die Lichter weg sind, weil dann dort für weniger Pixel ein zusätzlicher Pass gemacht werden muss.

Von MK42 am 31.03.2003, 23:11:53 Uhr
@Marc7759:
Das die Quake 3 Engine die Szene schneller darstellen würde liegt daran, dass sie Lightmaps verwendet. Stefan könnte mit seiner Engine sehr leicht alle Lichter blinken und sich bewegen lassen OHNE einen größeren Performanceverlust zu verbuchen. Außerdem sind 'reine' BSP-Engines wirklich nicht mehr zeitgemäß für die heutige Hardware. Es ist viel schneller größere Mengen von Dreiecken zu rendern, wie die kleinen Fragmente in den Leafs des BSPs zu akkumulieren und zu rendern.

In Doom 3 werden übrigens die Portale von Hand gesetzt :)

@hWnd:
Stefan könnte durchaus bump mapping integrieren. Doch würde das Buch dann bestimmt 100 Seiten länger, weil er so Krams wie Tangent Space erklären müßte ... wie wird er berechnet, was für Probleme kann es geben, etc... man muß ja auch noch *etwas* selber machen ... wenn Du in die Engine noch bump mapping, stencil shadows und specular lighting einbaust HAST Du Doom 3 ... so einfach ist das!

@MasterVC:
wer übringens meint, dass man €200 für eine GF3 und aufwärts zahlen muß, der sollte sich nochmal umschauen. Für soviel Geld kriegt man bereits eine DX9-fähige Karte ... für jemand der Grafik-Programmierung mag eigentlich ein MUSS!

-Marco

Von Torsten Richter am 31.03.2003, 23:25:58 Uhr
@Marc7759
Zitat:
Und ich kann mir auch nur schwer vorstellen, dass soviel Overdraw gut ist

Der gleichen Meinung bin ich auch. Sinn und Zweck einer guten Portal-Energie ist es doch das nur die von der aktuellen
Kameraposition sichtbare Flächen gerendert werden. Das entlastet auch die Grafikkarte
wenn noch aufwendige Bendingoperation, die nicht in einen Pass durchgeführt werden können, anstehen.
Wenn jemand eine ältere Karte hat, naund dann werden einfach die Effekte abgeschalten und es läuft trotztem.
Größe meines kleinen Testlevel:
3332 Vertices
3204 Polygone(Vierecke)
26 Sektoren
42 Portale
normale Ansicht:
Overdrawtest durch Transparentdarstellung
mit Sichtbarkeit testen:
alles Ausgeben:

Bitte nicht über meine billige Grafik lästern! (ohne Beleuchtung,Software)


@ToyToy
Danke für den Tipp.

Von MK42 am 31.03.2003, 23:42:04 Uhr
Was den Overdraw angeht ... der ist nicht so schlimm ... dank Early-Z Testing. Was viel mehr ins Gewicht fällt ist Füllrate ... also wieviel Fläche gerendert wird. D.h. es ist unter Umständen besser viele kleine Lichter zu haben, anstelle von ein paar Großen, die sich überlappen.

Ach ja, Stefans Screenshot würde deutlich besser mit bunten Lichtern und nicht so eintöniger Geometrie aussehen ... der Level ist jedoch für 'Programmers Art' schon beachtlich gut!

Man beachte: Stefan hätte die Engine durchaus besser machen können, aber er muss immer einen sehr feinen Grad zwischen 'cool', 'brauchbar' und 'einfach genug' wandern.

-Marco

Von Stefan Zerbst am 01.04.2003, 06:53:40 Uhr
Hi,


Zitat:
der Level ist jedoch für 'Programmers Art' schon beachtlich gut!


:D :D :D

Darum wird der Editor ja auch vorher released, damit die Community was Vernünftiges damit zustande bringen kann :)

Ciao,
Stefan

Von mastervc am 01.04.2003, 19:23:10 Uhr
Ich mag Indoor Ey nich so ;)

Aber wie wärs denn mit BSP + PSV oder wie das heisst ? Oder was eigenes ?

Also ich finde die Spiele sollten schon noch auf alten Rechner laufen *pc streichel* ;)

Ich cödel lieber Dx8.1, Dx9 is mir zu doof und bringt mir nix, da ich ASM (Shader) nich kapiere.

cya

Von int am 01.04.2003, 20:34:08 Uhr
mastervc: du redest hier so sinnloses zeug - unglaublich! dein erstes posting hat mir schon gereicht, aber das is auch net besser!

mir gefällt der shot sehr gut (zwar nicht so gut wie der editor, aber immer noch besser als das meiste andere)

zu der technik kann ich wenig sagen, kenn mich damit zuwenig aus

Von Stefan Zerbst am 01.04.2003, 20:54:20 Uhr
Hi,

@mastervc
Bezüglich BSP + PVS: Lies mal mein Posting 5 bzw. 7 über Deinem. Vielleicht bringt Dir das ja was? :D

@int
Thx, aber das Level ist ja noch lange nicht fertig. Ich bemüh' mich so gut es geht ;), und wenn erst mal ein paar Detail Objekte drin sind, dann sieht die Sache sicherlich noch ein wenig akzeptabler aus.

Ciao,
Stefan

Von ChrisM am 01.04.2003, 21:30:39 Uhr
Zitat:
Ich cödel lieber Dx8.1, Dx9 is mir zu doof und bringt mir nix, da ich ASM (Shader) nich kapiere.


Häh, dann müsste es doch grade andersrum sein, denn unter DirectX 9 kannst du ja eine High Level Shader Language benutzen, unter DirectX 8 musst du mit Assembler arbeiten. :)

ChrisM

Von Patrick am 01.04.2003, 22:01:51 Uhr
was ist eigentlich die Story von Pandora's Box?

Von Stefan Zerbst am 01.04.2003, 23:40:52 Uhr
Hi,

Story? Hm... Story (blätter im Ego-Shooter Duden)... was ist eine "Story"? :D

Natürlich gibt es hier keine Zwischensequenzen oder ähnliches falls Du das meinst :) Die Story, die sich um Pandora's Box rankt kann man jedoch in jedem einschlägigen Werk zur griechischen Mythlogie nachlesen, denn Lesen bildet bekanntermassen. Mehr Story als diese Sage hat auch Doom nicht zu bieten :D

Ciao,
Stefan