PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : Welche Genauigkeit braucht eine 3d Spielwelt?


Gast
2009-05-09, 02:09:48
Wenn ich an alte UT99 Zeiten zurückdenke, so entsprach die kleinste Einheit die ein 3d Objekt haben konnte, also den Integerwert 1 hatte, genau einem Inch und ein Level konnte dabei genau maximal 65535 inch groß sein.


Gleitkommawerte konnte ein 3d Objekt dabei nicht haben, da alles in Intgrößen gemessen wurde.
So sah also der imaginäre 3d Raum aus.


Aber wie wurde das von der visuellen 3d Darstellung gelöst?
Wenn man z.b. zu einem Würfel mit der Seitenlänge 1 inch heranzoomte,
war dann im 3d Raum diese 1 nicht infinitiv?
D.h. der Würfel konnte unendlich vergrößert werden, solange man halt seine Clippingfläche nicht berührte.


Aber gibt das keine Bildstörungen in Form von Rundungsfehlern und Objektruklern?

Wenn man z.b. im Spiel ein Fernrohr benutzt (Sniperrifle),
dann wurde das Bild recht schnell unruhig, je weiter man heranzoomte.


Kurz gesagt, mich würde mal grob interessieren wie das bei 3d Spielen gelöst wird.
Vielleicht denke ich auch in die ganz falsche Richtung und jemand kann mir das näher erläutern.

Monger
2009-05-09, 11:42:57
Achtung, gefährliches Halbwissen: afaik hat sich an der geometrischen Auflösung seither nicht viel getan. Man konnte schon im UT Leveleditor das Grid deaktivieren, und die Geometrie millimetergenau platzieren - nur das ergab regelmäßig Clipping- und Beleuchtungsprobleme, und war auch aus Performancegründen nicht erstrebenswert.

Sehr kleine Objekte baust du in aller Regel nicht als 3D Objekt nach, sondern als Partikeleffekt. Größere komplexere Strukturen erstellst du in einem 3D Editor à la Maya oder 3dsMax, und generierst daraus einen "Mesh". Detailinformationen werden da in aller Regel als Normal Map errechnet, weil Texturen da eben weit unproblematischer sind.

Ich kann mich noch an eine Unreal Tech Demo erinnern, in der sie damit geprahlt haben dass in dieser Szene 2 Millionen Polygone verbaut sind. Afaik haben wir das in Spielen bis heute nicht erreicht, eher im Gegenteil: mit besseren Texturierungs- und Shadingtechniken gibt es nicht mehr so viel Bedarf für komplexe Geometrie.

rotalever
2009-05-10, 00:04:04
Ja diese Probleme gibt es aber doch durchaus bei sehr großen Landschaften?

Die Position der Objekte muss man ja irgendwie speichern, zum Beispiel mit der Genauigkeit von 1cm. Datentypen wie float/double erscheinen mir da eher ungeeignet, da sie "in der Ferne" nicht mehr die benötigte Genauigkeit haben. Also muss man das irgendwie mit Integern speichern. Nimmt man die Szene jetzt "einfach so" und gibt sie der Grafikkarte, wandelt man die Koordinaten ja wieder in Floatingpoints um. Da müsste es doch eigentlich Probleme geben, oder nicht?

Gast
2009-05-10, 00:17:48
Ja diese Probleme gibt es aber doch durchaus bei sehr großen Landschaften?

Die Position der Objekte muss man ja irgendwie speichern, zum Beispiel mit der Genauigkeit von 1cm. Datentypen wie float/double erscheinen mir da eher ungeeignet, da sie "in der Ferne" nicht mehr die benötigte Genauigkeit haben. Also muss man das irgendwie mit Integern speichern. Nimmt man die Szene jetzt "einfach so" und gibt sie der Grafikkarte, wandelt man die Koordinaten ja wieder in Floatingpoints um. Da müsste es doch eigentlich Probleme geben, oder nicht?

Ja, sehe ich auch so.

Außerdem, mit welcher Genauigkeit berechnen heutige GPUs denn die Geometrie?
Mehr als 32 Bit wird es wohl kaum sein. (Achtung, bitte nicht verwechseln mit der Genauigkeit bei der Farbtiefe, das ist eine andere Baustelle)

Und dann wäre da noch der Z-Buffer, der ist ja auch noch recht mickrig.
16 Bit wars glaube ich, oder?

Gast
2009-05-10, 00:18:45
Was ich damit sagen will, es gibt heute wohl noch keine 64 Bit GPUs, oder?

PatkIllA
2009-05-10, 08:54:19
Die können auch mit doppelter Genauigkeit rechnen. Wird dann aber langsamer. 32 Bit Gleitkomma ist das für aktuelle Grafikkarten gängiste Format.
Mit Maßeinheiten wie cm oder, hat das überhaupt gar nichts zu tun.

rotalever
2009-05-10, 11:57:27
Die können auch mit doppelter Genauigkeit rechnen. Wird dann aber langsamer. 32 Bit Gleitkomma ist das für aktuelle Grafikkarten gängiste Format.
Mit Maßeinheiten wie cm oder, hat das überhaupt gar nichts zu tun.
Schon klar, dass das nichts mit cm zu tun hat.. Aber wenn deine Genauigkeit in der Spielwelt 1cm (oder noch kleiner) entsprechen soll und man eine genügend große Landschaft hat, dann müsste es doch Probleme geben, diesen Maßstab auf die Gleitkommazahlen zu übertragen, oder nicht?

Neomi
2009-05-10, 14:09:44
32 Bit Gleitkomma reicht für eine ganze Menge aus. Wenn man die Einheit als m bestimmt, dann kommt man zwar nicht ganz exakt ran (0.01 = 1/128 + 1/512 + 1/8192 + 1/16384 + ...), aber wenn man die Einheit als cm definiert, dann kann man die auch exakt darstellen. Zumindest für ein Quadrat mit einer Seitenlänge von etwas über 335,5 km (je 16777216 cm in positiver und negativer Richtung). Sowas kann man machen, muß man aber nicht, einen besonderen Sinn sehe ich darin nicht.

Eine Beschränkung auf cm ist eher für eine andere Sache sinnvoll. Beispielsweise kann man das Szenario in Quadranten mit einer Seitenlänge von 500 m aufteilen, dann reicht ein short (16 Bit Integer) für die cm genaue Positionierung innerhalb des Quadranten. Der Vertexshader kann mit shorts direkt umgehen, der Offset des gerade zu rendernden Quadranten wird aus einer Konstanten dazugeholt. Das spart Speicherplatz und als Nebeneffekt auch Speicherbandbreite beim Fetchen der Vertices.

Spasstiger
2009-05-10, 17:19:18
Ich kann mich noch an eine Unreal Tech Demo erinnern, in der sie damit geprahlt haben dass in dieser Szene 2 Millionen Polygone verbaut sind.
Bei Crysis sind 1-3 Mio. Polygone pro Frame schon üblich (oder sinds 1-3 Mio. Vertices/s?).
/EDIT: Ein Baum in Crysis hat zwischen 500 und 2500 Dreiecke: http://www.obsidianedge.net/index.php?option=com_content&task=view&id=93&Itemid=117

Schon klar, dass das nichts mit cm zu tun hat.. Aber wenn deine Genauigkeit in der Spielwelt 1cm (oder noch kleiner) entsprechen soll und man eine genügend große Landschaft hat, dann müsste es doch Probleme geben, diesen Maßstab auf die Gleitkommazahlen zu übertragen, oder nicht?
Ich kenne mich nicht aus, aber mit dem heute üblichen Streaming sollte man doch beliebig große Spielwelten generieren können unabhängig von der Genauigkeit, mit der die Geometrie verrechnet wird. Die Sichtweite ist halt eingeschränkt. Und mit 32 Bit Genauigkeit kann man bei einer kleinsten Strukturgröße von virtuellen 1 mm immer noch 4300 virtuelle km abbilden.

Trap
2009-05-10, 18:22:50
Und mit 32 Bit Genauigkeit kann man bei einer kleinsten Strukturgröße von virtuellen 1 mm immer noch 4300 virtuelle km abbilden.
Mit 32-bit Gleitkomma hat man aber keine 32 Bit Genauigkeit sondern nur 24. Sind bei 1mm Strukturen nur ~17 km.

Bei Rechnungen damit verliert man noch das eine oder andere Bit, realistisch nutzbar sind wohl weniger als 8 km.

No.3
2009-05-10, 18:37:35
Mit 32-bit Gleitkomma

ich denke er meint 32 Bit Integer ;)

Markus89
2009-05-10, 19:29:45
ich denke er meint 32 Bit Integer ;)
Was sollte dann in dem Zusammenhang "Genauigkeit" sein?

Ein anderer Gast
2009-05-10, 21:29:19
Muss man den ganzen Kram eigentlich absolut speichern? Es genügt doch die Objekte relativ zu positionieren ...
Objekt a ist 1cm von Objekt b ist 0.0005cm von Objekt c ist ....
und sich im späteren Verlauf/Auswertung an "Fixpunkten" zu orientieren.

rotalever
2009-05-10, 21:58:44
Muss man den ganzen Kram eigentlich absolut speichern? Es genügt doch die Objekte relativ zu positionieren ...
Objekt a ist 1cm von Objekt b ist 0.0005cm von Objekt c ist ....
und sich im späteren Verlauf/Auswertung an "Fixpunkten" zu orientieren.
So würde man es ja im Prinzip machen, wenn man das Feld in Sektoren unterteilt.

Gast
2009-05-10, 22:15:49
Eine Beschränkung auf cm ist eher für eine andere Sache sinnvoll. Beispielsweise kann man das Szenario in Quadranten mit einer Seitenlänge von 500 m aufteilen, dann reicht ein short (16 Bit Integer) für die cm genaue Positionierung innerhalb des Quadranten.


500 m sind aber schon für jeden Militärshooter eine zu geringe Sichtweite.
D.h. auf großer Distanz über 500 m sieht man dann entweder den Gegner nicht oder seine Position wackelt ständig wegen Präzisionsungenauigkeiten.

Man denke da nur mal an OFP oder Arma.
Sichtweiten von 3000 m sind da das mindeste was der Rechner drauf haben sollte und da das alles auf Grashalmebene abläuft, braucht man auch die Präzision im cm Bereich.
Man denke nur an das treffen des Gegners mit ner Sniper 2 cm vom Helm
oder das ruchrobben auf dem Boden.

Gast
2009-05-10, 22:18:43
Ich kenne mich nicht aus, aber mit dem heute üblichen Streaming sollte man doch beliebig große Spielwelten generieren können unabhängig von der Genauigkeit, mit der die Geometrie verrechnet wird.

Streamen ja, aber Spieleintern brauchst du ja trotzdem deine Weltgenauigkeit.

Du kannst also bestenfalls von der imaginieren Spielwelt auf die Grafikkarte für die Visuelle Darstellung streamen.

Aber ne Rakete, die in 20 km nen Panzer ferngesteuert treffen soll, die muß halt dennoch genau ankommen und bei Streaming wird sie den visuellen Würfel sehr schnell verlassen, treffen muß sie aber trotzdem.





Die Sichtweite ist halt eingeschränkt. Und mit 32 Bit Genauigkeit kann man bei einer kleinsten Strukturgröße von virtuellen 1 mm immer noch 4300 virtuelle km abbilden.

Ja, siehe oben, man braucht 20 km.


Richtig gut wird es erst mit 64 Bit.

Gast
2009-05-10, 22:20:25
So würde man es ja im Prinzip machen, wenn man das Feld in Sektoren unterteilt.

Vorausgesetzt man kann es in Sektoren unterteilen.

Zu OFP und 3 km Sichtweite habe ich ja schon etwas gesagt.


Tja und dann wären da noch die Wolken, die müssen auch noch in 20 km Entfernung regen giessen lassen und nicht einfach am Sektorende aufhören zu existieren.

sth
2009-05-10, 22:31:12
Wenn man z.b. im Spiel ein Fernrohr benutzt (Sniperrifle),
dann wurde das Bild recht schnell unruhig, je weiter man heranzoomte.
Du meinst sicherlich Z-Fighting. Das hängt von der Genauigkeit des Z-Buffers (http://de.wikipedia.org/wiki/Z-Buffer) ab und hat eigentlich wenig mit den eigentlichen Geometriedaten zu tun.

Kurz gesagt, mich würde mal grob interessieren wie das bei 3d Spielen gelöst wird.
Vielleicht denke ich auch in die ganz falsche Richtung und jemand kann mir das näher erläutern.
Gängiger Standard (schon seit dem Beginn der hardwarebeschleunigten 3d-Spiele) ist die Verarbeitung von Geometriedaten in 32bit Floating-Point.

Spasstiger
2009-05-10, 23:01:49
Mit 32-bit Gleitkomma hat man aber keine 32 Bit Genauigkeit sondern nur 24. Sind bei 1mm Strukturen nur ~17 km.
:confused:
Mit 32-Bit-Floating-Point hast du auch 32-Bit-Genauigkeit. Und der Dynamikumfang vergrößert sich sogar durch die Fließkommadarstellung.
Bei 8 Bit Exponent, 24 Bit Mantisse und 1 Bit Vorzeichen nach IEEE 754 geht dein Wertebereich im Positiven von 1,0*2^-126 bis 1,11*2^127. Den gleichen Bereich gibts auch nochmal im Negativen.

No.3
2009-05-10, 23:07:37
Was sollte dann in dem Zusammenhang "Genauigkeit" sein?

wenn Du auf einer virtuellen über 4000 Kilometer langen Achse Objekte auf 1 Millimeter genau positionieren kannst, also wenn das mal keine Genauigkeit ist, dann weiss ich auch nicht mehr

Neomi
2009-05-10, 23:25:02
500 m sind aber schon für jeden Militärshooter eine zu geringe Sichtweite.
D.h. auf großer Distanz über 500 m sieht man dann entweder den Gegner nicht oder seine Position wackelt ständig wegen Präzisionsungenauigkeiten.

Die Quadrantengröße hat doch mit der Sichtweite nichts zu tun. Wer sagt denn, daß man innerhalb eines Frames nur einen Quadranten zeichnen kann? Jeder sichtbare Quadrant (innerhalb des View Frustrums und innerhalb der gewünschten Sichtweite) wird mit jeweils passendem Offset gezeichnet. Die Koordinaten, die relativ zum Quadranten (also in dessen Local Space) abgelegt sind, werden auf den Offset aufaddiert, den der Quadrant relativ zur Kamera hat (wenn die Kamera als am Nullpunkt befindlich angesehen wird) bzw. relativ zum Quadranten, in dem sich die Kamera befindet (ebenfalls nicht schwer umzusetzen). Genauigkeitsprobleme gibt es da keine, außer man hat einen Bug in der Implementierung.

Trap
2009-05-10, 23:31:28
:confused:
Mit 32-Bit-Floating-Point hast du auch 32-Bit-Genauigkeit.
Nö, das ist gleich auf mehreren Ebenen falsch. Es gibt verschiedene Bitmuster in 32-bit Gleitkommazahlen mit gleicher Bedeutung, damit kann man schonmal nicht 2^32 Bedeutungen haben.

Genauigkeit im Sinne von Positionierungsgenauigkeit würde ich über +1 Schritte zählen und gucken obs stimmt definieren und da kommt eben 2^24 raus, über 2^24 gibt es keine floats mit Abstand 1 mehr.

Spasstiger
2009-05-10, 23:46:33
@Trap: Warum sollte man 32-Bit-Fließkomma verwenden, wenn man nur die Positionierungsgenauigkeit von 24-Bit-Integer hat?
Übrigens werden Fließkommazahlen normalisiert, so dass jede darstellbare Zahl eindeutig dargestellt wird. IEEE 754 single (32 Bit) kann 2^32 verschiedene Zahlen darstellen.

rotalever
2009-05-10, 23:55:07
@Trap: Warum sollte man 32-Bit-Fließkomma verwenden, wenn man nur die Positionierungsgenauigkeit von 24-Bit-Integer hat?
Übrigens werden Fließkommazahlen normalisiert, so dass jede darstellbare Zahl eindeutig dargestellt wird. IEEE 754 single (32 Bit) kann 2^32 verschiedene Zahlen darstellen.
Ja, vielleicht 2^32 verschiedene Zahlen. Aber du stimmst mir doch zu, dass wenn meine Einheit zum Beispiel 1 ist und ich jetzt eine sehr große Fließkommazahl A habe und dann A+1 rechne, dass dann wieder A rauskommt. A+1=A. Das heißt, dass in der Entfernung deine Genauigkeit sinkt.

Fließkommazahlen sind dann sinnvoll, wenn man einen großen Bereich abdecken will, wo die Genauigkeit nur relativ gut sein muss. Für ein Game braucht man aber absolute Genauigkeit.

edit:Ich will damit sagen, dass entfernte Objekte mit der selben (Millimeter-)Genauigkeit gespeichert sein müssen, wie Objekte, die nahe dranliegen. Denn irgendwann wird sich die Spielfigur auch in diese weit entfernten Bereiche bewegen, und wenn sie sich dann bei Koordinaten befindet, wo die absolute Genauigkeit stark gesunken ist, wird das Bild schlecht.

Neomi
2009-05-10, 23:56:05
@Trap: Warum sollte man 32-Bit-Fließkomma verwenden, wenn man nur die Positionierungsgenauigkeit von 24-Bit-Integer hat?

Falsche Annahme, man hat deutlich mehr Präzision als mit einem Integer, aber eben nur bei kleinen Zahlen. Dafür eben weniger Präzision bei größeren (ab 16777216). Und man kann sogar Zahlen darstellen, die sogar größer sind als die maximal darstellbaren mit einem 64 Bit Integer. Es ist ja auch nicht so, daß Float besser wäre als Integer oder Integer besser als Float. Beides ist wichtig, beides hat Stärken und Schwächen, jede CPU kann beides und der Programmierer muß sie richtig einsetzen.

Übrigens werden Fließkommazahlen normalisiert, so dass jede darstellbare Zahl eindeutig dargestellt wird. IEEE 754 single (32 Bit) kann 2^32 verschiedene Zahlen darstellen.

Falsch. +0 und -0 sind beide 0, damit fehlt schonmal eine. Viel mehr geht dadurch verloren, daß bei positiven und negativen Zahlen jeweils 2^23 Möglichkeiten sich nur unter Inf und NaN aufteilen.

Für ein Game braucht man aber absolute Genauigkeit.

Bitte nicht so generalisieren. In einem Spiel gibt es viel, was absolut genau sein muß, und mehr, bei dem relative Genauigkeit reicht.

rotalever
2009-05-11, 00:01:29
Bitte nicht so generalisieren. In einem Spiel gibt es viel, was absolut genau sein muß, und mehr, bei dem relative Genauigkeit reicht.
Ja, hast ja recht :redface:

Spasstiger
2009-05-11, 00:02:32
Rechnet die Grafikkarte nicht eh mit Koordinaten relativ zur Kamera? Da braucht man ja eine hohe Geometrieauflösung nur nahe der Kamera. Ok, auf der HDD sollten die Koordinaten auch vernünftig gespeichert werden. Aber da kann man ja auch eigene Formate definieren.
Hab leider von 3D-Programmierung null Ahnung.

@Neomi: Meine Frage drückt ja schon unterschwellig aus, dass 32-Bit-Fließkomma auch eine höhere Präzision zulässt als 24-Bit-Integer. Und mir ist bekannt, dass bei großen Zahlen in der Fließkomma-Darstellung die Auflösung geringer ist als bei kleinen Zahlen.

Falsch. +0 und -0 sind beide 0, damit fehlt schonmal eine. Viel mehr geht dadurch verloren, daß bei positiven und negativen Zahlen jeweils 2^23 Möglichkeiten sich nur unter Inf und NaN aufteilen.
Ok, Peanuts. ;)
Dafür kann die Mantisse effektiv 1 Bit mehr haben als gespeichert wurde, weil erst ab höchstwertigen 1 gespeichert werden muss.

rotalever
2009-05-11, 00:18:36
Rechnet die Grafikkarte nicht eh mit Koordinaten relativ zur Kamera? Da braucht man ja eine hohe Geometrieauflösung nur nahe der Kamera. Ok, auf der HDD sollten die Koordinaten auch vernünftig gespeichert werden.

Letztendlich rechnet die Graka wohl mit Float, oder nicht?
Und ja, diese sehr genauen Daten braucht man auf der HDD. Allerdings muss man sie der Grafikkarte natürlich auch entsprechend zu Verfügung stellen und umrechnen. Und da muss man halt ein wenig aufpassen.

Neomi
2009-05-11, 01:34:27
Rechnet die Grafikkarte nicht eh mit Koordinaten relativ zur Kamera? Da braucht man ja eine hohe Geometrieauflösung nur nahe der Kamera. Ok, auf der HDD sollten die Koordinaten auch vernünftig gespeichert werden. Aber da kann man ja auch eigene Formate definieren.

Relativ zur Kamera rechnet die GPU implizit erst nach dem Vertexshader, wie der Vertexshader rechnet hängt natürlich vom Programmierer ab. Und da ist dann schonmal wichtig, in welcher Reihenfolge Matrizen verkettet oder andere Operationen ausgeführt werden, damit die Rundungsfehler sich nicht zu sehr auswirken.

Ok, Peanuts. ;)
Dafür kann die Mantisse effektiv 1 Bit mehr haben als gespeichert wurde, weil erst ab höchstwertigen 1 gespeichert werden muss.

Ja, aber das ist eine unveränderliche implizite 1 (bei Denorms eine 0, auch nicht änderbar) und trägt deshalb nicht zur Zahl der unterschiedlichen darstellbaren Zahlen bei.

Letztendlich rechnet die Graka wohl mit Float, oder nicht?
Und ja, diese sehr genauen Daten braucht man auf der HDD. Allerdings muss man sie der Grafikkarte natürlich auch entsprechend zu Verfügung stellen und umrechnen. Und da muss man halt ein wenig aufpassen.

Ja, die Grafikkarte rechnet mit Floats, in der Regel zumindest. Sie kann aber auch andere Datenformate entgegennehmen. Auf der HDD braucht man nur das, was zur Rekonstruktion der letztendlich benötigten Daten nötig ist. Je nach darzustellendem Objekt kann sogar durchaus auch ein 8 Bit Integer reichen, also eine Position in einem UByte4 (normalerweise für Farbwerte benutzt) gespeichert werden.

Beispiel:
Wer mißt schon nach, ob die Vertices in einem sowieso schon unregelmäßigen Felsen mit etwa 5 m Durchmesser jetzt alle nur auf ca. 2 cm genau positioniert sind? Und wem würde auffallen, daß der Felsen einen halben cm weiter nördlich platziert worden wäre, wenn die Genauigkeit es zugelassen hätte?

Gast
2009-05-11, 04:53:25
Die Quadrantengröße hat doch mit der Sichtweite nichts zu tun. Wer sagt denn, daß man innerhalb eines Frames nur einen Quadranten zeichnen kann? Jeder sichtbare Quadrant (innerhalb des View Frustrums und innerhalb der gewünschten Sichtweite) wird mit jeweils passendem Offset gezeichnet. Die Koordinaten, die relativ zum Quadranten (also in dessen Local Space) abgelegt sind, werden auf den Offset aufaddiert, den der Quadrant relativ zur Kamera hat (wenn die Kamera als am Nullpunkt befindlich angesehen wird) bzw. relativ zum Quadranten, in dem sich die Kamera befindet (ebenfalls nicht schwer umzusetzen). Genauigkeitsprobleme gibt es da keine, außer man hat einen Bug in der Implementierung.

Aber ist das nicht Rechenaufwendiger dieses umrechnen als einfach alles in 64 Bit zu berechnen?

Neomi
2009-05-11, 11:45:34
Warum jetzt gleich 64 Bit? In dem Posting ging es um 32 Bit Gleitkomma gegen noch kleiner gepackte Integerformate (16 Bit).

Erstmal zu 32 Bit gegen 64 Bit im Floatbereich: GPUs unterstützen bisher kein 64 Bit, deshalb ist 32 da das Maximum. Auf CPUs ist 32 Bit, wenn richtig genutzt, mindestens doppelt so schnell. Mindestens deshalb, weil manche Operationen mehr Iterationen benötigen, um die von Double benötigte Präzision zu erreichen. Doppelt so schnell, weil man per SIMD 4x 32 Bit Float gleichzeitig berechnen kann, aber nur 2x 64 Bit (und das auch nur ab SSE2, SSE1 dagegen kennt kein Double), alleine dadurch wird schon der Durchsatz halbiert. Abgesehen davon belegen Doubles den doppelten Speicherplatz im Vergleich zu Floats, verschlingen deshalb mehr Speicherbandbreite und verringern die Cacheeffizienz, in Grenzfällen muß sogar mehr geswapt werden.

Und jetzt zur Geschwindigkeit zwischen 16 Bit Integer und 32 Bit Float: per CPU kostet die Umwandlung natürlich, GPUs dagegen haben diese Umwandlung festverdrahtet. Egal ob du im Vertexshader jetzt Floats oder 16 Bit Integer fetchst, der Shader bekommt in beiden Fällen die Daten als Floats (Ausnahmen durch neu hinzugekommenen expliziten Integersupport, ob nun per D3D10 oder OpenGL-Extensions, mal ausgenommen). Ob diese automatische Konvertierung Zeit kostet, hängt von der GPU ab, aber es sollte in der Regel keine Rolle spielen. Es kommt bloß ein einziger Befehl (Multiply Add) dazu, um die Daten in die passende Range zu bringen. Ein Befehl, der unter all den anderen gar nicht mehr auffällt, vor allem da nur in den seltensten Fällen die Vertexlast der limitierende Faktor ist. Oft (wenn die Position im Worldspace nicht separat benötigt wird) kann dieser eine Befehl auch noch eliminiert werden, wenn er direkt in den Transformationsmatrizen verrechnet wird. Und wenn das mal doch nicht geht UND die Vertexlast der limitierende Faktor ist, dann wird das wohl durch die geringere benötigte Speicherbandbreite (weniger Platzbedarf pro Vertex, also auch weniger zu übertragen) mehr als ausgeglichen. In der Praxis sollte der Effekt durch Packen in kleineren Datentypen eigentlich immer irgendwo zwischen "weniger Speicherbedarf" und "etwas höhere Geschwindigkeit bei gleichzeitig weniger Speicherbedarf" liegen.

rotalever
2009-05-11, 15:29:20
Abgesehen davon belegen Doubles den doppelten Speicherplatz im Vergleich zu Floats, verschlingen deshalb mehr Speicherbandbreite und verringern die Cacheeffizienz, in Grenzfällen muß sogar mehr geswapt werden.

Ja, sowas hatte ich mal. Da habe ich was mit 32bit Integern gemacht, da aber die Werte nur sehr klein waren, habe ich mal probiert, was passiert, wenn ich 1byte chars verwende. Obwohl ich dann einige Typecasts machen musste, lief alles um einen großen Faktor schneller. Vermutlich durch die bessere Ausnutzung des Caches.

tokugawa
2009-05-13, 00:04:15
Um auf den genauen Wortlaut des Originalposters einzugehen: "brauchen" tut eine Spielewelt eigentlich meistens nicht mehr als 32-bit floating point-Genauigkeit. Damit hab ich eigentlich noch bei keinem Projekt ein Problem gehabt.

Bei 32-bit FP-Genauigkeit wird selbst bei Beachtung kleiner Strukturgrößen die "Ausdehnung" für das damit darstellbare Areal groß genug sein, dass die entsprechende Levelgeometrie inklusive Texturen nicht mehr in den Speicher heute üblicher Systeme passt. Es limitieren also vorher schon andere Dinge bevor die Floating-Point-Genauigkeit zu tragen kommt.

Gast
2009-05-18, 09:04:50
Es gibt viele Spiele die Probleme mit 'nur' float haben. Am offensichtlichsten ist das bei Weltraumspielen, bei denen man riesige wege abfliegen will, aber auch seinen Laser akkurat gegen Kleinteile feuern moechte.
Auch bei GFX-Karten gibt es des oefteren genauigkeitsprobleme, es ist nicht trivial bei so weiten Entfernungen noch die Projektionsmatrix aufzusetzen, sodass man nicht mit z-fighting leben muss.
Aber auch schon bei normalen Level in Shootern, bei denen auch physik berechnet wird, kann man Probleme bekommen, entsprechend hatte nicht nur UT99 limitierungen, sondern auch die heutigen Engines.

Mr. Lolman
2009-05-27, 09:23:29
Achtung, gefährliches Halbwissen: afaik hat sich an der geometrischen Auflösung seither nicht viel getan. Man konnte schon im UT Leveleditor das Grid deaktivieren, und die Geometrie millimetergenau platzieren - nur das ergab regelmäßig Clipping- und Beleuchtungsprobleme, und war auch aus Performancegründen nicht erstrebenswert.

Clippingfehler gabs iirc nur, wenn man gepfuscht hat. Und performancetechnisch machte das iirc auch keinen großen Unterschied.


Ich kann mich noch an eine Unreal Tech Demo erinnern, in der sie damit geprahlt haben dass in dieser Szene 2 Millionen Polygone verbaut sind. Afaik haben wir das in Spielen bis heute nicht erreicht, eher im Gegenteil: mit besseren Texturierungs- und Shadingtechniken gibt es nicht mehr so viel Bedarf für komplexe Geometrie.

Je nach Auflösung kommt das bei Crysis tw. schon hin. Bei meinem Level mit Mster Config 3.0 sinds mit 1920x1200 stw. sogar ~7Mio Polys/frame. (Meine 512MB HD4870@825/1150 schafft im Editor an dieser Stelle ~27fps)