Lasst uns mal zusammenfassen wer für Binary und wer für text ist.
Vieleicht sind wir ja schon alle für eins und es ist bei den vielen Posts untergegangen.
Da hier mehere Beispiele zu beiden gibt brauch ich da nichts wiederholen.
Ich hab mal versucht aus den Post zu interpretieren wer zu was tendiert.
Bitte bei nicht korrekter einteilung melden und bei nicht in der liste stehen auch melden

Text:
Tomok

Binary:
TAK2004
Flo
Lossy eX

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

Projekte: https://github.com/tak2004

Lese hier mit und würde gerne einen Text Loader nehmen.
Der Grund ist einfach:
Kompitabilität.
Wenn die Version geändert wird, sollten ältere Dateien auch ohne grössere Probleme geladen werden können.
Wenn es die Binärfraktion schaffen würde, dies bei sich einzubeziehen, hätten sie meine Unterstützung, aktuell bin ich aber für Text.

Diese binäre Baumstruktur die ich Vorgeschlagen hatte bietet genau dieses Feature

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

Nun ich habe ja beides vorgeschlagen und zu minimalem Aufwand. Die gleichen Token nur als Hexwert oder ausgeschrieben. Es macht ja durchaus Sinn zwei Varianten des gleichen Formates zu haben um mal die einen oder anderen Vorteile nutzen zu können.
Abwärtskompatibel ist natürlich beides mit vollen Typeinformationen.

Was soll eigentlich das Ziel dieses Formates sein? Irgend wie konnte ich das aus dieser Diskussion nicht richtig raushoeren. Text oder Binaer ist doch zweit rangig.
Fuer mich waere eigentlich nur die naehe zu Blender interessant, also ein Format dass das wiederspiegelt was ich in Blender kreeiren kann. Damit ich diese Daten einfach weiterverarbeiten kann ohne einen speziellen exporter zu schreiben.

Eigentlich ist Blender dabei nur die Umgebung die es uns überhaupt erst ermöglicht ein Eigenens Format so einfach zu entwerfen. Wenn das Format gut balanciert ist könnte ich mir durchaus vorstellen, dass vielleicht in einem halben bis einem Jahr es auch ein Cinema4D Plugin für das Format gibt... Das ist schlichtweg nur der Verbreitung geschuldet. Je besser das Modell jetzt geplant wird, umso schneller wird es seinen Platz erobern. Wenn man dann von dieser Seite aus Exporterscript(e) und Load (Delphi /C++) zur verfügung stellt, sollte das sicherlich seine Stellung erobern.

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

Wie Flash geschrieben hat ist es nicht unpraktisch ein wenig in die Zukunft zusehen und zu überlegen wofür man es noch alles einsetzen könnte. Und das ist auch genau ein Punkt an dem man feststellen sollte, dass das Format nur Mittel zum Zweck ist und man sich auf Binär oder Text festlegen sollte. Ich finde man sollte es so sehen wie Lars es auch schon mal erwähnt hatte. Der Loader bekommt seine Daten irgendwoher. Und je nach Ableitung kann dies Binär, Text oder als Speziallfall auch XML sein. Im Endeffket spielt es doch keine Rolle wo es her kommt. Es könnte unter anderem auch einen XML Loader mit den JEDI Klassen geben und einen der die XMLDOM von MS benutzt. Es muss an der Stelle nur eine astrakte Schnittstelle geschaffen werden.

Abwärtskompatibilität: Wenn man es tatsächlich vor hat das Format so public zu machen, dann sollte das definitiv auch gegeben sein. In meinen Augen würde es vollkommen genügen, wenn man zu Begin eines Objektes Informationen zum Überspringen des Selbigem ablegt. Also Größe oder sonst etwas. Bei Verteices würde das aus Platzgründen wohl kaum Sinn machen. Allerdings die Objekte in Version 1.0 müssen sowieso überall bekannt sein. Da muss man auch einfach mal herrausfinden was sich lohnt und auf Dauer bewährt. Ausgiebige Beta Phase zwingend vorrausgesetzt.

Nur zur Info, es wird weitergeschrieben an meinem Format!

Hier mal ein Link, ich hoffe das ist nicht zu schlimm das es eine Extra Seite hat!
http://wishlist.delphigl.com/index.php/ ... zum_Format

Edit:
Der Shader da drin ist übrigens gut wenn ihr einen Glow Effekt wollt!

_________________
Shareholder und Leitender Entwickler bei Pipedream-Games.

Zitat: Siehst du diesen Park da unten? Jeden Tag lernen sich darin Menschen kennen und verlassen einander. Und du hast dein ganzes Leben Zeit darin zu gehen.

OT: Hey Phob, hier misbraucht jemand die wishlist als projektplanungstool.

Nun wenn man den Datenblockansatz von Lars (Quasiklassen) benutzt, könnte man doch bei jedem Block mit angeben ab welcher Loaderversion das Feature unterstützt wird. Der Laoder würde dann sehen "Huch da bin ich zu alt für" und läßt die Daten weg. Somit hätte man Versionskompatibilität (Sogar nach oben)

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

Konnte es leider nicht auf meinen tripod Account bringen, zudem fehlt sowas!

_________________
Shareholder und Leitender Entwickler bei Pipedream-Games.

Zitat: Siehst du diesen Park da unten? Jeden Tag lernen sich darin Menschen kennen und verlassen einander. Und du hast dein ganzes Leben Zeit darin zu gehen.

Ja, so ähnlich hatte ich das auch gedacht. Das DGL Meshformat besteht dann aus einer gewissen Anzahl an Klassen mit Attributen die unterstützt werden müssen. Alles zusätzliche ist optional und kann als Extension deklariert werden. Z.B. könnten einige Attribute beim Mesh hinzukommen die nur speziell bei einem bestimmten Modeller vorhanden sind.

Ich erlaub mir mal wieder ne zusammenfassung.

Das Format soll mit Tags arbeiten und kann somit in Text und Binary abgespeichert werden da man die Tags mit Konstanten zahlen benennt die in der Binary den Tag ersetzten. Zum lesen der daten werden Strukturen verwendet die alle samt einen einheitlichen header besitzten der in etwa so aussehen könnte.

Im Textformat sind diese daten im header am anfang festgehalten und im Binären werden sie vor dem befehl selber gesetzt.
So ist es möglich die Versionsnummer zu lesen und festzustellen ob die Struktur vom loader überhaupt unterstützt wird.
Wenn das der Fall ist wird mit hilfe der passenden Struktur die daten ausgelesen. Wenn das nicht der Fall ist dann wird mit hilfe von size diese struktur einfach übersprungen und die nächste wird unter die Lupe genommen. So ist es Möglich mit einem gemeinsamen Klassensatz beide formate auszulesen, da der Text in die binärform interpretiert wird und dann verarbeitet wird.

Ich hätte da noch ne idee bezüglich der binären speicherform.
Aus einem <vertexarray>3,2,4,2,1,3,5,3,3.0</vertexarray> in textform könnte man in Binärform folgendes machen
[Header]
[0010]Version
[0012]size
[Zusatz]
[0001]typ (vertexarray)
[Daten]
daten des arrays
...

also statt immer ein tag auf und ein tag zu in der binärform zu nutzten einfach nur einmal ein tag der als typ festgehalten wird. Denn da wir wissen wie lang die Strukturen sein werden ist der Tag nur speicherfresser.

Type
Tag_Typ=(vertexarray,header,texturcoordarray,texturename0,texturename1,...);

const
Tag_Typ_Name:array [Tag_Typ] of string=('<vertexarray>', '<header>', '<texturecoordarray>', '<texturename0>', '<texturename1>', ...);

type
Tag_Header=record
version:cardinal;
size:cardinal;
typ:Tag_Typ;
end;

So könnte man über Tag_Typ_Name die Texttags in binäre Tag_Typ interpretieren und diese werden dann normal in den funktionen verwendet.[/code]

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

Projekte: https://github.com/tak2004

Das ist doch dann wieder viel zu unflexibel, wenn man spezielle Tags definiert und dann auch noch die Versionen prüfen muß. Und Typeinformationen sind bei dieser Varianten dann wohl auch nicht drin. Man muß also wissen welche Tags welche ID haben um sie korrekt auszulesen. Nein, das ist sicherlich nicht die richtige Lösung. Eine Datei muß selbstbeschreibend sein.
Ich habe ja auch vorgeschlagen die Start und Endmarkierungen wegzulassen, da man ja anhand der Typeinfos weiß welches Feld als nächstes kommt und wie lang es ist. Dann liegen die Vertex Daten in der binären Version nämlich direkt hintereinander im Speicher und können so als Vertex Array leicht weiter verarbeitet werden.
Das man Binär und Textformat gleich lesen muß ist klar. Wenn man hier noch zwei verschiedene Varianten macht ist das nur noch schwer zu warten.

Was haltet ihr dem von dem Beispiel hier?
http://wishlist.delphigl.com/index.php/ ... f#Beispiel

MfG
Flo

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

Der Vorschlag entspricht auch ungefähr meinen Vorstellungen, weil die Typen vorher genau beschrieben werden. Obwohl ich noch nicht genau verstanden habe, was variable Größe Type 3 bedeutet. Wenn man einfach einen beliebigen Datenblock unterbringen möchte, kann man das ja auch als Byte Array deklarieren. Die Größe muß bei allen Arrays natürlich vor den eigentlich Daten mitgespeichert werden.
Nur die Sache mit den Tabellen vor den eigentlichen Daten finde ich nicht so gut, weil man dann eben wie gesagt zwei Durchläufe über die Struktur benötigt.
Das es langsamer zu laden oder zu schreiben ist, wenn man die Typen und Strings direkt nach ihrer ersten Verwendung abspeichert, sehe ich auch nicht unbedingt. Der Loader erkennt, dass der Type oder String Index größer als die Summe alle bekannten Typen/Strings bislang ist und weiß das dann entweder der String oder die Typedefinition folgen muß.