Assimp + Blender -> Welches Format?

[Eisflamme]

Hey ho,

Ich habe mich jetzt ein wenig mit Blender eingearbeitet und meine "Engine" kann inzwischen nicht viel aber mit Hilfe von Assimp Modelle laden und bei x-Dateien z.B. auch mit Textur darstellen.

Problem: Welches Format kann ich nutzen, um Modelle so zu exportieren, dass sie mit Blender exportiert werden und mit Assimp importiert werden können? Hat da jemand vielleicht Erfahrung?

Oft ist es so, dass die Textur nicht geladen wird oder dass die Texturkoordinaten halt einfach verschwinden. Das ist sehr schade.

Ich bin nicht sicher, ob es an Blender oder Assimp liegt... Wie gesagt, hoffe auf praxiserfahrene Benutzer. :)

Viele Grüße
Eisi

[Aramis]

Die neueste Assimp-Version (SVN) bietet sogar direkte Unterstuetzung fuer das Blender-Format … die ist eher experimentell, aber du kannst sie gerne mal probieren. Zu viel will ich aber nicht versprechen, .blend ist das muehsamste Format das ich je gesehen habe.

Ansonsten wuerde ich es mal mit 3DS, OBJ und Collada probieren. Alle 3 Blender-Exporter haben so ihre Macken, aber Assimp muesste im Normalfall damit klar kommen.

Praxiserfahrung in der Nutzung von Assimp mit Blender habe ich nicht, mein Kenntnisstand beruht alleine auf Importtests im Laufe der Entwicklung der einzelnen Loader.

[Seraph]

Danke fuer die Antwort, auch wenn ich nicht der Fragesteller war. :)

[Schrompf]

OBJ und 3DS gehen nur, wenn Du keine Bones haben willst. Wir benutzen das DirectX .x-File recht intensiv - das klappt inzwischen in allen Lebenslagen ganz gut. Zu Blenders XFile-Exporter konkret kann ich aber nichts sagen. Collada funktioniert aber auch sehr gut, das ist inzwischen unser Ausweichformat geworden, immer wenn irgendwas an .X nicht geht.

[Eisflamme]

Hi,

Okay, also .x klappt gut, wenn ich es als externe Datei verwende, aber der Blenderexporter funktioniert anscheinend überhaupt nicht.

Vielleicht mache ich auch etwas falsch, also ich beschreibe Mal, was ich so mache:

Ich habe ein Standardview, dass auf Layer0 halt Kamera, Licht etc. hat. Auf Layer1 lege ich eine Plane an. Dann erstelle ich ein Material, dieses erhält dann eine Image-Textur, da lade ich ein Bild. Zum Rendern blende ich Layer0 und Layer1 ein und sehe die Plane mit Textur. Wenn ich exportiere, wird die Textur allerdings nicht exportiert.

In der .x-Datei steht nichts von einer Textur!?

Ach und kann mir Mal einer die Texturkoordinaten erklären? Ich dachte immer, die sind bei u und v von 0 bis 1, aber jedes Format scheint da wild rumzumachen, wie es lustig ist. :(

[Schrompf]

@Materialien: Was da im Material steht, hängt vom Exporter ab. XFiles haben eh nur eine rudimentäre Material-Unterstützung, aber das fand ich bisher immer irrelevant, weil sich die Materialdaten eh nicht auf die Strukturen der eigenen Engine abbilden lassen. Kann aber sein, dass das bei Dir anders ist.

@Texturkoordinaten: Texturkoordinaten können beliebige Zahlen annehmen - die Textur wird halt dann wiederholt. Wenn Du eine große Ebene mit einer kleinskalierten Textur belegst, wird die Textur darauf halt sehr oft wiederholt und in den Texturkoordinaten stehen halt größere Zahlen. Das tut dem Aussehen aber keinen Abbruch.

[Aramis]

Einige wenige antike Formate enthalten unnormalisierte Texturkoordinaten (d.h. absolute Texelkoordinaten), zu erkennen daran dass nur ganze Zahlen auftreten und die hoechste auftretende Zahl meist 1 unter einer 2er-Potenz liegt :-)

Solche Faelle werden von Assimp theoretisch intern korrigiert.

[Eisflamme]

Wie gesagt, ich will ja nicht viel. Ich bilde nur Texturkoordinaten ab und er soll das Texturmapping natürlich exportieren, dafür halt auch das Material. Beides geschieht nicht. Habe mir die .x-Datei ja im Texteditor angeschaut, da sind keine TAGs dafür. :(

[Schrompf]

Dann liegt es entweder an einer Exporter-Einstellung - ich kenne das Blender-Plugin dafür nicht - oder Du nimmst halt einfach ein anderes Format. Ich habe allzeit gute Erfahrungen mit Collada gemacht, aber (Vorsicht!) wieder nie mit Blender, sondern immer nur mit den "großen" 3DModellern wie 3DSMax und so.

Für statische Modelle sind OBJ-Files auch geeignet, oder .3ds - wobei ich bei OBJ relativ sicher bin, dass es da eine harte Grenze gab, wieviele Vertizes / Dreiecke ein einzelner Mesh haben darf. Bei ner Plane betrifft Dich das nicht, aber wenn Du eine große HeightMap oder sowas exportieren willst, wirst Du da evtl. an Grenzen stoßen.

[Eisflamme]

Also der Exporter war definitiv Müll. Die anderen aber auch. Ständig gibtes Pythonskriptfehler, vll sollte ich Mal wieder 2.6 installieren statt 2.7, der scheint damit nicht klar zu kommen. Ist Python per Definition abwärtskompatibel?

Collada export klappt auch nicht, denn der hat als Texturnamen dann $Texture.png statt meinem Dateinamen :P Das nützt natürlich herzlich wenig.

Hat hier niemand Mal mit Blender ein Modell mit Texturkoordinaten exportiert und mit Assimp importiert?

[kimmi]

Hm, Python 2.7 hat zu Python2.6 eigentlich nicht so viele Kompatibiltätsprobleme. Von 2.6 auf 3.0 hat sich einiges geändert. ich habe mal den Obj-Exporter von Blender benutzt, der ging eigentlich ganz gut. Kannst du den Collada-Exporter vielleicht selber dir mal anschauen? Ansonsten stell doch einfach einen Bug bei dem Exporter ein. Die Seite hat mienes Wissens ein ganz guten Forum, das könnte auch nützlich sein.

Gruß Kimmi

[Eisflamme]

Hi,

aus irgendeinem Grund funktioniert es jetzt. Ich kann auch nicht mehr reproduzieren, was das Problem war. Die .x-File-Exporter sind nach wie vor Schrott, weil nirgendwo ein Texturname in der Datei steht, aber Collada 2.4 klappt ganz gut. Ich meine, mehr als Mesh, UV-Koordinaten etc. brauche ich ja erstmal nicht. :)

Was aber eigentlich einfach und sehr wirkungsvoll in der Optik ist, sind Bumpmaps. Wie macht ihr das mit denen? Ich schaetze Assimp kann das nicht importieren, in den meisten Formaten wird ja nicht Mal gespeichert, ob das eine Bumpmap etc. ist, oder? Ähnliches mit Alphamaps... oder kann man die gut simulieren, indem man einfach ein PNG nimmt? Aber bei Transparenz muss man dann dafür selbst sortieren und so, ne? Ist das nicht super aufwendig, muss ja alles über die CPU laufen oder macht man das über Shader?

[Schrompf]

Da kommen wir ja schon zum Thema Renderer: für BumpMaps, AlphaBlending und sonstige Effekte brauchst Du folgendes:

a) Texturen. Transparenz kann man üblicherweise noch gut im Alphakanal der Diffuse-Map unterbringen, für Normal Mapping und weiterführende Techniken braucht es Normal- und BumpMaps, also zusätzliche Dateien mit abweichenden Dateinamen. XFiles können nur in Ausnahmen mehr als einen Texturnamen pro Material speichern, Collada theoretisch beliebig viele, aber nach unklaren Richtlinien. Die Texturdaten selbst kann man z.B. in einem PNG abspeichern - PNG unterstützt ja einen Alphakanal. TGA geht aber auch, DDS sowieso, BMP oder JPG dagegen nicht.

b) Shader. Die ganzen Vertex- und Texturdaten müssen von irgendwem ja verrechnet werden. AlphaTesting / AlphaBlending kriegst Du in DX9 noch mit RenderStates hin, aber spätestens für Normal Mapping braucht es dann dedizierte Shaderarbeit. Dazu sollte es Tutorials im Internet geben.

c) Tangent Space Matrix - auch TBN genannt (für Tangente, Bitangente, Normale). Das sind Zusatzdaten pro Vertex, die man aus Position, Normale und Texturkoords der Mesh-Vertizes berechnen kann. Assimp bietet Dir dazu Post Processing Steps an, die das bereits sehr gut umsetzen. Sie vermeiden aufgrund schmerzhafter Erfahrung bereits einige Fehler, die ein großer Teil der im Netz herumschwirrenden Implementationen noch macht.

Speziell zu c) sei zu erwähnen: der Mesh muss dazu überall valide Flächen, Normalen und Texturkoordinaten haben. Ein zum Strich zusammengestauchtes Dreieck im Mesh wird für #NAN-Werte im Normal Mapping führen, genauso wie gestreckte Texturkoordinaten. Stell Dir einen Würfel vor, den Du im 3D-Modeller nur mit einer Ebenen-Texturierung versiehst. Dann haben z.B. Ober- und Unterseite korrekte Texturkoordinaten, an den vier Seiten dagegen streckt sich ein unendlich dünner Texturstreifen über die komplette Höhe. Auch so ein Mesh wird zu ungültigen Zahlenwerten beim NormalMapping führen.

[edit] Transparenz-Sortierung ist Bonus. Mach erstmal ohne. Die Splitterwelten sortieren z.B. nur objektweise und für Massengeometrie wie das Gras gar nicht... merkt man aber nur als Eingeweihter, wenn man ganz genau hinschaut. Daher: lass Dich von der Tiefensortierung erstmal nicht aufhalten.

[Eisflamme]

Ich bin immer wieder begeistert, wie großzügig sich hier Zeit genommen wird, auf Fragen/Unklarheiten einzugehen, danke schon Mal. :)

Das mit den Texturen usw. habe ich verstanden. In Blender habe ich über so ein Farn-Tutorial (findet man bei google sofort) z.B. eine normale Texture, Alpha-Textur und BumpMapping-Textur verwendet, entsprechend eingestellt und schon läuft's. Da interessiert mich insbesondere aber, wie man das speichert. Ich meine, unterstützt Collada z.B. die Möglichkeit pro Mesh zig Texturen zu speichern + die Information zu liefern, ob diese jetzt als Bummap etc. verwendet werden kann und importiert Assimp diese Information auch? Wenn nicht, müsste man sich ja eine Art Helferformat zusätzlich basteln.

Zu Shadern muss ich mich auf alle Fälle noch informieren, mein Laptop ist da aber sehr beschränkt und gerade da ich mit OGL unterwegs bin... aber die Anfangsschwierigkeiten hatte ich ja schon Mal überwunden.

Und das Postprocessing für Tangenten habe ich bereits entdeckt. Dass Faces bestehend aus praktisch nur zwei verschiedenen Vertices keine Zusatzvektoren berechnen können, verstehe ich. Die Normalen sind bereits integriert, die Tangenten wären auch kein Problem, aber was macht man mit denen eigentlich? Ist das für Schattenwurf oder Spiegeln oder noch was anderes? Bzw. wonach sollte ich googlen für Material, will dir/euch ja keine Löcher in den Bauch fragen (will schon, wär aber bissel dreist ;)).

Wieso sieht man das bei Splitterwelten beim Gras nicht? Ist euer Gras selbst halbtransparent oder wieso gibt es da überhaupt Transparenz, sind ja einfach nur Rechtecke, oder? Oder habt ihr eine Grasbewegung als Animation, die dann obv. Transparenz braucht?

Nochmals danke bereits!

[Schrompf]

Das Phänomen, was Du bei mir gerade erlebst, nennt sich "Compile Time" :-) Da hab ich dann je nach Umfang des letzten Auscheckens mal ne halbe Stunde am Stück für Foren Zeit.

Zu Collada-Materialen: ja, da steht einiges drin. Es können theoretisch viele Texturen genannt werden, die auch Kategorien zugeordnet werden. Allerdings gibt es da nicht nur eine Kategorie "Normal Map", sondern drei oder vier, wenn ich mich recht erinnere... und wir haben damals raten müssen, was wir nun als Normal Map betrachten. Ganz zu schweigen davon, wie der Exporter-Schreiber diese Texturkategorien interpretiert hat. Ich würde mich daher nicht darauf verlassen, dass in den Materialstrukturen auch das drinsteht, was Du erwartest. Und spätestens, wenn Du ein paar Shader angehäuft hast, wirst Du feststellen, dass die Materialstrukturen auch nicht sonderlich gut auf die Materialien Deiner Engine abzubilden sind.

Ich kann's nur nochmal wiederholen: Leute, vergesst endlich Materialien beim Importieren. Es ist ein riesiges Grab an Arbeit, Rumraterei und Grenzfalljagd... das bekommt ihr nicht verlässlich. Und da man bei einem Spiel nicht aus solchen Zwischenformaten lesen kann, sondern sowieso ein eigenes Dateiformat erfindet, aus dem man performant genau die benötigten Daten liest, ist es doch ein NoBrainer, dazu auch noch ein paar Materialdaten zu schreiben, die ihr vorher beim Import zugewiesen habt.

Randbemerkung: AlphaBlending / Alphatest packt der Laptop auf jeden Fall... aber alles nennenswert komplexe erfordert ZWINGEND Shader. Wenn Dein Laptop nicht mindestens PixelShader-Modell 2.0 unterstützt, kannst Du Normal Mapping und alles andere vergessen.

Bezüglich der TBN-Matrix: das ist eine Matrix, die zwischen Textur-lokalen Koordinaten und Objektkoordinaten vermittelt. Die wird also für praktisch alle Per-Pixel-Techniken benötigt. Stell Dir eine Normal Map vor: jeder Pixel der NormalMap ist eine Normale, also ein Vektor. Der ist erstmal in Texturlokalen Koordinaten gegeben, also sozusagen relativ zur Oberfläche. Das X dieser Normale zeigt die Neigung der Oberfläche nach links oder rechts, das Y die Neigung nach oben oder unten und das Z die "Heraus"-Komponente, also weg von der Oberfläche. Nun ist die Oberfläche von Objekten aber nunmal meist gekrümmt, geneigt, irgendwie vielfältig. Ein "Nach links/rechts, nach oben/unten, heraus" bedeutet also je nach Stelle auf der Objektoberfläche was anderes. Und genau das beschreibt die TBN-Matrix. Die T - Tangente besagt, in welche Richtung an der Stelle das "Rechts" auf der Textur zeigen würde, die B - Binormale besagt das "Runter" auf der Textur und die N - Normale beschreibt die Richtung des "Heraus". Mit diesen drei Vektoren, die ja zusammen eine Matrix sind, kannst Du die Normale aus einer Normal Map in das Koordinatensystem des Objektes transformieren. Und von da aus kannst Du dann ja mittels der Objektmatrix ins Welt-Koordinatensystem transformieren. Und in Weltkoordinaten sind ja dann die Lichtquellendaten gegeben.

Bezüglich AlphaBlending und Sortierung: das ist einfach zu erklären. Es gibt ja den ZBuffer, oder auch DepthBuffer genannt. Der merkt sich, wie tief der letzte gezeichnete Pixel war, um beim nächsten Pixel entscheiden zu können, ob der neue jetzt davor ist (und damit den alten überschreibt) oder dahinter (und damit nicht gezeichnet wird). AlphaTesting ist ja eine Technik, die anhand des Alphawerts den Pixel komplett zeichnet oder komplett weglässt. Also ganz banale An/Aus-Transparenz, früher auch als Color Keying oder Maskierung aufgetreten. AlphaTesting ist also bezüglich der Zeichenreihenfolge egal - da muss man nichts sortieren, der ZBuffer erfüllt seinen Job.

Anders ist das bei AlphaBlending. Da wird die Ergebnisfarbe aus dem PixelShader mit der bisherigen Farbe an dieser Stelle verrechnet. Beim klassischen AlphaBlending wird interpoliert je nach Alphawert der Textur - je höher der Alphawert, desto mehr von der neuen Farbe und desto weniger von der alten Farbe wird geschrieben. Hier kann aber nicht mehr der ZBuffer seine Aufgabe als Ermittler des vordersten Pixels erfüllen - durch das Alphablending sehen wir auf einem Bildschirmpixel jetzt ja potentiell mehr als eine Oberfläche. Hier müsste man also die Oberflächen sortieren, damit sie in der korrekten Reihenfolge übereinander gezeichnet werden. Wenn aber die teiltransparenten Teile der Grafik nur sehr klein sind, kann man sich das sparen. Und bei unserem Gras sind sie das. Da ist ein Großteil der Grastextur leer oder komplett undurchsichtig und nur die Übergänge an den Grashalm-Rändern zum Beispiel sind teilweise durchsichtig. Diese teiltransparenten Bereiche sind auf dem Bildschirm so klein, dass ich entschieden hatte, mir die Rechenzeit für's Sortieren zu ersparen. Andere halbtransparente Sachen (wie z.B. Fenster) sortieren wir dagegen sehr wohl, aber nur objektweise.

[Eisflamme]

Versteeeeeehe, ok, das ist ja cool. Und die TBN-Matrix hilft letztendlich dann bei Belichtung/Schattierung und erzeugt den Effekt, den auch BumpMapping erzeugt oder geht sogar noch weiter? Auf alle Fälle macht das alles schöner, denk ich Mal.

Ganz verstanden hab ich das mit dem Extraformat immer noch nicht. Schreibt man sich jetzt letztendlich sein eigenes Dateiformat und eigenen Exportierer sowie Importierer? Oder schreibt man sich zusätzlich zur Objektdatei so ein Format und gibt dann Zusatzinformationen der Meshes für Materialien mit? Wie aber würde man dieses Format dann befüllen, dann müsste man sich ja ein Skript schreiben, welches erstmal die klassiche Modelldatei (z.B. Collada) importiert, die Meshes filtert und dann irgendwie die Materialien zuordner, eine Info, die aber bei Arbeitsteilung eigentlich nur dem Modellierer gegeben ist. Irgendwie muss man dem Modellierer ja seine Arbeit leicht machen (also alles, was die technische Seite) betrifft und der Programmierer soll möglichst nicht bei jedem Modell nachbearbeiten müssen, oder gibt es da keine so klare Arbeitsteilun

Das mit der Transparenz hab ich jetzt kapiert. Ich hatte dummerweise einfach eine Seite gecullt, daher sah das so dämlich bei mir aus, hatte letztlich nix mit Transparenz zu tun. Ich weiß auch, wie ich auf das Alphasorting kam und zwar bei Partikelsystemen, da hat man ja sehr viele mittelschwellige Alphawerte. Wie macht ihr das in Splitterwelten?

Ich stell mir bei ein paar 100 Partikeln für jeden Renderdurchlauf ein Quicksort immer etwas umständlich vor und wenn man nach jeder Materialbewegung vergleich, erscheint das ja fast noch aufwendiger. Außerdem muss die Sortierung ja bereits nach Anwendung aller Matrizen (bis auf vll Projektion) geschehen, da je nach Drehung ja die z-Achse schnell zur x-Achse wird, wie macht man denn das? Oder dreht man das Partikelsystem einfach nicht, was natürlich streng genommen ein Fake wäre, was aber keiner sieht? Das vermute ich jetzt Mal.

Durch GLSL oder wie das heißt unterstützt mein Laptop zum Glück ein bisschen was, glaub ich. :) Werd das nochmal testen, aber nach Australien gibt's eh den neuen Laptop, glaub ich (Desktopmaschine wär zwar geiler, aber ich wohn wieder nur ein Jahr in der Stadt und zieh dann um, außerdem brauch ich mein Gerät immer für die Uni und da programmiere ich auch gern ;P).

[Schrompf]

Du brauchst den Tangenten- und Bitangenten-Vektor zusätzlich zum Normalenvektor pro Vertex, um *irgendwas* an Berechnungen pro Pixel zu machen. Es geht hier nicht um "helfen" oder "besser aussehen", es geht um unvermeidliche Voraussetzungen, die erfüllt sein müssen, damit Normal Mapping, Bump Mapping und all die anderen PerPixel-Methoden überhaupt funktionieren können.

Thema "Extra-Format" - das ist eine reine Performance-Betrachtung. Ein 3D-Modell oder eine Szene in das Spiel zu importieren kostet Rechenzeit - die allermeisten der Zwischenformate wie Collada, XFiles usw. speichern die 3D-Info in mehr oder minder verqueren Strukturen, aus denen man die eigentlichen 3D-Daten erstmal zusammenstellen muss. Dann folgen da noch die ganzen Aufbereitungsschritte wie das Berechnen der Tangenten/Bitangenten, die VertexCache-Optimierung, die Koordinatensystem-Transformationen, die Triangulation... das alles kostet ordentlich Zeit. Als Beispiel: ein durchschnittlicher InGame-Charakter mit vielleicht 10k Dreiecken lädt ein bis zwei Sekunden aus einer Collada-Datei. Wenn Du das fertig importierte Ergebnis dann aber in einem eigenen Dateiformat speicherst, so dass Du die Daten direkt in den Vertex- und Index-Buffer laden kannst, braucht das Laden eines solchen Charakters nur noch Millisekunden. Man muss also nicht zwangsweise ein eigenes Dateiformat erfinden, aber für alle Spiele mit mehr als eins zwei 3DModellen ist man schon mehr oder weniger gezwungen, das zu machen, sonst ufern die Ladezeiten aus.

Und wenn Du dann schonmal dabei bist, ein kleines Tool zu schreiben, um z.B. mittels Assimp 3D-Dateien zu laden und dann in Deinem eigenen Schnell-Format wieder abzuspeichern, kannst Du auch gleich noch eine kleine GUI dazu bauen, die die Auswahl von Shader, Texturen und Shaderparametern dafür erlaubt. Und diese Daten schreibst Du dann mit in die Schnell-Datei, damit Deine Engine weiß, wie es das 3D-Modell zu rendern hat. Die Materialinformationen aus den ursprünglichen Export-Dateien sind dazu nicht geeignet - die sind einfach zu vielfältig, meist unvollständig, die Pfade zu den Texturen passen nicht, und so weiter und so fort.

Zum Thema Tiefensortierung: bei uns sortiert der Renderer, falls das Material das wünscht. Demzufolge sortieren wir nur DrawCalls untereinander, nicht einzelne Flächen. Auch Partikeleffekte werden untereinander nur emitter-weise sortiert, die einzelnen Partikel bleiben unsortiert. Bei additivem Alphablending ist das ja auch nicht nötig, bei interpolierendem Alphablending schon eher... aber drauf geschissen. Das ist mir die Rechenzeit nicht wert. Gedreht oder verschoben werden die Partikelsysteme natürlich trotzdem. Wie gesagt: wenn man teiltransparente Flächen nicht untereinander nach Tiefe sortiert, stürzt ja nichts ab oder sowas... es sieht nur potentiell nicht perfekt aus. Tiefensortierung ist also eine Abwägung von Rechenzeit gegen Grafikqualität, keine Mindestanforderung.

[Eisflamme]

Wieder was gelernt. :) Vielen Dank! Dann hab ich doch noch etwas mehr zu tun, bis ich mit meiner "Engine" ein Spielchen machen kann. ;) Macht aber nix, das lohnt sich dann ja!

[Chromanoid]

Wenn es dir ums Spiele machen geht, würde ich an deiner Stelle das Entwickeln einer eigenen Engine ganz schnell vergessen. Ich meine mich zu erinnnern, dass auch Schrompf anhand seiner Erfahrungen mit Splitterwelten immer dazu rät (oder?).
Ansonsten weiterhin viel spaß :).

[Schrompf]

Nein, aus heutiger Sicht würde ich von der Eigenentwicklung einer Engine abraten. Es gibt viele gute Engines da draußen, eine Eigenentwicklung bedeutet primär erstmal eine Menge Arbeit, ohne das dabei zwangsweise etwas rauskommt, das fertige Engines nicht auch könnten.

Aber ich kann sagen, dass eine Engine-Eigenentwicklung Spaß macht :-) Es ist ein Haufen lästiger Pflichtarbeit dabei, aber auch eine Menge kreativer Entwurfsmöglichkeiten. Die erste Engine wird eh immer unbenutzbarer Rotz, aber das gilt ja auch für die ersten Spiele, die man so schreibt. Wenn man eine Engine entwickeln will, sollte man das also tun. Wenn man aber "nur" ein Spiel entwickeln will, wäre eine Engine-Eigenentwicklung erstmal nur eine Menge zusätzliche Arbeit ohne Gewinn.

[Eisflamme]

Mir geht es halt um viele Dinge. Ich möchte auf Dauer Mal die gesamte Renderingpipeline verstehen und wirklich die Hintergründe sicher haben. Einfach eine Engine zu benutzen, wäre da nicht zielführend. Und ein Spiel hätte ich am Ende gerne, weil Spiele eben geil sind. Und wenn ich am Ende beides habe, bin ich echt richtig froh.

Ich weiß nicht, ob man das, was ich mache, überhaupt Engine nennt. Ich möchte eigentlich nur genug zusammenbasteln, womit ich dann ein Spiel machen kann. Das soll nie im Leben alles abdecken, das ist gar nicht das Ziel. Jetzt sind Bumpmaps etc. eigentlich recht einfach und sehen sehr geil aus, darauf möchte ich dann halt nicht verzichten, es soll halt schon wenigstens ein bisschen cool aussehen ;)

[RustySpoon]

Zum Thema Tiefensortierung: bei uns sortiert der Renderer, falls das Material das wünscht. Demzufolge sortieren wir nur DrawCalls untereinander, nicht einzelne Flächen. Auch Partikeleffekte werden untereinander nur emitter-weise sortiert, die einzelnen Partikel bleiben unsortiert. Bei additivem Alphablending ist das ja auch nicht nötig, bei interpolierendem Alphablending schon eher... aber drauf geschissen. Das ist mir die Rechenzeit nicht wert. Gedreht oder verschoben werden die Partikelsysteme natürlich trotzdem. Wie gesagt: wenn man teiltransparente Flächen nicht untereinander nach Tiefe sortiert, stürzt ja nichts ab oder sowas... es sieht nur potentiell nicht perfekt aus. Tiefensortierung ist also eine Abwägung von Rechenzeit gegen Grafikqualität, keine Mindestanforderung.

Oder du renderst in 2 Pässen. Im ersten Pass mit aktivierten Alpha- und Tiefentest und deaktiviertem Blending nur die opaken Pixel und im Zweiten mit aktiviertem Blending und umgekehrten Tiefentests aber ohne erneutes Schreiben in den Tiefenpuffer die Transparenten. So bekommst du quasi für Lau wenigstens die opaken Pixel sortiert und an den transparenten Rändern (an Grashalmen oder Partikeln zum Beispiel) stört sich wirklich niemand.