Buddhabrot

[Eichhoernchen]

Es ist noch kein fertiges Programm was ich euch hier Präsentieren möchte, es sind eher Codeschnipsel mit nem schnell gebastelten Programm zusammen!

Und zwar geht es um die Buddhabrotmenge...(nicht Butterbrot)

Es ist ein Fraktal(denke ich zumidest, ist ja schwer zu definieren)

Hier estmal ein paar Bilder wie das aussieht:
BILD1 (Gefärbt)
Bild2
Bild3
Bild4
Missglückter färbeversuch

Den Namen hat es wegen seiner Buddha ähnlichen Form.
Also ich finde das recht cool.

So erstmal zum Buddhabrot, es hat was mit der Mandelbrotmenge zu tun, wie man glaub ich sehen kann.

Und zwar ist die Buddhabrotmenge sowas wie eine Karte der Punkte C der Mandelbrotmenge die Divergieren(d.h. nicht zur Menge gehören).
Als erstes sucht man sich ein zufälliges C, danach lässt man dieses C den Mandelbrotmengen Algorithmus durchlaufen, wenn das C nach N Iterationen noch zur Menge gehört, wird ein neues C gesucht und von vorne gestartet, wenn das C aber nicht dazu gehört, wird die Iteration wiederholt, und alle Atraktoren, die Punkte die z anspring( z = z² + c) werden markiert, bzw. das array an dieser Stelle wird um 1 erhöht.

Leider entstehen erst brauchbare Bilder wenn man dies sehr oft tut. Bei ca 5 Millionen Iterationen des Hauptalgorithmus, also nicht von der Mandelbrotmenge entsteht ein brauchbares schwarz/weiß Bild. Wenn man jetzt noch gern ein farbiges Bild hätte benötigt man gleich 3 Arrays (r, g, b). Für farbige Bilder sind Fluchtiterationen(die Iterationen der Mandelbrotmenge) deutlich höher zu setzen als für schwarz/weiß Bilder. Bsp.: 10000 Fluchtiteratioen, wenn der Punkt C unter 100 Iterationen divergiert gehört er zum Rot teil der Menge und das Rot array wird erhöht. Wenn C unter 1000 und über 100 Iterationen divergiert gehört C zum Gelb teil und das Gelb array wird erhöht. Und das Blaue bei 10000 und > 1000.
Anschließend wird nur noch duch ein einfaches verfahren die arrays als r, g, b Teil eines Bildes dargestellt.

Für grobe Bilder wie Bild3 oder Bild2 kann man mit einer Rechenzeit von ca 10-20 Minuten rechnen(AMD 3000+) mit Bildern wie Bild 1 muss man schon mit 1,5 Stunden Rechenzeit rechnen. Und das Bild was ich zur Zeit berechne ist schon seit 3 Stunden am Rendern (und noch nichtmal uir hälfte fertig).

Naja ihr könnt euch ja mal den Code anschauen, ich habe noch andere Färbeversuche jetzt im Programm, diese sollten aber kein Problem sein wegzudenken!

[Eichhoernchen]

Zitat von paresy:

Wär cool, wenn du das Programm auf Multithreading/MultiCPU optimierst, damit ich meinen Dual Xeon 3Ghz mal vollständig auslasten kann

Grüße, paresy

Gern, wenn du mir sagt wie das geht^^

[shmia]

Die Trennung der Units QTypes und QMath macht softwaretechnisch keinen Sinn, da Datenstrukturen
(TComplex & TQuad) und Funktionen (die darauf angewendet werden) zusammengehören.
Ich würde alles in QMath packen.

[CADdy]

@dizzy:

ich wollte das Programm testen, bekomme aber beim Compilieren eine Fehlermeldung:

[Fataler Fehler] Unit1.pas(7): Datei nicht gefunden: 'GR32.dcu'

Was ist "GR32.dcu"? Ich hab Delphi 7 enterprise.

Servus
Peter

[turboPASCAL]

@CADdy GR32.dcu gehört zu einer Grafikkomponente für Delphi.
Such hier mal im Forum gr32 bzw. http://g32.org oder http://sourceforge.net/projects/graphics32

[Hador]

gehört zur Graphics32 Kompo

[CADdy]

danke für die hilfreichen Links!

Servus
Peter

[dizzy]

Zitat von shmia:

Die Trennung der Units QTypes und QMath macht softwaretechnisch keinen Sinn, da Datenstrukturen
(TComplex & TQuad) und Funktionen (die darauf angewendet werden) zusammengehören.
Ich würde alles in QMath packen.

Es machte in Verbindung mit meinem Parser, und mit meiner 2. nicht asm-optimierten QMath durchaus Sinn. Die beiden Files sind hier nur aus diesem Verbund heruasgerissen.

@Eichhoernchen: Das mit dem random hatte ich weniger der Geschwindigkeit wegen entfernt, als viel mehr um ein gleichmäßigeres Ergebnis zu erhalten. Gerastert finde ich hat man aber auch trotzdem schneller ein recht ansehnliches Bild imho.
Der Typ TComplex ist ein Record. Einfach deine Variablen "zr" und "zi" (z.B.) zusammengefasst. Das macht keinen Geschwindigkeitsvorteil, ich find's nur besser Werte die zu derselben Zahl gehören untern einen Hut zu packen - und nicht zuletzt erwartet die QMath ihre Parameter so, und die hatte ich nunmal schon fertig
Die Schreibweise ist zum größten Teil an den (halb-)(in-)offiziellen () Styleguide von Borland angelehnt, den ich in weiten Teilen für sinnvoll halte. Sicherlich ist es am Ende geschmackssache, nur in einem Betrieb nicht mehr wo mehrere Leute an einem Code arbeiten müssen... aber das Thema hatten wir hier schon ab und an mal, und es gibt mannigfaltig Meinungen dazu . Am Ende machts eh jeder wie er will ^^
Zu Punkt 5: Extrem teure Faulheit in diesem Fall

Gruss,
Fabian

[Ultimator]

@dizzy: Jetz hab ich so n schönes Bild gerendert und dann krieg ich DAS wenn ich speichern will:

Zitat:

---------------------------
Project1
---------------------------
TBitmap32 kann nicht zu TJPEGImage zugewiesen werden.
---------------------------
OK
---------------------------

[dizzy]

Um das Speichern hab ich mich null gekümmert... Wollte nur den Algo an sich optimieren.

[Eichhoernchen]

Soo, ich hab auch nochmal nen bisschen was gemacht,
man brauch hierfür keine weiteren Units oder sonstwas geht alles mit dem Standart zeug.

Und dank der Verbesserungen die ihr hier gepostet habt nun auch einiges schneller!

Hab ne kleine Render funktion eingebaut, sodass man vielleicht mal nen Desktophintergrund machen kann!

Alles nur auf die schnelle hab heute viel zu tun...

Ihr könnt ja mit der Programmversion auch mal vergleichen, den Unterschied zwischen random und den Bildschirm abgehen, random ist schöner