[3D Art] Rubik's Triple

Hellstorm

Minima de malis
ID: 110419
L
11 August 2006
293
43
Mal wieder ein neuer Versuch, mich an Blender heranzuwagen.

Damit nicht gleich die erste Szene in die Hose geht, hab ich mich für nen Rubik's Würfel entschieden.

Modelliert ist das Ganze logischerweise in Blender 2.55 beta und gerendert mit Luxrender.

Für die einzelnen Flächen hab ich meinen Zauberwürfel eingescannt und draus dann mehrere Farb- und Bump-Texturen erstellt.

Halt noch nen schönes HDRI für den Hintergrund+3 Flächenlichter.
Und dann das ganze rendern lassen. 12 Stunden auf 6/8 Threads eines i7 860.

 
Wow das sieht echt geil aus.
Aber die original Rubiks Cubes sind zwar geil und das Geld echt wert.
Aber nen richtiger Speedcube echt viel viel besser.
ich habs nicht geglaubt, bis selber mal einen in den Händen hatte.
Echt krasser unterschied.
Die Gehen viel geschmeidiger und haben extrem geiles Cornercutting.
Kann ich nur empfehlen.
 
Damit nicht gleich die erste Szene in die Hose geht, hab ich mich für nen Rubik's Würfel entschieden.

Modelliert ist das Ganze logischerweise in Blender 2.55 beta und gerendert mit Luxrender.
Schick, schick, hat funktioniert ;)
Mal wieder ein neuer Versuch, mich an Blender heranzuwagen.
Wieso tust du dir das an? :mrgreen:
Der Workflow muss doch ziemlich frustrierend sein, wenn man woanders bereits Routine hat. Gerade beim shortcutlastigen blender. Von einigen Bugs und fehlenden Features mal ganz zu schweigen.
Allein der Patch von 2.49b auf 2.50a hat mich bestimmt nen halbes Jahr zurückgeworfen, davon hab ich es nach den ersten Tagen etwa drei Monate aus Frust nicht angefasst :mrgreen:
 
Halt noch nen schönes HDRI für den Hintergrund+3 Flächenlichter.
Und dann das ganze rendern lassen. 12 Stunden auf 6/8 Threads eines i7 860.

Ich habe zwar 0 Ahnung davon aber mal ne Frage, hat das Rendern des Bildes in 1900pixel beim I7 Prozessor 12 Std. gedauert?? oder wie darf man das verstehen?
 
Jop. Hat 12 Stunden gedauert. Wobei "Dauer" es hier aber nicht ganz trifft.
Theoretisch hab ich auch nach 1 Minute schon ein Ergebnis. Das Bild wird bei Luxrender sukzessive "verbessert". Zu beginn hat man dabei ein extrem verrauschtes Bild und bei doppelter Renderdauer halbiert sich das Rauschen.
Sprich: Nach 1 Minute: viel Rauschen, nach 2 Minuten nur noch halb soviel rauschen, nach 4 Minuten hat sich das rauschen wieder halbiert, dann nach 8, dann 16, 32, etwa 1h...

Man kann also sagen, dass man auch nach 3 oder 6 Stunden schon ein gutes Ergebnis haben kann, hängt aber immer von der Beleuchtung und vielen anderen Sachen ab. Aber im allgemeinen gilt halt: Je länger man es backen lässt, desto besser wird das Ergebnis.
 
Je länger man es backen lässt, desto besser wird das Ergebnis.
Algorithmische Frage:
Hast du dann abgebrochen oder gibt es einen Zustand, wo das Bild "fertig" ist, d.h. sich auch durch weitere Berechnung kein einziges Pixel mehr ändern wird?
 
Algorithmische Antwort: Wenn ich eine Zahl immer halbiere (in dem Fall das Rauschen), wird sie dann irgendwann 0 erreichen?

Genauso ist es beim rendern. Das Bild wird sich wohl immer weiter verbessern, jedoch irgendwann visuell kein Unterschied mehr zu erkennen sein (oder die 32bit pro Kanal reichen für ne differenzierung nicht mehr aus).

Generell kann man aber sagen, dass man den Rendervorgang in der Regel immer irgendwo zwischen 1000 und 2000 Samples pro Pixel abbrechen kann.
Bei geeigneten Shadern und Beleuchtung evtl. sogar schon nach 100 Samples pro Pixel.

Es gibt da zig Einstellmöglichkeiten, den Sampling-Algorithmus anzupassen. Zum einen auf Ebene der Sampling Pattern (Metropolis, ERPT, Zufall oder Niederige Diskrepanz), als auch auf der Render-Ebene (Path-Tracing, Bi-Directional Path Tracing, Distributed Path-Tracing, ...).

Was am schnellsten geht oder am besten geeignet ist, muss man immer von der Szene und Lichtbedingung abhängig machen. Aber irgendwann wird das Auge so oder so keinen Unterschied mehr wahrnehmen können.
 
Algorithmische Antwort: Wenn ich eine Zahl immer halbiere (in dem Fall das Rauschen), wird sie dann irgendwann 0 erreichen?
Ja klar, das is mir schon klar.

Es hätte aber ja auch sein können, dass ab einem bestimmten Zeitpunkt das Verfahren in einen Schwingzustand geht und somit nie zu einer absoluten Lösung konvergiert.

Genauso ist es beim rendern. Das Bild wird sich wohl immer weiter verbessern, jedoch irgendwann visuell kein Unterschied mehr zu erkennen sein (oder die 32bit pro Kanal reichen für ne differenzierung nicht mehr aus).
Die zweite Sache, die du mir aber damit schon beantwortet hast, ob das Programm selbstständig sich beendet, wenn es erkennt, dass im Rahmen der Genauigkeit keine Änderung mehr erfolgt.

Klar, mathematisch kannst du bis in alle Ewigkeiten rechnen, aber du gibst die Bildauflösung ja vor dem Start fest an, d.h. damit is das Pixel als kleinste Einheit gewählt (maximal "Subpixel", wenn man sagt, dass pro Kanal noch 256 Abstufungen drin sind, die man erkennen kann). Alles, was drunter is, ändert effektiv das Bild nicht mehr und du kannst danach aufhören.

Is ja genauso, wenn du Pi mit nem Float-Datentyp berechnest. Hast 3,14159265, is Schluss, mehr kannst du nicht rausholen.
Aber irgendwann wird das Auge so oder so keinen Unterschied mehr wahrnehmen können.
... und das Auge steigt sogar vorher schon aus, selbst wenn sich noch was am Bild ändert.
 
Man könnte sicherlich ne Art Frame-Delta einbauen, aber die meisten dieser Renderer begnügen sich als Stopp-Kriterium mit Renderzeit oder Samples pro Pixel. Das Problem beim Delta ist, dass es lokal einige Pixel geben kann, an denen per Zufall nen recht intensiver "Pfad zum Licht" gefunden wird. Sind das nur ein oder zwei Pixel und der Rest ändert sich nicht, wäre evtl. das Delta erreicht aber man hat nen störendes zu helles Pixel. Somit hätte man keine ideale Lösung.
Der Metropolis-Sampler würde dem Pfad nachgehen und somit wieder die Pixel irgendwann in ne vernünftige Farbe bringen. Deswegen werden wohl die Renderer dieser Art sowas nicht integriert haben, da es wohl recht kompliziert ist, per Algorithmus das perfekte Bild zu finden - das überlässt man lieber dem Menschen :D