Welches Genauigkeit von PI brauche ich für 3D-Grafik?

dot

Nur vorsichtig sein wegen dem Typ. Wenn du mit float Werten rechnest, willst du auf jeden Fall pi auch als float definieren und auf keinen Fall als double. float und double willst du nicht nur aus rein ästhetischen Gründen auf keinen Fall vermischen, sondern vor allem auch, da der Compiler sonst gezwungen ist, langsamen Code zu produzieren, was du wohl vor allem in einem Software-Renderer vermeiden willst...

Btw: Rotationswinkel kann man sehr elegant als Normalized Integer darstellen...

hustbaer

Th69 schrieb:

Doch Sone, das meine ich Ernst, s. z.B. http://stackoverflow.com/questions/1727881/how-to-use-the-pi-constant-in-c
Alternativ eben
const double PI = acos(-1.0);
Der Compiler kann es eben exakt ausrechnen mit maximalen Nachkommastellen (je Architektur).
Natürlich nur sinnvoll, wenn Intrinsics aktiviert sind bzw. die Berechnung nur genau einmal am Anfang des Programms durchgeführt wird.

Sorry, aber ich halte das auch für Unfug.
Es ist zwar "sicher", in dem Sinn dass keine Fehler passieren werden, aber es kann unnötigerweise bremsen.
Bzw. ich behaupte mal: es *wird* unnötigerweise bremsen. Mag sein dass einige Compiler schlau genug sind das optimieren zu können. Dem mit dem ich gerade arbeite (MSVC 2005) traue ich die Optimierung aber nicht zu.
Und vor allem garantiert dir keiner dass es vom Compiler deiner Wahl *immer* korrekt optimiert wird.
Irgendwann änderst du was und die Optimierung "bricht" und dann läuft dein Programm unnötiger weise langsamer.

In den meisten Fällen wird es natürlich nicht viel ausmachen. Für Quatsch halte ich es trotzdem.

Lichtweite

dot schrieb:

Nur vorsichtig sein wegen dem Typ. Wenn du mit float Werten rechnest, willst du auf jeden Fall pi auch als float definieren und auf keinen Fall als double. float und double willst du nicht nur aus rein ästhetischen Gründen auf keinen Fall vermischen, sondern vor allem auch, da der Compiler sonst gezwungen ist, langsamen Code zu produzieren, was du wohl vor allem in einem Software-Renderer vermeiden willst...

Btw: Rotationswinkel kann man sehr elegant als Normalized Integer darstellen...

Danke, nettes Forum, habe mich gleich mal angemeldet.

rapso

cooky451 schrieb:

Hmja, ich mein nur. Mir scheint 3D Grafik ohne FPU irgendwie witzlos zu sein.

sag nicht du hast nie eine playstation(1),nintendo ds gesehen:P, keine FPU, aber 3d Grafik ;). sehr viele software engines haben frueher rein mit int gerechnet, da float zu langsam war, selbst mit fpu, alleine float->int konvertierung, die du frueher oder spaeter machen musstest, war mit der masse an vertices bzw pixeln untragbar.

weshalb wir float nutzen? ja, es ist an sich schlechter als int, aber man kann relativ gedankenfrei damit arbeiten. es stoesst schon an unsinn, wenn leute anfangen modelle als halfs zu speichern um platz zu sparen, statt short, aber naja...

@Lichtweite
man muss nicht nur eine genauigkeit festlegen. wenn ich auf so limitierten platformen arbeite(te), speichere ich meine modelle meistens mit 8bit 'genauigkeit' und um den bereich bestens auszunutzen, hab ich einen skalierungswert (auch 8 bit, der besagt wieviel geschiftet werden muss, wobei das ein signed wert ist).
bei den ganzen transformationen nutze ich meistens 20:12 als genauigkeit, damit hab ich einen wertebereich von -512k bis +512k mit 1/4096 genauigkeit.
nach dem clipping und projektion arbeite ich dann mit 12:20, das ist ein ausreichender wertebereich fuer sich wiederholende texturen (wrapping) und die genauigkeit ist gut genug um bei gross gezogenen polys noch eine smooth UV interpolation zu haben (z.b. bei terrain).

graphikkarten haben etwa 48bit fixpoint zur interpolation von polys, das liegt an deren 'guard band' der dafuer sorgt, dass nicht geclippt werden muss (jedenfalls 'kaum'). davon ist die aufteilung, soweit ich weiss, 44:4, jedoch wird das nur zum evaluieren benutzt, ob ein pixel im oder ausserhalb vom dreieck liegt, wenn das erstmal feststeht, wird die pixelposition in float umgewandelt und spaeter damit interpoliert.

Lichtweite

Danke für den interessanten Einblick, da sind Punkte bei über die ich mir noch gar keine Gedanke gemacht habe. Naja, meine Pipeline steht ja auch noch nicht.

cooky451

rapso schrieb:

sag nicht du hast nie eine playstation(1),nintendo ds gesehen:P

Zu jung fürs eine und zu alt fürs andere.

rapso schrieb:

weshalb wir float nutzen? ja, es ist an sich schlechter als int, aber man kann relativ gedankenfrei damit arbeiten.

Schon, aber würde es nicht viele Probleme lösen? Wenn man sich auf ein bestimmtes Festkommaformat einigen würde, wären zumindest mal alle Skalierungen gleich. Ich frage mich, ob ich mal versuchen soll in meinen Shadern mit ints zu rendern. Nur habe ich das Gefühl, dass die Grafikkarten dafür nicht wirklich optimiert sind, und das zieht sich dann wohl durch's ganze Programm, wenn man nicht irgendwo teuer umwandeln möchte.

dot

cooky451 schrieb:

Nur habe ich das Gefühl, dass die Grafikkarten dafür nicht wirklich optimiert sind [...]

Mit diesem Gefühl liegst du da richtig; für eine GPU ist float quasi der native Datentyp und alles andere wird (auf Shader Ebene) bestenfalls gleich schnell sein, in der Regel meist langsamer.

Festkomma ist kein Ersatz für Gleitkomma und auch nicht umgekehrt. Beides hat völlig andere Vor- und Nachteile und je nach Anwendungsfall wird das eine oder das andere zu bevorzugen sein. Charakteristisch für Festkomma ist jedenfalls, dass es eben für Zahlen einer gewissen Größenordnung gedacht ist. Sich allgemein "auf ein Festkommaformat zu einigen" ginge rein prinzipiell am Sinn von Festkomma vorbei...

Bashar

cooky451 schrieb:

Wenn man sich auf ein bestimmtes Festkommaformat einigen würde, wären zumindest mal alle Skalierungen gleich.

Ja, aber für die meisten wäre die Skalierung falsch. Wenn man mit Festkomma arbeitet, muss man für jede Variable entscheiden, wie die Skalierung aussehen soll. Die Skalierung gehört quasi zum Datentyp dazu.

rapso

cooky451 schrieb:

rapso schrieb:

sag nicht du hast nie eine playstation(1),nintendo ds gesehen:P

Zu jung fürs eine und zu alt fürs andere.

rapso schrieb:

weshalb wir float nutzen? ja, es ist an sich schlechter als int, aber man kann relativ gedankenfrei damit arbeiten.

Schon, aber würde es nicht viele Probleme lösen? Wenn man sich auf ein bestimmtes Festkommaformat einigen würde, wären zumindest mal alle Skalierungen gleich.

aber oben drueber schrieb ich, dass ich mich mit mir selber nicht auf nur ein format einigen konnte

Ich frage mich, ob ich mal versuchen soll in meinen Shadern mit ints zu rendern. Nur habe ich das Gefühl, dass die Grafikkarten dafür nicht wirklich optimiert sind, und das zieht sich dann wohl durch's ganze Programm, wenn man nicht irgendwo teuer umwandeln möchte.

DirectX 8 shader bzw texture stages (bzw register combiner) haben genau das gemacht. das war anfangs nichtmal definiert wie es sein sollte und je nach hardware bzw treiber waren die resultate dann unterschiedlich.
geforce 3/4 hatten glaube ich 1:1:8 (vorzeichen,-1 bis +1 und 1/256 genauigkeit)
GeforceFX hattae 1:2:9
Radeon 8500 hatte 1:3:10
geforce4MX hatte eine nicht standard kompilante emulation in software, und Nv hatte sich immer grosszuegig zeit mit dem fixen gelassen.

rapso

dot schrieb:

Charakteristisch für Festkomma ist jedenfalls, dass es eben für Zahlen einer gewissen Größenordnung gedacht ist.

das problem mit float ist, dass es gewissermassen auch so ist, es ist quasi ein fix point, dem man jedesmal mitgibt wie der wertebereich ist.
bei statischen fix points muss man sich damit auseinander setzen, weil eine bereichsueber/unterschreitung zu fehlern fuerht. bei floats hat man hingegen grundsaetzlich einen viel kleineren bereich der sicher abgedeckt ist und wenn der bereich ueber-/unterschritten ist, wird der 'fehler' silent ignoriert und einfach die range angepasst.
das sieht man nicht mit dem auge, aber es kann sein, dass sich irgendwelche physic objekte ploetzlich zueinander ueberschneident verhalten, nur weil man sie weiter vom zentrum der level bewegt hat.

das lustige ist eigentlich, dass wissenschaftler mit floats (bzw eher mit doubles) genau so arbeiten wie graphikprogrammierer mit fix point gearbeitet haben. sie waehlen algorithmen oft danach aus (und implementieren sie so) dass der wertebereich nur einen gewissen maximalfehler hat. und fuer sie ist die genauigkeit von double so limitierend wie es bei graphik mit fixpoint ist.
man simuliert eine galaxie und in dieser die einzelnen sternensysteme, bei deren entstehung ist es quasi bis runter zum staub den man simulieren will.

hier gab es mal ein thread wie man ausrechnet wieviel flops eine funktion hat und manche haben es fuer nicht machbar gehalten alle operationen zu zaehlen, wissenschaftler gehen soweit die fehler anhand der operationen zu zaehlen (was nicht nur die operationen sondern die reihenfolge der operationen und die zu erwartenen wertebereiche einzelner register miteinbezieht).

fuer graphic/spiele sind floats einfach nur ein fire&forget weg, quasi das arithmetisch, was C#/java VMs fuer den speicher sind.
bei fix point musste man sich gedanken machen
bei float24 (z.b. radeon 9500) musste man noch alle objekte relativ zur kamera schieben
bei float32 hat man nur noch bei weltraumspielen und bei speziallfaellen probleme (z.b. manchmal in physics wenn die schrittweite zu klein wird oder wenn man cascaded shadow maps macht und sie stabil halten will).