Das klingt für mich alles nicht so legal wie es eigentlich sein sollte.

Aber ich glaube dir das mal. So intensiv (kriminell) habe ich mich damit auch noch nicht beschäftigt. Ich bin dann eher auf Pointer umgestiegen als Dinge zu verwurschteln.

Das mit den Versionen meine ich nur für Versionen unter der 1.0. All die Subversionen haben ne spezialbedeutung.

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

Ich glaube am ende haben wir ein leichten html clon ^^
Wenn man eine Anfrage an ein Webserver für eine datei macht wird auch ein header gesendet und in datenteil die datei selber. Der header weißt nur darauf hin um was es sich handelt also html1.1,... .
Ein Fileheader sollte gut ausgeklügelt sein, denn den in nachhinein zu verändern wäre vertal für die kompatibilität.
Die Versionsnummergeschichte würde ich auf ein Release.Subversion(C=custom) beschränken. also z.B. 1.1 oder 1.1C für
eine userseitig veränderte Version. Ich denke für bugfixes oder kleine addons sollte ein erhöhen der Subversion reichen und für änderungen in der Struktur, sprich neue tags sollte ein releaseversion geben. So kann man schnell erkennen ob eine Version stark veraltet ist oder nur kleine änderungen geschehen sind. Wenn jemand den Loader anpasst soll er es mit ein C kennzeichnen und mit den versionsnummer mit gehen. Die Versionen sollten nur einfluss auf die anzahl der erkannten Tags haben und nichts weiter. Um nur Teile der Datei zu laden sollte man lieber die Objekte passend designen.

Für das filehandling bin ich für den typ file of char und file und nicht für ne TStream klasse. Am ende ist es kein unterschied ausser in der kompatibilität.

DGLMESH 1.0 BINARY "Kommentar"#13#10

Dies halte ich für völlig ausreichend und man kann es in beiden formaten gut auslesen dank des umbruches

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

Projekte: https://github.com/tak2004

Spricht doch nichts dagegen sich hier und dort von ein paar Ideen inspirieren zu lassen.
Außerdem geht es nur um einen kleinen Header. HTTP macht noch viel mehr.


Das auslesen aus Dateien sollte davon recht unbeeindruckt bleiden da stimme ich dir zu. Allerdings finde ich ist die Kompatibilität ein nicht unwichtiger faktor. Mit einem File of char kannst du sicherlich nicht aus einer Resource lesen. Außerdem hast du so auch keine Möglichkeit zum Beispiel mit den Indykomponenten zu kommunizieren. MemeoryStreams gibt es auch noch. Zusätzlich unterstützen PNGs, Bitmaps und JPEGs das Laden aus Streams. Ich sage mal nur Texturen im Mesh. Das ist nicht zu unterschätzen.


Ich dachte da eher an Linux, Mac etc. In Linux besteht ein Zeilenumbruch nämlich nur aus #10 (oder wars #13). Aber nur aus einem davon. Deswegen halte ich das außerhalb von Text (wo beides fast ignoriert werden kann) für recht problematisch. In Binär könnte daraus schon die ein oder andere kritische Situation entstehen. Vor allem wenn man zwei erwartet aber nur eines bekommt. Wenn der erste Befehl dann ausgerechnet #10 wäre ist das nicht so praktisch. Da wirst du zustimmen.

Aber im Endeffekt war es nur ein Idee für den Aufbau. Welches Byte an welche Stelle kommt spielt jetzt glaube ich noch nicht so die Rolle. Sollange es sich in der Endwicklung befindet spricht ja nichts dagegen es zu ändern. Und das sollte man auch tun, wenn nicht so ganz hinhaut.

Ein apacheserver nutzt z.B. #13#10#13#10 als hinweis auf befehlsende, also wiegesagt es ist nur wichtig das es ein nicht druckbares zeichen ist um einfach problemen zwischen text und binary aus dem weg zu gehen. Ich glaube auch das noch ein bischen was passieren wird bis version 1.0 existent ist .

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

Projekte: https://github.com/tak2004

Hi,

und schon wieder bewegt ihr euch auf der Stelle.

TRAKBinaryStreamData würde die Entwicklungszeit sehr wahrscheinlich um einen nicht zu verachtenden Teil verkürzen und wie jeder weiß ist eine lange Entwicklungszeit oft der Todesstoß für ein Hobbyprojekt.
Diese Unit (Auch wenn es eigentlich mehrere sind) kann desweiteren problemlos erweitert werden mit speziellen Datentypen.
Und die Unit kann auch recht einfach von überflüssigen Datentypen bereinigt werden. Hab' ich mal ausprobiert und beim ersten Anlauf geschafft. Und das will was heißen

Dadurch entfallen die meisten Kritikpunkte. Die wenigen verbliebenen möchte ich hier noch aus der Welt räumen:

Stimmt. Es gibt verschiedene Units für die aktuellen Delphi-Versionen. Aber wenn wir die Unit von unnötigen Datentypen befreien, brauchen wir auch nicht mehr auf die marginalen Unterschiede zwischen den Delphis Rücksicht nehmen. Außerdem ist die Mehrzahl der Units im Internet in unterschiedlichen Versionen erhältlich bzw. in der Unit wird dann tonnenweise mit ifdefs gearbeitet. Ich finde die Lösung hier doch etwas eleganter


^^. Man braucht nicht sämtliche VCL-Units, Fremdunits braucht man schon gar nicht.
Wieso siehst du es als unvorteilhaft an, wenn die Unit viele Typen unterstützt? Man kann doch überflüssige einfach löschen. Ich persöhnlich finde das Löschen von vorhandenem Code viel einfacher als das Neuschreiben
Eine entschlackte Version sollte auch mit Lazarus keine Probleme machen.


Was hast du gegen ein Zwischenformat? Das erleichtert die Sache doch. Nicht umsonst haben z.B. sämtliche Canvas-Klassen von Delphi ein Zwischenformat. Oder ließt du etwa deine Bitmaps manuell ein um sie dann in ein TBitmap zu zeichnen?


All das lässt sich mit TRAKBinaryStreamData problemlos realisieren. Wie gesagt, meine komplette Engine basiert darauf und es läuft einfach himmlisch. Allein die Zeit zum File-Debuggen ist nicht mehr nennenswert, da sie mittlerweile gegen Null geht.

Wo du bei einem komplett eigenem Format das Problem hast, dass du die Datei bei einem Bug beim Speichern nicht mehr lesen kannst und höchstens mit einem Hex-Editor noch Ansatzweise die Datei betrtachten kannst, hast du mit dem Editor, der bei TRAKBinaryStreamData dabei ist ein recht komfortables Tool fürs debugging.

Sicher, es mag seine Vorteile haben, einen eigenen Loader zu schreiben, der nur das nötigste enthält, gleichzeitig aber auch perfekt auf die Anforderungen zugeschnitten ist. Aber es verlängert dadurch die Entwicklungszeit nicht unerheblich und damit steigt das Risiko, dass das Projekt auf Eis gelegt wird. Wie hier schon erwähnt wurde, gibt es hier viele Ideen aber nur relativ wenige, die sie umsetzen. Woran liegt das? Allein in diesem Thread wird hin und her diskutiert und gleich nocheinmal.

Mit TRAKBinaryStreamData hätte man dann ein Basis-Format und man könnte solange diskutieren, bis man blau anläuft *sg*. Denn es ist faktisch egal, wie so lapidare Dinge wie ein Versionsinfo oder der Datei-Header aussehen, da das alles bereits von der Unit gehandhabt wird.

Fazit: Ich denke, dass der Aufwand, TRAKBinaryStreamData auf die Anforderungen des DGL-Fileformats zurechtzustutzen wesentlich geringer ist als einen komplett eigenen Loader auf die Beine zu stellen. Mit XML, Ab- und Aufwärtskompatibilität, Objektstruktur, Streambarkeit, Fehlerfestigkeit, Wartungsfreundlichkeit... All das und noch mehr ist bereits vorhanden und wartet darauf genutzt zu werden.

Gruß,
Frase

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

Ja, entweder das RAK Zeugs oder das Streaming von Delphi. Beides sind ja mehr oder weniger bewährte Methoden. Wenn hier jeder seine privaten Frickeleien durchsetzten will, kommen wir nämlich nicht weiter.

Kleiner Tip Zeit ist weniger das Problem , sondern ein ordentliches resultat und mit der unit ist das nicht Möglich.
Ich weiß ja nicht ob du es schon gemerkt hast aber es soll auch systemunabhängig und auch nicht Pascal compiler abhängig sein. Sprich ein Delphi/Freepascal unit die auf z.B. Linux, Mac OS, Windows, Win CE und so weiter läuft. Ein erweitern dieser Libary würde eher in mehr zeit ausatem als eine eigene zu schreiben. Noch dazu weiß ich nicht was daran so aufwendig sein soll ? Wir sind programmierer mit meheren Jahren Erfahrung +-ein paar Jahre und ich glaub das eine eigene variante die bessere ist.

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

Projekte: https://github.com/tak2004

Ich empfehle jedem hier mal ausdrücklich die Lektüre vom Thread über den DGL-Benchmark. Lars hatte schon eine recht brauchbare Lösung geliefert, trotzdem wurde eine halbe Ewigkeit hin und her diskutiert und als Vorschlag kam dann doch im Großen und Ganzen Lars Lösung heraus. Von daher... Außerdem sieht man dort auch sehr schön, dass Zeit evtl. doch zum Problem werden kann. Oder tut sich etwa was beim Benchmark? Ich will einfach nicht alles andauernd diskutieren, wenn es schon mehrmals besprochen wurde. Ich finde, Lars hat vollkommen recht mit seiner Einschätzung des Dateiformats.

Ich hab' auch nicht gesagt, dass es uns an Erfahrung mangeln würde. Das wäre ja das geringste Problem. Aber ich weiß, dass wenn ich behaupte, das ein DGL-Dateiformat nicht im nächsten Jahr zustande kommen wird, wenn wir hier noch so weiter diskutieren, dass diese Behauptung stimmen wird. Das gleiche Gefühl hatte ich beim Benchmark nämlich auch. Auch dort wurden Vorschläge gebracht, vernünftige Vorschläge und sogar bereits Lösungen ganz am Anfang (von Lars) und wer hat da schon konkret auf diesen Lösungen aufgebaut?

Hier gibt es zwar noch keine vollständige Lösung, aber ich denke TRAKBinaryStreamData ist doch ein sehr guter Teilerfolg.

Ich denke sogar, dass es mit dieser Unit u.U. möglich ist, ein noch saubereres Resultat zu erzeugen, als mit einem selbst gestrickten Format.

Und ja, ich habe es bemerkt, dass es Platformunabhängig sein soll. Und das finde ich auch durchaus lobenswert. Aber ich verstehe nicht ganz, warum das gegen RAK spricht. Die Unit sollte doch recht einfach anzupassen sein und vielleicht greift uns sogar der Entwickler selbst unter die Arme .

Das mit dem "nicht Pascal Compiler abhängig" muss ich aber wohl überlesen haben. Soll das dann in eine Lib ausgelagert werden? Wollt ihr damit OOP bei dem Format über Bord werfen?

Aber was solls. Ihr macht ja eh, was ihr wollt. Egal ob es jetzt vielleicht besser ist oder auch nicht, und im Endeffekt könnte es mir auch egal sein, da ich das Format wohl eh nicht benutzen werde (Mangels Lust auf Blender). Wenn ihr dazu ein 3ds Max Plugin liefern würdet, sähe die Sache schon anders aus. Dann hätte ich sowas schon längst allein gemacht Ach träumen ist schön.
BTT:
Fazit: Nun, ich hab' mir des öfteren selbst ein komplett eigenes Dateiformat gebastelt mit eigenem Loader. Ich habe aber auch RAK benutzt. Ich kenne Blender ein bisschen, Linux läuft bei mir als Primär-System, mit fpc arbeite ich auch. Von daher... Ich weiß also halbwegs, wovon ich rede. Und wenn das jetzt hier noch so weitergeht, mit dem im Kreis herumreden, dann sehe ich da keinen Anlass mich am Format hier zu beteiligen. Bin nämlich kein besonders großer Fan von Stillstand und andauerndem Diskutieren über die gleichen Themen.

Gruß,
Frase

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

Ja genau. Das Problem ist ja nicht so was zu programmieren, sondern die Frage ist, ob man sich überhaupt jemals auf die Details einigen kann. Wichtig ist ja, dass alle mit dem Format halbwegs zufrieden sind, weil es sonst nicht benutzt wird. Grundsätzlich gehen die Ideen ja alle in die gleiche Richtung. Und wenn man einfach was fertiges nimmt, dann heißt das ja nur dass man das erstmal als Format nimmt. Es ist ja keiner gezwungen die RAK Units zu benutzen. Obwohl ich das Delphi Format auch nicht schlecht finde, weil die classes Unit schon dabei ist. Erstmal geht's ja ums Format. Das man da erstmal einen Standard hinbekommt. Loader kann ja jeder selber schreiben, wenn man nicht die vorgegebenen Units benutzen will. Mit Streams oder file of char. Ich programmiere ja z.B. in c# und werde sowieso die Pascal units nicht benutzen können.

Meine Einschätzung der Sachlage um was wir hier gerade diskutieren:

In diesem Tread soll ein neues Fileformat konzipiert werden welches als DGL-Format promoted wird und Anfängern wie Fortgeschrittenen reichen soll.

Nachdem wir beim eigentlichen aufbau des Files einige Punkte angesprochen hatten sind wir jetzt zum Thema Loader übergegangen.

Das Fileformat ist von der Sprache nahezu völlig unabhängig. Solange die Scriptsprachen der Modeller (wie Phyton im Fall Blender) in der Lage sind die Daten entsprechend unsere Formatdefinition abzuspeichern.

Der Loader muss natürlich in den Sprachen geschrieben sein, in dem er verwendet werden soll. Das heißt konkret:
Ein Delphiloader für unsere Comunity und idealerweise ein C++-Loader um das Format den restlichen 80% der Grafikprogrammierer zur verfügung zu stellen (das ist wichtig, damit sich das Format auch außerhalb unserer "Grenzen" durchsetzt).

Die Loader(!) sollten nach Möglichkeit nur eine Datei umfassen (also nur eine UNIT bzw. nur ein HEADER+SOURCE) welche später vom Nutzer eingebunden werden soll.

Das Fileformat soll in zwei formen also Binär und Text (XML ähnlich(!) ) aufgebaut sein. Zu diesem Zwecke werden 2(!) Exportskripte(!) pro Modeller geschrieben werden müssen. Der Loader soll beide Formate lesen können.


Ich bitte an dieser Stelle alle Beteiligten zu sagen ob diese Einschätzung korrekt ist. Das gilt dann als Beschlossen und umumstößliche Wahrheit für die weitere Planung.

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

Das mit dem "nicht Pascal Compiler abhängig" muss ich aber wohl überlesen haben. Soll das dann in eine Lib ausgelagert werden? Wollt ihr damit OOP bei dem Format über Bord werfen?

^^ hab da ausversehen ein "nicht" eingebaut aber es hätte eigentlich auffallen müssen, da ich im folgendem text dann vom gegenteil sprach.

Jo ich glaube auch die diskussion, ob diese unit oder nicht ist auch sinnlos. Wiso über was diskutieren was noch weit entfernt ist ? Wir haben immer noch keine genaue Syntax von daher ist es eher sinnlos über die codeseitige realisierung zu reden sprich fremdunit, eigene unit oder weiß der Teufel was es noch für dinge gibt.

Mir ist wichtig, dass eine ordentliche Syntax und eine Dokumentations zu den Richtlinien zu stande kommt. Wenn nötig schreibe ich mir mein eigenen Loader aber erstmal ist der erste Schritt zu machen und nicht über den letzten zu diskutieren.

Mir ist der Benchmark Thread wohl bekannt und muss sagen der ist nicht mit hiesiegen verlgeichbar. Die Idee des Benchmarks ist ja schon seit über ein Jahr vorhanden und unser gerade mal 2Wochen und für den Vortschritt den wir hier verzeichnen kann man wohl kaum von "in diskussionen verrennen" reden. Ich finde es toll wenn du einige erfahrung auf dem Gebiet hast und würde mich auch freuen wenn du diese einbringen würdest. Allerdings wird dieses Projekt nicht weiter kommen, wenn jeder hier schreibt was er für Erfahrungen hat ohne diese einzubringen.

Ich hab mal eine Testfile gebaut.


Nun sollte es leichter fallen, zu sagen was nicht so sein sollte und was dazu muss.
Ich hab erst überlegt die möglichkeit wie in xml vorhanden und im DGLMESH Tag genutzt, die daten im der tag eröffnung zu erlauben aber mir viel in diesem beispiel auf das es die leserlichkeit beeinträchtigt. Deswegen hab ich mal nur ein Tag so gemacht. Der DGLMESH Tag ist auch wie in XML der einzige Tag der kein ende, wie die anderen erwartet.

Ich bin gespannt was da für resonanz kommt und übrigens sollten wir langsam in erwägung ziehen im vorhandenem Wikieintrag die ersten Fakten zu verewigen. So sollte alle die sich am Projekt Beteiligen schnell sehen können, was schon für gut befunden wurde und was noch offen ist. Ich glaub auch das keiner mehr dagegen ist Tags zu verwenden und das Daten in Text und Binär gepeichert werden. Somit wären es schonmal 2 Punkte in der Liste und dann sind auch warscheinlich wieder gewisse Personen glücklich das sich was nicht im kreis bewegt .

EDIT:
Jepp, ich stimme dem vorigen post zu.

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

Projekte: https://github.com/tak2004

Wenn auch die anderen erstmal den Grundlegenden Sachen aus meinem vorhergehenden Post zustimmen, dann können wir das schonmal manifestieren.


was ich als MustHave unseres Formats sehen wöllte ist die Möglichkeit (auf die gefahrhin ich wiederhole mich ) Meshs gezielt Teilweise auszulesen. Ich glaube, dass es u.U. von nutzen sein kann, wenn man aus einem File welches Animation und allen Schnickschnack enthält nach Bedarf nur die Vertexdaten der Urform des Meshs laden kann. Ob das nun nur über den Loader geregelt wird, oder expliziet im File gespeichert steht, ist dabei noch zu klären.

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

Ich hab den Thread hier mal überflogen, und frage mich grade warum ihr hier was Eigenes machen wollt, wo es doch schon sowas wie Collada gibt? Das wird von der Industrie unterstützt, ist plattform-unabhängig (u.a. wird Sony dieses Format für die PS3 nutzen) , nutzt XML Schemata und es gibt Exporter und Importer für diverse 3D Packages und 3D Engines. Hier ist eine FAQ die genau erklärt was Collada ist und was es alles speichern kann. Dadurch dass es ja quasi XML und es verschiedene Profile (z.B. für verschiedene 3D-Packages) unterstützt kann man bei Bedarf auch selbst erweitern.

_________________
www.SaschaWillems.de | GitHub | Twitter | GPU Datenbanken (Vulkan, GL, GLES)

Ich persönlich kannte Collada bis jetzt noch gar nicht. Auf den ersten Blick betrachtet sieht das so aus, wie das, was das hier mal werden soll. Es ist wahrscheinlich so, dass, wie so vieles im Internet, den Meisten hier Collada nicht bekannt ist. Würde mich auch nicht wundern, wenn du der einzige hier bist, der davon etwas weiß
Das wäre ein möglicher Grund, warum hier versucht wird etwas eigenes auf die Beine zu stellen.

Ein anderer Grund: Inwiefern kann man Collada unter Delphi/Kylix/Lazarus/fpc nutzen?
Gibt es Importer und Exporter für Blender?

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