spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Genau sowas habe ich als Master-Projekt gemacht, das nennt man Texture Atlasing.
Google doch mal im Zusammenhang mit Blender, da findet sich sicher etwas. Meine Implementierung war für 3ds max.

Zitat von »Muhk«

Ist es überhaupt notwendig so penibel mit den Textur-Ressourcen umzugehen?

Man sollte im Allgemeinen so wenige Texturwechsel wie möglich anstreben (bzw. so wenige Draw Calls wie möglich). Also ist das schon gut, dass du daran denkst. In diesem Fall geht es auch nicht auf die Kosten der CPU, wie das bei anderen Verfahren der Fall ist, die ebenfalls die Anzahl der Draw Calls zu reduzieren versuchen (z.B. Occlusion Culling).

Blender hat äußerst mächtige Baking-Tools. Du würdest dir also ein neues UV-Layout für dein komplettes Modell erstellen, und kannst dann aus beliebig vielen Texturen eine neue Textur generieren lassen.

Das schöne ist, dass du auch gleich Ambient-Occlusion Maps generieren kannst. Oder Normal-Maps. Und so weiter. Ich habe damit auch mal statische Schatten für eine Spielumgebung berechnet und in die Textur "gebaked", was mit wenig Aufwand sehr nette Ergebnisse geliefert hat.

Solche Lücken entstehen oft, wenn dein Mesh nicht gut verbunden ist, sondern quasi nur eine lose Sammlung von Faces ist, die keine gleichen Eckpunkte teilen.

Sind das hier überhaupt noch Texturatlaten? Ich dachte, unter einem Atlas versteht man einfach mehrere Texturen unverändert zu einer neuen zusammen zu fassen, und dann die Texturkoordinaten des Modells zu ändern. Hier erstellst du ja keine "Collage" sondern generierst eine komplett neue Textur.

Das das Modell so viele Lücken hat, liegt eben an deinem UV-Layout. Vielleicht hast du es automatisch generiert, du kannst aber auch eines per Hand erstellen, du hast also im Grunde alle Freiheiten der Welt. Theoretisch sollte man sogar gleich texturierte Stellen im Modell auch im UV-Layout übereinander legen können, mit ein bisschen Glück funktioniert (oder eher Finetuning) das baken dann immer noch vernünftig und du hast keine doppelt gespeicherten Stellen mehr.

Andererseits: Wenn du viele Häuser rendern willst, die sich alle die gleichen Grund-Texturen teilen, kannst du natürlich auch nach Material sortiert rendern. Sagen wir du hast 10 verschiedene Texturen (Holz, Stein, usw.) und renderst jedesmal alle Objektteile, die diese benutzen, hast du insgesamt auch nur sehr wenig Texturwechsel, kannst aber trotzdem hochauflösende und gekachelte Texturen benutzen.

Aber am sinnvollsten wäre es hier vermutlich, nochmal das UV-Layout fürs Baken zu ändern. Da ist ja mindestens die Hälfte der Pixel schwarz, mit einem optimierten Layout könntest du also ohne Mehrkosten die doppelte Qualität erreichen. Vielleicht reich das dann ja schon.

<Klugscheisser>Korrekt heißt es Atlanten</Klugscheisser>
Bei einem einfachen Bakingvorgang sollte es nicht ohne weiteres möglich sein mehrere Teile vom Modell über den gleichen Bereich der Textur zu legen. Das macht auch sinn, sobald an der Textur nachträglich geändert werden soll, oder Normalmaps etc mit eingebacken werden sollen. Ansonsten bräuchte man zwei Versionen der Baking Funktion. Eine welche möglichst textursparend arbeitet und eine die arbeitet wie gewohnt. Welche Möglichkeiten man da jetzt genau hat weiß ich nicht. Ich denke aber es sollte möglich sein die Texturen zusammen zu fassen und dabei den Detailgrad jeder Textur zu behalten. Dass die neue Textur dann um einiges größer ist liegt eben einfach an dem Problem alle Texturen in einer unter zu bringen. Das geht aber effizienter als in deinem gezeigten Beispiel. Auch automatisiert.

Zitat von »Schorsch«

<Klugscheisser>Korrekt heißt es Atlanten</Klugscheisser>

Moment, bezieht sich das auf mein "Texturatlaten" von oben? Hätte ich "Texturatlasse" geschrieben, hätte ich das ja verstehen können, aber einen Tippfehler derartig zu korrigieren halte ich für etwas übertrieben. (Wobei ich mich grundsätzlich gerne korrigieren lasse).


Zum Thema: Ich meiner mich zu erinnern, dass Blender beim Baken einfach Face für Face über das Modell geht, und das Face in die entsprechende Stelle in der Textur rendert. Wenn sich im UV-Layout jetzt Bereiche überlappen, dann wird halt ein altes Ergebnis in der Textur nochmal überschrieben. Wenn allerdings wirklich beide male das selbe reingeschrieben wird, macht das ja keinen Unterschied. Aber bei sowas wie Normalmaps oder Ambient-Occlusion kann das natürlich nicht funktionieren. Natürlich ist beispielsweise gerade das Ambient-Occlusion-Overlay sehr niederfrequent, was bedeutet, dass man hier mit einer sehr kleinen Textur auskommen kann (dadurch kann man also vielleicht eine hochauflösende Colormap getiled auf ein Modell legen und hat trotzdem noch Ambient-Occlusion - zum Preis das man jetzt wieder zwei Texturen anstatt nur einer hat; und natürlich einen komplexeren Shader).

Ich glaube, letztendlich ist hier viel experimentieren angesagt. Man muss gucken, wie man mit halbwegs wenig Texturen ein halbwegs gutes Ergebnis erzielt. Es gibt so viele Entscheidungen, die das Eine auf Kosten des Anderen verbessern, und die kann man auch noch bunt kombinieren. Letztendlich wird es vielleicht nie perfekt sein, aber das muss es ja vielleicht auch gar nicht. Ich würde auch auf jeden Fall die Content-Pipeline nicht außer acht lassen, es ist immer gut, wenn du Modelle mit wenig Aufwand ins Spiel bringen kannst und nach jeder Änderung erst wieder in langwieriger Arbeit optimieren musst.