Multiplikationen/divisionen optimieren

[Memnarch]

Tag alerseits,
Wie bereits erwähnt, arbeite ich aus spass an der freude an einem Softwarerasterizer.
Leider habe ich eine große geschwindigkeitsbremse:

Die interpolation des ZWertes eines beliebigen Punktes P im Dreieck ABC. Das mache ich so:

Code:

  ZWert = ((FlächePBC*ZWertA) + (FlächePCA * ZWertB) + (FlächePAB * ZWertC)) / Gesamtfläche

Obige werte sind alles Integer werte, ausnahme ist ZWert, das ist ein "Single".

Bringt es mir einen geschwindigekitsvorteil wenn ich mit Floatingpoint variablen kalkuliere?(Knechte hier gerade nen P4). Wie kann ich die kalkulation ansonsten noch optimieren?
(Die flächen musten als integer kalkuliert werden, da sie mit der gesamtfläche auf gleicheit überprüft werden. Oder wie ist das, wenn ein Single eh keinen wert nach dem komma hat, dann kann ich vergleichen?)

MFG
Memnarch

[Lemmy]

Hi,

Floats kannst Du per Definition nur über Differenzwerte vergleichen, alles andere geht schief:

http://wiert.wordpress.com/2011/03/0...tack-overflow/

Eine Variante wären Currency, da hättest Du dann immerhin 4 Nachkommastellen. Keinen Plan ob dir das ausreicht.

Wie das aber mit der Optimierung aussieht kann ich dir nicht sagen

[Memnarch]

In dem angegebenen beispiel hat die Float zahl ne nachkommastelle. Meine zahlen haben NIEMALS nachkommastellen, wenn ich auf gleicheit prüfe. Da bis dorthin nur additionen/multiplikationen/subtraktionen mit ganzzahlen stattfinden(also sollte der fall von rundungsfehlern noch wegfallen oder nicht? wird ja nie gerundet). Erst nach der gleichheitsprüfung, würde eine division folgen, aber dann wird auch nur noch auf < oder > geprüft.(obige formel komtm NACH der gleichheitsprüfung, ab hier entstehen kommazahlen, das ist aber hier an der stelle wurscht)

Mh..beantwortet aber leider noch nicht meine primärfrage zur optimierung

MFG
Memnarch

[BUG]

Code:

ZWert = FlächePBC*(ZWertA/ Gesamtfläche) + FlächePCA*(ZWertB/ Gesamtfläche) + FlächePAB*(ZWertC/ Gesamtfläche)

Sieht nach Skalarprodukt aus, vielleicht ist da mit Vektoroperationen was zu reißen.
Berechnest du mehrere Punkte pro Dreieck?

[Lemmy]

hi,

den Link habe ich nur angegeben, weil dort ein paar Hintergründe der Thematik besprochen werden.

Und wenn deine Floats nie Nachkommastellen haben - warum sind das dann Floats? Und zum Rest sag ich nix: Versuch es, beschwer dich aber nicht, wenn deine Anwendung beim Kunden wegen so was mal aussteigt und Fehler schmeißt, die keiner reproduzieren kann, am wenigsten du!

Und wegen Optimierung: Ich habe letztes Jahr mal was zu Delphi-Integer-Optimierung gelesen, leider finde ich das nicht mehr. Aber eines noch: Du bist sicher, dass diese Gleichung der Performance-Killer deiner Anwendung ist?

Grüße

[himitsu]

Du kannst natürlich einfach davon ausgehn, daß es keine Probleme gibt,
aber wunder dich dann nicht, wenn es dennoch einmal nicht paßt.

Wenn dich eh keine Nachkommastellen interessieren, dann kannst du doch einfach mit 'nem Delta/Epsilon von 0.1 vergleichen ... ob es nun einen Rundungsfehler gibt oder nicht, ist ab dann doch vollkommen egal.
SameValue

[Memnarch]

Kurze zusammenfassung(nicht das ich was vergesse und euch dan infos fehlen^^):

Berechnen der gesamtfläche das Dreiecks(wird nur einmal ausgeführt)

Berechnen der Fläche Teildreiecke PAB/PBC/PCA
Addition und vergleich mit der gesamtfläche

eine fläche wird so berechnet:

FlächePBC = |PXBY + BXCY + CXPY - PXCY - CXBY - BXPY|
Alle teile der formel wo KEIN p drin vorkommt, werden ebenfalls einmal vor begin der routine berechnet, da sie sich nicht ändern.
Alle teile mit PY werden nur neukalkuliert, wenn sich die YAchse ändert, alle PX teile werden jedesmal neu kalkuliert. Obige formel muss 3mal angewand werden, für jedes teildreieck einmal.

Ja ich berechne mehrere punkte pro dreieck. So ziemlich jeden pixel der drin ist(im schlimsten fall der ganze bildschirm von 512*512px)>.<
Viel schöner wäre es, wenn ich in chunks rechnen könnte. Also(vorausgesetzt es ist innerhalb des dreiecks), bei einem rechteck von 8*8 punkten, nur z.b eckpunkte so aufwendig kalkulieren und den rest simpler. Aber dass weiß ich nicht.

@Lemmy, kurz zum klarstellen: das was ich mache, mache ich aus selbstlernzwecken. Experimentieren erwünscht. Es ist zumindest EIn performancekiller. Die formel zur berechnung der flächen z.B habe ich wie oben beschrieben aufgesplittet damit sie nicht bei jedem zyklus voll ins gewicht fällt.

Zu den vekoroperationen muss ich mal googlen.

EDIT: ich hab vorher mit Integern gearbeitet, hatte zu Single gewechselt um zu gucken ob die CPU performance mässig dort anders arbeitet.

EDIT2: ich hatte auchmal die kalkulation des ZWertes rausgenommen(also obige problemformel), und der Performancegewinn war beträchtlich.

EDIT3: und nochwas zur größen ordnung: Der Renderer ist eine echtzeitapplikation. Ohne DepthTest ratert der auch bei gut 1000Polygonen noch gut mit 60FPS

MFG
Memnarch

[Lemmy]

Zitat von Memnarch:

@Lemmy, kurz zum klarstellen: das was ich mache, mache ich aus selbstlernzwecken. Experimentieren erwünscht. Es ist zumindest EIn performancekiller. Die formel zur berechnung der flächen z.B habe ich wie oben beschrieben aufgesplittet damit sie nicht bei jedem zyklus voll ins gewicht fällt.

Danke für die Klarstellung. Du solltest hier aber nun auch schon lange unterwegs sein um zu wissen, dass es da draußen jede Menge CopyPaster gibt, die alles kopieren

Grüße und viel Spaß beim experimentieren...

[Medium]

Warum musst du überhaupt die Z-Werte von Punkten auf den Dreiecksflächen berechnen? Der übliche Weg ist es, 3D-Weltkoordinaten erst in 2D-Bildschirmkoordinaten zu transformieren, und dann dadrauf die Flächenfarben zu interpolieren. Z fällt für die teuren pixelweisen Rechnungen dann ganz weg.

[Memnarch]

@Medium: Aber ohne ZWert kein ZBUFFERING. Das ist der Kasusknaktus. der Painteralgo ist nur bedingt einsetzbar, um richtiges ZBuffering kommste nicht drumherum wenn die Grafiken vernünftig dargestellt werden sollen.


MFG
Memnarch