Ich bin heute wieder auf ein recht unangenehmes Thema gestossen.
Die rede ist von Scriptsprachen, es ist schlicht weg notwendig Scripte zu verwenden, wenn man ein Material, Szenen Objekte oder ganze Level verwalten und schalten will.
Wenn man ein Material hat, dann enthält dieses Informationen von zu ladenen Texturen, Shadern und benötigt oft auch bestimmte fähigkeiten, um z.B. eine Zeitkonstante oder ähnliches zu ändern.
Die ganze Sache kann aber wesentlich komplexer werden, wenn man z.B. mehrere Passes hat, OpenGL3 verwendet oder schlicht weg keine statische Engine haben will.
Ich und Oc2k1 haben dieses Thema schon 1-2 mal aufgegriffen und wieder verworfen.
Wärend ich bei Lua geblieben bin hat Oc2k1 javascript verwendet und es ist nicht schwer fest zu stellen, dass Materials dann nicht kompatibel zueinander sind.
Heute haben wir wieder überlegt und sind auf die Idee gestossen eine art CG für Scriptsprache, sprich ein compiler und mehrere plugins, welche eine generische einfache scriptsprache in verschiedene andere Scriptsprachen konvertieren kann. So wäre es möglich, in einer Engine 2-3 Scriptanbindungen zu entwickeln und je nach Entwickler, kann dieser dann die Materials, Modelscript, Levelscripts dann in die entsprechenden Scriptsprache konvertieren und in dieser weiter arbeiten.

So könnte eine mögliche Variante aussehen.


Ich hab den Thread gestartet und will einfach mal gucken, ob sich wer anderes noch mit dem Thema befasst hat, weitere Ideen oder sogar interessierte Entwickler hier rum geistern.

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004

Overkill. Absoluter Overkill
Universelle Skriptsprache, die in andere Skriptsprachen übersetzt werden kann... Dann mal viel Spaß mit den schlaflosen Nächten

_________________
"Für kein Tier wird so viel gearbeitet wie für die Katz'."

Ich habe mit Oc2k1 noch ein bischen zusammen gearbeitet und das ganze mal ein bischen weiter runter abstrahiert.

Das wäre dann ein Klartext Datenformat, welches man auch einfach als Binäres format ablegen könnte.

Die Zuweisung, von Stream auf ein OpenGL Buffer und die verarbeitung von den Daten kann man dann über ein Script lösen.

Owner wäre eine immer existierende Konstante, ModelData wäre eine variable, die nur bis zur beendigung des Scriptes existiert und dann abgeräumt wird.
Owner.Mesh und Materials sind wrapps aus der verwendeten Engine.

Nachdem bekannt ist, was für Daten vorliegen und weitere benötigte Daten geladen wurden, kann man nun noch mit dem Materialscript die Daten zeichnen.
Index,Vertex,Normal,Texcoord,Color wurden im Modelscript angelegt und sind daher als globale Konstanten im Materialscript verfügbar.
Neben diesen ist auch wieder Owner definiert und es stehen die typen TTexture und TShader zur verfügung.

Das ganze ich nun recht abstrakt und kann z.B. problemlos zwischen lua,squirrel und javascript hin und her geportet werden.
Es ist ausserdem auf OpenGL3 ausgelegt, man hat zwar keine Möglichkeit mehr OpenGL<3.0 zu verwenden aber man entwickelt ja auch für die Zukunft und nicht für die Vergangenheit.

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004

Nun muss ich auch mal etwas dazu schreiben. Gerade die scriptsprache hat sich in der vergangenheit als außerst problemtisch herausgestelt. In Lumina hatte ich ECMA verwendet, jedoch hat dies große mängel bei der unterstützung von OpenGL freundlichen datentypen. Gerade wo mit OpenGL 3.x die fixed funktions komplett wegfallen (wenn man nicht die kompatibilitäts ARB für ein nues design verwenden will)


Das wären in etwa die anforderungen:

Die Scriptsprache muss als Leim zwischen Engine und Model dienen können. d.H. jedes Modell muss von der engine gleich angesprochen werden können, egal ob es sich dabei um Terrain, Boneanimierte Modelle oder sonstiges handelt. Es muss einfach so sein, das die engine das Model aufordert, sich in eine shadowmap zu rendern. Es ist nicht die Aufgabe der Engine Buffer zu binden, die dem Model gehören.

Die Scripsprache muss auch als Leim zwischen der Physikengine und der Grafik dienen. Dazu mussen die sichbaren Objekte ermittelt werden und gegebenfalls zu instanzierte Drawcalls zusammengefasst werden. Ohne eine mächtige scripsprache ist es kaum möglich unsichbare objekte hier schon aus derpipline zu entfernen, ohne die engine mit zusätzlichem ballast zu füllen, der eh nicht algemein funktionieren kann (da die shader ja frei programierbar sind, müssen auch solche test frei programierbar sein)

Als Datentypen mussen für eine saubere Anbindung alle Datentypen von GLSL mit unterstütz werden. Da GLSL Typisiert ist, sollte es auch die scriptsprache sein. Komplexere datentypen haben auch den vorteil, das der scriptoverhead im vergleich zu im script nachgebauten vektor/matrix operationen stark sinkt.
Eine häufige anwendung dieser Datentypen ist z.B. das multiplizieren von Kamera (View) matrix und Modelmatrix. Die wäre zwar auch im shader möglich, jedoch is es auf keinen Fall sinnvoll irgendwelcheuniform variablen dort miteinader zu verechnen.

Aus OpenGL sollte mit eingebaut werden:
Möglichkeiten auf Buffer schreibend (und lesend) zuzugreifen, uniform variablen von shadern schreiben.
Abfrage von Queries, Steuern von Stransform feedback usw

Gegenüber GLSL wegfallen könnte:
Alle Texturfunktionen. Es wäre möglich diese zu emulieren, jedoch würde dies einen Pipelinestall auslösen.

Ein kleines problem kann noch die Anbindung der shader und Buffer sein, deren Members mehr oder weniger dynamische Propertys sind. So wären z.B. die Uniform variablen und Attribute (In variablen) als Properties am sinvollsten implementierbar. Allerdings mussen hier die scripte mit den shadern gelinkt werden. Das hat wiederum zu folge, das shader nicht in scripten mehr verändert werden können. (Es sei den die propertys wären komplet dynamisch, was aber extreme performance probleme verursachen kann, da die namen dynamisch aufgelöst werden müssen)

Ein renderscript könnte so aussehen:



Offen bei diesem Beispiel ist allerdings noch wie die struktur von vertices definiert werden muss. Allerdings könnte man hier eventuell die syntax des bindless rendering übernemen, bei deen es erlaubt wird pointer in shadern zu benutzen.

Eine der größten probleme bei diesem Projekt ist, das hier ein vollständiger compiler implmentiert werden muss. Zwar muss er nicht auf die assemblebene herunter (was seh unpaktisch wegen der plattformunabhängigkeit wäre), aber dafür muss in einen bytecode compeliert werden, der alle GLSL typen native unterstützt (Also keine matrixoperationen aus einzelnen floatoperationen auf dem stack zusammen setzt)
Zur zeit erscheint es mir so als wenn mit Boost::Spirit am ehesten die change besteht den compiler zu implementieren.

_________________
Lumina plattform unabhängige GLSL IDE