ZFX + Developia

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).

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.

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!

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ß :).

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.

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 ;)

Schrompf hat geschrieben: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.