Fractal-Visualisierung in Delphi

[everdream]

Hallo,

ich möchte eine kleine Visualisierung für Fractale (bzw. zum Testen erstmal für die Mandelbrotmenge) entwickeln. Die Berechnungen hab ich alle schon. Ich brauche nur noch etwas, um meine Ergebnisse schnellstmöglich darzustellen.

Für alle, die jetzt nicht wissen was ich eigentlich mache:

• entweder kurz bei wiki nachlesen: Link zum Artikel "Mandelbrotmenge"
• oder, wenn euch das zu lang ist, folgende Situation:
  Ich habe für jeden Pixel einen Integerwert, der in eine Farbe umgerechnet und angezeigt werden soll.

Mit Canvas Pixel für Pixel zeichnen ist allerdings recht langsam, vor allem, wenn man bei höheren Auflösungen bildschirmfüllend anzeigen will.

Ich vermute, dass DirectX oder OpenGL meine Ansprechpartner sind. Wenn ich da richtig liege, könnte mir jemand einige Informationen dazu zukommen lassen?

Vielen Dank schonmal im Voraus!

lg, Max!

P.S.: Ich weiß, "gibts schon", aber ich hab halt Spaß dran :love:

[Muetze1]

Wie malst du bisher "pixelweise"? Nutzt du die Eigenschaft Pixels[] des Canvas oder schon ein OffScreenBitmap und dessen ScanLine[] Eigenschaft? Wenn ersteres, dann suche nach letzterem hier im Forum. Wenn letzteres, dann zeig mal den Code...

[everdream]

Bis jetzt male ich Pixel für Pixel mit Pen.color und canas.moveto/canvas.lineto.
werde mich mal nachder OffScreenBitmap erkundigen.

Habe mir orgestellt am ende einen flüssigen Zoom ins bild zu haben, wäre das damit möglich?


edit: Zu "OffScreenBitmap" find' ich irgendwie nich so viel. Meinst du damit einfach TBitmap?

[rawsoul]

Ich denke, dass er das meint, ja. Ein OffScreenBitmap wäre meiner Meinung nach ein TBitmap, welches nicht auf dem Bildschirm, sondern nur im Speicher existiert.

Der Zoom damit wäre nicht möglich, zumindest nicht flüssig. Ein Pixel ist ein Pixel.

[everdream]

nja, aber das ganze soll ja angezeigt werden,... im speicher bringts mir nix (ich weiß, bitmaps kann man ja auch anzeigen lassen)

ist das vllt mit DirectX oder OpenGL einfacher? or allem der zoom?

[rawsoul]

Bei DX bzw. OGL wirst du auch Pixel bemalen müssen, kommt also so ziemlich aufs gleiche raus. Du könntest jedoch eine - sagen wir mal 100px * 100px Darstellungsfläche setzen, jedoch ein gestretchtes (StretchBlt), oder verkleinertes Bitmap mit viel größeren Dimensionen darstellen.

Natürlich kannst du das OffScreenBitmap später darstellen, wenn du es fertig gezeichnet hast (TImage.Picture.Bitmap.Assign(TBitmap), ich glaube sogar, mit TImage.Assign(TBitmap) geht es auch). Oder bestehst du darauf, den Zeichenprozess beobachten zu können?

[everdream]

Nee, ich muss da nicht zugucken können.
Mir wäre auch recht, dass er im Voraus schonmal die Berechnungen für x-frames durchführt, bevor er startet, aber es muss ja möglich sein so einen Zoom hinzubekommen.

Müsste ich dann erstmal x bitmaps erstellen und die dann einfach alle zeigen lassen? das wäre sehr speicheraufwändig!
Das muss doch irgendwie anders gehen!

[rawsoul]

Wenn das so ist, dann nutze doch das zeichnen im OffScreenBitmap.

Ein verkleinertes Bild ist ja nicht mehr als ein (großes) Bild, bei welchem nicht alle Pixel dargestellt werden. Also berechne ein großes und stelle beim Zoomen den Skalierungsfaktor hoch. Der Benutzer kann dann selbst hineinzoomen.

[everdream]

ich hab ja schon ne lösung, bei der der user selbst zoomt, das ganze passiert halt auch noch mit canvas usw....
screenshots kann man da aber auch schon machen (ein screenshot vom 1600x1600 ist allerdings 10MB groß)

alles noch weit weg von perfektion!

das soll ja selber zoomen, darum gehts ja. sonst bräuchte ich auch nich (viel) schneller zeichnen....

[Muetze1]

Was machst du hier eigentlich für ein Aufstand? Eine Frage, vieles wird angenommen und alles ist schon wieder zu langsam. Also mal der Reihe nach...

1. OffScreenBitmap ist ein Bitmap welches du anlegst und zum malen nutzt. Dadurch erzeugst du das Bild einmalig nach einer Änderung und kannst dieses dann bei jedem Malen einfach auf die Form malen.
2. Nutzung von TImage ist von Nachteil. Selbst wenn nur ein kleier Teil neugezeichnet werden muss, wird das komplette TImage gemalt. Damit wird das Flackern gefördert und es verlangsamt den Zeichenprozeß.
3. Fülle das TBitmap über die ScanLine Property und du hast eine grundlegend hohe Geschwindigkeit.
4. Male das OffScreenBitmap direkt auf die Form. Nutze dabei die Eigenschaft ClipRect des TCanvas und male nur den markierten Bereich (also das Rechteck welches die Überschneidung zwischen ClipRect und deinem Bitmap darstellt). Dies kannst du einfach lösen mit [mdsn]IntersectRect()[/msdn] und BitBlt()
5. Zoom - wie stellst du dir das vor? Wenn du ein Bild berechnest, dann wirst du die schnellste und grafisch beste Darstellung bekommen, wenn du das Bild passend zu der dargestellten Bildauflösung berechnest. Wenn du nun hinein zoomen willst, dann geschieht das mathematisch mit Änderung deiner Formelparameter. Dadurch werden andere Pixeldaten errechnet und somit entsteht ein neues Bild und dieses zeigt dann einen bidlichen Zoom dar. Ein berechneter Pixel mit einem Farbwert kann nur als Rechteck/Quadrat gezoomt werden und somit wird aus einem roten Pixel gezoomt ein rotes Rechteck - dein zoom ist ein rein mathematisches Problem. verständlich?
6. Ein Screenshot unkomprimiert sind 10 MB an Daten - klar. Wenn du es komprimierst (z.B. PiNG), dann wird es weniger - also nicht immer TBitmap nutzen um was abzuspeichern.
7. Du kannst mit einem Thread im Hintergrund die Daten feiner rechnen. Das Problem beim vorberechnen von Bilddaten für den Zoom: wohin zoomt der Nutzer? man kann ja schliesslich oben links zoomen oder unten rechts ...

Schon allein wegen deinen Fragen und ein paar Dingen bezüglich Zoom, etc. eine Frage von mir: Kennst du fractint? Schonmal mit gearbeitet bzw. Zoom, Formelparameter etc?

[everdream]

1.-3. OK
4. Werd ich mir ansehen, kann mir aber grade nich vorstellen wie du das meinst.

5.: Jau, da liegt ja mein Problem: Zu jedem neuen Frame müssen erst alle Pixel neu berechnet werden. D.h. ich muss für jeden Frame die Bitmap komplett überprüfen und jeden Pixel, der sich verändert hat (was meißtens sehr viele sind) neu "malen". Die Parameter in der Berechnung hab ich dafür auch schon variabel eingestellt (wie gesagt, es gibt schon ne version, bei der der user manuel zoomen und sich auf dem bild bewegen kann)
6.: Joa, das stimmt auf jeden fall. ich denk drüber nach.
7.: dachte erstmal an einen zufälligen/om programm gesteuerten zoom.

Kennst du fractint? nein...

[Muetze1]

Zitat:

Zitat von everdream

5.: Jau, da liegt ja mein Problem: Zu jedem neuen Frame müssen erst alle Pixel neu berechnet werden. D.h. ich muss für jeden Frame die Bitmap komplett überprüfen und jeden Pixel, der sich verändert hat (was meißtens sehr viele sind) neu "malen". Die Parameter in der Berechnung hab ich dafür auch schon variabel eingestellt (wie gesagt, es gibt schon ne version, bei der der user manuel zoomen und sich auf dem bild bewegen kann)

Wenn gezoomt wird, dann sind doch zu 98%-100% alle Pixel neu zu berechnen. Und das musst du doch so oder so machen - wie willst du sonst wissen, ob der Pixel eine neue Farbe hat? Du brauchst schliesslich einen Vergleichswert.

Und aus deiner Erklärung könnte man vermuten, dass du die Pixel berechnest und dann erstmal vergleichst, ob der Pixel sich geändert hat. Das ist doch egal und kostet nur mehr Zeit - einfach Pixel berechnen und auf das OffScreenBitmap malen - egal ob geändert oder nicht.

Zitat:

Zitat von everdream

Kennst du fractint? nein...

Naja, zu den guten DOS Zeiten war das ein wirklich gutes Programm für Fraktale und es war Open Source. Die Formeln und Parameter sind schön dargestellt, etc. Es ist immernoch gut verfügbar, z.B. hier. Du kannst die DOS Version soweit auch noch unter 32 Bit Windows < Vista nutzen.

Schnelleinstieg fractint:

- ENTF/DEL: Auflösung wählen. Auch virtuelle Auflösungen für reine Bildberechnungen möglich.
- t - wählt die Formel bzw. den Fraktaltypen

auf dem generierten Fraktal dann folgende:

- Bild Hoch/Page Up/Bild runter/Page Down um ein Zoomrechteck zu positionieren
- Cursortasten beim Zoomrechteck zur Positionierung (mit ALT &/| STRG zusätzlich gehts schneller, unproportionaler Zoom, etc)

um das Zoomrechteck zu bestätigen und dessen Inhalt auf dem Screen berechnen zu lassen: ENTER

[Namenloser]

Hi.
Guck dir mal Graphics32 an. Die sind verdammt schnell.

[Nuclear-Ping]

Ich hab sowas ähnliches mal angefangen zu machen. Allerdings keine Mandelbrot-Menge oder so, sondern ein "Müller Fraktal" aus dem "Global Scaling". Die grafische Darstellung hab ich in OpenGL gemacht. Ist aber noch total unoptimiert, unfertig und langsam. Aber die Ausgabe, um das Prinzip zu vermitteln, funktioniert schonmal.

Wenn du Interesse hast, kann ich dir den Source geben.

[edit]
[OT]
LoL :lol: NamenLozer, hab mir grad nochmal den Beitrag aus deinem ">O<" Link in deiner Sig durchgelesen. Mußte wieder herzlich lachen ... Was waren das für Zeiten. :mrgreen:
[/OT]
[/edit]

[turboPASCAL]

Da hab ich doch mal was Vorbereitetgehabt. :mrgreen:

TheMandelbrötchen

[Kroko1999]

Zitat:

Zitat von NamenLozer

Hi.
Guck dir mal Graphics32 an. Die sind verdammt schnell.

Lohnt sich nicht wirklich, habe ich neulich erst ausprobiert mit
PixelFormat := pf24Bit und Scanline bist Du genauso schnell.

[everdream]

erstmal: Nen Vergleich, ob der Pixel sich verändert hat oder nicht, hab ich in meinem aktuellen Programm nicht drin.

Hm, also wenn ich jetzt alles noch etwas optimiere, mit Scanline usw. arbeite und die OffScreenBitmap dann komprimiert speichere, dann müsste ich einfach x-frames im voraus berechnen und dann mit meinen vielen einzelbildern ne art diashow starten, nur halt schneller, um nen mehr oder weniger flüssigen zoom zu erzeugen. fractint ist ja leider auch nicht bedeutend schneller.

Sowas muss man doch irgendwie hinkriegen.

[Kroko1999]

Zitat:

Zitat von everdream

erstmal: Nen Vergleich, ob der Pixel sich verändert hat oder nicht, hab ich in meinem aktuellen Programm nicht drin.

Der dürfte imho auch wenig bringen, erst testen und dann setzen, dann kannst auch gleich setzen :!:

Zitat:

Hm, also wenn ich jetzt alles noch etwas optimiere, mit Scanline usw. arbeite und die OffScreenBitmap dann komprimiert speichere, dann müsste ich einfach x-frames im voraus berechnen und dann mit meinen vielen einzelbildern ne art diashow starten, nur halt schneller, um nen mehr oder weniger flüssigen zoom zu erzeugen.

Gute Idee, sollte machbar sein, aber warum komprimieren :?:

Zitat:

fractint ist ja leider auch nicht bedeutend schneller.

Ich glaube, da irrst Du wirklich, mach doch mal ein paar Tests!

Zitat:

Sowas muss man doch irgendwie hinkriegen.

Ob das wirklich live (CPU-Speed) ist :?:

[Muetze1]

Zitat:

Zitat von Kroko1999

Lohnt sich nicht wirklich, habe ich neulich erst ausprobiert mit PixelFormat := pf24Bit und Scanline bist Du genauso schnell.

Na dann setz dich gleich nochmal ran und ändere es ab auf pf32Bit, das sollte nochmal ein klein wenig schneller sein, da jeder Pixel an einer gerade Adresse liegt und der Prozessor somit keine zwei Schreibzyklen drehen muss.

Zitat:

Zitat von everdream

die OffScreenBitmap dann komprimiert speichere

So war das nicht gemeint. Du sollst abgespeicherte Screenshots bzw. berechnete Bilder komprimiert ablegen. Die berechneten Bilder können ruhig ein paar MB gross sein und sollen das auch bleiben, weil nur so kann man sie schnell malen. Sonst müsste er jedesmal zum einen komprimieren und beim zeichnen dekomprimieren. Grundsätzlich: wenn es um die Laufzeitbilder geht, dann lass sie unkomprimiert. Was stören dich vllt. 100 MB bei Bilddaten? Die brauchst du aktiv und so gesehen sind 100 MB nicht viel. Ich habe Anwendungen die mit riesigen Datenmengen umgehen und die kommen auf 600 MB Speicherverbrauch etc. Somit mach dir keine Sorge, 2 GB sind dir von Windows zugesichert...

[calculon]

Zitat:

Zitat von Kroko1999

Ob das wirklich live (CPU-Speed) ist

Das bezweifle ich auch stark. Für so eine Qualität muss mit gängigen Rechnern für jedes Bild 'n ganzes Weilchen gerechnet werden. Ich schätze mal da lief der Rechner schon mindestens 'ne Nacht durch...

PS: Auch sehr cool...

[rawsoul]

Bei dem Youtube-Filmchen steht die Renderzeit: 96 Stündchen.

[everdream]

von mir aus kann das auch gaaaaaaanz langsam gehen. dann kann ich vllt die selben pixeldaten über mehrere frames nutzen...

wie gesagt, bei mir musses ja auch nicht echtzeit sein.

hm, habe da aber grade ne ganz andere idee... wie wärs denn, wenn der user von hand reinzoomt, dann kann mit der mittelpunktkoordinate als "fixpunkt" ein video erstellen,... das müsste doch besser funktionieren, als einen "live zoom" zu berechnen,... das video sollte dann später auch ohne probleme flüssig laufen.
damit kenne ich mich aber leider garniicht aus -.-'

Zitat:

Bei dem Youtube-Filmchen steht die Renderzeit: 96 Stündchen.

macht ja nix ^_^

[everdream]

Also: Wenn ich jezz ne vergleichbare Renderzeit akzeptiere, dann kann ich ja frame für frame berechnen... is ja nur parameterveränderung.

Aber: Wie krieg ich das dann in eine Videodatei?

[everdream]

Okay, ich habe mich jetzt mal ein bischen mit BMP2AVI "eingearbeitet".

Jetzt habe ich noch 2 Aufgaben:

• Die Farben etwas harmonischer zu gestalten und
• dann die Berechnung noch zu optimieren

Zu den Farben hatte ich folgenden Ansatz:
Da man gelegentlich einen "ungünstigen" Pixel erwischt, sticht dieser dann farblich sehr stark hervor.
Ich hatte also überlegt, den Pixel nochmal in 4 Teile zu teilen und für jeden Teilpixel die Anzahl der Iterationen zu berechnen. Der Endgültige Pixelwert wäre dann der Mittelwert dieser 4 Zahlen.
Das bedeutet natürlich, dass ich 4 mal so viel Rechenleistung für den gleichen Bildausschnitt benötige.

Zur konkreten Farbberechnung hatte ich folgenden Ansatz:

Delphi-Quellcode:

var iterationen: integer; //Anzahl der Iterationen für diesen Bildpunkt
    r, g, b: byte; //Farben rot, grün, blau
case iterationen of
  0..255: begin
    r:=0;
    g:=255;
    b:=iterationen;
  end;
  256..512: begin
    r:=0;
    g:=512-iterationen;
    b:=255;
  end;
{...}
end;

So werden alle mehr oder weniger wichtigen Farben durchlaufen, je näher man ranzoomt.

Zur optimierung komme ich, wenn die Farbgebung stimmt. Das Auge programmiert hier schließlich mit ^.^

[everdream]

edit: sry, die datenbank wollte nicht, wie ich wollte...

[Khabarakh]

[OT]

Zitat:

Zitat von Kroko1999

Ob das wirklich live (CPU-Speed) ist :?:

Schaut euch einmal XaoS an, dessen Echtzeit-Zoom ist wirklich unglaublich.
[/OT]

[everdream]

Zitat:

Zitat von Khabarakh

Schaut euch einmal XaoS an, dessen Echtzeit-Zoom ist wirklich unglaublich.

Das ist echt nicht schlecht... Aber ich möchte höhere Auflösung und mehr Details, da nehme ich die Rechenzeiten auch in Kauf...

Das hier ist mein aktueller Code für die Iterationen. Habe das ganze schon um eine Variable und eine Zuweisung erleichtert.
Kann man da noch was mit Assambler rausholen? Jeder Takt zählt ^.^

Delphi-Quellcode:

procedure TMandelbrotSet.DrawSet(var Image: TImage);
var
  Pxl_x, Pxl_y: integer;
  dx, dy: double;
  RealC, ImagC: double;
  x0, x1, y1: double;
  Iterations: integer;
begin
  dx:=Range_X / Image.width;
  dy:=Range_y / Image.height;

  for Pxl_x:=0 to Image.width-1 do
  begin
    for Pxl_y:=0 to Image.width-1 do
    begin
      RealC:=(Center_x - 0.5 * Range_x) + (Pxl_x * dx);
      ImagC:=(Center_y - 0.5 * Range_y) + (Pxl_y * dy);

      Iterations:=0;
      x0:=0;
      y1:=0;

      repeat
        x1:=(x0*x0) - (y1*y1) + RealC;
        y1:=(2*x0*y1) + ImagC;
        x0:=x1;
        Inc(Iterations);
      until ( (iterations >= MaxIterations) or (((x1*x1) + (y1*y1)) >= MaxValue) );

      if (iterations=MaxIterations) then
        Image.Canvas.Pen.Color:=clBlack
      else
        Image.Canvas.Pen.Color:=ChooseColor(Iterations);
      Image.Canvas.MoveTo(Pxl_x,Pxl_y);
      Image.Canvas.LineTo(Pxl_x+1,Pxl_y);
    end;
  end;
end;

[Kroko1999]

(a) statt Image Bitmap nehmen und zum Schluß ins Image kopieren
(b) Scanline verwenden, statt moveto und lineto (pixel[c,y] := color hätte es auch getan)!

[everdream]

Danke für die Tipps!

Die Prozedur ist nur zum Anzeigen auf der Form. Habe nochmal fast die Gleiche, nur, dass die halt das ganze auf na Bitmap macht und die dann speichert, statt sie anzuzeigen.

Momentan geht es mir daraum die reine Berechnung der Iterationen zu optimieren. Werde deine Vorschläge einbringen (d.h. Scanline muss ich nochmal gucken, wie genau die funzt).

[Der Jan]

Hallo,

hab vor paar Jahren auch mal so ein Programm "verbrochen". :) Ich hänge es einfach mal an, anstatt einen eigenen Thread aufzumachen. Vielleicht kannst du dir ja noch ein paar Anregungen holen. Ist eigentlich auch recht schnell, vor allem, wenn man die Effekte ausschaltet.
Falls ich den Sourcecode noch finden sollte, werde ich ihn auch noch posten, müßte eigentlich aug irgendeiner alten CD rumliegen.
Im Archiv sind auch ein paar "Projekte" enthalten, die geladen werden können.