Naja, außer Blender sollte man vielleicht noch Cinema4D unterstützen. Schließlich ist das auch umsonst downloadbar und um einiges benutzerfreundlicher.
Nur Cinema4D 6 war mal auf einer PC Magazin CD dabei. Auch wenn die Version schon etwas älter ist hat sie trotzdem einen guten Funktionsumfang und kann noch hier http://www.vollversion.de/download/maxo ... _1674.html herunter geladen werden. Die einzige Einschränkung ist die Renderauflösung, aber beim Modellieren sollte das egal sein.
Registriert: Di Mai 18, 2004 16:45 Beiträge: 2623 Wohnort: Berlin
Programmiersprache: Go, C/C++
Ein Exporter für die unterschiedlichsten sprachen zu schreiben ist weniger wild.
3D Studio Max, Cinema 4D, Blender, MilkShape bieten Scriptsprachen und leicht nutzbare SDKs aber das ist momentan eher nicht wichtig. Ich denke mal es wird eher ein kleinteil sein die sich eine 3ds Max oder Cinema 4D version gekauft haben von daher denke ich ist es sowieso zweitrangig.
Wegen der Unit, ich denke ebendfalls das alles aus einem Guß kommen sollte. Dies erleichtert den support und die verbreitung. Doch ist die Unit ein gutes Beispiel wie man soetwas machen kann .
Ich hab so mitlerweile das Gefühl das wir nun wissen was wir wollen und wir uns an die syntax von den formaten machen sollten. Ausser mit der Versionskontrolle, da glaube ich ist noch ein bischen gesprächsbedarf und zum Thema vorgegebene Variablentypen, aus denen die neuen Variablentypen und Strukturen gemacht werden, sollte auch noch eingegangen werden.
Doch glaube ich ist es erstmal leichter, wenn wir eine Syntax festlegen also wie ein tag aussieht wie er begind, endet anordnung von elementen. So kann man anschaulicher über das thema reden.
Mein Vorschlag wäre auf der gute html und xml struktur aufzubauen, mit ein paar modifikationen.
Tagregeln:
<tagname> (Öffnet ein Tag)
</tagname> (Schliest ein Tag)
Zuweisung von daten einer Struktur:
<tagname>
information1, information2,... (daten werden als array von element 1 bis element x durch komma angegeben)
<element1>information1</element1> (daten können für jedes element einzeln angegeben werden)
<element2>information2</element2> (im gegensatz zum array muss nicht jedes element zugewiesen werden und wird mit defaultwert besetzt)
</tagname>
neue Strukturen festlegen
<struct> (kennzeichnet das folgende tags als neue typen zu interpretieren sind)
<tagname>
element1:Boolean;
element2:Single;
</tagname>
</struct>
neue Vartypen festlegen
<type>
Tagname1:Boolean;
Tagname2:array char;
Tagname3:Boolean[5];
Tagname4:pointer of Boolean;
</type>
_________________ "Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren" Benjamin Franklin
Registriert: Do Sep 25, 2003 15:56 Beiträge: 7810 Wohnort: Sachsen - ERZ / C
Programmiersprache: Java (, Pascal)
Ich bin auch dafür, dass wir XML-Tags nehmen.
Als Grundtypen würde ich int, byte, char, pointer und single (eventuell noch word) nehmen.
Bei der Versionierung sollte man so vorgehen:
Die erste Version die von uns freigegeben wird hat die Versionsnummer 1.0.
Versionsnummern mit 0.x sind steuerinfos für den loader, die besagen, was geladen werden soll.
Z.B:
Wenn nur Vertexinformationen(V) geladen werden sollen wird dem Loader die Version 0.1 übergeben.
Wenn V und Normalen(N) geladen werden sollen, wird 0.2 übergeben
wenn V, N und Farben(C) geladen werden sollen, wird 0.3 übergeben
wenn V,N,C und Texturkoordinaten(X) geladen werden sollen wird 0.4 übergeben
wenn V,N,C,X und Texturnamen(T) geladen werden sollen wird 0.5 übergeben
wenn V,N,C,X,T und Animationsdaten geladen werden sollen wird 0.6 übergeben.
_________________ Blog: kevin-fleischer.de und fbaingermany.com
Registriert: Do Jun 19, 2003 10:44 Beiträge: 991 Wohnort: Karlsfeld (nahe München)
Hat jemand schon mit 64 Bit System Erfahrung? Mich würde mal interessieren was dann dort unter einen Delphi Integer, Single und Double verstanden wird. Und wie es mit den OpenGL Typen aussieht. Sprich aus wieviel Bits hat ein Paremeter von einer glVertex3[b]f[/f] Funktion?
Das mit den Pointern habe ich noch nicht ganz verstanden, wie wollt ihr Pointer abspeichern? Ich meine worauf zeigen die?
Das binäre Format solte noch folgende Typen haben um zum Text-Format kompatibel zu sein. Ok?
-Kommentar
-kein Bereich hat nur Namen (XML: <IchbinnurDa />)
-Bereich mit Eigenschaften (XML: <IchhabewichtigeEigenschaften WichtigeEigenschaft="23" BlaBla="bla" />)
-Bereich mit untergeordneten Bereichen(XML: <BereichzumTyp><untergeordnet /><untergeordnet /></BereichzumTyp>)
-Bereich mit Eigenschaften und Untergordneten Bereichen.<BereichzumTyp A="12" test="test"><untergeordnet /></BereichzumTyp>)
-binäre Daten ohne Typ wie z.B. eine in dem Modell abgespeicherte Textur (zu Not in XML: <hex>1FAD2F40</hex>))
_________________ Danke an alle, die mir (und anderen) geholfen haben. So weit... ...so gut
Das mit den Pointern habe ich noch nicht ganz verstanden, wie wollt ihr Pointer abspeichern? Ich meine worauf zeigen die?
Bei Pointern muß man dann eben auch das abspeichern, worauf gezeigt wird. Die Frage ist , ob man da beliebige Strukturen mit Zyklen oder nur Bäume erlauben sollte. Falls das Ziel des Zeigers in einer anderen Datei gespeichert wird, muß man eine Referenz auf die Datei und auf das Objekt mitspeichern. Z.b. könnten das gemeinsam genutzte Shader in einer Materialdatei oder ähnliches sein.
Das mit den Pointern habe ich noch nicht ganz verstanden, wie wollt ihr Pointer abspeichern? Ich meine worauf zeigen die?
Bei Pointern muß man dann eben auch das abspeichern, worauf gezeigt wird. Die Frage ist , ob man da beliebige Strukturen mit Zyklen oder nur Bäume erlauben sollte. Falls das Ziel des Zeigers in einer anderen Datei gespeichert wird, muß man eine Referenz auf die Datei und auf das Objekt mitspeichern. Z.b. könnten das gemeinsam genutzte Shader in einer Materialdatei oder ähnliches sein.
Sowas habe ich in meinem Format ja drinnen!
_________________ 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.
_________________ 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.
Ich finde auch, dass es aus einem Guß kommen sollte, was aber IMHO nicht gegen die genannte Unit spricht. Denn sowohl aus lizenztechnischer Sicht, als auch aus dem Grund eines möglichst geringen Frustfaktors spricht nichts gegen diese Unit. Sie ist leider nicht ganz endgeil, aber kurz davor. Habe selten so etwas praktisches gesehen.
In der DGL-SDK sind ja auch Fremdlibs enthalten und man muss sich trotzdem nichts zusammensuchen.
Von daher spräche recht wenig gegen TRAKBinaryStreamData. Wie gesagt, kann es nur wärmstens empfehlen.
_________________ "Für kein Tier wird so viel gearbeitet wie für die Katz'."
Ich habe mit diese Stream Units auch mal angesehen und die scheinen ganz ok zu sein. Man sollte das ganze vielleicht in einer Unit zusammenfassen, damit man es einfacher einbinden kann und dann nicht gleich 20 Fremunits da im Verzeichnis hat. Das ist immerhin eine funktionierende Lösung und sicherlich besser als der Durchschnitt von dem was hier selber zusammengestückelt würde. Gut gefallen hat mir auch der Editor mit dem man die Dateien immer lesen kann.
Registriert: Di Mai 18, 2004 16:45 Beiträge: 2623 Wohnort: Berlin
Programmiersprache: Go, C/C++
In 64Bit Systemen ändern sich die Typen wie Int nicht, denn integer beschreibt ein 32Bit Zahl mit vorzeichen und ein 64bit variable gibs ja schon int64 . Aber der Pointer wird sich ändern unzwar wird aus einerm Pointer mit 32Bit länge ein Pointer mit 64Bit länge was bedeutet eine Zahl ohne vorzeichen mit 64Bit.
Mit der Idee die GLTypen zu nutzten stimme ich ein, da die daten am ende in genau diese umgewandelt werden.
Aber wir brauchen zusätzlich noch String, PChar und Pointer, da diese für einige Funktion zusätzlich brauchen.
Wie z.B. das auslesen von supported Extensions mit string oder nutzten von VBO mit pointer.
Wegen der Unit, ich bin strikt dagegen diese zu verwenden, da es dgl sdk abhängiger von anderen units macht. Da wir sowieso vor haben eine unit zu schreiben können wir auch dies selber machen. Natürlich können wir uns Codesegmente ausborgen .
_________________ "Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren" Benjamin Franklin
Registriert: Do Sep 25, 2003 15:56 Beiträge: 7810 Wohnort: Sachsen - ERZ / C
Programmiersprache: Java (, Pascal)
Ist das so schlimm? Wenn wir im Gegenzug einen endgeilen loader griegen .
Idealer wäre natürlich, dass der Loader ansich alles enthält und man nur exakt eine Unit einbinden/verteilen muss. Aber bei komplexen projekten ist sowas quasi nie sinnvoll machbar.
_________________ Blog: kevin-fleischer.de und fbaingermany.com
Mitglieder in diesem Forum: 0 Mitglieder und 4 Gäste
Du darfst keine neuen Themen in diesem Forum erstellen. Du darfst keine Antworten zu Themen in diesem Forum erstellen. Du darfst deine Beiträge in diesem Forum nicht ändern. Du darfst deine Beiträge in diesem Forum nicht löschen. Du darfst keine Dateianhänge in diesem Forum erstellen.