Beim Bau des Dampfmaschinenmodells «Danni» von Modellbau Bengs hatte ich die Tradition ins Leben gerufen, von meinen physischen Modellen auch eine virtuelle Ausgabe zu erstellen, eine Interaktive 3D Animation. Dies habe ich beim Flammenfresser «Jarne» fortgesetzt.
Eigentlich habe ich beide Projekte, den Bau des physischen Modells und den «Bau» des virtuellen Modells, weitgehend parallel vorangetrieben. Wobei es unvermeidlich war, dass zu jedem Zeitpunkt das eine Projekt dem jeweils anderen geringfügig voraus war oder nachhinkte. Da ich mich gegen Ende des Baus des physischen Modells kurzfristig für eine kleine (aber feine 😎) Änderung der Konstruktion entschieden hatte, und die benötigten Teile erst bestellt und geliefert werden mussten und wir zwischenzeitlich zwei Wochen in Ferien waren, hat der «Rohbau» der 3D Animation von Jarne während eines Regentags in unserer Unterkunft als erster die Ziellinie überschritten. Rohbau deswegen, weil ich gerne noch Details wie eine animierte Flamme und einen sichtbaren Ausstoss abgekühlten Gases aus dem Auslassventil nachrüsten würde, dies aber eine Lernkurve in Sachen Partikelsysteme und möglicherweise Shader-Programmierung beinhalten wird. Etwas für längere Schlechtwetterperioden.
Genug der Vorrede: hier geht’s zur ➜
Interaktiven 3D Flammenfresser Animation
Statistik und mögliche Performance Optimierung:
Ich habe die Animation entsprechend der lt. Bausatz vorgegebenen Baureihenfolge nachgebaut. Die hohe Anzahl von Einzelteilen von «Jarne» und meine hohen Qualitätsansprüche an die Rundheit und Glattheit von Konturen haben ihren Preis. Das Modell erfordert pro Frame die Verarbeitung von
- 102 «calls« und rund
- 240’000 triangles.
Auf die (wahlweise) Darstellung von Schraubenköpfen und Muttern habe ich bisher verzichtet, um auf meiner Hardware (iMac 5k 2014, Macbook Air 2017, iPhone 13) weiterhin volle 60 fps zu erzielen, was derzeit auf allen drei Geräten schon grenzwertig ist, zumindest im eingezoomten Zustand.
Potenzial sehe ich insbesondere in der Zusammenfassung mehrerer unbewegter Bauteile gleichen Materials in eine «Super-Geometrie» mittels mergeGeometries – dies würde die Anzahl von GPU-calls signifikant verringern.
Und dann habe ich bisher allen rotationssymmetrischen Bauteilen (LatheGeometry) eine sehr hohe Umfangs-Segment Anzahl von 72 gegönnt. Eine Reduktion würde sich massiv auf die Anzahl von Dreiecksflächen auswirken, bei vermutlich nur geringer Qualitätseinbusse an Rundheit der Konturen.
Auch das ist ein Optimierungsprojekt für lange Schlechtwetterperioden. Daher, wie die angelsächsischen Kollegen sagen würden: don’t hold your breath …