[Blender] Dreiecke haben unterschiedliche Helligkeit in AO Map

Willkommen in der Transport Fever Community

Wir begrüßen euch in der Fan-Community zu den Spielen Transport Fever und Train Fever, den Wirtschaftssimulatoren von Urban Games. Die Community steht euch kostenlos zur Verfügung damit ihr euch über das Spiel austauschen und informieren könnt. Wir pflegen hier einen freundlichen und sachlichen Umgang untereinander und unser Team steht euch in allen Fragen gerne beiseite.

 

Die Registrierung und Nutzung ist selbstverständlich kostenlos.

 

Wir wünschen euch viel Spaß und hoffen auf rege Beteiligung.

Das Team der Transport-Fever Community


  • Servus,


    ich hab zum ersten Mal ein Modell komplett in Blender modelliert. Als ich fertig war mit strg+t alles in tris umgewandelt und dann exportiert.
    Die AO Map generiere ich mit xNormal. Komischerweise sind da auf ebenen Flächen die Tris in unterschiedlicher Helligkeit, ich verstehe nicht ganz woher das kommt.


    Hier noch ein Bild zur Veranschaulichung


    Gut zu erkennen ist das Problem vorne am Kessel. Weiß jemand wie ich das beheben kann?

  • Was xNormal nich alles kann oO Wie gehtn das? ^^ In Blender beim AO-Baking besteht das Problem, wenn mehrere Flächen auf die selben Texturbereiche gemapped wurden. Ich arbeite daher vermehrt mit Array- oder Mirror-Modifikatoren, das scheint er dann ganz gut hinzubekommen, dass nicht doppelt zu rendern. Diese Möglichkeit wird xNormal sicherlich fehlen, vermut ich mal. Also davon ausgehend, dass du dem Teil das Mesh als obj-Datei oder so zu fressen gibst.

  • Wenn du in Blender ein Objekt per Mirror-Modifier spiegelst, dann wird seine UV (seine Flächen) mMn dennoch nur EINMAL gerendert. Exportierst du das nun aber als obj-Datei, werden diese Modifier angewendet - sprich du hast das Mesh wirklich 2 mal und alle Flächen doppelt. Daher sollte man Modifier niemals zu früh anwenden bzw am besten garnicht. Man weis ja nie, wann man mal wieder weiterarbeiten muss. Stells dir als Projekt-Datei eines Zeichenprogramms vor: Dort hast du halt Ebenen die übereinander liegen. Unten die ist Rot, darüber eine Grüne. Speicher das Ding jetzt als Projekt-Datei* und du kannst jederzeit die Ebenen wieder nutzen um auch die roten Teile noch zu sehen. Speicherst du das aber als png bspw, dann werden alle Ebenen zusammen gerechnet und die Textur ist grün - die rote Ebene mit all ihren Informationen ist futsch ;)


    Genauso bei Blender. Als Projekt-Datei gespeichert hast du all die Modifikatoren noch drin, auch die nicht angewendeten. Dennoch behandelt Blender das Zeug erstmal so, als wäre das Resultat nicht wirklich gespiegelt oder verfielfältigt oder die Kanten nicht wirklich getrennt. Er zeigt es zwar an, aber es ist noch nicht so. Es ist quasi rein virtuell. Genauso wird er gespiegelte Objekte wohl auch nicht doppelt rendern -> dieser Überlappungs-Effekt bleibt dir erspart.


    Was man dazu anmerken muss: Will man am Ende ales zu einem Mesh zusammen joinen, muss man die Modifier wohl oder übel anwenden. Aber ganz ehrlich: Was schadet es denn, wenn in der children-Liste der mdl nen paar mehr Einträge drin sind und man die Meshes alle einzeln lässt? Was meint ihr, wieso meine Mods aus so vielen Einzel-Meshes bestehen? ^^




    *Zur "Projekt-Datei": Damit bezeichne ich immer das Dateiformat, das vom Programm mitgeliefert wird und eben alle Projekt-Daten noch beinhaltet, neben den reinen Daten des Ergebnis-Produkts. Also etwas konkreter gesprochen: Bei Blender .blend. Hier werden Render-Settings, die UI-Settings, die Modifikatoren und und und gespeichert. Bei paint.net die .pdn mit all den Ebene und Ebenen-Blend-Modi und weis der Geier. Bei Photoshop die .psd wo neben den Ebenen usw noch die Ebenen-Optionen mit all ihren Möglichkeiten drin sind (Schatten, Umrandung...). Linien sind Vektoren die man auch nachträglich noch ändern kann, Texte kann man ebenfalls immer wieder anpassen - das alles wird hier gespeichert, weshalb solche Projekt-Dateien eben deutlich größer ausfallen. Aber das nur zur Erklärung, was ich damit meine.


  • Also die roten Bereiche sind ein klares Zeichen für Triangulierungs- Fehler und die grünen Bereiche wirken er wie ein normaler Render mit AO aber nicht nach einer AO Map und sind meiner Meinung nach falsch gemappt.
    Weil das Mapping muss man sich ja wie ein Papiermodell vorstellen das noch auseinander gefaltet ist. Und bei den grünen Bereichen ist nichts auseinander gefaltet würde ich meinen. Hab jetzt nicht alles markiert aber das Mapping hat noch mehr Fehler meiner Meinung nach.
    Da ich aufer Arbeit bin und ich auch kein Blender nutze kann ich dir da auch leider nicht weiter helfen, aber da sind auf jeden Fall Fehler drin ob jetzt im Modell oder im Mapping kann ich nicht sagen und teilweise ist das Modell auch nicht fertig gemappt zb am Gestänge.

  • Das grüne sieht mir stark nach Project from View aus - und das auch noch perspektivisch >< Also sowas sollte man wenn schon orthographisch machen ;) War mir noch garnich aufgefallen. Aber auch bei orthografischer Projektion: Es gibt dann hier wieder Faces im Vordergrund und welche die dahinter gemapped sind (sofern man nich nur die sichtbare Seite mapped und die Rückseite seperat) -> kann zu diesen Überlappungsfehler führen. Bei dem AO Zeugs muss man höllisch aufpassen, dass die gemappten Flächen alle eigenen Raum auf der Textur haben. Man kann Glück haben, dass die Rückseite, die einen nich interessiert, zuerst gerendert wird und dann von der Vorderseite überschrieben wird, aber man sieht ja: Das klappt so gut wie nie überall.

  • vielen Dank für die zahlreichen Tipps.
    Es lag tatsächlich daran, dass duplizierte (mirror) objekte doppelt auf der selbe stelle das mapping hatten. Hab jetzt wie vorgeschlagen zwar den mirror modifier drauf gelegt aber nicht bestätigt und jetzt klappts.
    Dass meine UV map nicht optimal ist ist mir bewusst. Aber ich sehe einfach keinen Mehrwert kleinste Objekte komplett aufgeklappt zu mappen. Die werden ohnehin nur einfärbig angepinselt und die AO ist ingame m.M.n. nicht zu erkennen. Gemappt habe ich diese objekte mit project from view aus der orthographischen ansicht.

BlueBrixx