rocken lassen
Ich habe mir da etwas überlegt. Hier kann man es sich ansehen:
http://beyerk.magix.net/alle-alben/!/oa/7544734/
Danke Dir, musi, das ist ja prima!
Na dann: Viel Spaß beim Ansehen Allerseits!
Pete befasst sich ja mit deinem Problem. Bei seiner Antwort frage ich mich, was du da kompliziertes gemacht hast. Seht euch die Antwort mal an:
Ich habe das Kontrabass-Objekt in AoI mit dem PME entwickelt und es nie in ein Trimesh umgewandelt, weil es hieß, dass PME dies automatisch für das Rendering macht.
Man soll ein PolyMesh nicht in ein Triangle Mesh umwandeln - soviel ist richtig, aber PolyMesh erzeugt nicht "automatisch ein TriangleMesh". Stattdessen können alle renderbaren Objekttypen (PolyMesh, TriangleMesh, SplineMesh, Cube, Sphere, Cylinder...) ein RenderingMesh erzeugen, das aus Dreiecken besteht. Je mehr das Netz geglättet wird, desto mehr Dreiecke gibt es. Rendering-Dreiecke haben eine Menge Eigenschaften, die die Modellgeometrie nicht braucht.
Um die Sache noch komplizierter zu machen, können die Rendering-Meshes auf unterschiedliche Weise für die interaktive Verwendung (während der Modellierungszeit) und das Raytracing-Rendering von Bildern erzeugt werden:
Primitive Objekte verwenden Rendering-Meshes nur während der Modellierung. Für das Raytracing-Rendering verwenden sie Raytracing-Primitive (z.B. RTSphere), so dass sie mit der exakt richtigen mathematischen Oberfläche anstelle von Dreiecken gerendert werden.
PolyMesh hat einen mehrstufigen Prozess für das Raytracing-Rendering. Zunächst wird aus der Geometrie ein "QuadMesh" erzeugt, das dann in das endgültige RenderingMesh unterteilt wird.
Und jetzt kommen wir dem Problem schon näher.
Die Ursache scheint hier eine Kombination aus (und das kann man nicht so einfach sagen) schlechter Modellqualität und einer Stelle im QuadMesh-Code zu sein, die damit nicht ganz umgehen kann. Einige der Kanten der Problemobjekte sehen für mich sehr unordentlich aus und manchmal konnte ich nicht sagen, welche Kante mit welcher verbunden ist. Es scheint kollabierte und schlecht verdrehte Polygone zu geben, die wahrscheinlich irgendwo im Prozess eine mathematisch unmögliche Situation schaffen. Ich habe das getestet, indem ich die faltigen Bereiche von einigen der verschwindenden Objekte abgeschnitten habe, und sie begannen im Rendering zu erscheinen. -- Es fehlte natürlich nur ein Stück.
Das beigefügte Bild zeigt das erste Objekt. Ich habe den gleichen Schnitt an beiden Ecken vorgenommen, und die Falten erschienen auf dem Rendering.
Im QM-Code erscheint der Fehler jedes Mal in der gleichen Zeile, 1191. Dort wird eine Funktion previousVertex() (oder so ähnlich) direkt in der Zeile aufgerufen und das Ergebnis als Index an ein Array gesendet -- und in diesen Fällen ist der Index -1, was ein unmöglicher Wert für einen Array-Index ist. Noch merkwürdiger ist, dass es immer "-1 von 4001" zu sein scheint. Das sieht so aus, als ob es ziemlich detaillierte Nachforschungen erfordern würde, aber die Lösung könnte letztendlich ziemlich einfach sein.
*** Übersetzt mit http://www.DeepL.com/Translator (kostenlose Version) ***
Hochgeladene Dateien:
- Du musst dich anmelden um auf Uploads zugreifen zu können.
Hochnäsigkeit (siehe obere Posts #177-179) kommt vor dem Fall (siehe obigen Sourceforgekommentar von Pete; danke fürs Übersetzen, musi!):
Es ist interessant, dass Pete die entstandenen Probleme auf die unsauber modellierten Bereiche im Mesh zurückführt, von denen es ja tatsächlich genügend gibt. Denn alle Teile, die vor Ausschalten der Glättung nicht renderbar waren, enthalten diese unsauberen Meshbereiche!
Jetzt rächt sich also meine Faulheit, das Mesh vorab nicht bereinigt an Dich übergeben zu haben, musi, ab dem Moment, wo ich mich gezwungen sah, das Mesh weiter zu bearbeiten, um meine Pläne realisieren zu können.
Bin gespannt, ob es den tollen Codern bei Sourceforge gelingt, entweder AoI dazu zu bewegen, auch derartig verworrenes Zeug renderbar zu bekommen, oder ob stattdessen eine Warnung aufploppt, dass das Mesh unrenderbare Verwerfungen enthält, die erst behoben werden müssen.
Da wäre cool: Ein Skript oder eine andere Programmergänzung, das/die automatisch eine korrekt darstellende polygonreduzierte Hülle des wirren Bereiches entwickelt und austauschend eingliedert! Könnte jede Menge Arbeit nicht nur für newbies erleichtern. Aber da träume ich besser weiter.
Eben fällt mir die Geschichte vom Tresen wieder ein, die ich hier auch schon zum Besten gegeben habe (Post #69 dieses Threads). Da ging es um noch schlimmer ungültige Bereiche, die nicht einmal im Hauptbildschirm mehr dargestellt werden konnten ...
So relativieren sich also meine ins pedantische neigende "Genauigkeit" und die Diskussion über zu treibenden Aufwand aus einer völlig anderen Richtung, als der Beurteilung durch die Zuschauer: Die würden mangels Aufwand schon erst mal garnix zu sehen bekommen. Und die Eingeschworenen und mathematisch Genauen plagen sich schließlich damit herum, dass es da einer nicht besser konnte, oder wesentlich schlimmer noch: nicht wollte oder will, weil 's ja auch so schließlich zum Funzen zu bringen war.
Man kann den Fehler auch darin sehen, dass unsaubere Modellierung gar nicht möglich sein sollte.
Aber den Kontrabass habe ich ja in meiner Soloversion zum Schluss auch zerlegt. Da war alles in Ordnung.
Hochgeladene Dateien:
- Du musst dich anmelden um auf Uploads zugreifen zu können.
Tja, Du hattest zum Einen größere Stücke, in denen die Trennlinien weitestgehend durch "sauberes Terrain" verliefen. Daher waren die unsauber modellierten Stellen, in denen sich die Geometrien der Vielecke gegenüber dem ursprünglichen Modell auch nicht änderten, so gut wie nicht betroffen. Zum Anderen hast Du an den Teilen wahrscheinlich nicht viel mehr 'rumgebastelt, als eben das Ausgangsmesh zu zerteilen.
Bei mir gingen die Teilungsschnitte aber vielfach genau durch die stark verwurschtelten Bereiche des ursprünglichen Meshes, wie Randkanten und F-Loch"aussparungen". Ich habe das damals beim Modellieren schlicht weitestgehend ignoriert, war einfach nur froh den Baßcorpus überhaupt einigermaßen "echt" und detailreich mit meinen damaligen Modellierfähigkeiten hinbekommen zu haben.
Vielleicht kamen zur Ausbildung der Problembasis auch noch unvollständige Löschungen überflüssiger Geometrien in den unübersichtlichen Bereichen dazu (die vereinzelten Punkte von denen Pete spricht). Ich hatte ja den Baß buchstäblich für jedes Stück der ersten Bruchphase einmal im Urzustand kopiert und dann jeweils erst mal das weggelöscht, was für den gewünschten "Bruchteil" nicht benötigt wurde. Das geschah so, um die gekeyte Position des "Vorgängers" nicht zu verlieren, damit die Stücke rein optisch auch nach dem Trennvorgang genau zusammenpassen konnten (eine Erfahrung von der Modellierung des Plakatrisses aus der 1. Sequenz).
Zudem wurden die einzelnen einfachen Netzstücke von mir nachträglich zu neuen Vollkörpern aufgedoppelt/extrudiert, damit sie nicht so durchscheinend wären, wie das bei dem Plakatschnipsel der 1. Sequenz der Fall und als "feuchtes Seidenpapier"-Effekt gerade noch hinnehmbar gewesen war. Hierbei entstanden dann schon die ersten Artefakte, wie sie in Petes Transparentansicht als hellblaue Dreiecke ohne begrenzende Geometrie zu erkennen sind, die ich aber auch nur durch Punktverlagerungen im ungeglätteten Zustand des Polymeshes und Umstellen der Glättungswerte einzelner Kanten beseitigt bekam. Im (vergrößerten) Render wären sie als unschöne Eintiefungen oder Ausstülpungen der Oberfläche erschienen ( was Pete als eine Art fraktaler Ausblühungen nach Meshumwandlung beschreibt).
Manche weitere ähnliche Artefakte kamen erst, nachdem ich diese neu entstandenen Vollkörper (teils mit dem Messerwerkzeug des PME, teils über Nahtbildung und -öffnung) erneut zerlegt und die dadurch entstandenen offenen Ränderpunkte neu verbunden hatte. Das war für die unterschiedlichen Stufen des Zusammenbruchs notwendig geworden: Zunächst lösen sich ja durch die "harten Aufschläge des Rodeorittes" nach und nach nur die Klebenähte der Seitenflächen vom Baßcorpus, dann erst bersten Decke und Boden, sozusagen in einer zweiten Stufe der Zerstörung. Denn auch, wenn man es in meiner fertigen Animation nicht mehr wirklich erkennen kann, "brechen" Decke und Boden des Basses tatsächlich jeweils erst, wenn Woodys "Pobacken" bzw. die Kanten des Bühnenaufbaus sie unmittelbar berühren bzw. aufgrund der einwirkenden kinetischen Energie durchdringen würden.
Das dürfte aber bei Deiner eher explosionsartigen Baßzerstückelung alles von vornherein keine Rolle gespielt haben.
Wenn ich Petes Ausführungen richtig verstanden habe, kommt es bei dieser Problemstellung auf den Grad der Mesh"verkrumpelung" an: Wie bei einer feinen Waagschale kann AoI dann zunächst gerade noch damit umgehen, gleich darauf, bei der nächsten "mathematischen Unmöglichkeit", aber eben schon nicht mehr. Es tritt dabei also kein Programmfehler im eigentlichen Wortsinn auf, sondern der Vorgang spielt sich - jedenfalls Petes hoch differenzierender Analyse nach - sozusagen im Milieu mathematischer Toleranzgewährungen des Programms ab. Starke Erkenntnis!
Nun ist es tatsächlich schon Wirklichkeit:
Pete hat etwas im Code der PolyMesh.jar verbessert und schon kann dieses Problem nicht mehr auftreten!
Danke Pete, für mich bist Du ein Zauberer!
Die Verbesserung kommt sicher mit der nächsten AoI Version in den Skripte- und Erweiterungsmanager.
Wer aber das Ganze gern jetzt schon gegen seine alte PolyMesh.jar tauschen will, kann sich die verbesserte PolyMesh.jar hier aus Petes 4. Posting im Thread herunterladen und von Hand im Plugins Ordner seiner AoI Installation gegen die alte Version tauschen.
Aber das Ganze scheint dennoch ein größeres Ding zu sein, auf das ich da durch den Zufall meiner teils recht "wurschteligen" Arbeit bei der Erstellung des Kontrabasses sehr nachträglich erst "durchgestoßen" bin. Pete und Luke S. sitzen nämlich noch weiterhin über der Aufarbeitung davon. Vielleicht läuft es ja tatsächlich noch darauf hinaus, dass mit der späteren Version des PME dann gar keine mathematisch ungültige Struktur mehr erzeugt werden kann, wie Du es oben ja schon annonciert hattest, musi.
Jetzt kann 's für mich "einfacheres (= ziemlich unmathematisches) Gemüt" aber jedenfalls wieder weitergehen mit unserer Verfilmung.
Dafür habe ich die beiden anderen Musikanten Violeta und Spiros nun erst mal vereinzelt. Die Testrender können dadurch nämlich dann etwas schneller berechnet werden. Und es besteht so auch geringere Gefahr, irgendetwas mühsälig Hingepfriemeltes ungewollt zu demolieren.
Bei genauerem Überdenken der To-Do-Liste wurde allerdings dann doch noch eine kleine Plankorrektur nötig:
Da Violeta ja sowohl mit Woody als auch mit Spiros in ihren Stellungen und Aktionen korrespondieren wird, ist es nötig, zumindest ihre Positionierungen als Nächstes festzulegen, denn sonst kann Spiros zu den Punkten, an denen er mit Violeta Kontakt nehmen soll, die Tasten nicht mehr richtig bearbeiten. Immerhin soll Violeta ja an Spiros "herumturnen". Und wir erinnern uns: Der erste Schritt bei einer neuen Animation ist immer die möglichst korrekte Einrichtung der Spuren "Position" und "Orientierung"! Bei Spiros klappt das aber nur in Verbindung mit den Grundlagen zu Violetas Aktionen, eben wenigstens deren Positionen.
Unter Freunden: Wer hat bloß wieder solch eine Schnapsidee gehabt? 🙂
- Du musst dich anmelden um auf Uploads zugreifen zu können.
Na wer wohl.
Pete und Luke haben ja zu dem aufgetretenen Problem einen regen Dialog. Ich kann es Luke nachfühlen, wie es so ist, in einem fremden Programm Bugs zu suchen. Auch wenn das Programm noch so gut strukturiert und kommentiert ist. Da kann ich ihn nur bewundern.
Deine beiden nächsten Musikanten machen es dir aber auch nicht gerade leicht. 🙁
