Aufwachen !!!
Keine einwände oder anregungen mehr zum aktuellen Status ?
Weil sonnst könnte man sich um die Bezeichner kümmern und mit dem coden anfangen.

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

Projekte: https://github.com/tak2004

Ich würde vorschlagen das du ein Tutorial oder ähnliches draus machst.

Also zum Beispiel mit dem Titel: "Entwerfen eines eigenen Level Formates"

MfG
Flo

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

da wäre ich auch dafür

Ich würde mich bereit erklären aber wie stehts mit den anderen ?
Welche Meinung habt ihr zu der Idee daraus ein Tut zu machen ?

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

Projekte: https://github.com/tak2004

Die Idee ist Grundsätzlich nicht schlecht, du könntest den vollen Gesprächsstoff der hier im Thread ist mit einbringen. Du kannst z.b. Vor- und Nachteile von einzellnen Strukturen aufgreifen und gezielt auf Probleme und Vorteile eingehen. Zusätzlich wie man es noch besser machen kann.

Das ganze sollte man allerdings auf mehrere Tutorials verteilen, wo dann auf einzellne Dinge eingegangen wird( Wie z.b. Ani. )!

_________________
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.

Hier mal 2 Beispiele die ich mir als Leitfaden gebaut habe.
http://e-e.neroneus.de/test.xml
http://e-e.neroneus.de/gui.xml

Ich hab ein Parserunit(dglxml.pas) geschrieben die diese XML Beispiele parsen kann und in eine Baumstruktur verfrachtet.


Nun wollte ich die DGLData.pas anfangen die diese Baumstruktur nutzt und die Daten interpretiert und dem Entwickler in die Hand drückt.

Ich wollte die Möglichkeit anbieten die Daten als Pointer,Typ und Anzahl an Elementen zurück zugeben oder über eine passende Funktion.
Jetzt wollte ich wissen ob ihr ne andere Idee zur datenübergabe habt oder die momentane Lösung gut findet.
Momentan muss man daten noch mit XML.Childs[0].Childs[0].Childs[0].name laden und diese sind immer string drum kommen eigene Funktionen noch die erlauben per Kategorie,Segment oder als Baumstruktur zu zugreifen.
Sowas sieht dann in etwa so aus:


Jede funktion gibt immer ein nachfahren von TChild zurück, welches aus dglxml.pas ist und so aussieht.

Also die neue Struktur würde von TChild abstammen und noch zusätzliche funktionen wie oben genannt und eventuell noch spezielle variablen beinhalten können für Format spezifische sachen.

Wie man an den beiden Beispielen sehen kann kann man mit der Variante echt alles machen, vom Meshformat über Levelformat,Userdaten bis zu einer Gui file.
Ich hab mir schon ein paar Formate für spezielle dinge wie Gui,Level,Sternensystem und Mesh aufs Papier gekrizelt und würde am Ende 2 von denen für Tutorials verwenden.
Die Flexibilität ist ziemlich stark und ein XML fähiger Browser kann sogar bei Syntaxfehlern helfen wie z.B. Internet Explorer, FireFox oder Conqueror.

Der momentane XML parser lädt leider noch die komplette file mit einmal aber das steht ganz oben auf meiner fixliste aber zuvor will ich erstmal ein Grundgerüst haben was zwar wackelig ist aber funktioniert.

Ich hab mir schonmal gedanken über die Strukturierung der Tutorialreihe für das Format gemacht.

Auch hier wären noch Hinweise und Kritiken notwendig, zwar werde ich mit dem Zeug noch nicht anfangen aber dann hab ich auch dies schon gut vorbereitet.

Wer hier angekommen ist mein respekt für das lange durchhalten und meine entschuldigung für den langen post.

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

Projekte: https://github.com/tak2004

Oh je, jetzt bin ich aber KO,
habe mich jetzt durch den gesamten Thread zum DGLMeshformat durchgearbeitet.

Alles in allem geht das genau in die Richtung dessen was ich mir schon immer gewünscht habe (Ich hab nur nie bemerkt, dass ich es mir wünsche ).
Die bisherigen Entwürfe gehen sogar noch weiter, z.B. "Syntaxcheck mit normalen XML Viewern möglich". Einfach herrlich!

Ich hoffe wirklich, dass daraus etwas wird. Man könnte zwar für seine eigenen Projekte wahrscheinlich auch immer ein geeignetes anderes Format finden, aber DGLMeshformat, das sorgt für ... hmm naja ... ich sag mal ... Prestige!

Wenn das ganze dann auch noch mit Tuts gut erklärt wird, denke ich, dass so ein DGL-Format durchaus Verbreitung finden könnte (C++ Loader vorausgesetzt). Würde mich freuen, wenn das klappt!

Was mich jetzt noch interessiert ist, wie es mit der Arbeit daran aussieht. Zieht das TAK2004 jetzt alleine durch? Ist das überhaupt machbar?

Ich bin leider nicht so der Monsterprogger und will da jetzt durch mithelfen nichts kaputtmachen . Außerdem habe ich momentan wirklich wenig Zeit (Austauschjahr in Taiwan).

Werde trotzdem schauen, ob ich nicht irgend ne kleine Aufgabe in der Wishlist finden kann, schließlich hat DGL mir (als passiver Leser) auch schon oft geholfen. Ein bisschen Schwung in die Community bringen ... .

@TAK2004: Das mit dem TChild ist mir noch etwas unklar. Kannste das genauer beschreiben, wie auch den sonstigen Aufbau? Zur Tutorialstruktur muss ich sagen, gefällt mir sehr gut! Das kommt aber nicht alles in ein Tut, oder?

_________________
Flummi: Projektseite und Projektthread

Ich progge das allein, da ich genug zeit habe dafür, allerdings warte ich momentan auf response bevor ich weiter mache.
Der schwerste Teil ist für mich nur der xml parser , den ich ja schon geproggt habe und im alpha state ist.
Der XML interpreter ist der wichtige teil der dann die ganzen Regeln beinhaltet und die exporter sind dann eine benötigte beilage.
Weiß ja nicht ob du es mitbekommen hast aber das kleine Blender python exporter script im wiki war von mir somit ist auch ein passender exporter für blender kein problem.
Also die programmierung ist weniger das Problem als die lesbarkeit und von entwickler leicht bearbeitbar ist.

Der aufbau ist simpel, es gibt ne liste von TChilds und jedes Child enthält ne eindeutige ID sowie den namen eines tags oder wertes.
Jedes TChild hat selber ne liste von TChilds und somit kann man Baumstrukturen erstellen.
Nun wird alles zwischen ein Star und endtag in den startag gepackt und der endtag wird gelöscht.
Wenn er durch ist hat man ein tree der fertig sortiert ist wobei der tiefste Child ein wert ist.
Soviel zum thema parser, der interpreter muss dann den baum mit den regeln die wir festgelegt haben überprüft werden.
Also wenn ein tag namens "<category>" kommt muss er festlegen das es eine Kategorie ist und so weiter.
Mit hilfsfunktionen kann man dann daten auslesen und dank XML sowie unseren Regelwerk kann man auch das Format für andere Datenstrukturen benutzen nicht nur Mesh.

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

Projekte: https://github.com/tak2004

Wie du den Inhalt gestalltest möche ich mal dir als Autor des Tutorials überlassen, jedoch würde ich mal anmerken das es vielleicht besser wäre auf vorhandene XML Praser zurückzugreifen anstatt ihn "erneut zu erfinden".

Das mangelde Feedback liegt sicher an dem großen Thread den dann keiner mehr liest. Denke aber mal das sich für ein fertiges Tutorial mehere begeistern könnten.

Der Index sieht vom Inhalt und Aufbau gut aus. Die genaue Unterteilung wird sich sicherlich beim schreiben des Tutorials ergeben. Im Vorraus ist das schwer zu sagen wie lang ein Teil wird.

MfG
Flo

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

Ich bin auch ein Fan von neuen Tutorials. Aber bitte gleich im Wikiformat... (Das Übertragen schlaucht bei großen Tutorials auch ganz schön )



Die Einstellung lob ich mir! (Wenn das noch 3,4 machen sieht vielleicht Phobeus mal wieder das Tageslicht.)

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

Okey das reicht mir an response, dann werde ich mal heute wieder weiter schreiben. In den Tagen dazwischen hab ich ein Basecode für ein Strategiespiel geschrieben und Teile meine alten Engine in meine neue eingepflegt. Man kann in der Demo schon Gebäude bauen,ein Charakter rumlaufen lassen,kann kaufen/verkaufen,gui funtzt,hat ne map und war gerade dabei ein Techtree zu bauen der erlaubt abhängigkeiten zwischen Gebäuden und Forschungen zu erstellen. Ist schon erstaunlich was man alles so schaffen kann, wenn man nicht zockt und nicht durdh irgendwas abgelenkt wird

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

Projekte: https://github.com/tak2004

Ahh, gut. Hab jetzt glaub ich auch verstanden, wie das funktionieren soll. Danke!

Wenn auch noch ein Blenderexporter geschrieben wird muss ich wenigstens nicht auch noch Python lernen .
Exporter fuer andere Modeller (3dsmax, cinema4d, maya ...) kommen dann sicherlich auch noch von diversen Personen mit Interesse. Ich selbst brauch aber nur Blender.


Ja, und wenn er dann hier im Forum sein neuestes Projekt vorstellt, haben wir wohl zu viel getan

_________________
Flummi: Projektseite und Projektthread

Dass Exporter für 3ds max kommen, bezweifel ich doch etwas... Exportermäßig hat Blender ganz klar die Nase vorn und da man bei 3ds max nur mit dem SDK Plugins schreiben kann und das dann auch nur für die aktuelle Version (Da die 3dsMax-Plugins nicht abwärts/aufwärtskompatibel sind) sehe ich da recht schwarz... Und wer hat schon Lust, sich mit Max-Script herumzuplagen

Wie's bei Cinema4D aussieht, weiß ich nicht, bei Maya hingegen könnte ich mir schon vorstellen, dass es wahrscheinlich wäre. Dort mangelt es dann aber wieder an Leuten, die Maya benutzen...

Schade eigentlich, aber ändern wird sich das wohl nicht in nächster Zeit ...

Und in Bezug zu Flow und Arbeit wäre ich ein bisschen vorsichtig, da hat man schneller ein Todesurteil am Hals, als einem lieb ist

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

Naja ich dachte eigentlich an ein Exporterscript da ein plugin wiegesagt eine Lizens von Max benötigt.
Der Nachteil am Script ist klar die geschwindigkeit aber es ist nicht schwer zu realisieren.
Meine erfahrungen zum Maxscripten und Max SDK sind stark eingerostet unzwar mit version 6 und mit der neuen Version 8 die im Dezember als Deutsche Version erscheint hat ein komplett neues SDK mit neuer Doku nicht wie die letzten Version die mit SDK von Max5 rumschwirrten.
Aber das Scripten mit der neuen Version ist sehr geil im Workshop wo ich war wurden die neuen Scriptfeatures wie Variablenviewer sowie ein super Debugger und einiges nettes mehr vorgestellt. Übrigens für Studenten gibs 3ds Max 8 mit allen drum und dran ausser das recht dinge für comercial zu nutzen für schon 116€ bei Lichtbild4d. Aber ich denke die leute werden sich lieber mit Blender anfreunden ,da es sehr einfach von der Bedienung ist, es ist kostenlos,für Komerzielle zwecke nutztbar und es ist gerade für OpenGL progger praktisch da Blender intern schon optimierte OpenGL Daten beherbergt und ausserdem hat man die möglichkeit jedem objekt selber daten anzufügen. Super zum mappen,super für modeln und super zum texturieren ^^

Ausserdem kann blender mehr User gebrauchen um somit mehr developer für die weiterentwicklung zu werben und die momentanen entwickler zu zeigen das sich ihre arbeit lohnt.

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

Projekte: https://github.com/tak2004

Lichtbild4d... Werd' ich mir mal näher anschauen. Klingt gut
Ansonsten... Blender kann wirklich mehr Leute gebrauchen.

@Script: Kann man in MaxScript auf die gleichen Informationen zugreifen, wie in den Plugins? Also auf den Mesh, Material, Textur(-Koordinaten), Animationen, Bones, Modifier...?

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