schnelstmöglich dividieren?

[himitsu]

Welche Werte haben denn die ganzen Variablen so im Durchschnitt, bzw. sind einige davor "fest"?
Eventuell kann man ja die Berechnung selber verändern

[Memnarch]

Das ganze ist wie folgt:

Obiges ist ein MinimalTeil eines Softwarerasterizers den ich geschrieben habe, nämlich die Finale kalkulation der Farbwerte eines Bildpunktes. Dazu müssen die Farbwerte der 3 Vertices interpoliert werden.

Wenn ich ein dreieck ABC habe, und einen Punkt P der dadrin liegt, muss ich die Farbwerte für P ermitteln. Nehmen wir als beispiel den rotkanal:

Alle 3 Vertices haben einen Rotwert, diese 3 Vertices haben aber an verschiedenen punkten einen stärkeren/schwächeren einfluss. Je näher P an einem Vertex ist, desto stärker ist dessen Farbanteil, ansonsten schwächer.

Kalkuliert wird so:

Ich berechne für Vertex A das Dreieck PBC, für B das Dreieck PCA, für C das dreieck PAB. Und dann noch die fläche von ABC. Wenn ich nun eine der vorherigen flächen durch die Fläche ABC teile, bekomme ich den Faktor.

Also z.B PBC/ABC = Factor von Rotwert des Vertex A.

Was ihr am anfang gelesen habt war also:

Rotwert := (FlächeA*RotA + FlächeB*RotB + FlächeC*RotC) div Gesamtfläche; Wie bereits zu sehen ist ist die kalkulierung des Faktors so rausgekürtzt dass ich pro Farbwert nur einmal dividiere.

Da gabs auch noch was mit Linearer Interpolation übers dreieck(da kann ich die Formel durch kleine additionen ersetzen), aber da bekommt man Floatwerte raus, und die muss ich erst truncaten und dann komm ich zum selben ergebnis >.<.

In dem C++ Rasterizer von dem ich gelernt habe, wurden FixedKommaZahlen verwendet, das war glaub ich um besser von Komma nach Integer zahlen zu kommen. Leider absolut keine Ahnung wie ich das in Delphi umsetzen sollte, da hatte ich ein Paar probleme v.v

MFG
Memnarch

[Sir Rufo]

FixedKomma ist der DatenTyp Currency (der arbeitet intern als Int64)

[Memnarch]

Nur bei Currency bin ich mir icht sicher wie das ergebnis ausschaut. Wenn es sich um einen 64bit integer handelt, wie schnell kann der im vergleich zu einem 32bit integer kalkuliert werden?(P4 hier muhaha^^).

Und den bekomm ich dann z.B per bitshift in einen Integer oder übernimmt das Delphi hier für mich?
Erstmal testen wie schnell das mit dem datentypen hier geht o.O.( er braucht ja immerhin doppelt soviel an registerplatz wie "normale" integer)


MFG
Memnarch

[himitsu]

Int64-Divisionen und Multiplicationen sind sehr langsam, da sie über mehrere 32-Bit Operationen in den 32-Bit-Registern emuliert werden.

siehe Unit System:

Delphi-Quellcode:

{ 64-bit Integer helper routines }
procedure __llmul;
procedure __lldiv;
procedure __lludiv;
procedure __llmod;
procedure __llmulo;
procedure __lldivo;
procedure __llmodo;
procedure __llumod;
procedure __llshl;
procedure __llushr;

Currency wird aber als ein Befehl über die FPU behandelt, wie die normalen Float-Typen auch.
Wenn man Currency nach Int64 castet, dann steht im Int64 natürlich ein 10000 mal größerer Wert drin, wie im Currency.
Leider kann man soeinen "krumen" Wert (auch Sicht des Zweierkomplements) nicht weg-shiften und so "schnell" abrunden.

Eventuell könnte man über die MMX-Register da noch Einiges machen wie z.B. mehrere Berechnungen gleichzeitig durchführen.

[Memnarch]

Mit MMX hab ich zwar mal angefangen, aber nicht alles gefunden was ich brauchte. Ich habe es dann gelassen.

Soll ja für sowas wie geschaffen sein, da ich eine formel 3 mal hintereinander ausführe.
Hatte aber irgendwo seinerzeit probleme damit, ka mehr wo.

Aber am ende muss truncated werden und hier ist einfach alles futsch. da geht garnichts. wenn ich truncate kann ich auch gleich DIV benutzen, es gab da keinen nennenswerten unterschied.


MFG
Memnarch

[Medium]

Um die Division bzw. alternativ non-integers wirst du vermutlich kaum herum kommen. Eventuell findest du hier (letzte Kategorie) noch ein paar hilfreiche Anregungen.

Eine Idee hätte ich noch: Weg mit den baryzentrischen Koords, und her mit einer Scanline. Dann könnte man "von oben nach unten" durch gehen, und hätte pro Y-Koordinate pro Dreieck zwei lineare Interpolationen, plus einer weiteren für jeden Pixel. Dazu das Bildchen im Anhang. p0 und p1 müssten ja nur je ein mal pro Scanline pro Dreieick ermittelt werden (hat man Adjazentsinfos, kann man benachbarte Strecken gleich weiter benutzen und müsste bis auf beim ersten Mal sogar nur eine Strecke neu interpolieren), und pro Pixel muss dann nur noch zwischen den p0 und p1 linear interpoliert werden.

[Amateurprofi]

@Memnarch:

Ich würde ja ganz gern mal versuchen eine flinke Funktion zu schreiben, aber leider kann ich deinen Beiträgen nicht entnehmen, welche Variablen-Typen du verwendest.
Also sag mal :
a) Sind das Bytes oder Words oder ... ?
b) Welche minimalen und maximalen Werte können die Variablen A, B, C, x, Y, Z, x2, Y2, Z2, x3, Y3 und Z3 annehmen ?
c) Falls du z.B. Int64 Variablen nimmst, der größte vorkommende Wert aber in ein Word paßt, könntest du dann auf "kleinere" Typen ausweichen ?

[Memnarch]

@AmateurProfi: Flächen ABC und Gesamt sind Integer, in diesem Beispiel waren die XYZ variablen die Farben also Bytes.

Bei den flächen kann ich schlecht auf kleinere größen ausweichen. 512*512/2 liegt soweit ich weiß über Shortint.

Whops glaube ich hab mich verschrieben Pro BildAufbau werden 786432 DIVs für die FARBEN gebraucht.
ZWert ist natürlich imo "nur" 262144 pro bildaufbau(eben pro pixel)

Obige DIV werte sind darauf ausgerechnet dass 2 Triangles so vor der Camera hocken, das jeder Pixel bedeckt ist und somit kalkuliert werden muss.

Aber vllt könnte ich pro 8*8 PixelZelle eines dreiecks die 4 ecken wie oben kalkulieren und im Quadrat anders(linear?) interpolieren.....ah mist muss eh wieder truncated werden >.<



MFG
Memnarch

[Medium]

Noch ein Stichwort frei in die Runde geschmissen: Multithreading
Bringt bei einem P4 wohl nicht die Welt, nur bei aktuellen Quadcores mit HT wär das sicherlich nett.