Doom 3 High-Poly Models

[Rampage]

Hi,

in letzter Zeit hört man ja immer wieder das für Doom 3 und ähnliche Spiele, alle Moddels mit riesen Polygonenmengen vorgerendert werden, um sie dann runterzuregeln und aus den High-Poly-Modelen Bump Maps erzeugt. (war doch so ?!)

Jetzt zwei Fragen:

1. Ist das früher auch schon teilweise mit ähnlicher Technik gemacht worden, bzw hat man frpher auch erst highpoly Modele erstellt.

2. würde es einen Vorteil bringen wenn man, sagen wir nach einem Jahr, die Models neu herunterregelt, um eine bessere Grafik zu erreichen und aktuelle Hardware wieder ausreizen zu können ?


PS: Hauptaugenmerk liegt auf der Möglichkeit einer bessere Grafik zu erzeugen =)

[ice cool69]

JC hat bewusst auf ein verfahren mit vielen bump maps und geringerer polygonmenge gesetzt weil das ergebnis besser aussieht als viele polygone ohne bm.
wie die zukunft aussieht weiß ich nicht, ich hoffe es geht in die richtung welche matrox mit der parhelia eingeschlagen hat ;)

[Rampage]

meinst du displacement mapping ?? Waren schon geile Demos von der Parhelia =)

Ich finde allerdings das man es mit dem ganzen Bump-Mapping nicht so übertreiben sollte, das ist imho wie be schlechten Texturen, gehste nah ran siehts scheiße aus :|

[mirp]

IIRC hat JC was gegen DM (und TruForm), weil man damit nur schwer die Schatten korrekt berechnen kann, die ein solches Objekt wirft.

[Demirug]

Ja das Problem mit DM und Truform (N-Patch) sowie jeder anderen Form von HOS Verfahren ist das man die Geometrie damit nachträglich auf der Grafikkarte verändert. Die Schatten werden aber nach wie vor Teilweise von der CPU auf Basis der unveränderten Geometrie berechnet. Dadurch passen der Schatten und das Object nicht mehr zusammen was zu Artefakten führen kann. Vorallem wenn das Object auf sich selbst einen Schatten wirft.

JC würde auch lieber Highpoly+Bumpmapping benutzten aber das schaffen die CPUs (ja CPUs) nicht da die Schattenberechung stark CPU lastig ist und mit der Anzahl der Polys skaliert.

@Rampage:

1. Teilweise wurden auch schon früher Highpolymodels als Konzept vorlage benutzt oder wenn man für 2d Spiele die Figuren und Animationssequenzen gerendert hat wurde das auch meistens mit Highpolymodelen gemacht. Es ist eben einfacher ein gutes Highpoly model zu designen als ein gutes Lowpoly Model.

2. Ja bringen würde das schon was aber wie gesagt ist der Polycount eher ein CPU den ein GPU problem und die werden ja langsamer schneller als die GPUs.

[Endorphine]

Wenn man BM und DM nur als Mittel zum Zweck betrachtet und die Geometrieauflösung des Grundobjekts hoch genug ist sollte ein sehenswerter Schattenwurf doch IMHO kein Problem sein...

[Demirug]

Original geschrieben von Endorphine
Wenn man BM und DM nur als Mittel zum Zweck betrachtet und die Geometrieauflösung des Grundobjekts hoch genug ist sollte ein sehenswerter Schattenwurf doch IMHO kein Problem sein...

Leider doch :(

Das sind zwar nur wenige Pixel grosse Artefakte aber da sie in der Regel am Rand auftreten und von Frame zu Frame auch noch wandern können gibt das ein übles Pixelflimmern am Rand eines Objects weil die Pixel ständig zwischen der Schatten und Lichtzone hin und her wandern.

[Abe Ghiran]

Original geschrieben von Demirug
Die Schatten werden aber nach wie vor Teilweise von der CPU auf Basis der unveränderten Geometrie berechnet.

Mal abgesehen von HOS, wie sieht das dann eigentlich mit Geometrietransformationen durch Vertex Shader aus? Das Ergebnis kriegt die CPU doch dann auch nicht mehr zu sehen (denke ich mal)...
Muß dann der Schattenalgo der auf der CPU läuft die Transformation noch mal machen? Oder kann JC wenn er schon VS benutzt, auch die Berechnung der Schattenvolumen dort machen?

Grüße, Jan

[Xmas]

Original geschrieben von Abe Ghiran
Mal abgesehen von HOS, wie sieht das dann eigentlich mit Geometrietransformationen durch Vertex Shader aus? Das Ergebnis kriegt die CPU doch dann auch nicht mehr zu sehen (denke ich mal)...
Muß dann der Schattenalgo der auf der CPU läuft die Transformation noch mal machen? Oder kann JC wenn er schon VS benutzt, auch die Berechnung der Schattenvolumen dort machen?

Grüße, Jan
Die Berechnung der Shadow Volumes geht auch im Model Space, d.h. die Geometrie muss nicht transformiert werden. Lediglich die Position der Lichtquelle muss vom World Space in den Model Space transformiert werden, sowie evtl. die Near und Far Clipping Planes.

[Kai]

Wenn ich das richtig sehe wurden die Fragen des Threadstarters nicht beantwortet ;)

[Rampage]

Original geschrieben von Kai
Wenn ich das richtig sehe wurden die Fragen des Threadstarters nicht beantwortet ;)

danke :bier: :verd:

[Aqualon]

Original geschrieben von Demirug
@Rampage:

1. Teilweise wurden auch schon früher Highpolymodels als Konzept vorlage benutzt oder wenn man für 2d Spiele die Figuren und Animationssequenzen gerendert hat wurde das auch meistens mit Highpolymodelen gemacht. Es ist eben einfacher ein gutes Highpoly model zu designen als ein gutes Lowpoly Model.

2. Ja bringen würde das schon was aber wie gesagt ist der Polycount eher ein CPU den ein GPU problem und die werden ja langsamer schneller als die GPUs.

Reicht das denn nicht als Antwort? :kratz:

[micki]

man kann die shadowvolumes vollkommen auf dem vertexshader machen (wenn die vertices einmal richtig vorbereitet wurden) aber nach einer tesselierung sind die informationen zerstört meiner meinung nach.

ich bleibe bei shadowmaps, da kann man das alles nutzen und hat kein problem.

übrigens sagte carmack in einem der letzten interviews, dass die objekte bis ca 5k polys haben (also als lowpoly würde ich das nicht bezeichnen auch wenn man auf den screenshots kanten erkennt, es war ja die alpha)

MfG
micki

[Demirug]

Original geschrieben von micki
man kann die shadowvolumes vollkommen auf dem vertexshader machen (wenn die vertices einmal richtig vorbereitet wurden) aber nach einer tesselierung sind die informationen zerstört meiner meinung nach.

Davon mal abgesehen das für vollständig im Vertexshader berechnete Schattenvolumen derzeit die Chipleistung nicht ausreicht hast du damit recht das eine Tesselations das dafür notwendige Datenformat zerstört.

ich bleibe bei shadowmaps, da kann man das alles nutzen und hat kein problem.

Wenn ATI das ganze unter DX zugänglich machen würde wäre die Sache durchaus noch interresanter. Beim R300 kann man sich notfalls mit einer FP Texture helfen aber das ware ist das auch nicht.

übrigens sagte carmack in einem der letzten interviews, dass die objekte bis ca 5k polys haben (also als lowpoly würde ich das nicht bezeichnen auch wenn man auf den screenshots kanten erkennt, es war ja die alpha)

MfG
micki

Da kann man wohl nur abwarten wie es am Ende aussieht.

[egdusp]

Wieso ist das Shadowing so CPU intensiv? OK, technische Erklärungen benötige ich nicht unbedingt, aber mich würde interessieren, ob man das nicht auch einfach mit spezialisierten Einheiten in der GPU machen kann? Angelbich sollen ja bei NV40 und ATI R4(5)00 solche Einheiten (nicht nur auf Schatten bezogen) vorhanden sein, ich komme nicht mehr auf den Namen, hatte aber was mit Flußkontrolle und Sprungvorhersage zu tun.

mfg
egdusp

P.s.: Endlich mal wieder ein niveauvoller Thread, seit Nagus aus dem Urlaub zurück ist (war wohl mit Tarkin dort :D) steigt das Flameniveau beträchtlich. Seltsamerweise ist Nagus selten der schlimmste Flamer.

[Demirug]

Original geschrieben von egdusp
Wieso ist das Shadowing so CPU intensiv? OK, technische Erklärungen benötige ich nicht unbedingt, aber mich würde interessieren, ob man das nicht auch einfach mit spezialisierten Einheiten in der GPU machen kann? Angelbich sollen ja bei NV40 und ATI R4(5)00 solche Einheiten (nicht nur auf Schatten bezogen) vorhanden sein, ich komme nicht mehr auf den Namen, hatte aber was mit Flußkontrolle und Sprungvorhersage zu tun.

mfg
egdusp

P.s.: Endlich mal wieder ein niveauvoller Thread, seit Nagus aus dem Urlaub zurück ist (war wohl mit Tarkin dort :D) steigt das Flameniveau beträchtlich. Seltsamerweise ist Nagus selten der schlimmste Flamer.

egdusp, ja beim NV40 sprechen die Gerüchte von einen PPP (Programmable Primitive Processor) welcher das erzeugen von Schatten volumen in der GPU ermöglichen soll. Was aber wirklich dran ist weiss man noch nicht so genau.

Der Grund das die Schatten so CPU intensive sind besteht darin das die CPU für jede Kante eines Objekts eine berechnung ausführen muss um festzustellen ob von dieser Kante ein Schatten ausgeht. Falls ja müssen für diese Kante 2 neue Dreicke erzeugt und in eine Liste kopiert werden.

Man kann diese rechung durchaus auch in der GPU durchführen dabei entstehen aber mehrer Probleme.

Das kleinste ist der Speicherplatz da für jede Kante des Objects 4 Verticen und 2 Dreiecke vorgesehen werden müssen.

Da es nun 4 Verticen pro Kante gibt und ein Vertexshader nur auf Vertexebene rechnen kann muss er die Berechnung 4 mal ausführen.

Bei nicht benötigten Kanten setzt der Vertexshader alle 4 Verticen so das es dem Trisetup nicht möglich ist ein Dreieck damit zu rendern und es deswegen verworfen wird. Trotzdem müssen die Dreiecke den Beginn des Trisetups durchlaufen und zählen daher als Dreiecke wenn es um die Frage der Dreiecke/Sekunde geht. Letzen Endes kostet also jede Kante 2 Dreiecke ob sie nun gebraucht wird oder nicht.

[micki]

Original geschrieben von Demirug
Davon mal abgesehen das für vollständig im Vertexshader berechnete Schattenvolumen derzeit die Chipleistung nicht ausreicht hast du damit recht das eine Tesselations das dafür notwendige Datenformat zerstört.


ich weiß net genau was du mit "die Chipleistung nicht ausreicht" genau meinst, aber ich benötzige dafür (falls ich jetzt net was übersehe, die sachen hab ich zuhause) pro vertex 3 oder 4 instruktionen mehr als ohne und die schatten sind perfekt (also nicht für jedes dreieck ein volume).

gehen geht das schon, klappt sogar mit animierten vertices (skinning) wobei dann die anforderungen um einiges höcher, aber noch erträglich, sind.

MfG
micki

[Demirug]

Original geschrieben von micki
ich weiß net genau was du mit "die Chipleistung nicht ausreicht" genau meinst, aber ich benötzige dafür (falls ich jetzt net was übersehe, die sachen hab ich zuhause) pro vertex 3 oder 4 instruktionen mehr als ohne und die schatten sind perfekt (also nicht für jedes dreieck ein volume).

gehen geht das schon, klappt sogar mit animierten vertices (skinning) wobei dann die anforderungen um einiges höcher, aber noch erträglich, sind.

MfG
micki

Ich beziehe mich auf das vollständige Volumen Verfahren so wie es im GDC 2003 Papier von nVidia zum Thema Schatten volumen ab Seite 59 beschrieben wird und beim 3dmark eingestzt wird. Das ist schon recht aufwendig.

Ich vermute jetzt mal das du das Verfahren das ab Seite 61 beschrieben wird (Vertex Normal-based Extrusion) meinst.

Oder am ende etwas ganz anderes?

[micki]

hab's mir ma angesehen, also ich glaube nicht dass einer von den algorithmen auf meinen zutrifft, da die entweder vertexnormal-based arbeiten oder einiges auf der cpu abarbeiten wollen.

ich hab nen vertex bestehen aus
float3 pos
Color Nor1,extrudeflag
Color Nor2
-----------
5*4Byte=20



cpu vorarbeit:
ich generieren für jede kante 4 vertices, für die zwei am objekt ist extrude flag 0.f für die extrudierten sind die 1.f.
in nor1 und nor2 speicher ich (in byte quantitisiert) dann die zwei normalen ab, die zu den zwei triangles gehören, die die kante bilden.

im shader muss ich dann
dp3 r1,nor1,lightdirection
dp3 r2,nor2,lightdirection
mul r3,r1,r2

dann kann man ja prüfen ob r3 positiv ist oder negativ und abhängig davon dann in r4 1 oder 0 setzen lassen. dass dann mul extrudeflag und das mul den vector zum extruden und das auf die vertexposition addieren.


also so hab ich das bisher in keinem paper gehsen *kopfkratz*, aber es läuft.

MfG
micki

[Demirug]

Das ist eigentlich mehr oder minder das Verfahren das ab Seite 59 beschrieben wird.

Wenn es für deine Zwecke schnell genug ist sollte es immer korrekte Schatten produzieren.

[micki]

hmm soweit ich gesehen habe benutzen die das orginal mesh und haben dadurch nur die normalen zur hand.

und ja,
meines läuft performanter als es mit der hilfe der cpu ginge und die schatten sind auch korreckt.

aber wie ich schonma gesagt hatte, ich benutze lieber meine shadowmaps, dann kann ich für alles schatten generieren ohne mir gedanken über die geometrie zu machen... wie all die shadowvolume leute

und mit pixelshadern kann man die schadowmaps sogar gut soften, falls man das will.

MfG
micki

[zeckensack]

Original geschrieben von micki
hmm soweit ich gesehen habe benutzen die das orginal mesh und haben dadurch nur die normalen zur hand.

und ja,
meines läuft performanter als es mit der hilfe der cpu ginge und die schatten sind auch korreckt.Wie hoch ist der Polycount pro Modell? Welche Graka?
aber wie ich schonma gesagt hatte, ich benutze lieber meine shadowmaps, dann kann ich für alles schatten generieren ohne mir gedanken über die geometrie zu machen... wie all die shadowvolume leute

und mit pixelshadern kann man die schadowmaps sogar gut soften, falls man das will.

MfG
micki Shadow mapping hat aber auch Probleme, das ist dir doch bewußt? :)

(Verzerrungen, toter Punkt, Z-Fighting)

[micki]

wie hoch der polycount ist kann ich nun nicht mehr sagen, hab ich net gemessen, aber...

... ich berechne ja jede kante nur einmal (nicht wie in den papern beschrieben 3kanten pro tirangle, falls ich die skizzen und kürzel richtig verstand). somit ist mein volume so perfekt wie man es auch mit der cpu bekämme...

... ich rechne mit nem effektivem vertexformat für die volumes (die haben ja wegen dem stark ansteigendem vertexcount gemeckter, das versuch ich dadurch wenigstens in bezug auf die datenmenge zu reduzieren)...


wieso sollte es mir net bewust sein :), dass shadowmaps probleme haben? alles hat probleme, aber die vorteile find ich viel gewichtiger.

man kann die maps mit ~25fps generieren auch wenn die fps bei 75 liegt, weil man das während der ganzen bewegung nicht so stark merkt. Gegen zfighting nutzt man dann D24 maps und/oder front und backfacke maps, deren mittel verläuft durch die objekte, damit hat man dann den zverlauf innerhalb eines objektes und ziemlich saubere kannten (hatte jemand bei ogl.org im forum gepostet) und soweit ich sah, hat man bei beim spotlight keine großen verzerrungen und für ommilights nimmt man (je nachdem ob die lichtquelle im frustum ist oder nicht) dual parabolid maps bzw. mono parabolid maps.

was aber tolles hinzu kommt ist, dass man mit den pixelshadern bis zu 32 reads aus der map machen kann, mit einem selbst gemachten grid und das kann man dann auch noch, je nach entfernung zwischen lichtquelle und schattenwerfendem objekt und empfänger, skalen und somit soft oder hard shadows bekommen.
dazu kommt noch, dass man objekte beliebig animieren und verformen kann mit dem vertexshader und die schatten sehen richtig aus, man kann alpahtest maps nutzen (im normalen rendering) und falls man noch ein wenig rumtrickst, dann kann man von transparenten objekten die schatten werfen (kirchenscheiben) und eventuell nen volumelight effekt machen.

was eventuell noch hinzu kommt ist, dass man für alle lichtquellen in einem pass das "richtige" rendering machen könnte (falls die shader so lange sein könnten und soviele reads möglich wären), dammit würde man
1. performance gewinnen, weil nicht additiv auf den framebuffer gepinselt werden muss (was wohl mit einer der grossen performance fresser ist), man muss die normalen texturen nur einmal lesen bzw. die materialien (wood :D) nur einmal generieren.
2. ist das die einzige möglichkeit die ich sehe um transparente objekte richtig mit einzurechnen, weil das blending mit 5 passes ganz anders ausschaut als mit einem pass. (ist mathematisch ja nachvollzierbar)


das einzig wahre bleibt raytracen, aber solange das nicht perfomant geht, bevorzuge ich die shadowmaps :D

MfG
micki

[zeckensack]

Original geschrieben von micki
... ich berechne ja jede kante nur einmal (nicht wie in den papern beschrieben 3kanten pro tirangle, falls ich die skizzen und kürzel richtig verstand). somit ist mein volume so perfekt wie man es auch mit der cpu bekämme...???
Wie deckt sich das damit:
Original geschrieben von micki
cpu vorarbeit:
ich generieren für jede kante 4 vertices, für die zwei am objekt ist extrude flag 0.f für die extrudierten sind die 1.f.
Ich hatte das so verstanden, daß du statische Degenerates in die Modelle einfügst, und diese dann im VS aufbläst, wenn sie auf einer Silhouette liegen.

So weit richtig???

[micki]

ich weiß nicht genau wo du da den wiederspruch siehst.

aber ich versuch das mal anders zu sagen...


... ich generiere _einmal_ eine _extra_ geometrie (mit der cpu), die nur aus den kanten besteht, würd ich das nicht extruden, würde man quasi ein wireframe haben (das man aber wohl nicht sehen würde, weil die breite der "linien" 0 ist ohne extruden.

dann extrude ich die kanten, deren zwei normalen nach dem dotproduct mit dem lichtquellen vector unterschiedlich sind.

das generieren des meshes mach ich einmal, und dann extrudiere ich das jedesmal im vertexshader, je nach lichtquellenvector.


MfG
micki

ps. müßte eigentilch die ganze zeit in der vergangenheitsform tippen, da ich ja volumeshadows nicht mehr nutze, weil ... shadowsmaps...blablabla :D

[micki]

emm.. falls du dich wegen front&backfacing wurderst.. das tue ich auch gerade..

hab aber den source gerade nicht hier, müßte nachsehen wie das war, weil ich mich net direkt dran erinner. *tsorreee*

MfG
micki

[zeckensack]

Es ging mir darum herauszufinden, wieviele zusätzliche Vertices du einfügst. Und so weit ich das jetzt verstanden habe, hatte ich es auch schon verstanden ?-)

Ich schrieb oben "... daß du statische Degenerates in die Modelle einfügst, und diese dann im VS aufbläst". Damit meinte ich natürlich die 2 extra Dreiecke pro 'echter' Kante.

Btw, du machst das also so, daß du die Vertices nicht ins Modell einfügst, sondern ein zusätzliches "Gitter-Modell" seperat anlegst? Wenn du dich am "einfügen" gestört hat, okay, ist jetzt klar :)

Ich komme aber schon wieder zu dem Schluß, daß dein Code prinzipiell den gleichen Workload erzeugt wie 3DM03, evtl mit weniger Vertex-Bandbreite. Und das wundert mich eben, weil du ja sagst daß dein Verfahren angenehm schnell ist. Was ich dir auch glaube, ich versuch's halt nur zu verstehen ;)

Liegt die besch***ene Performance von 3DM03 jetzt wirklich nur an den zu komplexen VS/PS???

[zeckensack]

Original geschrieben von micki
emm.. falls du dich wegen front&backfacing wurderst.. das tue ich auch gerade..

hab aber den source gerade nicht hier, müßte nachsehen wie das war, weil ich mich net direkt dran erinner. *tsorreee*

MfG
micki Wenn du seperat eine Modellinstanz "für's Rendern" und eine "für die Extrusion" hast, dann kannst du die Frontfaces und die Caps (falls gebraucht) IMO aus dem Rendermodell erzeugen. Vielleicht hattest du das ja so gemacht? ;)