simpleIrrlicht - Irrlicht in "Einfach"

Kommentare anzeigen Worklog abonnieren
Gehe zu Seite Zurück  1, 2, 3 ... , 13, 14, 15  Weiter

Worklogs simpleIrrlicht - Irrlicht in "Einfach"

das Licht wird heller

Donnerstag, 21. Mai 2009 von Farbfinsternis
Es gibt Erfolge zu vermelden: Alle Shaderpasses werden nun ordungsgemäß verarbeitet und am Ende kommt ein fluffig bloomiger Screen dabei heraus. Der Haken: Das Shader-Ergebnis wird noch nicht mit dem hochauflösenden Screen verrechnet, aber auch das sollte zu lösen sein.

user posted image

ein Lichtlein brennt

Mittwoch, 20. Mai 2009 von Farbfinsternis
Zwar brennt es noch nicht besonders hell, aber es ist ein Funken. Es liegt offensichtlich nicht am Wrapper, sondern an BlitzMax selbst. Wenn sich herausstellt dass Irrlicht seine ShaderCallback-Liste mit einem Schlag pro Draw abarbeitet sind PostProcessing-Effekte entweder gestorben, oder man beschränkt sich auf SinglePass Filter welche stets den gesamten Viewport bearbeiten (Overkill, da knechtet CPU und GPU ordentlich dran).
Material-Shader sind scheinbar einfacher zu lösen, aber auch hier könnten dann keine Multipass Effekte angewendet werden.

Ich arbeite dran und bin eigentlich froher Hoffnung, auch wenn das alles ganz schön irritierend und Zeit fressend ist.

Nachbrenner ausgelöscht

Montag, 18. Mai 2009 von Farbfinsternis
Das Problem konnte nun lokalisiert werden: Während man in anderen Sprachen, die ein Binding für Irrlicht haben, noch in den Renderprozess eingreifen kann ist das in BlitzMax nicht möglich. Ein simples "drawAll()" arbeitet stur die Shaderliste ab und das wars. Für einen PostProcess Effekt ist es aber notwendig nach dem letzten Shader die Textur des "FullScreenQuad" zu wechseln. Da es in BlitzMax scheinbar keine Möglichkeit gibt das Abarbeiten der Shaderliste zu kontrollieren und damit den letzten Shader abzufangen, fällt Postprocessing aus. Somit wird simpleIrr eine langweilige "letztes Jahrtausend" 3D Engine die zum Glück noch RT-Shadows bietet.

Ich bin frustriert.

Nachbrenner #hmpf

Sonntag, 17. Mai 2009 von Farbfinsternis
Auch wenn Matthias in den Comments lieber ein simpleIrr ohne Shader sehen würde, so kann ich es dennoch nicht lassen. Während die direkte Programmierung in Irrlicht kein Problem mit Shadern hat, will simpleIrr Erfolge nicht eintreten lassen.
Eben noch auf dem Papier wunderbar auseinander klamüsert und detailreich mit dem Bleistift in Szene gesetzt, versagt das System und geht in der Brandung der BlitzMax Unzulänglichkeiten verloren.

Ich habe keine Ahnung warum der Callback seine Parameter nicht aus einer Liste lesen möchte, ebensowenig ist mir klar warum eine Variable eben noch einen Wert hatte, dieser aber nur Millisekunden später verloren geht. Ich würde ja gerne annehmen dass BlitzMax Altzheimer hat, aber das ist dann doch wohl eher unwahrscheinlich.

Es geht ja nicht nur um PostProcess Effekte, das System soll später ja sämtliche Materialshader verarbeiten. Zudem ist es mir ein dringliches Anliegen auch Softshadows, Normalsmaps, Specularmaps etc. anbieten zu können. Aber das einfachste (PostProcess) funktioniert halt noch nicht.

Aber um nicht nur zu weinen: @Matthias: Surfaces kommen, aber die sind in Irrlicht fast komplizierter als Shader.

Nachbrenner #3

Freitag, 15. Mai 2009 von Farbfinsternis
Shader sind relativ leicht zu implementieren, Shader für Blitz3D Jünger verfügbar zu machen ist ungleich schwerer. Das Problem ist dass ein PostProcess selten aus nur einem Shader besteht, meistens findet der Render-Prozess in mehreren Schritten (Passes) statt. Prinzipiell ist es einfach:

  • Erstelle neuen PostProcess
  • Füge einen RenderPass hinzu
  • Füge einen RenderPass hinzu
  • Füge einen RenderPass hinzu
  • ...
  • Rendere pro Frame die ganze Geschichte

Problematisch daran (für Blitz3D verwöhnte User) ist dass dieser Vorgang Unmengen an Parameter benötigt und der User auch noch wissen muss welche Daten der Shader gerne hätte um funktionieren zu können.

Hier am Beispiel eines simplen "Bloom" was alles zu tun ist:

  • erstellen eines neuen PostProcess Objekts
  • definieren des Pixelshader- und des Vertexshader-Modells (Default 1.4 und 1.1)
  • definieren der Puffergröße (Texture die der Shader manipuliert) (Default 256x256)
  • definieren des Einstiegspunktes für Vertex- und Pixelshader (Default "main", "main")
  • prüfen welcher Renderer verwendet wird (OpenGL oder DirectX) um die richtigen Shaderprogramme zu übergeben. Wer seinen Renderer selbst bestimmt muss nur die Shader übergeben, für Vertexshader existieren im Modul Defaults
  • Übergeben der Shaderfiles oder Strings in denen der Shader definiert ist (fromFile:Byte)


Echt ne Menge Aufwand. Ich will hier niemanden entmutigen. Wer mit den Defaultwerten zufrieden ist kann mit vier Zeilen einen Bloom-Effekt nutzen, wer mehr will muss aber auch mehr tippen.

Um das alles zu vereinfachen ist ein Shader-Tool geplant welches eine Shader-Material Datei erzeugt welche dann mittels LoadPostProcess() geladen und angewendet werden kann.

Vielleicht tritt mir ja die Tage noch die Muse ins Gemächt und erzählt mir wie ich das alles noch weiter vereinfachen kann.

Nachbrenner #2

Mittwoch, 13. Mai 2009 von Farbfinsternis
Mittlerweile bin ich auf dem Weg. Als Grundlage für das PostProcessing System habe ich das C++ Framework von Slin auserwählt. Dieses hat den Vorteil dass ein PP Effekt in mehreren Passes gerendert werden kann was einem wiederum RenderMonkey (AMD) und FX Composer (NVidia) als Shader-Designer öffnet.
Im Moment funktioniert es zwar grundlegend, aber die Komposition mit der Scene ist noch nicht möglich. Hier ein Bild wie es aussieht wenn ein Glow geplant war, aber nur ein Blur daraus wurde:

user posted image

Diese Scene wurde in 4 Passes gerendert ... der 4. Pass muss wohl eingeschlafen sein, der sollte das blurred Image mit dem Backbuffer mischen.

Ich bin am Ball!

Nachbrenner

Donnerstag, 7. Mai 2009 von Farbfinsternis
Heute habe ich mich, trotz der vielen anderen Baustellen, mal mit dem PostProcess-System befasst. Das Resümé: Schwierig, aber machbar.

Ziel dieser Arbeit soll sein dass man mit einem einfachen Funktionsaufruf so Sachen wie Bloom, Motionblur, Depth of Field etc. hinzufügen kann. Ein Bloom würde folgenden irrsinnigen Aufwand bedeuten:
Code: [AUSKLAPPEN]
SetBloom(True, 2.0)

Das Schnipselchen schaltet einfach nur den PostProcessing-Effekt "Bloom" an und definiert dafür eine Stärke von 2.0 ... aufregend, wa?

Das Irrlicht-Shadersystem wird natürlich durchgeschliffen, so dass man nicht gänzlich auf vordefinierte Shader angewiesen ist.

Schattenautomatik

Mittwoch, 6. Mai 2009 von Farbfinsternis
Nachdem gestern die Funktionalität zum laden kompletter Szenen eingebaut wurde, habe ich mich heute dem Problem gewidmet dass die geladenen Objekte keine Schatten werfen können. Mit der eben hochgeladenen r55 geht das nun automatisch, allerdings war dazu ein finsterer "Hack" am irrB Exporter notwendig. Wer dies nutzen möchte muss die irrB Datei "iExporter.py" im Plugin-Verzeichnis "irrbmodules" durch diese Version ersetzen: http://simpleirr.sedm.de/bmx/iExporter.py

Bitte beachtet dass dies nur eine Übergangslösung ist, ich bastle daran dass man in Blender direkt definieren kann welche Objekte Schatten werfen sollen und welche nicht. Im Moment wirft automatisch jedes Objekt der Scene einen Schatten, was hier und da natürlich der komplette Performance-Killer sein kann. Zudem wird jedes Mesh als "animiertes Mesh" geladen, was zusätzliche Resourcen benötigt ohne das das notwendig wäre. Naja, wie gesagt: Ich arbeite daran.

user posted image

rev54

Dienstag, 5. Mai 2009 von Farbfinsternis
Mit Revision54 bekam simpleIrr die Funktionen LoadIrrScene() und FindEntity() spendiert. Damit ist es möglich eine IrrlichtScene zu laden und auf deren Einzelteile zuzugreifen. Irrlicht-Scenes können aus Blender mittels eines Plugins und aus IrrEdit exportiert werden. Es werden alle Materialen, Texturen, Kameras, Lichter etc. übernommen. Somit stehen der simpleIrr zwei Editoren für Euren Game-Content zur Verfügung. Selbstverständlich können Irrlicht-Scenes auch aus Zip-Archiven geladen werden.

Hier noch ein kleines Sample:
Code: [AUSKLAPPEN]

SuperStrict

Framework sedm.simpleirr

InitIrrlicht()
Graphics3D()

AddZip("data/data.zip")
LoadIrrScene("scene.irr")

' die Würfel aus der Scene holen
Local cube:TEntity = findEntity("Cube")

' die Plane aus der Scene holen
Local ground:TEntity = findEntity("Plane")

' das Licht aus der Scene holen.
' BEACHTE: FindEntity() gibt ein Objekt
' vom Typ TEntity zurück. Um dieses als
' simpleIrr Licht behandeln zu können
' muss es erst auf den richtigen Typ
' gecasted werden.
Local l:TLight = TLight(findEntity("Lamp"))

Repeat
   TurnEntity(cube, 0.1, 0.1, 0.1)
   RenderWorld()
Until IsKeyDown(KEY_ESCAPE)
End


Der Screenshot ist nicht besonders spektakulär ... ich weiß.
user posted image

    Sonst noch?
  • added: TPrimitives.Cube() ' erstellt einen Quader
  • added: TPrimitives.Sphere() ' erstellt eine Kugel
  • added: TPrimitives.Skybox() ' lädt eine Skybox


Im SVN Repository kann die rev54 als vorkompiliertes Modul für Win32 heruntergeladen werden.

EDIT
Ich habe jetzt das komplett Archiv auf den Server geladen weil der Download des simpleirr.mod nichts bringt. Alle die versucht haben das Modul ans Laufen zu bekommen sollten das aufgeben und gleich den neuen Download nehmen. Sorry, mein Fehler.

Linux *hrrrrr*

Montag, 4. Mai 2009 von Farbfinsternis
Allein mittels BlitzMax unter Linux programmieren zu wollen gleicht schon einer Selbstgeisselung da keine benutzbare IDE existiert. Dann aber seine Änderungen ins Repository schicken zu wollen ist schon gewagt! Gut 1,5 Stunden habe ich benötigt um dies zu bewerkstelligen.

Egal.

Die rev47 bringt nur marginale Änderungen mit sich: Ich habe jeder Klasse eine Delete() Methode spendiert damit die Objekte vernünftig aus dem Speicher entfernt werden können.

Als nächstes stehen einige komplizierte Entity-Methoden und das Material-System an. Letzteres lässt sich nur schwer auf Blitz3D Syntax wrappen, aber ich denke ich bekomme das hin.

Wir sind jetzt an einem Punkt an dem sich der altbekannter Blitz3D Syntax nur noch schwer in die Irrlicht Engine pressen lässt. Ich verspreche aber dass die Änderungen und Erweiterungen genauso einfach zu programmieren sind wie aus Blitz3D gewohnt.

Gehe zu Seite Zurück  1, 2, 3 ... , 13, 14, 15  Weiter