Das ist nach meinem Verständnis keine Engine, sondern bestenfalls ein API-Wrapper. Der ist im besten Fall tatsächlich austauschbar, da hast Du Recht.BlueShark hat geschrieben: Also ich hab für meine 3D-Engine ein Interface geschrieben, dazu gibt es dlls, einmal für DirectX9 und OpenGL, die Funktion Draw() macht in beiden Fällen das selbe, die Umsetzung ist jedoch verschieden. Es ist also gar nicht nötig, dass die Editorengine die selbe sein muss, oder zumindestens sehr ähnlich, wie die, die man in seinem Spiel verwendet.
Da gehen die Meinungen auseinander. Ein BSP-Tree z.B. ist schon eine reichlich spezifische Organisationsstruktur für statische Geometrie, und noch dazu eine, die vor 5 Jahren den Zenit ihrer Nützlichkeit überschritten hat und seitdem mehr Performance kostet, als sie bringt. Für's Rendern. Für Kollisionstest z.b. wäre wieder eine andere Beschleunigungsstruktur nötig.Ich bearabeite im Editor ein Level, eine kleines Dorf zum Beispiel. Nun habe ich, sagen wir 10 Modelle für die Häuser und dazu nochmal 100 Texturen für alles, das Ganze ist dann in einem BSP-Tree verpackt. Nun speicher ich das ganze in einer Datei, wo dann folgendes steht:
Wie man hier sieht, sind die Daten nicht 3D-Engine abhängig, soll heißen dass jede beliebige 3D-Engine in der Lage sein müsste dies Daten zu verarbeiten.
Naja, das kann ordentlich Rechenzeit brauchen, das sollte man nach Möglichkeit bereits vorher getan haben... z.B. in einem Editor :-) Bei uns zählen zur Vorab-Aufbereitung zum Beispiel Kollisionsmesh-Vorkompilierung, Bewuchsverteilung, LOD-Berechnung, statische Spiegelungen, globale Konsistenzprüfungen und nicht zuletzt die Umgebungslicht-Berechnung dazu - allein letztere braucht mehrere Stunden für eine mittelgroße Welt.Die Daten müssten beim Laden in das Engine freundliche Format gebracht werden, aber das war es dann auch schon.
Ja, mir fällt da zum Beispiel die Ausleuchtung ein: der Leveldesigner verteilt und konfiguriert Lichtquellen, um bestimmte Stimmungen in bestimmten Bereichen des Levels zu erreichen. Das z.B. schreit geradezu danach, im Editor die selbe Engine zu nehmen wie im Spiel, damit der Designer das Endergebnis sofort sieht. Gleichzeitig ist aber z.B. die ganze Render-Pipeline mit Beleuchtungsmodell und Lichtorganisation eine meiner Meinung nach sehr individuelle Geschichte, für die sich nicht so einfach eine wiederverwendbare Schnittstelle finden lassen dürfte.Das Problem wird jedoch sein, dass das ein extrem simples Beispiel ist. Schließlich will man in seinem Editor mehr machen als nur Level auf Polygonbasis zu kreieren, sondern auch Skripten können. Und das wäre nur ein Punkt, dazu kommt noch sehr viel mehr.
Nichts, das ist ja der Standardweg. Bzw. andersrum: man benutzt die Spielengine auch für den Editor. Im Spiel muss es ja gut aussehen, und im Editor muss es möglichst wie im Spiel aussehen, damit die Designer nicht blind arbeiten müssen.Aber mal so ganz am Rande, was spricht dagegen, dass man für sein Spiel die 3D-Engine des Editors verwendet?
Was ich aber an der Idee für das problematischste halte, sind die Konflikte, die bei der gemeinsamen Bearbeitung ganz automatisch entstehen. Die gängigen Versionsverwaltungen lösen das auf Textzeilen- oder Byte-Ebene. In einem komplexen Szeneneditor würde man dagegen eine Lösung benötigen, die sehr viel mehr Wissen von den zu bearbeitenden Datensätzen benötigt.. ein Merge für ein Model sieht z.B. ganz anders aus als ein Merge für Objektplatzierungen oder eins für Physik-Geometrie. Hier könnte man wahrscheinlich erstmal auf Basis einer kleinsten Einheit (z.B. einem Szenegraph-Node) arbeiten und alle Änderungen verschiedener Leute, die die selbe kleinste Einheit betreffen, dem Nutzer zur Auflösung hinhalten. Das "Mergen" wäre dann eine Übertragung aller Fern-Änderungen auf die lokale Arbeitskopie, solange die betroffenen Einheiten nicht auch lokal verändert wurden. Und die Konfliktauflösung würde sich auf "Schau's Dir an, so sieht Deine aus, so die geänderte aus dem Repos. Welche willst Du?" beschränken.
Geht natürlich nicht für die ganzen globalen Daten wie Wesen-Vorlagen, Gegenstände, Skripts, Tag/Nacht-Einstellungen, Quests, Dialoge, Story, usw... aber es wäre ein Anfang.
Bye, Thomas
