Frage 1 :
beides macht meiner Meinung nach nur den Laoder komplizierter und vereint die Nachteile beider (Langsam zu laden, da Textanteile, nicht immer lesbar da Binäranteile ...). Ich tendiere inzwischen auch zu einem Textformat, da dieses extrem leicht erweiterbar ist, und für schnelles Laden in Binärform gespeichert werden könnte (extra funktion des Loaders ??)

_________________
Bevor du definierst, was etwas ist, versichere dich seiner Existenz.

Mal eine Frage meinerseits:

Wer hat sich schon im wishlist Wiki die Formate mal angeschaut?

Dort gibt es schon eine Vor und Nachteilssammlung:
http://wishlist.delphigl.com/index.php/ ... _Vorschlag

Erweiterbar ist zum Beispiel die Binäre Baumsturktur genauso, sie bietet genausoviel wie XML nur noch ein bischen mehr da man nicht auf Text beschränkt ist (zum Beispiel könnte man einen Typ Vertex Array definieren). Das editieren und anschauen der Modelldateien ohne 3D Programm könnt ihr vergessen. (Wers nicht glaubt sollte mal mein altes 3D Modeller Program rauskrammen; bei dem Projekt ist mir das klar geworden das man gute Objekte nicht durch die Eingabe von Zahlen erstellen kann). Dazu könnte man ja so eine binäre Baumtstruktur zwecks debuggen des Loaders gut in eine XML Form umwandeln. Anders rum, also von XML zur binären ist das ohne weitere Formatvorgaben nicht so gut möglich.

Ein Vertex-Array Typ könnte dann zum Beispiel in das umgewandelt werden:

oder auch(wenn man es möchte) in:

wobei erste Version fürs überprüfen des Loaders wohl doch anschaulicher ist.

Im binären Format würde so ein Vertex gerade mal 12 Bytes belegen. In der zweiten (XML richtigeren) Version 72 Bytes !!
(die Konotenpunkte dürften ungefähr gleich viel Platz benötigen, wenn man die bei der binären Version benötigte Tabelle berücksichtigt)

MfG
Flo

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

Den Loader müßte man gar nicht doppelt schreiben wenn das Text und Binärformat 1:1 übereinstimmen. Man braucht nur eine Klasse Reader mit Funktionen wie ReadToken, ReadInt, ReadFloat usw.. und dann davon abgeleitet TextFormatReader und BinaryFormatReader. (Writer dann entsprechend)
Ganz wichtig bei so einem Format sind aber vollständige Typeinformationen. Alle Objekte die innerhalb der Datei gespeichert sind müssen vorher beschrieben werden. Eigentlich will man ja, egal bei welchen Format auch immer, nichts anderes als seine Objektstruktur in eine Datei schreiben und die gleiche Struktur nacher wieder herauslesen. Bei vollständiger Beschreibung kann man dann nur aus der Datei heraus die Klassen und Objekte erstellen und auch wenn sich z.B. im Programm einiges an Formaten geändert hat ist man aufgrund der Typeinformationen abwärtskompatibel. Damit meine ich ganz konkrete Klassendefinitionen wie man sie in Delphi hat. Also in der Datei müßte stehen die Klasse Vertex hat z.B. die Felder x,y,z vom Type single und r,g,b,a vom Type byte. Die Klasse AnimationSequence hat ein Feld Name vom Type string und ein Array Keys von Type AnimationKey. usw... Am besten speichert man die Typen am Anfang der Datei und möglichst einfach.
Erst auf so einem allgemeinen Format aufbauen kann man dann den DGL Standard definieren, der dann minimale Vorraussetzngen beschreibt, z.B. dass es eine Meshklasse geben muß, bei der die Vertex Daten in einem Feld "VertexArray" gespeichert werden usw...

Wenn ich dich richtig verstehe willst du eine Tag basierte variante in binary damit vorstellen.
Sprich ein tag hat ein Wert zwischen 0 und 255 und per konstanten werden diese festgehalten.
Sprich
const
Command_Tag=0
Header_Tag_Open=1
Header_Tag_Close=1
Verticearray_Tag_Open=2
Verticearray_Tag_Close=2

type
header:record;
ID:cardinal=1;
data:array of byte;
end;

header_advanced:record;
ID:cardinal=2;
name:string;
blakeks:cardinal;
end;

und dann durch z.B. der Kombination 01 darauf hinweisen das der header aufgemacht wurde, dann die daten rausgelsen werden(durch den passenden typ) und wenn ein 01 kommt der Header zuende ist und wenn nicht halt die nächste struktur gelesen wird.

Oder hab ich da was falsch verstanden ?
Weil diese Variante so wäre sehr Praktisch.
Es würde die alle Vorteile von Binär mit der Flexibilität von Text vereinen.
Der einzige nachteil ist man müsste erst mit einem Tool die daten in lesbaren text convertieren, was aber eher ein kinderspiel ist.

Edit:
Wenn ich das bisher richtig verfolgt habe, sind wir einer Meinung bezüglich eines auf Tag basiertem Formates.
Aufgrund der Flexibilität und lesbarkeit.

Ob Text oder Binär sehe ich noch als ungeklärt an.

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

Projekte: https://github.com/tak2004

Ich bin ein überzeugter Fan von Binärformaten und benutze nur recht selten Textformate. Aber allen erstes bin ich der Überzeugung, dass man beides unterstützen muss! Bei der derzeit recht übersichtlichen Anzahl an Stimme die sich melden hat man schon klar zwei Lager. Binärlager und Textlager. Entweder man schafft es sich auf eines zu einigen oder beides muss implementiert werden. Anderenfalls dürfte sich das Format recht fix in Wohlgefallen auflösen, da dann alle ein wenig frustriert sind.

Wenn man sich ein Format ausdenkt was sowohl Text auch Binär kann dürfte man die wenigsten Problem haben. Der strukturelle Aufbau muss bei beiden gleich sein. Lediglich die Informationen sollten unterschiedlich abgelegt werden. Ein paar abstrakte Objekten wirken da Wunder. Genau wie Lars das auch meinte.

Delphi DFMs sind ja auch Text, Binär, Text aus Resource oder Binär aus Resource. Wo die Daten nun her kommen halte ich für so etwas von unwichtig. Viel wichtiger ist doch die Struktur der Daten. Aber so blockbasiert ist immer schon eine sehr praktische Erfindung.

Mit den Tags meinte ich das ungefähr so:





Namen sollten spezielle Arten von Strings sein die sich häufig wiederholen. Da braucht man in der Binärvariante nur beim ersten Mal den String und danach nur noch einen Index zu speichern. Die Tabelle mit den Namen kann man während des Schreibens und Lesens aufbauen.



Aus so einem Format bekommt man die Daten immer wieder heraus. Man kann sich zudem z.B. ein Tool schreiben, dass aus einer Datei die entsprechenden Delphi Klassen generiert und eine Loader Unit erstellt.

Also die Klassendefintion würde ich so nicht machen. Wenn man konfigurieren kann welche Felder in einem Vertex enthalten sind, dann solte das vollkommen ausreichen. Es würde genügend flexibilität bietet und würde vom Parsen und benutzen her nicht zu kompliziert sein.

Ich würde dann auch darauf achten, dass Binär auch wirklich Binär wäre. So hat es mich noch zu viel Textzüge. Also dadurch, dass X, Y und Z alleine auch schon als Text enthalten sind. Irgendwo muss man dem Loader dann ja auch sagen was er mit welchen Daten anfangen soll. Und da würde ich sagen ein Vertex hat eine bestimmte Anzahl an möglichen Feldern. (Koordinaten, Farben, Texturkoodinaten, Sonstige Parameter)


Ich denke mal, man sollte es nicht zu perfekt machen. Der Vorteil ist im Vergleich zum Aufwand eher ungerechtfertigt.


Ob ein Vertex auch abgeschlossen werden muss stelle ich mal so dahin. Normal ist seine größe durch die Definition festgelegt.

Gut das begin/end kann man sich innerhalb der Daten sparen (Beitrag oben editiert). Der Type ist ja durch die Deklaration festgelegt und so liegen die Vertexdaten im binären Format wenigstens hintereinander. Aber vollständige Typeinformationen(nicht nur konfigurierbar) sollten schon drin sein und das Format sollte unabhängig von konkreten Typen sein. Der Loader soll gar nichts mit den Daten anfangen, denn es geht ja um ein allgemeines flexibeles Format. In deinem Bsp sind nicht genug Informationen enthalten um die Objekte aus der Datei ohne Zusatzwissen zu extrahieren .

Ja so habe ich mir das auch ungefähr mit dem Binären Typformat vorgestellt:

Es gibt eine Tabelle (bzw. Liste)die am Anfang die Typdeklarationen enthält. Ein Block beginnt immer mit einen Index auf diese Typdeklaration.

In der Typdeklaration ist ganz für jeden Typ eindeutig festgelegt:
* Wie groß er ist
* oder das er eine Variable größe hat. und nach dem Typ-Index bei jedem Block die größen Angabe des Blockes folgt.

Das hätte den Vorteil das man sobalt man Kopf und falls vorhanden Größenangabe eingelesen hat sofort zum Ende springen kann.

Neben dieser Typtabelle gibt es dann oben auch noch eine String Tabelle in der sämtliche Tag und Eigenschaftsnamen abgelegt sind. Auf diese kann dann wieder mit einen Index zugegriffen werden.

Beides zu haben binäres und Textformat, wäre möglich wenn genau festgelegt wird wie zum Beispiel ein Block der den Typ Vertex-Array beschreibt in der Text-Version aussieht.

siehe auch: http://wishlist.delphigl.com/index.php/ ... at_Entwurf

Ansonsten weitere Vorschläge bitte ins wishlist Wiki.

MfG
Flo

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

@Lars: Na ja. Okay. Das ist auch irgendwo wahr. Ich befürchte da nur, dass das eine solche Komplexibilität die Geschwindigkeit, Übersicht und die Unanfälligkeit gegenüber von Fehlern negativ beeinflussen wird. Und ich schätze mal, dass solche eine komplexe Flexibilität nur von einer Hand voll Leuten genutzt wird (werden kann).

Komplexität:
So ein allgemeines Format ist nicht zu komplex, weil man die Funktionalität zum Lesen und Schreiben nur ein einziges Mal programmieren muß.

Zu Tabellen in Formaten:
Tabellen wie z.B. Strings oder Objektreferenzen sind schwer zu schreiben, weil man dann am Anfang erstmal alle Strings durchgehen müßte. Dann lieber die Tabellen die man braucht generell während des Schreibens/Lesens füllen. Also man schreibt immer einen Index und nur beim ersten Vorkommen dann den Eintrag dahinter.

Eigentlich eher Formate(Typdeklaratione) in Tabellen

Also bei Blender läuft das beim Exportieren normalerweise so ab das man erst die Daten in der gewünschten Form in einen Objekt-Baum abspeichert. Danach schreibt man die Daten nur noch in die Datei. Bei diesen Trasfarieren in den Objektbaum das wir sowieso machen müssen, können wir auch gleich die Tabellen aufstellen. Auch andere benötigte Datein wie Blockgrößen können dann ermittelt werden, falls diese nicht offensichtlich sind.

Ich habe jetzt mal ein, zugegen nicht ganz fertiges Beispiel ins Wiki gestellt:

http://wishlist.delphigl.com/index.php/ ... f#Beispiel

MfG
Flo

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

@Benutzung: Die meisten Leute werden einfach das Writerscript und den Loader nehmen und denen isses Wurscht was drinnen steht. Die Vielseitigkeit ist dann nur für die "proffesionelleren" anwender interessant. Und die sorgen dafür, dass das Format Verbreitung findet.

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

Nun ja. Ich weiß nicht inwieweit es da Unterstützung von Blender her gibt, aber so ein zweischrittiges Speichern ist unter Delphi dann doch eher umständlicher. Und wie verschachtelt man dann Objekte ineinander? Man hat ja nichts davon wenn man am Ende ein paar große Listen hat und die Beziehungen dann über Indizes oder Ähnlichem heraussuchen muß.

Ich bin eigentlich davon ausgegaben das wir ein Format brauchen das auf Lade und nicht auf Exportzeiten optimiert ist.

Wenn man vorher schon weis was das format beinhaltet, oder mininmal größere Datein in kaufnimmt kann man auch direkt die Daten exportieren. Den schrtt der Anpassung kann man natürlich nur dann weglassen wenn nichts anders anfällt. Bei Blender ist es oft noch nötig die Mischung aus Vier und Dreiecken einheitlich zu Dreiecken zu machen.

Edit: @ Lars: ach ne so kompliziert habe ich das gar nicht gemeint.
MfG
Flo

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