Hey,
ich wollte mal fragen, was ihr mir empfehlen würdet als dateiformat für modelle zu nutzen - da ich cinema 4D nutze läge für mich ein format nahe, das c4d schon nativ kann - was da halt hauptsächlich 3ds wäre - da bin ich mir jetzt aber unsicher, ob ich das dann auch noch nutzen darf, wenn ich mein projekt(spiel) verkaufen möchte. Auf einer Website habe ich folgendes gefunden:



Weis hier jemand näheres? Der Gedanke ein eigenes Format zu schreiben behagt mir momentan noch gar nicht - auch wenn es letztlich performance-technisch wohl das beste sein würde... schreibt mir dazu jemand nen tutorial ?

Bin für jede Auskunft dankbar - hab jetzt ziemlich lange rumgesucht und weder auf englisch noch deutsch verwertbare informationen gefunden (bzw was ich fand war nicht belegt)


mfg grey

Es gibt kein ideales format. Alle Formate wie 3ds, obj, md2/3/5 oder BSP tree basierende sind für heutige anforderungen kaum zu gebrauchen, da die flexibilität fehlt. Bei Collada dagegen ist die flexibilität so groß, das man ein ganzes team benötigt um die komplette spezifikation abzuarbeiten, damit das eigene programm mit allen collada quellen wirklich zusammenarbeiten kann. Nebenbei ist XML sehr ineffizient um große mengen an binärdaten zu encodieren (overhead zwischen 3 und 10).

Als anhalt schau die mein format mal an http://lumina.sourceforge.net/Documenta ... mFile.html Die ist nicht ideal und wird wohl in zukunft ein wenig geändert werden.

Designmäßig wird es mit opengl 3.0 so werden das es keine fixed function pipline mehr geben muss und feste zuordnungen wie position, normal, texturkodinaten oder tangent vektoren nicht mehr gibt. Prinzipiell ist man gezwungen den vertexshader zu einem teil des modell zu machen obwohl er genauso abhängigkeiten der engine aufweist. (die transformation z.B.)

Zur zeit gibt es zwei sinvolle mögliche entscheindungen:

1. Benutze ein verfügbares format welches für eine fixed function pipline gedacht ist (MD2/3/5, 3ds , obj) und bau einen loader der diese möglichst gut handeln kann.

2. Bau ein eigenes Format und wie lum, welches mit wenigen seiten text spezifiziert werden kann. Besondere probleme sind die setups der rendervorgänge, da im fall einer scriptsprache extreme abhängigkeiten entstehen. Gegebenfalls macht es sin zu compelierenden code in das model aufzunehmen, welcher nach bedarf compeliert wirdund wie ein plugin gleaden wird. Dieser code kann dann unter umständen vom exporter selbst geschireben werden.

3. Sich mit Collada rumschlagen und wochen dabei verlieren...

_________________
Lumina plattform unabhängige GLSL IDE

Das .x-Format (Direct 3D) ist kommerziell nutzbar und auf moderne 3D-Anwendungen ausgelegt. Von daher ist dieses Format momentan die beste Lösung, sofern man nicht etwas Eigenes entwickeln will. Collada ist zwar auch ein aktuelles Format und frei nutzbar, allerdings besitzen noch nicht alle Anwendungen brauchbare Im- und Exporter, und das Format an sich ist stark aufgebläht, selbst simple Szenen erzeugen große Dateien (Collada ist ein XML-Format).

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

also von xml halte ich persönlich eigentlich gar nix. ich würde gerne bones für die animationen benutzen - und opengl 3 wird wohl in absehbarer zeit auch nicht eingesetzt werden - ich will eine möglichst große abwärtskompatibilität erreichen (wäre z.b. gut wenn ich auf nem 945GM noch arbeiten könnte und gleichzeitig auf meinem stationären pc T&L aktivieren könnte (also möglichst viel einfach abschaltbar machen)

ich werd dann denke ich mal mich mit nem loader für 3ds auseinandersetzen und mir vll noch einen für md2 ansehen um so nen gewisses grundkonzept zu haben, wie ich das strukturieren müsste.

danke für die anregungen!

mfg grey

I believe milkshape ascii might be commercial useable also, but i am not sure. It support bones and is available in gl3ds. Reading sourcecode is provided at the milkshape site. Nothing on license about that though.
The fact that the .3ds fileformat is not commercial useable never crossed my mind. I should look into this.
For the .x format i recently found a nice exporter for google sketchup written in python. I am looking into modifying that to export milkshape ascii. Or should i put in effort to make gl3ds read the .x format?

_________________
http://3das.noeska.com - create adventure games without programming

oc2k1 schrieb:

Das würde ich gern näher wissen. Auch OpenGL3 braucht Meshdaten, nehme ich an. Meshdaten bestehen nunmal aus Vertices. Man kann unter gewissen Umständen die Faces weglassen. Aber Vertices und Texturkoordinaten weglassen, wie soll das gehen?

Ach ja und die Frage nach einem Loader taucht immer wieder auf gell? Eine Lösung wäre, wenn wir uns endlich auf ein Meshformat einigen könnten. Dass die verschiedenen Loader nicht kompatibel sind, weil der eine Polygone laden will und nicht Dreiecke und der andere Tangent Vektoren ist in meinen Augen einfach eine Ausrede. Wir selbst könnten ein offenes Format definieren und damit einen Standard schaffen: "Was machen wir heute Abend, Brain...."

the gl3ds loader supports both milkshape ascii and .3ds. In the most recent version can be extended to support other formats also. It works like timage.

_________________
http://3das.noeska.com - create adventure games without programming

Ich habe geschrieben, das es in Zukunft keine feste Zuordnungen mehr geben wird (zumindest sind die Fixed function names alle als deprecated makiert). Das heist zwar es gibt keine vorgefertigten Attribute mehr, jedoch nicht, das man keine selbst definierten verwenden kann.
Der vorteil ist, das man auf diese weise alle Attribute mit dem gleichem code behandeln kann. Man kann sich einfach einen namen ausdenken und sich ein format ausuchen. Eventuell kann man aber auch ganz darauf verzichten und die geometrie komplett aus der vertex ID erzeugen (zumindest mit opengl 2.1 weigert sich der shadercompiler noch).

_________________
Lumina plattform unabhängige GLSL IDE

@Noeska: I agree with you. For me a 3D model is not so different from an image. I have implemented an image-Object that can be fed from several providers, eg. a Jpeg-provider, a TGA-provider and so on. A 3D model should also be feedable from a 3DS data file or an OBJ data file or a MD5 datafile and the outcome should always be the same. Of corse there are models that are rigid and others are flexible (they have a skeleton, for example) but in my opinion this could not really be a problem for a well constructed interface between model and loader.

A really practical short and free model format with skeletal animation does simply not exist and everyone around here builds his own. Me too. My solution was to take the OBJ-format and to add skeletal animation in a similar way Cal3D does.

@oc2k1: Danke für Deine Antwort. Sieht so aus als ob sie in Richtung freie Programmierbarkeit gehen. ich frag mich, ob sie mit Opengl wirklich weitermachen, wenn sie gleichzeitig auch OpenCL implementieren.

OpenCL und OpenGL haben überhaupt nichts mit einander zu tun. OpenCL ist eher mit cuda zu vergleichen. Beide benutzen nur die shadereinheiten der Grafikkarten, andere Einheiten wie Triangle setup, ROPs (z test, blending....) werden gar nicht genutzt.

_________________
Lumina plattform unabhängige GLSL IDE

In der OpenCL API ist ein Interface für OpenGL implementiert, damit man FBO und VBO daten in OpenCL direkt vom Grafikspeicher aus verarbeiten kann.
Dabei wird in OpenCL ein OpenGL Context erstellt und der reelle OpenGL Context mit übergeben, dann kann man das entsprechende FBO übergeben und mit OpenCL z.B. jedes Pixel verarbeiten(für z.B. Virtual Texture, um die fehlenden Texturblöcke zu finden).

Das Problem bei Modelformaten ist schlicht und einfach, es gibt zuviele unterschiedliche Bedürfnisse.
Ein Softwareprojekt z.B. braucht noch zusätzliche Metainformationen, für ihre Augen- und Gesichts-Animation, ein anderes soll möglichst klein sein und benutzt z.B. half-float oder ein weiteres soll sehr schnell sein und muss entsprechend dann sich den gegebenheiten eines compilers anpassen(serialisierung).
Deshalb gibt es diese Frage immer und immer wieder, weil es kein Format gibt, welches Allgemein für jedes Bedürfnis nutzbar ist und dieses findet man bei jeden Datenformat wieder. Bei Bilddaten, Sound, video, Datenbanken,... gibt es das gleiche Problem.

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

Projekte: https://github.com/tak2004