Deshalb meinte ich ja den ganzen Loader in eine Unit zu packen. Zudem gibt's auch der Seite auch noch eine Unit um dieses Format in XML zu konvertieren, wodurch man dann beides hätte. Eventuell kann man auch mal den Author anschreiben, ob er das auch in einer Unit zur Verfügung stellt.

Ja das wäre sicherlich mal ne gute Idee. Wie man ja weis sind Hobbyentwickler bei solchen Sachen recht kooperativ. Wenn man den mit ins Boot hohlt ist das sicherlich ein gewinn.

_________________
Blog: kevin-fleischer.de und fbaingermany.com

Ich weiß nicht wo das Problem sein soll das selber zu machen ?
Erstens ist der Faktor 25Units und 1inc file wohl sehr stark dagegensprechend.
Wir können keinen vollwertigen support zur verfügung stellen, ich sollte auch erwähnen das wir keine Macht haben zu sagen unter welchen Lizensbedingungen dieses läuft und da der Urheber keine Lizensbedingungen festgelegt hat bisher ist es fraglich ob er die passende Form wählt wenn er feststellt das seine Unit von aufeinmal sehr vielen Personen verwendet wird.
Es gibt auch personen die nicht ihren code weitergeben wollen, lust haben Lizensgelder zu zahlen oder den urheber zu erwähnen. Noch dazu ist unbekannt wie er das Projekt pflegt und ob es noch überladener wird als es momentan der fall ist.

Wenn wir das selber programmieren haben wir folgende Vorteile.

-eigene wahl der Lizensierung
-genau zugeschnittender code
-vollständiger support da die coder von dgl kommen und den code geschrieben haben
-schnellere reaktionsmöglichkeit auf wünsche oder probleme
-erleichterung für den endanwender durch übersichtliche Lizensbedingungen und unit sammlung

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

Projekte: https://github.com/tak2004

Aber anscheinend gehen hier die Vorstellungen weit auseinander. Daher wäre ein externes Format doch ein Kompromis.

Allerdings haben wir auch einen Nachteil...WIR müssen uns mit dem Code beschäftigen und WIR müssen ihn erstmal schreiben.

In letzter Zeit war es eher das Problem, dass viele Leute bei DGL was wollten, es aber nur sehr wenige gab die tatsächlich selbst hand an die anstehenden Aufgaben gelegt haben. Es ist da ganz klar die frage, wer es machen will. Wenn jetzt jemand aufspringt und sagt, "Ich werde diese Streambibiothek schreiben und pflegen, sagt mir nur wie die Schnittstelle aussehen soll!" dann wird hier bestimmt niemand dagegen sein.

_________________
Blog: kevin-fleischer.de und fbaingermany.com

Von mir aus würde ich das komplette Projekt coden. Den Exporter denke ich mal hätte ich sowieso für Blender geschrieben.
Da ich für meine Engine ein gutes Fileformat brauche welches ich zwischen blender und mein eigenen Toolsets nutzten kann und auch lesbar ist und am ende Binär ist bietet sich das sowieso an.

Wiegesagt ich muss momentan nur noch mein VFS fertig machen, dann hab ich Zeit dafür.

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

Projekte: https://github.com/tak2004

Das Problem ist meiner Meinung nach nicht das Programmieren an sich. Ich habe sowas auch schonmal in den vielfältigsten Variationen gemacht, sondern dass man sich einig ist und nicht da nacher an dem Gefriemel einer privaten Implementierung von jemanden hängt. Die genannte Unit scheint ja recht bekannt zu sein und sich schon bewährt zu haben.

Ich habe mir mal das Tutorial über RakBinaryStreamData angeschaut. Das ganze scheint für eine einzelne Delphi Anwendung doch ganz ok zu sein. Ich halte es allerdings als Grundlage für unsern Loader als unbrauchbar, da es nicht eine Version für alle Delphi Version gibt. Statt dessen gibt es Units für Delphi 5, Delphi 6, Delphi 7 und Delphi2005. Delphi 1- 4 und Delphi 8 Nutzer bleiben ausen vor, ganz zu schweigen von den Lazarus Nutzern.

Auch das Feature "RakBinaryStreamData unterstützt fast jeden Datentyp von Delphi direkt." ist absolut nicht Vorteilhaft für uns da hier auch die verschiedensten Klassen gemeint sind. Das heißt wer diese Unit in seinem OpenGL program nutzt braucht plötztlich sämtliche VCL Units. Schlussendlich braucht diese Unit sogar noch weitere Fremdunits, so das ein Zusammenfassen oder eine Lazarus/Freepascal freundliche Version gerade zu unmöglicht wird.

Ich schließe mich also TAK2004 an. Zumal wir ja auch für das Auslesen auch kein Zwischenformat wie bei RakBinaryStreamData brauchen.

z.B. einen Mesh aus Dreiecken zu laden könnte in Pseudocode so aussehen:

- Versionsheader einlesen.
- Überspringe so lange Blöcke bis du am Block Ojects bist
- überspringe so lange die Blöcke bist du einen Bereich vom Typ Objekt hast.
- überspringe wieder so lange die Blöcke(innerhalb des Bereiches Objekt ) bis du weist, ob das Objekt Meshdaten hat und wenn ja welche Bezeichnung sie haben.
- - falss dieser Objektblock keine Meshdaten hat schaue nach ob das nächste Objekt Meshdaten hat.
- verlasse den Objects block und überspringe so lange wieder Blöcke bis du beim Meshdatenblock bist.
- schau be jeden Mesh Block alle Eigenschaften durch bis du einen hast dessen Eigenschaft Name den gewünschten Wert hat.
- schau beim ersten Block innerhalb dieses Meshblockes nach was er für einen Typ hat und fülle demensprechend einen Vertex Array.

Das war jetzt nur ein Beispiel, aber so ungefähr könnte ein einfacher Loader realisiert werden.

MfG
Flo

_________________
Danke an alle, die mir (und anderen) geholfen haben.
So weit... ...so gut

Nun für die paar datentypen die wir brauchen wäre das sicherlich überdimensioniert. Das sollte auch selber gemcht werden können.Etwas aufwändiger ist vielleicht der eigentliche Loader. Das streamlesen ist ja nur ein helferlein.

_________________
Blog: kevin-fleischer.de und fbaingermany.com

Ich hab mal überlegt wie man die erkennun von Text oder Binär realisieren kann, bin aber bisher auf keine perfekte variante gekommen die immer funktioniert.
Um zu erkennen obs Text ist müsste man einfach ein bischen lesen und dann gucken ob ein tag existiert also <irgendwas>.
Das Problem ist das in Binär diese beiden zeichen auch auftren können und es auch lange dauert diese erkennung zu machen.
Binär zu erkennen wäre durch das lesen der ersten bytes 2 oder 4 Bytes je wie groß ein tag sein soll und überprüfen ob es ein gültiger tag sein könnte. Hier ist aber das Problem wie in Text, dass es auch in Textform zufällig solch ein wert geben kann.
Drum war eine Idee das wir im Binärdatein an den ersten 4Bytes 4 verschiedene nicht druckbare zeichen festlegen um jeden zufall vorzubeugen. Da im Text ja nur Umbruchskommandos nicht druckbar sind ist diese variante sehr gut und schnell , muss aber halt als Konventionen festgelegt werden. Ich hoffe das euch noch eine bessere variante einfällt da diese ja die dynamic einschränkt.

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

Projekte: https://github.com/tak2004

Ich finde du bist in deiner Überlegung schon ein Stück zu weit. Wie können wir zum Beispiel im Binären auch unterscheiden ob der jenige uns jetzt nen MP3 oder ein echtes Mesh gegeben hat? Na ganz klar anhand des Dateiheaders. Jede Datei hat einen eindeutigen Anfang der Datei. Oder sollte es zumindest. Beim BMP ein "BM". Beim PNG ein (Promillezeichen) + "PNG".

Da denke ich, dass wir auch einen Header brauchen. So können wir schon grob unterscheiden ob wir es lesen können oder nicht. Und da würde ich sagen, dass der Header sowohl für Text als auch für Binär gleich aussehen sollte/muss. Da im Text Binärzeichen doof aussehen sollten der Header wohl aus Text bestehen.
-Kennung "DGLMESH"
-Version "1.0"
-Format "BINARY" oder "TEXT"
-Zusatzinfos

Also könnte der in etwa so aussehen.
DGLMESH (1.0 BINARY "Kommentar")(Zeilenumbruch)
Daten

Das Prinzip sollte in etwa so ablaufen. Das Format des Header sollte sich auch ein wenig an dem Textformat orienten um nicht vollkommen aus der Rolle zufallen. Im Binären könnte man aus Sicherheitsgründen auch den Zeilenumbruch weglassen und sofort nach dem ) mit den Daten beginnen. Wäre wohl auch besser wegen Win/Linux.

So könnte die Leseklasse auch problemlos bestimmen was als nächstes zu tun wäre ohne, dass der Entwickler wissen muss mit was für einem Format er gerade arbeitet.

Ja..schätze das is so praktikabel.
Die Versionsangabe stellt dann die Version dar welche ein Loader haben muss, um alle enthaltenen Daten zu lesen. Wenn man das System des "gezielten Teilweisen auslesens von Informationen" (was ich oben beschrieben habe) machen will, kann man dann davon ausgehen, dass alle geringeren Versionen geladen werden können.

_________________
Blog: kevin-fleischer.de und fbaingermany.com

Was ist eigentlich mit dem normalen Delphi Streaming Format? Immerhin kann man alle Objekte die von TPersistent abgeleitet sind auf einen Stream packen und wieder laden und das alles im Text und Binärformat.
Mittels TStream.WriteComponent/TStream.ReadComponent kann man von TComponent ableitete Klassen speichern. Alle untergeordnenten Klassen müssen nur von TPersistent sein. TComponent stellt ja bereits die Funktionen für eine Baumstruktur zur Verfügung.
Mit ObjectBinaryToText,ObjectTextToBinary kann man zwischen den Formaten hin und her konvertieren und mit TestStreamFormat schauen welches Format im Stream liegt.


Folgede Struktur ist z.B. ohne Mehrarbeit nur durch Funktionen aus classes bereits mit einer Zeile auf einem Stream zu speichern und zu laden.

Version:
Also ich weiß gerade nicht was du mir Oben meinst aber Version des Loaders direkt mit dem des Formates zu verknüpfen mag bis zu einem gewissen Grad okay sein. Aber folgende Probleme drängen sich mir gerade auf.

Jedes Release des Loaders muss eine vollständig eindeutige Versionsnummer besitzten so müsste dann die Version des Loaders 3 stellig sein. Hauptversion.Nebenversion.Release

Aber dann ist noch die Frage wie man funktionale Erweiterungen im Loader in der Version verankert. Es muss sich dabei ja nichts am Format geändert haben? Was weiß ich. Eine neue Technik wurde eingebaut um nicht existierende Flächennormalen berechnen zu lassen oder die interne Struktur wurde geändert? Das man sich dann auf die Versionsnummer 1.0.2341 verschränkt halte ich aus "verkaufstechnischen Gründen" (hätte nie gedacht so etwas mal zu sagen) für unrentabel. Ich denke, wenn man in dem Loader funktional etwas ändert, dann soll man das auch an der Versionsnummer sehen. Also dann darf er ruhig die Version 1.1 tragen. Auch wenn das Format nur maximal 1.0 als Version haben kann. Oder wenn dann später noch eine 1.1 nachgeschoben wird die er nicht lesen kann. Zur Not könnte man die dann als 1.2 deklarieren was aber wiederrum verwirrung stifftet, da man erwartet, dass es auch eine 1.1 gibt.

Ich denke auch mal, dass es für die Entwickler selber auch besser wäre wenn man sieht, dass man jetzt auf die 1.2 zuarbeitet und nicht von der 1.0.1245 auf die 1.0.1246. Das ist gelinde gesagt frustrierend und Außenstehende erwarten dann lediglich einen Bugfix und keine Eierlegendewollmilchsau.

Delphi Streaming Format:
Ich für meinen Teil mag es nicht, wenn jedes noch so kleine Teil ein Objekt sein muss. Und genau das wäre da der Fall. Ich habe mit solch einer extremen Form der Objektorientierung schon gearbeitet und bin dann sehr schnell und dankend wieder zu einer Mischung aus Objekten und Pointer gekommen. Eben auch weil diese wesenlich bessere Optimierungsmöglichkeiten bieten. Wenn man 100000 Klassen erstellen und wieder frei geben will, dann braucht man ne Weile. Vor allem frei geben ist langsam wie Sau. Aber einen Speicherbereich mit Platz für 100000 Punkten anzulegen und freizugeben ist kinderkram. Und 100000 Punkte sind für ein Mesh noch keine Zahlen. Nicht wenn man den Trend beobachtet.
Außerdem machen es zu viele Objekte nicht leicher mit zum Beispiel VBOs zu arbeiten. Diese dann darein zu kopieren dauert wieder ewig.
Klar das wäre sehr einfach, würde alles unterstützen was man bräuchte etc. Aber den Nachteil finde ich schon nicht unerheblich.

Die Meshklasse mit den Vektoren ist ja nur ein Bsp.

1)Man kann Klassen auch auf einen kontinuierlichen Bereich anlegen. Dazu muß man einfach nur NewInstance überschreiben und den Zeiger zurückgeben wo man die Klasse gernen haben möchte.
2) Für Sachen wie Vertex Arrays kann man auch DefineProperties überschreiben und sie dann in einem Block als Binärdaten laden. Schließlich werden auch die Bilder aus der Form in diesem Format gespeichert.

Versionsnummern finde ich nicht gut, weil man dann immer die entsprechenden Versionen verwalten muß. Lieber den Loader nachsehen lassen, was er von der Datei brauchen kann. Es kann nämlich z.B. auch möglich sein, dass manche Sachen nut optional dabei sind und es keinen linearen Verlauf bei den Versionen gibt. Durch festgelegte Versionen verkompliziert man sich nur die Verwaltung.