schnelstmöglich dividieren?

[Medium]

Uhlala, nen vollwertiger Z-Puffer in Software ist allerdings happig du. Da kenne ich, als "üblich" Sortierung nach Dreiecksschwerpunkt-Z und Front-to-Back Rendering mit einfachem Stencil. Man kann natürlich Fälle bekommen (bzw. mutwillig erzeugen ), bei denen dann mal was komisch wird (das ein oder andere Loch ggf.), aber die Ersparnis in der Verarbeitungszeit ist doch gewaltig dann - verglichen mit dem gerigen Umfang an "glitches" den man sich einhandelt vor allem.
Bei Front-to-Back muss man so allerdings Transparenz etwas spezieller behandeln. Es kann die Sache aber dennoch sehr wert sein finde ich.

Nichtsdestotrotz ließe sich volles Z-Buffering mit o.g. Scanlinemethode wie vorgeschlagen schneller erledigen als mit baryzentrischen bzw. trilinearen Koordinaten, wenn es denn unbedingt sein muss =)

[Memnarch]

Ich nutze FrontToBack rendering + Groben TopLevel ZBuffer + PerPixelZbuffer.

Der grobe Buffer Speichert von einem dreieck an den stellen immer nur den Größt möglichen ZWert des dreiecks, so können andere dreiecken deren kleinster ZWert darunter liegt an diesen stellen gleich verworfen, und der ZWert nicht erst interpoliert werden .
Indem ich Die dreiecke in Quadrate unterteile, die die ganz Im Dreieck sind(immer 8*8 pixel), können anhand des ZWerts des quadrats diese stellen vom dreieck halt komplett verworfen werden, was bei meinen scenerien doch schon nen guten schub bietet.(Als Drahtgitter render war gut zu sehen, wie die Gitter anderer objecte hinter vorderen verschwanden, hatte mal zum debuggen nachgeguckt)

Bild ist immoment 512*512 PX groß, die Optimale füllgeschwindigkeit erlaubt im Moment ca 30FPS(GouradShading)

[blackfin]

Eventuell könnte dir vielleicht auch, je nach Komplexität und Polygonanzahl, die Technik des Span-Buffers weiterhelfen...

[Namenloser]

Zunächst mal gucken, ob es bestimmte Werte gibt, die fest sind oder nicht jedes mal neu berechnet werden, wie Jumpy in #4 gesagt hat.

Ansonsten könnte auch SSE interessant sein. Die 128Bit breiten Register von SSE bestehen, wenn ich es richtig verstanden habe, aus 4 32Bit breiten Unterregistern, sind also quasi ein Vierer-Vektor. Operationen werden dann immer für alle Register ausgeführt.

Deine 3 Ergebnisse kannst du ja als Dreier-Vektor auffassen. Was du aktuell machst ist ja folgendes:

Delphi-Quellcode:

Ergebnis[1] := (A*X1 + B*Y1 + C*Z1) div Wert;
Ergebnis[2] := (A*X2 + B*Y2 + C*Z2) div Wert;
Ergebnis[3] := (A*X3 + B*Y3 + C*Z3) div Wert;

Mit SSE könntest du (A*X1 + B*Y1 + C*Z1), (A*X2 + B*Y2 + C*Z2) und (A*X3 + B*Y3 + C*Z3) in einen Vektor packen, und dann alle Divisionen in einem Rutsch ausführen!

Ich habe aber selbst noch nicht mit SSE gearbeitet, daher kann ich es nur oberflächlich beschreiben...

[Medium]

Das heisst, dass dein Wert 7.864.320 op/s für die Ermittlung der Z-Koords nur ein Worst-Case ist gell? Das aber nur am Rande. Nach wie vor bin ich überzeugt, dass diese dual-lineare Interpolation schneller wäre als trilinear (was du jetzt machst).

Ich hatte vor einiger Zeit auch mal einen Artikel zu heaven7 gelesen. Dort wurde mit Hilfe eines Octrees entschieden, ob Punkte tatsächlich getraced werden müssen, oder ob die Szene in dem bereich so simpel ausfällt, dass Interpolation im Screenspace von bereits berechneten Pixeln ausreicht. Das ist zwar ein Raytracer, aber ggf. dennoch eine möglicher weiterverwurstbarer Ansatz zur Optimierung.

Der Span-Buffer ist interessant, riecht aber nach mächtig Overhead. Mag sowas nicht, wenn die Effizienz einer Optimierung je nach Datenlage zur Verschlechterung mutieren könnte

[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

[Bjoerk]

Bist Du Dir mit den 7864320 /s sicher?

Mit Intel Core 2 Q6600 2,4 GHz 2,4 Ghz 250-300 ms (laut GetTickCount).

Delphi-Quellcode:

function J: integer;
begin
  Result:= Random(10000)+1;
end;


procedure TForm1.Button11Click(Sender: TObject);
const
  N = 7864320;
var
  T: cardinal;
  Ergebnis1, Ergebnis2, Ergebnis3,
  Wert,
  A, B, C,
  X1, Y1, Z1,
  X2, Y2, Z2,
  X3, Y3, Z3: integer;
  I: integer;
  S: double;
begin
  A:= J;
  B:= J;
  C:= J;
  X1:= J;
  X2:= J;
  X3:= J;
  Y1:= J;
  Y2:= J;
  Y3:= J;
  Z1:= J;
  Z2:= J;
  Z3:= J;
  Wert:= J;
  S:=0;
  T:= GetTickCount;
  for I:= 1 to N do
  begin
    Ergebnis1:= (A*X1 + B*Y1 + C*Z1) div Wert;
    Ergebnis2:= (A*X2 + B*Y2 + C*Z2) div Wert;
    Ergebnis3:= (A*X3 + B*Y3 + C*Z3) div Wert;
    S:= S+Ergebnis1+Ergebnis2+Ergebnis3; // damit die CodeOptimierung ..
  end;
  ShowMessage (IntToStr(GetTickCount-T));
  ShowMessage (FloatToStr(S)); // .. nicht zuschlägt
end;


procedure TForm1.FormCreate(Sender: TObject);
begin
  Randomize;
end;

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

[Amateurprofi]

@Memnarch:

Ich hab das mal mit der FPU versucht, aber die Ergebnisse sind, gelinde gesagt, ernüchternd (etwa doppelte Rechenzeit vs. simplem Delphi-Code).
Sorry.
Ich hab auch über SSE3 nachgedacht, aber keinen vernünftigen Ansatz gefunden.