Wow, das war lustig: ich habe quasi erst ein Mini-Tut Video mit völlig unkorrigierten und unvorbereiteten Materialien aufgenommen um Dein Rostbeispiel nachzuzeichnen, dann den Ton extrahiert und durch aTrain gejagt (ein Speech-2-Text-Tool, das lokal läuft und somit auch Datenschutz-gerecht arbeitet, da keine Daten hin und her geschickt werden.).
Ist aber trotz des umfangreichen Datensatzes auch in Deutsch nicht wirklich 100% zuverlässig, und ein unvorbereiteter Text wie dieser ist, äh, sehr "nachbearbeitungswürdig". Hätte ich auch gleich tippen können
Ich hoffe, Du verstehst trotzdem was ich sagen will ^^
Zu deiner Annahme, die irrig sei, wenn du eine Textur bäckst:
Normalerweise, wenn man eine Textur im Sinne von einer Bitmap bäckt, dann sollten sie so aussehen wie das Original.
In deinem Fall hast du zwei Dinge "erwischt", die das ganze erschweren. Und zwar hast Du einmal mit dem Rost ein
3D-Material genommen. Das ist keine Textur, sondern zieht sich durchs "Innere" eines Objektes, es wird in allen 3 Texturkoordinaten, also U, V und W berechnet. Wenn Du in die Einstellungen vom Rost gehst und zum einen die beiden Schieberegler für das Blau und das Rot ziemlich nah zusammenschiebst und zum anderen einen relativ hohen Kontrast vorgibst, indem Du die Frequenz zum Beispiel auf 0,2 einstellst, sodass große rote Flecken entstehen, wirst Du das sehen. Nun unter Menü => Rendern den "Interaktiven Renderbereich" aktivieren - im Editorfenster werden die prozeduralen Shader wie der Rost und andere Noise-basierte sonst kaum korrekt dargestellt - und ein Rechteck um Deinen Quader ziehen. Dann sollte auffallen, dass einige rote Flecken "um die Ecke" gehen. Würde man an der Stelle etwas heraus-boolen, fällt auf, dass sich der Rost "innen" weiterzieht.
Normale Texturen sind jedoch Bilder. Auch das, was gebacken wird, sind letztlich ja nur 2D-Bitmaps. Das kann keine 3D-Eigenschaften enthalten, die in die Tiefe gehen. Da kollidiert das Backen dann anscheinend mit den 3D Fähigkeiten des Shaders. Ähnliches würde z.B. mit dem Holz/Wood Shader passieren. Auch hier gehen die Jahreringe korrekt durch das Objekt, und sobald man etwas wegschneidet, tauchen die entsprechend auf. Beim Backen würde das vermutlich wieder schief gehen.
Natürlich sollte Cinema dazu in der Lage sein, das korrekt zu backen. Vllt. geht das auch, aber, ehrlich - ich würde lieber dafür gute Bitmaps erstellen und die für einen Echtzeit-Export nutzen, egal ob gebacken oder nicht, und habe dann die Kontrolle.
Das Baking Tool kann aus einem 2. Grund Deine Anfrage nicht leisten:
Du hast einen Generator genommen, ein Würfel-Grundobjekt, und das ist leider auch in der R2025 anscheinend intern immer noch falsch mit UV-Polygonen beklebt.
Stell dir vor, Du möchtest diesen Würfel auf allen sechs Seiten mit den Augen eines Spielwürfel bekleben - das würdest Du mit dem normalen Grundobjekt-Würfel im UV-Modus nicht hinbekommen. Diese Grundobjekte haben alle eine internen UV-Map und die sieht beim Würfel so aus, dass alle sechs Seiten, die UV-Polygone aller sechs Seiten exakt übereinander liegen. Wenn du jetzt ein beliebiges Material im UV-Modus da drauf klebst auf den Würfel, sind alle sechs Seiten gleich beklebt. Eigentlich sollte man mit der Texturprojektion Quader das ganze hinbekommen (das geht auch) und dann ein neues UV-Tag erzeugen. Aber genau
das geht dann wieder nicht, ohne das Grundobjekt zu konvertieren.
Das kann man in deinem Vorschaubild ganz gut sehen. Wenn man auf das linke Bild mit dem gebackenen Material schaut, kann man sehen, dass du einen PNG bekommen hast, "TexturFarbe-5.PNG". In Deinem Screenshot siehst Du, dass an drei Seiten diese Textur, wenn auch natürlich teils gestreckt, überall die gleiche ist. Es wird also nur ein Bild berechnet, weil der Würfel eben auch nur sechsmal das gleiche UV-Polygon übereinander liegen hat, statt nebeneinander, und dieses eine Bild findet sich dann auf allen 6 Seiten wieder.
Du brauchst bei den exportierten Sachen wie GLB und GLTF und so zwingend korrekte UV-Maps. UV-Mapping ist ein ziemlich eigenes und sehr umfangreiches Thema, aber als Beispiel, man müsste den Würfel in ein Polygonobjekt konvertieren, dann ins UV-Layout gehen und die nun sichtbar übereinander liegenden sechs UV-Polygone neben und übereinander sortieren. Die UV Ma bzw. die Anordnung der UV-Polygone ist im UV-Tag gespeichert, das nach der Konvertierung sichtbar wird.
Übrigens sind wir auch jetzt gerade im Bodypaint-Bereich ^^ Das "normal" UV-Unwrapping ist jedenfalls ein Teil davon.
Stell dir vor, Du hast sechs quadratische Blätter und Du legst 2x drei nebeneinander und die beiden Reihen untereinander. Das ist die Anordnung der UV-Polygone (eine mögliche - Hauptsache, alle 6 UV-Polygone liegen neben und nicht übereinander, und das möglichst platzsparend), und einmal soll es Deine Textur werden, auf dem die Pixel genauso angeordnet sind. In einer Bildbearbeitung zeichnest Du eine unterschiedliche Anzahl von Augen für den Würfel auf jede dieser 6 Seiten. Im Fall der Textur sind es gedachte 6 Seiten, man sieht die Polygone da nicht. Oder blendet sie aus, wenn man einen Screenshot dafür erzeugt hat (geht auch in BP in Cinema). Dann kannst du tatsächlich
einfach diese Textur, so wie sie ist, per UV auf das Objekt beppen. Also ein Material damit erstellen und auf den o.g., konvertierten und "ge-unwrapp-ten" Würfel mit neuer UV-Map, legen.
In dem Fall des konvertierten Grundobjektes, dessen UVs Du neu angeordnet hast, würdest Du evtl. auch mit dem 3D Shader eine andere Rostmap bekommen, die eben auch mal alle sechs Seiten verrostet zeigt. Ob
die tatsächlich sehr viel besser und korrekt ist, weiß ich nicht, möchte ich aber grad nicht ausprobieren
Und Houdini ist meine Messlatte für den Umgang mit diesem tollen Stoff, aus dem die Simulationen sind ^^
