Ich kannte das bisher auch nicht.

Nun...wenn der Funktionsumfang stimmt, wäre das sicherlich eine Alternative

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

Nach dem Inhalt der Seite:
"Jeder Entwickler hat sich zur Zeit selber um einen Importer / Exporter zu kümmern"

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

So was nennt man unerwartete Wendung

Also, versteh' ich das richtig, dass kein richtiges Collada-SDK existiert, sondern nur PlugIns für 3ds Max, Cinema 4D, XSI und für OSG von 3dlabs? Also kein Blender? Und ein SDK für Delphi hab' ich dort auch noch nicht gefunden. Bleibt also die Frage: Wäre das was für uns?

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

Ich hatte mir das schon vor einiger Zeit mal angesehen und fand das ein wenig überladen. Falls man schon von Cinema4D exportieren kann ist gut, aber andererseits ist so ein Exporter auch schnell gemacht.

Das sehe ich als das kleinste Problem. Viel intressanter wäre wo es zum Beispiel Tutorials über dieses Format gibt, oder andere Informationen die an Ersteller von In - und Exportern gerichtet ist. Auch die Frage ob es das ist was wir suchen versuche ich gerade noch auszuloten.

Mein erster Eindruck ist allerdings schonmal nicht schlecht. (Das Feature "Plattformunabhängigkeit" empfinde ich allerdings als schlechten Witz, da ich mir nicht vorstellen kann wie ein offenes Format für 3D Modelle Plattformabhängig sein kann)

Den großen Vorteil sehe ich vorallem darin, dass das Format schon fest steht und offen ist und wir keine Spezifikationen verfassen müssen.

Die Spezifikationen habe ich hier gefunden:
http://collada.org/public_forum/viewtopic.php?t=209

MfG
Flo

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

@Blender :
Die Macher von Blender (und anderen 3D-Paketen) wurden bereits dazu "eingeladen" Ex/Importer für Collada zu schreiben. Soweit ich weiss gibts sowas aber schon von einer Privatperson, einfach mal im Collada Contributions-Forum suchen.

@SDK :
Collada ist "nur" ein Dateiformat. Da braucht man doch kein SDK für, da reichen ja die Spezifikationen um Exporter/Importer und andere Sachen zu entwickeln die das Format nutzen.

@Collada und Delphi :
Collada ist ja wie gesagt ein XML-Schema, von daher kann man das bequem mittels XML-Komponente bzw. XML-Loader laden und nutzen.


Man darf allerdings nicht vergessen dass Collada noch sehr frisch ist und es daher noch nicht sonderlich viele Exporter bzw. Importer gibt. Den 3D-Studio Exporter den ich mal angetestet habe (vor einigen Monaten) war leider nicht 100%ig. Allerdings sind bereits reichlich große Namen an Board und sogar die Khronos Gruppe hat Collada für OpenGL|ES adaptiert (siehe hier). Und das ist dann auch der größte Vorteil ggü. z.B. nem DGL-internen Format. Viele Hersteller an Bord zu haben bedeutet dann auch dass es für viele Anwendungen Importer/Exporter gibt und geben wird.

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

Ich kenne Collada von den OpenGL News aber wie heisst es doch so schön "Aus den Augen aus dem Sinn".
Es sieht fast so aus als könnten wir diesen Thread fast schließen.

Ich gucke mal schnell nach ob alle Punkte erfüllt werden und ob jemand schon ein Exporter für Blender gebaut hat.

EDIT:
So bin mal durch die Specs durch und auch durchs Board. Ist nicht der Burner es ist ähnlich wie unser Konzept nur ist dessen für uns nicht so das richtige. Die Strukturen sind im vorhinein festgelegt worden und liegen auf dem colleda.org server. Also wenn man ein Loader schreiben will muss man entweder eine verbindung zum inet haben oder immer mit jeder version den loader neu machen, da sonnst nicht die neuen Strukturen verstanden werden. Da eh ein Loader sowie ein exporter dann geschrieben werden muss bin ich dafür nur uns an den Strukturen vom collada zu bedienen und fertig.

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

Projekte: https://github.com/tak2004

Also wenn das so ist, ist es nicht gerade sooo flexibel.

Du Sascha, du hast ja auch schon recht viel mit importierten Meshs gearbeitet.
Wie würdest du es finden, wenn man gezielt nur spezielle Informationen aus einem File laden kann (Also z.B. aus einem File welches ne Ani und was weis ich ...Shader... enthält nur die Vertexdaten der Urform des Models zu laden, und die anderen Infos wegzulassen). Ich versuche persönlich gerade auszuloten, ob für sowas Bedarf besteht.

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

Also Vertexgroups sollte man implementieren für Animationen. Speziel eine Gruppe zu laden sollte dann kein Problem mehr sein...

MfG
Flo

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

Ich bin gerade auf cal3d gestoßen:

Zitat aus: http://cal3d.sourceforge.net/docs/api/h ... 3dfaq.html


Features laut Readme:


Da Blender schon einen entsprechenden Exporter hat, brauchen wir eigentlich nur irgendwie eine Pascal anbindung in zum Beispiel Form eines weitern Headers schaffen.

MfG
Flo

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

Ich hatte mal zu cal3d eine delphidemo und musste sagen die lib ist supper, dass mischen von meheren animationen und eigenen festlegungen sind sehr überzeugend. In der Demo die ich kenne war noch eine LOD funktion drin aber ich weiß nicht ob die von der lib kam.

Zum format hab ich mal wieder eine tolle variante gebastelt.



Als erstes der Header den ich zum vorigen Beispiel nicht verändert habe, dann kommen die Kategorien.
Um später sagen zu können lade nur vertice oder texturkoordinaten legt man eigenen Kategorien fest und weist diese den typen zu. So kann man später mit dem GetCategoryData('Vertice') z.B. nur Vertice laden oder man sagt vertice,texcoord und normalen sind unter mesh bekannt und wenn ich diese daten haben will lade ich mit GetCategoryData('Mesh') dann alle daten die in diese Kategorien eingeteilt sind.
Eine Type Sektion erlaubt das defenieren von grundtypen und eine Structure Section erlaubt die erstellung von Typen bestehend aus meheren Typen. Comment ist ein Kommentar und durch Tag(auf) und Tag(zu) kann man mehrzeiligen Text schreiben. Data leitet eine Datensektion ein also wo wirklich die daten gelagert werden. So kann man mehere Datensektions ermöglichen für z.B. Level-1 und Zwischensequenz. Im Datatag sollte dann die länge und die benutzten typen stehen die im Datateil vorkommen. So kann man die sektion überspringen und muss die daten nicht einlesen und wenn bestimmte daten oder die damit verbundenen Kategorien sucht braucht man nur im header gucken und weiß ob der teil die gewünschten daten enthält.

Und was meint ihr ?

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

Projekte: https://github.com/tak2004

Hast du das Beispiel noch? Oder weist du wie man die Bibliothek mit Delphi nutzen kann?

Für ein eigenes Dateiformat hätte ich sonst noch den vorschlag Informationen in XML und andere Daten in binären Dateien abzuspeichern. Damit besteht zwar ein Modell aus meheren Dateien aber diese könnte man ja in einen Zip, tar oder tar.gz Archiv zu einer Datei zusammen fassen.

Hier mal ein Beispiel + Erklärung
http://wishlist.delphigl.com/index.php? ... oldid=1428

MfG
Flo

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

Ich habe das ganze nochmal gründlich überdacht. Das Hauptproblem ist der unterschiedliche Verwendungszweck.

Der eine möchte nur einen Loader und Exporter für ein einfaches Modell. Für ihn ist es von Vorteil wenn das Format verbreitet und anerkannt ist. Vorteilhaft ist also einhalten an Standarts, Einfachheit und klare Regeln wie was auszusehen hat. Schließlich wäre es fatal wenn unter Umständen ein Format exportiert werden kann, welches nicht alle Loader auch laden können.

Der andere brauchst ein Format welches auch noch sehr viele Anwendung spezifische Daten mit abspeichert. Hierbei können die unteschiedlichsten Ansprüche an das Format entstehen, angefangen bei komplexen Typen bis hin zu eingebundenen binären Dateien.

Wer sich diesen Konfikt vor Augen führt für dem sollte klar sein, dass es ein optimales Format für beide Verwendungszwecke nicht geben kann. Meine Empfelung ist daher, dass wenn ihr ein an die eigene Anwenung angepasstes Format entwickelt euch keine zusätzlichen Standartszwänge oder ähnliches auferlegt. Programmiert einfach das an eure Anwendung am besten angepasste Format und dokumentiert es entsprechend. Andernfalls nutzt schon vorhandene Formate wie das cal3d Format, welches gut eure Unterstütztung bei der Verbreitung gebrauchen kann.

MfG
Flo

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

Mein Gedanke bei diesem Projekt liegt darin ein Format zu schaffen, was es ermöglicht mit wenig aufwand ein Dateiformat in ein Programm zu implementieren. Diese Format sollte sich selbst erklären und leicht erweiter bar sein. Um eine erweiterung zu erleichtern sollte eine Textform vom Format möglich sein und im release dann als Binary genutz werden.

Eine Textdatei erlaubt das schnelle kontrolieren auf fehler in der Struktur oder Möglichkeiten der optimierung der Strukturen.
Hierbei sind die Werte eher nebensächlich und sollten wie Flo es vorgeschlagen hat auslagerbar sein.
Also die möglichkeit zu haben, zu sagen von dieser Struktur will ich nur die Struktur aber nicht die daten sehen und werden somit ausgelagert. Diese auslagerung sollte in eine Binary file geschehen, dass spart Platz, ist schneller zu lesen und bewart die übersichtlichleit.

Wer mit seinem modifikationen fertig ist, kann dann das Format als eine Binary File abspeichern, da nun nur noch geschwindigkeit zählt.

Der Vorschlag, die augelagerten daten in unterschiedliche files nach datentypen zu lagern behindert eher den Workflow als ihn zu erleichtern. Es ist ein erheblicher mehraufwand die vielen Fatein zu kopieren und dann mit einem anderem Program zu laden.
Im Textmodus ist größe und geschwindigkeit eher zweitrangig und die Idee die datein in ein Archive zu lagern macht alles um ein vielfaches aufwendiger. Denn dann müsste man noch ein kompremierungs und dekompremierungscode hinzufügen und die Möglichkeit eine Textdatei zu untersuchen würde noch mehr beeinträchtigt werden.

Also eine Auslagerungsmöglichkeit, von Daten in eine Binary File ist im Textmodus eine gute sache.

Ein weiteren Vorteil den wir bei Binary und der Strukturierung haben sind Instanzen. Also die Möglichkeit zu sagen das Objekt nutz die Meshdaten von Objekt xy und hat folgende eigene translations- und rotation-werte. Bei Technicken wie VBO sollte sowas revorragende Ergebnisse erzielen, da In Levels z.B. Preferbs oder Teile von Levels gleich sind. 3D Studio Max bietet ja eine Möglichkeit der Instanz und in Blender müsste man es nur mit ein Data Eintrag in dem Objekt kennzeichnen.

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

Projekte: https://github.com/tak2004

Auch eine Rückkonvertierung von Binary zu Text hat Vorteile. Vorallem um zu prüfen, was da tatsächlich abgespeichert wurde. Bei Fehlern in der Ausgabe erleichtert das das Debugging bestimmt.

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