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

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

  • L

    Pi ist mir nur eingefallen da man es und ein paar Terme damit als Konstanten definiert. Die Frage ging aber, wie du richtig erkannt hast, in die Richtung, wie viele Stellen nach dem Komma ich minimal brauche um noch vernünftig 3D Transformationen etc. machen zu können?

    Ich bin mir mittlerweile schon gar nicht mehr sicher ob meine Frage überhaupt einen Sinn ergibt, wenn alle hier mit den Schultern zucken^^ Praktisch nutze ich jetzt Konstanten mit sechs Stellen hinter dem Komma.

    0
  • S

    Kannste abschätzen: guck die Kondition deiner Transformationsmatrizen an und mach ne Fehlerabschätzung.

    0 

  • const double PI = 4.0 * atan(1);
    0
  • S

    Th69 schrieb:

    const double PI = 4.0 * atan(1);

    Das ist jetzt hoffentlich nicht dein Ernst.

    0
  • C

    Lichtweite schrieb:

    Praktisch nutze ich jetzt Konstanten mit sechs Stellen hinter dem Komma.

    Warum nutzt du überhaupt Festkommazahlen?

    0
  • L

    Ich nutze FP für Fälle wo auf der Zielplattform keine FPU vorhanden ist únd ansonsten floats, wo ich aber auch PI und die üblichen Formen davon, wie PI Halbe, 1/PI etc gleich als Konstanten für Lookup-Tables oder schnelle Sinus-Annäherungen etc. verwende.

    @ScottZhang: Interessant, inverse Matrix kenne ich, aber eine Normalform einer Matrix habe ich noch nie gebildet, geschweige denn aus deren Produkt dann die Kondition ausgerechnet.

    0
  • C

    Du schreibst 3D Anwendungen für embedded systems? Vielleicht solltest du mal etwas genauer beschreiben was du da eigentlich vor hast. 🙂

    0
  • L

    Ich schreibe eine kleine 3D-Engine von der Picke auf ohne Hardwareunterstützung, die halt auch mal eventuell auf verschiedenen Mikrocontrollern laufen soll. Es ist aber nur ein Lernprojekt und wird wahrscheinlich nie irgend jemanden nutzen. Wenn es meine Horizont für die 3D-Programmierung erweitert und ich durch dieses Projekt viel lernen kann, dann hat es sein Ziel schon erreicht.

    Ich möchte es in C aber auch in C++ umsetzen, um so auch beide Sprachen mal wirklich an einem mittleren Projekt in Aktion zu erleben.

    0
  • C

    Hmja, ich mein nur. Mir scheint 3D Grafik ohne FPU irgendwie witzlos zu sein. Wobei - für Rotationen macht es sogar irgendwie Sinn, bei 360° fängt man ja wieder von vorne an. Und jetzt, wo ich drüber nachdenke, macht es eigentlich auch für Positionen Sinn, schließlich will man ja eine gleichverteilte Präzision, und keine die relativ zum Nullpunkt immer schlechter wird. Kann mir mal jemand erklären warum wir floats für den Quatsch nutzen? 😃

    Lichtweite schrieb:

    Ich möchte es in C aber auch in C++ umsetzen, um so auch beide Sprachen mal wirklich an einem mittleren Projekt in Aktion zu erleben.

    Könnte interessant werden - allerding leider nur wenn du auch beide Sprachen gut beherrschst.

    0

  • Lichtweite schrieb:

    Hi,

    PI wird ja heute bis auf Millionen von Stellen nach dem Komma berechnet, tatsächlich braucht es aber für die meisten Berechnungen nur recht wenige Stellen. Wie viele Stellen sind denn eurer Meinung nach für die Berechnung von 3D Grafik notwendig, also für Rotationen etc.?

    Wenn Du Berechnungen durchführst, spielt es keine Rolle, ob Du mit 3 rechnest, mit 3.14 oder einer Million Stellen. Eine Operation dauert so lange, wie eine Operation dauert. In ein Float oder Double passt eine gewisse Größe rein, nicht mehr. Nimmst Du weniger Stellen wird der Algorithmus nicht schneller. Willst Du mehr Stellen musst Du aufwendigere Geschichten fahren, das wird tierisch langsam. Das willst Du vermutlich auch nicht.

    Bei Winkeln wirst Du sowieso schnell merken, dass Ungenauigkeiten im Kreis mit dem Radius zusammenlaufen. Ein Winkel wird bei maximaler Genauigkeit durch den Radius schnell in einen kritischen Bereich multipliziert, so dass Du hier schnell in aus der Epsilontik läufst und Deine Ergebnisse genauso gut Würfeln kannst.

    Für die Frage gibt es also nur eine sinnvolle Antwort: Pack rein, was in Dein Register passt und hoffe dass es reicht. Dann wird es nämlich richtig interessant. ^^

    0
  • C

    @Xin Da er ja mit Festkommazahlen rechnet, wollte er wahrscheinlich wissen an welche Stelle er das Komma setzen soll - das ist ja nicht ganz klar auch bei gegebener Registergröße.

    0

  • cooky451 schrieb:

    @Xin Da er ja mit Festkommazahlen rechnet, wollte er wahrscheinlich wissen an welche Stelle er das Komma setzen soll - das ist ja nicht ganz klar auch bei gegebener Registergröße.

    Double hat maximal 53 Nachkommastellen (binär). Das sind ca. 15 dezimale Stellen. Und das reicht nicht immer. Solange sich der Winkel im Bereich von 0 bis pi befindet, gehen vorne auch mal gleich 2 weitere Stellen verloren, bleiben also nur 51 binäre Stellen.

    Wie immer ist die Frage mit welchen Größen er arbeitet und wie er sie verrechnet.
    Vermutlich werden die Strecken weniger Nachkommastellen benötigen, als die Winkel, es stellt sich also schon die Frage, ob Winkel und Strecken mit dem gleichen Datentyp gespeichert werden sollten, weil sich das Komma an unterschiedlichen Punkten befindet, bzw. die Strecken und Winkel auf einen Wertebereich abgeglichen werden müssen.

    Diesen Abgleich macht man bei Fließkommazahlen mit dem Exponenten. Wenn man den einsparen kann, kann man natürlich größere Mantissen speichern. Dafür sollte bei Winkeln das Festkomma bei Bit 61 stehen. Die Strecken wird er aber vermutlich nicht im Bereich von -4.9 bis +4.9 halten wollen, dann würde ein Radius ihm auch kaum Probleme bereiten. 😉

    0

  • 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.

    Du kannst natürlich auch PI als Literal verwenden (3.14...). Aber entweder du gibst unnötigerweise zu viele Nachkommastellen an oder eben zu wenig. Wer weiß, vllt. gibt es in einigen Jahrzehnten den Datentyp 'double' mit 100 Nachkommastellen und dort steht dann nur PI = 3.14159265.
    Dann würde mein Programmcode trotzdem mit bestmöglicher Genauigkeit arbeiten und der mit dem festdefinierten Literal nicht.

    0
  • S

    Gut, ich sehe ein, das macht doch Sinn.

    0

  • 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...

    0

  • 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.

    0
  • L

    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.

    0
  • R
    Mod

    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.

    0
  • L

    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.

    0
  • C

    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. 😞

    0
Anmelden zum Antworten