Performance PhysX

[HPVD]

Hallo

was sagt Ihr zu der These von VR-zone:

kann man vermuten, dass die Ursache für die schlechte Game-Performance mit PhysX-Karte nicht an der Karte selbst liegt sondern dass sie z.B. bei Explosionen so viele neue sich sehr schnell bewegende Teile produziert, dass heutige Grafikkarten (und CPUs?) schlicht mit der Berechnung vom Aussehen dieser Teile überfordert sind?

vgl: http://vr-zone.com/?i=3632&s=1


Konnte im Forum leider bisher keine Meinung dazu finden... falls bereits vorhanden bitte einfach kurz linken.


Gruß HPVD

[TheGamer]

Gibt sicher welche die es besser wissen, aber ich sag das diese These fuer mich absolut logisch klingt

[Juice]

Nunja, ich denke mal vor allem die Grafikkarte limitiert bei heutigen Spielen am stärksten, weshalb ich auch nicht verstehen kann, wieso um die PhysX - Karte so ein großer Aufriss gemacht wird, insofern diese der Grafikkarte nicht beim Rendering hilft, wird da keine großes Performenceplus zu erwarten sein...

[ESAD]

weil bisjetzt dei cpu nicht in der lage war große mengen an physikalsichen berechnungen in angemessener zeit durchzuführen, durch die physikkarte wird dieses problem gelöst, bzw. sollte gelöst werden,
das die grafikkarte limitiert glaube ich persönlich zumindest bei den momentanen highendboliden nicht

[KraetziChriZ]

Also ich fände es Klasse, wenn ich die 3D-Leistung meines P4-2.6Ghz-7800GS-Gespann mit so einer Karte z.B. in Crysis, sagen wir um 50% steigern könnte - natürlich zu einem angemessenen (100€?) Preis.
Aber so... nein danke

gruß
chris

[tombman]

die GH Preise sind schon bei 220€... wenn die in Massen auf dem Markt sind, wirds schnell 200€ werden -> geht noch mit Preis ;)

[Mark]

also wenn diese these stimmen sollte (klingt ja plausibel), dann bräuchte man ja immer eine extrem gute grafikkarte, vielleicht sogar sli. und für sli bzw die sli treiberlast wäre ja auch dualcore angebracht

[SKYNET]

tombman[/POST]']die GH Preise sind schon bei 220€... wenn die in Massen auf dem Markt sind, wirds schnell 200€ werden -> geht noch mit Preis ;)

wenn man bedenkt, das die 7300GT das gleiche kann... aber weniger als die hälfte kostet! X-D

[Neomi]

SKYNET[/POST]']wenn man bedenkt, das die 7300GT das gleiche kann... aber weniger als die hälfte kostet! X-D

Erstens wird es nur Effektphysik sein, keine Spielphysik, also kann von gleichen Fähigkeiten keine Rede sein. Zweitens ist HavokFX noch nicht verfügbar.

[HPVD]

was mich wundert ist, dass diese, wie ich ja auch finde sehr logische These, nicht schon eher die Runde gemacht hat - vor allem auf dieser Seite-
und dass aegia nicht gleich nach dem Aufkommen der ersten schlechten Benchmarks auf einen solchen Zusammenhang hingewiesen hat... Wäre doch schließlich ein klasse Marketing für sie: "wir bringen so aufwendige und realistische Effekte ins Spiel, dass die aktuelle Grafikhardware (wieder) das große Nadelöhr ist..."
und schon wäre der schwarze Peter wo anders und alle würden sie aufgrund Ihrer "Physik-Performance" loben...

-vielleicht ist es also doch etwas anders...

Gruß HPVD

[Wishnu]

KraetziChriZ[/POST]']Also ich fände es Klasse, wenn ich die 3D-Leistung meines P4-2.6Ghz-7800GS-Gespann mit so einer Karte z.B. in Crysis, sagen wir um 50% steigern könnte - natürlich zu einem angemessenen (100€?) Preis.
Aber so... nein danke

gruß
chris

Mehr also der prozentuale Anteil, der der Physik zukommt, wird da sowieso nicht drin sein. Die fiktiven 50% würden ja bedeuten, dass von vorneherein 50% der Rechenleistung für die Physik eingeplant werden. Das wird bei Spielen wie Crysis nie geschehen (da soll ja auch die Geometie, KI und sonstiges überzeugen), wohl eher bei irgendwelchen Geschicklichkeitsspielchen der Turmbau-von-Babel-Art. ;)

[Juice]

ESAD[/POST]']weil bisjetzt dei cpu nicht in der lage war große mengen an physikalsichen berechnungen in angemessener zeit durchzuführen, durch die physikkarte wird dieses problem gelöst, bzw. sollte gelöst werden,
das die grafikkarte limitiert glaube ich persönlich zumindest bei den momentanen highendboliden nicht
Die Grafikkarte bringt aber immernoch die Bilder auf den Monitor, da kann eine PhysX machen was sie will, würde die Grafikhardware nicht irgendwie limitieren, dann bräuchten wir auch nicht alle 6 Monate eine neue Chipgeneration...

[tombman]

Die Graka ist nicht das Problem bei Cellfaktors großen Explosionen :rolleyes:

[Monger]

Wir hatten das ja hier schon mehrfach...

Die Grafikkarte ist es ganz bestimmt nicht, die CPU aber anscheinend auch nicht. Bisher hab ich überhaupt noch keine glaubhafte These für die schlechte Performance gesehen.

[deekey777]

SKYNET[/POST]']wenn man bedenkt, das die 7300GT das gleiche kann... aber weniger als die hälfte kostet! X-D

Und wie kommt es zu diesen weisen Worten? GFlop/s-Spielereien? Auch wenn Neomi schon gepostet hat, dass es sich bei Havok FX und Effekte-Physik geht, übersehe ich dies.

Wie soll die 7300GT das gleiche wie die PhysX-Karte können, wenn ihre Leistung in Vergleich zur PPU unterirdisch ist?
Nichteinmal eine X1900XTX erreicht die Leistung der PhysX-Karte, und diese Aussage kommt von ATi selbst.

[Coda]

Alles andere wäre auch ein Armutszeugnis für Ageia

[Blaze]

deekey777[/POST]']
Wie soll die 7300GT das gleiche wie die PhysX-Karte können, wenn ihre Leistung in Vergleich zur PPU unterirdisch ist?

Indem HavokFX effizienter arbeitet als PhysX?

[deekey777]

Blaze[/POST]']Indem HavokFX effizienter arbeitet als PhysX?
Nur hat Havok FX nichts, gar nichts mit Ageias PhysX zu tun. Oder ist die PhysX-Karte eine Grafikkarte, die SM 3.0 beherrscht?

[Gaestle]

Was mich sehr interessieren würde, wäre die Leistung bzw. die optische Verbesserung bei Flüssigkeiten durch PhysX. Hat da jemand Info's?
Ansonsten sind für mich persönlich Partikel erstmal zweitens.

Des weiteren würde ich alles begrüßen, was die CPU derart entlastet, dass mehr Lebendigkeit auf dem Bildschirm entstehen kann, d.h. mehr als drei (in Worten drei) NPC's pro Level, mit denen man quatschen kann und der Rest nur taube, stumme Masse.

Das ist für mich eigentlich das größte Manko, was Computerspiele derzeit haben - soziale Sterilität.

Grüße

[Coda]

Ich glaube da liegt das Problem eher im Programmieraufwand begründet.

[Nightspider]

Bei w-computer gibt es für 239,90 Die Asus PPU mit Ghost Recon:AW

Was haltet ihr davon und wieso kauft sich keiner von den reichen Leuten hier so eine Kombi ? :D

[robbitop]

Das Problem von der PPU liegt meines Erachtens an 2 Dingen:

-Latenz
(bis eine DGL von der CPU über den RAM über den PCI Bus zur PPU gelangt, vergehen
einige hundert CPU Takte. Die jeweils fertig berechnete Position des zu berechnenden Objektes geht den gleichen langen weg zurück. Erst jetzt kann die CPU entsprechende Geometrie an die GPU schicken.)

-Blockieren der CPU
durch das Ausführen der Masse an physikalischen Abläufen, die zur PPU laufen sollen, wird gewiss auch Rechenzeit abverlangt. Dies könnte man gewiss regeln, in dem man den Treiber auf Multi Core auslegt.

Vorteil Ageia vs GPUs/Havok:
-deutlich mehr Rechenleistung
-ein geeigneteres Design zur Physikberechnung
-muss nicht noch nebenher Grafik rendert
-kann mehr als nur Effektphysik, sondern auch spielrelevante Physik

Nachteil ggü. HavokFX/GPUs:
-Verbreitung und daraus resultierendes Henne/Ei Problem ... die jetzige Umsetzung steckt anscheinend noch in den Kinderschuhen
-der natürlich notwendige Umweg über die CPU, da die Physik ja das Spiel beeinflußt

IMO besitzt Ageia die bessere Lösung, jedoch hat man es sehr schwer. Ich vermute, dass das Spiel ganz schnell über die größere Marktmacht entschieden wird und sich mal wieder die schlechtere Lösung durchsetzt.

[Hübie]

Ich schätze das da auch die Kooperation seitens Ageia, nVidia und ATi noch etwas hinkt. Immerhin ist die Grafikkarte das Ende der Fahnenstange.
Somit muss sich die PPU mit der GPU/VPU mehr koordinieren, als mit der CPU (ich denke da speziell an Kollisionsabfragen).

Ich schätze das der Stein jetzt erst ins Rollen kommt und wir nur noch ein wenig Geduld haben müssen.

Oder habe ich einen Denkfehler gemacht?

bye Hübie :smile:

[Coda]

Die GPU hat doch mit der Kollisionsabfrage nix am Hut.

[das_Apo]

Sollten nicht irgendwann auch PhysX Karten für PCI Express kommen?
Würde das evtl. dem von robbitop angesprochenen Problem der Latenz ein wenig Abhilfe schaffen?

[Gast]

robbitop[/POST]']Das Problem von der PPU liegt meines Erachtens an 2 Dingen:

-Latenz
(bis eine DGL von der CPU über den RAM über den PCI Bus zur PPU gelangt, vergehen
einige hundert CPU Takte. Die jeweils fertig berechnete Position des zu berechnenden Objektes geht den gleichen langen weg zurück. Erst jetzt kann die CPU entsprechende Geometrie an die GPU schicken.)




Die Positionsberechnung ist nach wie vor Aufgabe des Vertexshaders der GPU und hat nichts mit der PPU zu tun.

[Coda]

Nö, die Vertexshader machen die entsprechenden Transformationen abhängig von den Positonsdaten die sie von der PPU bzw. CPU bekommen.

das_Apo[/POST]']Würde das evtl. dem von robbitop angesprochenen Problem der Latenz ein wenig Abhilfe schaffen?
Die Physik sollte sowieso mit einem Frame lag berechnet werden, dann ist das kein Problem.

Und nein PCIe ist da sogar schlimmer als PCI.

[robbitop]

das_Apo[/POST]']Sollten nicht irgendwann auch PhysX Karten für PCI Express kommen?
Würde das evtl. dem von robbitop angesprochenen Problem der Latenz ein wenig Abhilfe schaffen?
Sie verschlimmert es eher. Leider eine Schwachstelle im PCIe.


Die Positionsberechnung ist nach wie vor Aufgabe des Vertexshaders der GPU und hat nichts mit der PPU zu tun.

Wie stellst du dir das vor? Die Vertices erscheinen also aus dem Nichts? Die muss die CPU schon selbst berechnen. ;)
Und wo kommen die neuen Positionen der Vertices her, wenn spielbestimmende Physik zum Einsatz kommt? Richtig, aus den Ergebnissen der DGLs die die PPU freundlicherweise berechnet hat.
Sonst bräuchte man das Teil ja nicht. :)
Der Vertexshader ist für die Transformation der Vertices zuständig. Denn irgendwie muss ja die 3D Welt in 2D gerastert werden.

[robbitop]

Coda[/POST]']
Die Physik sollte sowieso mit einem Frame lag berechnet werden, dann ist das kein Problem.

Das ist die Frage. Wieviele Takte dauert es, ein Frame zu errechnen? Ist die Latenz trotz der großen Übertragungswege noch immer unbedeutend? Ich bin mir der Größenordnung leider nicht bewußt. Wie sehen die Verhältnisse denn ungefähr aus?

[Coda]

Das reicht ewig. 16ms bei 60FPS. Das sind 33 Mio. Takte bei 2Ghz X-D

Die PPU spuckt nicht die Position einzelner Eckpunkte aus, sondern die Position und Orientierung ganzer Objekte.

[HPVD]

wenn ich das recht verstehe sind wir
damit dann doch wieder auf die Leistung der Graffikkarte angewiesen...

[Coda]

Nö, die Vertexshader sind 1. eigentlich nie das Flaschenhals und 2. Ist die Transformation eine Matrix-Vektor-Multiplikation die eigentlich immer gemacht werden muss.

[robbitop]

Coda[/POST]']Das reicht ewig. 16ms bei 60FPS. Das sind 33 Mio. Takte bei 2Ghz X-D

Die PPU spuckt nicht die Position einzelner Eckpunkte aus, sondern die Position und Orientierung ganzer Objekte.

Hilf' mir mal bitte.
Zum Rechnen nehmen wir lieber 30ms. Taschenrechner suckz.
~30 ns braucht es, einen 32 Bit Wert über den PCI Bus zu transportieren.
Das ist immerhin Faktor 1000. Allerdings müssen ja mehrere Werte pro Objekt übertragen werden. Pro Größe brauchen wir 3 Werte (x,y,z). Keine Ahnung wieviele Größen pro Objekt übertragen werden müssen. Sagen wir mal die Anfangsgeschwindigkeit (aus dem Impuls), die Lage, die Masse (nur 1 Wert).
Das sind 7 Werte. Nehmen wir einfach mal 10. Sind wir pro Objekt schon bei 300 ns reine Übertragungszeit zur PPU. Es braucht nur 3-4 Objekte bis wir im ms Bereich sind. Zusätzlich kommt noch die Berechnungszeit der PPU (kann man vernachlässigen, das sind nur ein paar ns) und der Rückweg (ist ja nur die Lage mit 3 Werten).
Also bereits ~25-50 Objekte könnte es deutlich bremsen.
Oder habe ich irgendwo einen Denkfehler?

edit: brainfart!
habe mich um 10^3 geirrt. (zw ms und ns sind ja noch µs) Also dürften es bei reiner Massenphysik maximal ein paar tausend umherfliegende Objekte sein, um nicht zu bremsen. Das reicht locker. Ist nur die Frage, wieviel die Qualitätsphysik frisst (Stoffe, Fluide).
Somit ist das Latenzproblem ja erstma vom Tisch. Danke. :)

[Demirug]

Was rechnet den ihr da zusammen?

Gehen wir mal davon aus das wir 20 MB des PCI Transfers für die PPU Daten abzweigen können.

20 MB = 20*1024*1024 = 20971520 Byte

Ein Vektor mit 3 32 Bit Fließkomma Werten braucht 12 Bytes

20971520 Byte / 12 Byte ~ 1747626 Vektoren

Wir wollen nun 60 FPS erreichen:

1747626 Vektoren / 60 FPS ~ 29127 Vektoren pro Frame

Teilen wir das nun noch gleichmässig auf Up und Download auf kommen wir auf etwa 15000 übertragbare Positionsänderungen pro Frame.

[Hübie]

Coda[/POST]']Die GPU hat doch mit der Kollisionsabfrage nix am Hut.

Nein das nicht, aber mit der Darstellung derer. Die muss ja mitgeteilt bekommen ob das Objekt durch die Wand geht oder net (z.B. ein Flummy der durch einen Raum springt).

bye Hübie

[Neomi]

Demirug[/POST]']Gehen wir mal davon aus das wir 20 MB des PCI Transfers für die PPU Daten abzweigen können.

...

Teilen wir das nun noch gleichmässig auf Up und Download auf kommen wir auf etwa 15000 übertragbare Positionsänderungen pro Frame.

Die Position alleine reicht ja nicht, wenn man nicht gerade Pointsprites rendern will. Deshalb würde ich ein wenig anders rechnen.

Wenn das Spiel ein Objekt in eine bestimmte Pose bewegen will, braucht er eine Position und drei Eulerwinkel (spart immerhin einen Wert im Vergleich zum Quaternion, der aber praktischer ist), also 6 Werte à 4 Bytes. Eine fertig berechnete Pose auf dem Rückweg zur CPU braucht die gleichen Daten. Will das Spiel eine Kraft auf ein Objekt ausüben, benötigt es die Kraft als Vektor und eine Position als Ansatzpunkt, also wieder 6 Werte.

Da auch bekannt sein sollte, welches Objekt gerade verändert wird, gehört noch eine ID (4 Byte) dazu. Da Quaternions eh praktischer sind (keine Winkelfunktionen bei der Wandlung in eine Matrix) als Eulerwinkel, nehmen wir mal die, schon kommen wir auf genau 32 Byte pro verändertem Objekt (bzw. 28 für die ausgeübte Kraft, aber da lohnen sich schon fast alignmentfreundliche 4 Füllbytes). Geschwindigkeiten usw. kann die CPU aus der Differenz ganz leicht selbst errechnen, dafür muß man nicht den Bus belasten. Andere Objekteigenschaften (Inertia usw.) werden wohl hauptsächlich bei der Initialisierung gesetzt und eher selten zur Laufzeit geändert, also kann man die aus der Rechnung ganz rauslassen.

20 MiB/s bei 60 Hz sind 349525 Bytes/s, bei 32 Bytes pro Aktion reicht das für 10922 Aktionen für beide Richtungen zusammen. Da eingefrorene Objekte nicht laufend aktualisiert werden müssen (ihre IDs kommen im Ergebnisstream einfach nicht vor), sollte das locker reichen, auch für noch so große Explosionen.

[predprey]

Hmm, wenn man sich Tombmans letztes Video anschaut von CellFactor

http://www.forum-3dcenter.org/vbulletin/showthread.php?p=4318411#post4318411


kann man rechts oben die Werte anschauen.
Die Objekts steigen bei der Explosion von ca. 1295 auf ca. 2820 und die Batchms von 5 auf kurzeitig direkt nach der Explosion auf 1358. Kurz vor der Explosion gehen noch andere MS werte nach oben.

Was sind das für Werte und könnte das vll. aufschluss geben ?

http://img112.imageshack.us/img112/7590/cellfactorimage11kn.jpg

[Neomi]

Hübie[/POST]']Nein das nicht, aber mit der Darstellung derer. Die muss ja mitgeteilt bekommen ob das Objekt durch die Wand geht oder net (z.B. ein Flummy der durch einen Raum springt).

Warum sollte die GPU interessieren, ob nun ein Objekt in einer Wand steckt oder nicht? Das Objekt wird einfach gezeichnet und der ZBuffer sorgt dafür, daß die verdeckten Pixel verworfen werden. Der GPU ist die Kollision völlig egal.

[Monger]

Neomi[/POST]']
...
Da auch bekannt sein sollte, welches Objekt gerade verändert wird, gehört noch eine ID (4 Byte) dazu. Da Quaternions eh praktischer sind (keine Winkelfunktionen bei der Wandlung in eine Matrix) als Eulerwinkel, nehmen wir mal die, schon kommen wir auf genau 32 Byte pro verändertem Objekt (bzw. 28 für die ausgeübte Kraft, aber da lohnen sich schon fast alignmentfreundliche 4 Füllbytes). Geschwindigkeiten usw. kann die CPU aus der Differenz ganz leicht selbst errechnen, dafür muß man nicht den Bus belasten.

Weder Grafikkarte noch CPU müssen doch wissen, weshalb sich ein Objekt bewegt. Zumindest will ich das schwer hoffen... Koordinaten plus Vektor (für die Orientierung) sollten völlig reichen.

Klar: wenn die PPU sich die Rechenarbeit mit der CPU teilt, ist der Bus schnell zugemüllt. Aber so doof werden sie doch hoffentlich nicht gewesen sein!?!


Nö, also dass es irgendwas mit Latenzen zu tun haben soll, kann ich mir beim besten Willen nicht vorstellen.

[Neomi]

Monger[/POST]']Weder Grafikkarte noch CPU müssen doch wissen, weshalb sich ein Objekt bewegt. Zumindest will ich das schwer hoffen... Koordinaten plus Vektor (für die Orientierung) sollten völlig reichen.

Für bestimmte Objekte kann ein Spiel durchaus am Grund interessiert sein. Was spricht denn deiner Meinung nach dagegen? Als Beispiel für Zusatzdaten habe ich die Geschwindigkeit genannt, die hat nichts mit dem "Grund" der Bewegung zu tun und kann für bestimmte Effekte (bei Geschwindigkeiten wohl hauptsächlich Motion Blur, gibt aber noch andere Anwendungsmöglichkeiten) durchaus interessant sein.

[Monger]

Neomi[/POST]']Für bestimmte Objekte kann ein Spiel durchaus am Grund interessiert sein. Was spricht denn deiner Meinung nach dagegen? Als Beispiel für Zusatzdaten habe ich die Geschwindigkeit genannt, die hat nichts mit dem "Grund" der Bewegung zu tun und kann für bestimmte Effekte (bei Geschwindigkeiten wohl hauptsächlich Motion Blur, gibt aber noch andere Anwendungsmöglichkeiten) durchaus interessant sein.

OK, Motion Blur ist was anderes. Aber wenn schon die PPU Physikberechnungen macht, sollte sie gefälligst ALLES daran machen, und nicht zur weiteren Interpretation der CPU überlassen.

[Neomi]

Monger[/POST]']OK, Motion Blur ist was anderes. Aber wenn schon die PPU Physikberechnungen macht, sollte sie gefälligst ALLES daran machen, und nicht zur weiteren Interpretation der CPU überlassen.

Bei der Geschwindigkeit ist das so eine Sache. Die wird natürlich von der PPU berechnet, ist ja auch zur Bewegung der Objekte nötig. Eine Übertragung ist natürlich auch möglich, aber IMHO sinnlos. Muß man es etwa aus Prinzip machen, weil es geht? Oder sollte man nicht lieber das machen, was am effektivsten ist? Die Geschwindigkeit ist aus der Positionsänderung so simpel zu berechnen, daß eine Übertragung von der PPU aus nicht nur den Bus stärker belasten würde, sondern auch noch langsamer wäre.

[777@Asyl]

Coda[/POST]']


Die Physik sollte sowieso mit einem Frame lag berechnet werden, dann ist das kein Problem.

.

In der vorletzten c't ist eine ähnliche Aussage zu finden. Das ist auch der Grund, warum Doom 3 auf 60 Bilder/s beschränkt ist (wenn mich mein Gedächtnis nicht täscht), damit gewährleistet wird, dass die Physik rechtzeitig berechntet wird.

[Neomi]

Doom 3 ist nicht auf 60 Bilder/s beschränkt, nur die Physik ist mit 60 Hz getickert.

[robbitop]

Demirug[/POST]']...Teilen wir das nun noch gleichmässig auf Up und Download auf kommen wir auf etwa 15000 übertragbare Positionsänderungen pro Frame....
Das sagt doch aber noch nicht viel über die Latenz aus. Dass die Bandbreite genügt, bezweifeln wir gar nicht. Oder stehe ich gerade auf dem Schlauch?

[Gast]

Coda[/POST]']Nö, die Vertexshader machen die entsprechenden Transformationen abhängig von den Positonsdaten die sie von der PPU bzw. CPU bekommen.


Das ergibt imo keinen Sinn. Wenn die PPU "die jeweils fertig berechnete Position" (Robbitop) zurueckgibt, was hat denn dann der VS noch zu tun? Bislang war ich der Meinung, dass in den VS untransformierte Vertices reingehen und transformierte Vertices rausgehen. Wenn jetzt aber die transformierte Position bereits bekannt ist....... ich hoffe du verstehst mein Problem.

[robbitop]

Gast[/POST]']Das ergibt imo keinen Sinn. Wenn die PPU "die jeweils fertig berechnete Position" (Robbitop) zurueckgibt, was hat denn dann der VS noch zu tun? Bislang war ich der Meinung, dass in den VS untransformierte Vertices reingehen und transformierte Vertices rausgehen. Wenn jetzt aber die transformierte Position bereits bekannt ist....... ich hoffe du verstehst mein Problem.
Die Transformation der Vertices war ja ursprünglich Aufgabe der CPU, dann hat man eine TnL Einheit dafür genutzt und inzwischen machen es die VS. Die eigentliche Aufgabe des VS sind andere Dinge (z.B. Beleuchtung, die dreiecks-genau Berechnet wird).

Die Positionen sind in 3D bekannt, aber nicht in 2D. Dazu müsen die Vertices ja transformiert werden.

[aths]

Neomi[/POST]']Doom 3 ist nicht auf 60 Bilder/s beschränkt, nur die Physik ist mit 60 Hz getickert.Genau. Ich weiß auch nicht, warum das so oft missverstanden wird.

[Neomi]

Gast[/POST]']Das ergibt imo keinen Sinn. Wenn die PPU "die jeweils fertig berechnete Position" (Robbitop) zurueckgibt, was hat denn dann der VS noch zu tun? Bislang war ich der Meinung, dass in den VS untransformierte Vertices reingehen und transformierte Vertices rausgehen. Wenn jetzt aber die transformierte Position bereits bekannt ist....... ich hoffe du verstehst mein Problem.

Aus der fertig berechneten Position und Rotation eines Objektes wird die Transformationsmatrix gebaut, und die gilt dann für alle Vertices des Objektes. Die Position des Objektes muß also schon vorher bekannt sein, damit die Geometrie des Objektes im Vertexshader entsprechend transformiert werden kann.

Das Kollisionsobjekt ist in der Regel auch nur eine sehr grobe Approximation der Geometrie, die hinterher gerendert wird. Beides ist unabhängig voneinander.

[aths]

robbitop[/POST]']Die Transformation der Vertices war ja ursprünglich Aufgabe der CPU, dann hat man eine TnL Einheit dafür genutzt und inzwischen machen es die VS. Die eigentliche Aufgabe des VS sind andere Dinge (z.B. Beleuchtung, die dreiecks-genau Berechnet wird).... oder die Vorarbeit für pixelgenaue Beleuchtung zu leisten.

[robbitop]

aths[/POST]']... oder die Vorarbeit für pixelgenaue Beleuchtung zu leisten.
Wie beim Dot-product Bump Mapping (das ja streng genommen nicht pixelgenau ist in der Praxis)? Dort wird auch nur eine pertubed Normale pro Polygon berechnet und für alle Pixel entsprechend interpoliert.

[Neomi]

robbitop[/POST]']Wie beim Dot-product Bump Mapping (das ja streng genommen nicht pixelgenau ist in der Praxis)? Dort wird auch nur eine pertubed Normale pro Polygon berechnet und für alle Pixel entsprechend interpoliert.

Die Normale, die im Vertexshader berechnet wird, ist bei Dot3 (also normales Normalmapping) nur eine Komponente des Tangentspace, der wird dann über das Dreieck interpoliert (Berechnungen pro Dreieck wird es erst mit D3D10 per Geometryshader geben). Die Normale wird schon pro Pixel aus einer Textur geholt, muß dann aber natürlich noch korrekt transformiert werden (per Tangentspace 3x3-Matrix).

[deekey777]

Neomi[/POST]']Doom 3 ist nicht auf 60 Bilder/s beschränkt, nur die Physik ist mit 60 Hz getickert.
aths[/POST]']Genau. Ich weiß auch nicht, warum das so oft missverstanden wird.

Schlechtes Erinnerungsvermögen meinerseits.:redface:
Aus der c't 2006/10, Seite 106:
"... Aus diesem Grund läuft beispielsweise die Physik-Engine von Doom 3 konstant mit 60 Zeitschritten pro Sekunde."

[Coda]

Gast[/POST]']Das ergibt imo keinen Sinn. Wenn die PPU "die jeweils fertig berechnete Position" (Robbitop) zurueckgibt, was hat denn dann der VS noch zu tun? Bislang war ich der Meinung, dass in den VS untransformierte Vertices reingehen und transformierte Vertices rausgehen. Wenn jetzt aber die transformierte Position bereits bekannt ist....... ich hoffe du verstehst mein Problem.
Sie sind untransformiert. Es wird ja jeweils die Position eines gesamten Meshes gesetzt.

Neomi[/POST]']Die Normale wird schon pro Pixel aus einer Textur geholt, muß dann aber natürlich noch korrekt transformiert werden (per Tangentspace 3x3-Matrix).
Bitte? Du transformiertst im Vertexshader schon die Lichtvektoren in den Tangent-Space, an den Pixeln wird nix mehr transformiert. Da bräuchte man dann wenn man sowas machen wöllte die Inverse der Tangentspace-Matrix, was ziemlich böse wäre pro Pixel.

Oder hab ich dich jetzt irgendwie falsch verstanden?

[Neomi]

Coda[/POST]']Bitte? Du transformiertst im Vertexshader schon die Lichtvektoren in den Tangent-Space, an den Pixeln wird nix mehr transformiert. Da bräuchte man dann wenn man sowas machen wöllte die Inverse der Tangentspace-Matrix, was ziemlich böse wäre pro Pixel.

Eine Transformation pro Pixel ist zwar nicht ganz billig, aber wenn man die Normale (korrekt transformiert) eh noch für andere Dinge braucht (Cubemaplookup für Reflektion hauptsächlich), muß man es sowieso tun. Oder kann man das etwa durch die Transformation des Eyevektors im Vertexshader irgendwie umgehen? Wenn man es nur für die Beleuchtung braucht, hast du auf jeden Fall Recht, da sollte man den Lichtvektor vortransformieren. Falsch verstanden hast du mich jedenfalls nicht, ich habe nur die Performanceoptimierung für pure Beleuchtung unterschlagen.

Die Inverse der Tangentspace-Matrix braucht man nicht, weil man ja nicht von Worldspace in den Tangentspace transformiert, sondern vom Tangentspace in den Worldspace.

[Quasar]

aths[/POST]']Genau. Ich weiß auch nicht, warum das so oft missverstanden wird.
Vielleicht weil Physik und Fps gekoppelt sind?

[Coda]

Neomi[/POST]']Die Inverse der Tangentspace-Matrix braucht man nicht, weil man ja nicht von Worldspace in den Tangentspace transformiert, sondern vom Tangentspace in den Worldspace.
Die Tangentspace-Matrix transformiert aber vom Worldspace in den Tangentspace :|

[Neomi]

Quasar[/POST]']Vielleicht weil Physik und Fps gekoppelt sind?

Nicht bei getickerter Physik. Da wird dann alle Objektposen (Position + Rotation) doppelt vorgehalten. Zwischen den einzelnen Zuständen wird dann für die Darstellung (und nur dafür) entsprechend interpoliert, wenn die Framerate nicht zufällig exakt mit der Physikrate übereinstimmt.

[Neomi]

Coda[/POST]']Die Tangentspace-Matrix transformiert aber vom Worldspace in den Tangentspace :|

Achso, um den Begriff ging es also. Ja, der ist nicht ganz korrekt, eigentlich ist es eine Worldspace-Matrix. Weil der Begriff aber schon belegt ist (durch die Localspace-to-Worldspace-Matrix), mir Tangentspace-to-Worldspace-Matrix zu lang war und die invertierte Variante (zum Tangentspace hin) weder im Vertexshader noch Pixelshader benötigt wird, habe ich es so abgekürzt. Gibt es denn eine passendere (nicht allzu lange) Bezeichnung dafür?

[Quasar]

Neomi[/POST]']Nicht bei getickerter Physik. Da wird dann alle Objektposen (Position + Rotation) doppelt vorgehalten. Zwischen den einzelnen Zuständen wird dann für die Darstellung (und nur dafür) entsprechend interpoliert, wenn die Framerate nicht zufällig exakt mit der Physikrate übereinstimmt.
Dann frage ich mal direkt: Wie bekomme ich in-Game oder in einer Demo (ohne "timedemo") dann mal mehr als 60 Fps?
Mein bisheriger Versuch auf einer X800 XL und A64 bei 2,2 GHz: Low Quality eingestellt, 640x480, VSync off und mit dem virtuellen Gesicht vor mehrere Wänder gestellt.

[Neomi]

Quasar[/POST]']Dann frage ich mal direkt: Wie bekomme ich in-Game oder in einer Demo (ohne "timedemo") dann mal mehr als 60 Fps?

Das ist nicht nur bei mehr als 60 fps interessant, sondern auch bei weniger. Bei zu großen Zeitscheiben kann die Physik sonst richtig unrund laufen und das "Bullet through Paper"-Problem verschärft sich. Gelöst wird das ganz einfach dadurch, daß die Physik einfach mehrmals aktualisiert wird zwischen zwei Bildern. Die Interpolation ist nach wie vor wichtig, sonst gibt es bei z.B. 40 fps bei jedem dritten Bild einen kleinen Ruck nach vorne.

[Quasar]

'Tschuldigung, ich wollte auf was anderes hinaus. Ich geh' mein OT mal melden.

edit:
Doom ist sehr wohl auf 60 Fps beschränkt - auf Grund der Physik vermute ich, Nur eben im Timedemo-Modus nicht.

[Gast]

Mit D3 geht's bitte dort weiter (hier ist's ja eh off-topic):
http://www.forum-3dcenter.de/vbulletin/showthread.php?t=297880

Wäre toll, wenn der eine oder andere hier im Thread aktive dort seine Position nochmals genauer erläutern kann, damit ich's verstehe.

Q

[Coda]

Neomi[/POST]']Achso, um den Begriff ging es also. Ja, der ist nicht ganz korrekt, eigentlich ist es eine Worldspace-Matrix. Weil der Begriff aber schon belegt ist (durch die Localspace-to-Worldspace-Matrix), mir Tangentspace-to-Worldspace-Matrix zu lang war und die invertierte Variante (zum Tangentspace hin) weder im Vertexshader noch Pixelshader benötigt wird, habe ich es so abgekürzt. Gibt es denn eine passendere (nicht allzu lange) Bezeichnung dafür?
Das was du an Meshes an den Vertices hast ist Binormal, Normal & Tangent und die bilden zusammen eine Transformation in den Tangentspace. Nicht davon raus.

Du hast nachher deine Lichtvektoren im Pixelshader im Tangentspace, nicht umgekehrt.

[Neomi]

Coda[/POST]']Das was du an Meshes an den Vertices hast ist Binormal, Normal & Tangent und die bilden zusammen eine Transformation in den Tangentspace. Nicht davon raus.

Wieso funktioniert es dann, wenn ich per Tangente, Normale und Bitangente (ja, wird überall Binormale genannt, aber Bitangente ist der passendere Begriff) nicht den Lichtvektor transformiere, sondern die gesampelte Normale?

float3 n = ...; // sampeln und je nach Texturformat umrechnen
n = n.x * input.tan + n.y * input.bitan + n.z * input.norm;

In der Form bilden die drei Vektoren eine Matrix, die vom Tangentspace aus in den Worldspace transformiert. Eine Normale im Worldspace ist auch nötig, wenn man für eine Reflektion noch einen Lookup in eine Cubemap machen will. Funktioniert prima. Wie willst du die Koordinaten für so einen Lookup denn ermitteln, wenn du nur eine Matrix zur Transformation in den Tangentspace hättest?

Coda[/POST]']Du hast nachher deine Lichtvektoren im Pixelshader im Tangentspace, nicht umgekehrt.

Das gilt logischerweise nur dann, wenn man den Lichtvektor in den Tangentspace transformiert, und das tut man dann natürlich im Vertexshader. Wenn man aber den Lichtvektor nicht im Tangentspace haben will, weil man eh die Normale im Worldspace braucht, sieht die Sache anders aus.

[Coda]

Neomi[/POST]']Wieso funktioniert es dann, wenn ich per Tangente, Normale und Bitangente (ja, wird überall Binormale genannt, aber Bitangente ist der passendere Begriff) nicht den Lichtvektor transformiere, sondern die gesampelte Normale?

float3 n = ...; // sampeln und je nach Texturformat umrechnen
n = n.x * input.tan + n.y * input.bitan + n.z * input.norm;
Das ist doch keine Transformation :|
Wahrscheinlich kommt zufällig was halbwegs richtiges raus.

Schau dir mal die ganzen Papers usw. über Bump-Mapping an. Die Transformieren alle die Lichtvektoren im Vertexshader in den Tangent-Space und interpolieren dann diese über das Dreieck. An den Pixeln hast du dann Normale aus der Textur und die Lichtvektoren im selben Raum.

Edit: Wobei, da ist was dran an der Rechnung. Hab ich aber ehrlich gesagt noch nie so gesehen.

Neomi[/POST]']In der Form bilden die drei Vektoren eine Matrix, die vom Tangentspace aus in den Worldspace transformiert.
Nein andersrum.

Was man machen kann ist die Transponierte an den Pixeln zu benützen - das entspricht aber nur dann der Inversen wenn die Tangentspace-Vektoren orthogonal sind, was nicht der Fall sein muss.

[Neomi]

Coda[/POST]']Das ist doch keine Transformation :|
Wahrscheinlich kommt zufällig was halbwegs richtiges raus.

Klar ist das eine Transformation, nur in einer anderen Schreibweise. Ich könnte auch eine 3x3-Matrix bauen mit Tangente, Bitangente und Normale in der Reihenfolge als Zeilen. Würde ich dann die gesampelte Normale mit der Matrix multiplizieren, wäre das Ergebnis identisch, nur eben mit mehr Codezeilen.

Coda[/POST]']Schau dir mal die ganzen Papers usw. über Bump-Mapping an. Die Transformieren alle die Lichtvektoren im Vertexshader in den Tangent-Space und interpolieren dann diese über das Dreieck. An den Pixeln hast du dann Normale aus der Textur und die Lichtvektoren im selben Raum.

So würde ich das auch machen, wenn ich keine transformierte Normale für einen Reflektionslookup brauchen würde. Die Papers sind ja keine "so und nicht anders"-Anweisung, sondern eine Empfehlung für den jeweiligen Fall. Ich bin richtig froh, daß die Shader frei programmierbar sind und man sich nicht daran halten muß.

Coda[/POST]']Was man machen kann ist die Transponierte an den Pixeln zu benützen - das entspricht aber nur dann der Inversen wenn die Tangentspace-Vektoren orthogonal sind, was nicht der Fall sein muss.

Ist mir bekannt. Deshalb interpoliere ich die gleichen Vektoren auch bei der Berechnung der Normalmaps, die exakt sein müssen (die, die man per Raycasting von Lowpoly zu Highpoly erhält), invertiere die resultierende Matrix korrekt (transponieren reicht da ja nicht, gibt nur häßliche Darstellungsfehler hinterher) und multipliziere die ermittelte Normale damit, bevor sie mit niedrigerer Präzision in die Normalmap wandert. Dadurch ist das Ergebnis hinterher so genau, wie es im Rahmen der Normalmappräzision (Format und Auflösung) nur sein kann.

Tilingfähige Normalmaps als Struktur kann ich auf diese Art nicht anpassen, da ist das Ergebnis dann wirklich nur eine Approximation. Solange aber die Geometrie keinen Unsinn macht (sehr große Krümmung im Dreieck -> starke Vektorverkürzung durch Interpolation), fällt das nicht auf. An Stellen, an denen das nicht ausreicht, langt sowieso keine Fakegeometrie, da muß echte Geometrie her. Von daher kann ich gut damit leben, daß es mathematisch anfechtbar ist, solange es nur gut aussieht.

[T.]

Coda[/POST]']Das was du an Meshes an den Vertices hast ist Binormal, Normal & Tangent und die bilden zusammen eine Transformation in den Tangentspace. Nicht davon raus.

Du hast nachher deine Lichtvektoren im Pixelshader im Tangentspace, nicht umgekehrt.
Hm, wenn ich zum Beispiel 2 Einheiten von der Oberfläche weggehen will, nehme ich dazu im Tangentspace den Vektor (0, 0, 2). Um das selbe im Worldspace zu tun, muss ich die 2 mit der Normalen multiplizieren.
[Entsprechendes gilt für die Tangente und Bitangente]
Also stellen diese 3 Vektoren doch eine Transformation in den Worldspace dar.
Oder irre ich mich?