Verhalten der Brycesoftware beim Sichern großer Szenen
Wozu eigentlich die Beschäftigung mit Speicherzeiten gut ist:
Sicher ist einigen von Ihnen schon einmal aufgefallen, daß Bryce bei vielen größeren Szenen enorm lange zum Speichern der Daten braucht. Dabei fällt weiterhin auf, daß diese zusätzliche Speicherzeit überproportional schnell ansteigt, wenn erst einmal eine bestimmte Szenengröße erreicht wurde. Bei Szenen mit einigen Tausend Objekten schließlich, wird das Abspeichern oft zu einem zeitraubenden Prozeß, welcher Minuten bis Stunden in Anspruch nehmen kann. Lädt man hingegen die in vielen Minuten abgespeicherte Datei wieder ein, so geschieht dies meist in wenigen Sekunden – also in einem Bruchteil der Speicherzeit.
Es stellt sich daher die Frage, was Bryce da eigentlich solange abspeichert und in welchem Zusammenhang die Speicherzeit mit der Szenengröße steht. Letztendlich muß auch geklärt werden, ob die Struktur der Szene dabei eine Rolle spielt, und wie man sich evtl. Vorteile nutzbar machen kann.
Natürlich spielt das alles bei einer kleinen oder durchschnittlichen Szene keine besondere Rolle, daher richtet sich dieses Tutorial vor Allem an diejenigen, welche häufig mit sehr großen Szenen arbeiten. Ich selbst habe im Bryceform einige Szenen veröffentlicht, die ohne die im Folgenden erläuterten Erkenntnisse nicht machbar gewesen wären. Für die Szene Metropolis mußte ich beispielsweise noch im Bearbeitungsstatus vom Anfang 2000 eine Speicherzeit von über 4 Stunden (!) in Kauf nehmen; heute ist die Szene noch deutlich größer, aber trotzdem in wenigen Minuten gesichert….
Der folgende „Versuch“ soll das Problem der Speicherzeiten darstellen:
In eine leere Bryceszene wird ein Parametrischer Würfel gestellt und mit Hilfe der Duplizieren-Funktion kopiert. Die so entstandenen zwei Würfel werden abermals dupliziert, es entstehen vier Würfel. Dar Vorgang wird solange wiederholt, bis man 32 Würfel in der Szene hat. Diese werden nun gespeichert und die Dauer des Vorgangs wird mit Hilfe einer TSR-Software exakt gemessen. Anschließend dupliziert man die Würfel auf die Zahl 64 und wiederholt die Speichermessung. Das Duplizieren und Messen wird solange fortgesetzt, bis der Prozeß des Dublizierens unerträglich lange dauert und die Grenzen des Computersystems erreicht sind. Die folgende Meßreihe ist dabei herausgekommen:
|
Tafel Nr. 1
|
||
|
Zahl der Würfel*
|
Zeit für das Abspeichern:
|
 |
|
32
|
0,07 Sek.
|
|
|
64
|
0,26 Sek.
|
|
|
128
|
0,82 Sek.
|
|
|
256
|
3,45 Sek.
|
|
|
512
|
11,01 Sek.
|
|
|
1024
|
46,01 Sek.
|
|
|
2048
|
218,45 Sek.
|
|
|
4096
|
880,33 Sek.
|
|
*Sie können natürlich auch jedes andere Grundojekt von Bryce dazu benutzen!“
Es fällt schnell auf, daß es sich bei der dargestellten Funktion um eine nichtlineare Funktion mit einer überproportionalen Steigung handelt. Zum Abspeichern einer Szene mit 512 Objekten benötigt Bryce offensichtlich deutlich länger als für zwei Szenen à 256 Objekte.
Der Faktor zwischen den Speicherzeiten liegt im Mittel bei etwa 3,89, was verdächtig nahe an 4 liegt. Daher ist es naheliegend, von einer quadratischen Funktion auszugehen, die nun mit Hilfe einer polynomialen Regression mit dem Faktor ² untersucht werden soll. Das Ergebnis ist mehr als eindeutig:
|
Tafel Nr. 2
|
|
|
Quadratische Regression Aus der quadratischen Regressionsfunktion ergibt sich ein ungewöhnlich hohes Bestimmtheitsmaß von 99,99%, was die Vermutung einer quadratischen Entwicklung weiter bestätigt. Mit diesem Verhalten führt Bryce schließlich jeden schnellen Rechner an seine Grenzen – worauf ich noch eingehen werde. |
 |
Aus der Regressionsfunktion ergeben sich für noch größere Szenen gradezu dramatische Prognosen:
|
Tafel Nr. 3
|
|||
|
Zahl der Würfel:
|
Zeit für das Abspeichern:
|
Zahl der Würfel:
|
Zeit für das Abspeichern:
|
|
6000
|
30 min.
|
20000
|
5 Std. 32 min.
|
|
8000
|
53 min.
|
30000
|
12 Std. 30 min.
|
|
10000
|
1 Std. 23 min.
|
50000
|
1 Tag 11 Std.
|
|
12500
|
2 Std. 06 min.
|
100000
|
ca. 6 Tage
|
|
15000
|
3 Std. 08 min.
|
1000000
|
1,5 Jahre 😉
|
Obwohl diese Prognosen natürlich nur theoretische Werte sind und durch Speicher und Prozessorgeschwindigkeit andere Grenzen viel früher gesetzt werden, kann man den Daten jedoch gut nachvollziehbar entnehmen, daß die Zahl der parametrischen Szenenobjekte umso problematischer wird, je größer die Szene wird.
Ein Bißchen Mathematik zum Abschluß: Ableitungen der Speicherregression
|
f(x)=0,00005X²-0,0052X
|
f´(x)=0,0001X-0,0052
|
f´´(x)=0,0001
|
Da das 1. Differential einer Funktion bekanntlich ihre Steigung beschreibt, kann man auch schlußfolgern, daß bei komplexen Szenen die Einsparung einiger weniger Szenenobjekte recht große Effekte haben kann. Die „Grenzspeicherzeit“ für ein Objekt kann bei dem Testrechner in einer Szene von 5000 Objekten bereits mehr als 0,5 Sekunden betragen (f´(5000)=0,0001*5000-0,0052), bei einer Komplexen Szene mit z.B. 31245 parametrischen Objekten (mein Projekt Metropolis hat zum Zeitpunkt der Verfassung dieses Textes exakt diese Ausmaße) dauert das Abspeichern nur eines einzigen Objekts am Ende schon 3,12 Sekunden. Die komplette Szene auf dem Testrechner abzuspeichern würde etwa 13,5 Stunden in Anspruch nehmen.* Lasse ich eines der größeren Bauwerke mit ca. 950 Objekten weg, dann reduziert sich die Speicherzeit theoretisch schon um etwa 1 ganze Stunde!
* warum es eben keine 13,5 Stunden dauert, wird noch erläutert werden!