Du bist nicht angemeldet.

Stilllegung des Forums
Das Forum wurde am 05.06.2023 nach über 20 Jahren stillgelegt (weitere Informationen und ein kleiner Rückblick).
Registrierungen, Anmeldungen und Postings sind nicht mehr möglich. Öffentliche Inhalte sind weiterhin zugänglich.
Das Team von spieleprogrammierer.de bedankt sich bei der Community für die vielen schönen Jahre.
Wenn du eine deutschsprachige Spieleentwickler-Community suchst, schau doch mal im Discord und auf ZFX vorbei!

Werbeanzeige

Schrompf

Alter Hase

Beiträge: 1 470

Wohnort: Dresden

Beruf: Softwareentwickler

  • Private Nachricht senden

11

10.11.2011, 16:25

Ogre verwende ich nicht, möchte so auch keine Dateiformate dafür verwenden. Die anderen guck ich mir auf jeden Fall an, mal sehen welches am einfachsten zu laden ist.

Nunja, Ogre-Files wären einfach zu laden und es gibt halbwegs verlässliche Exporter dafür. Du musst ja auch die andere Seite bedenken: wer produziert Dir die Files, die Du dann laden willst? Zumal es ja nur um den Datentransport geht, für das alltägliche Laden bei jedem Programmstart brauchst Du eh ein eigenes Dateiformat. Ich würde also ein Format nehmen, für das es für viele 3D-Modellierer vernünftige Exporter gibt. Oder Du nimmst Assimp.
Häuptling von Dreamworlds. Baut aktuell an nichts konkretem, weil das Vollzeitangestelltenverhältnis ihn fest im Griff hat. Baut daneben nur noch sehr selten an der Open Asset Import Library mit.

DeKugelschieber

Community-Fossil

  • »DeKugelschieber« ist der Autor dieses Themas

Beiträge: 2 641

Wohnort: Rheda-Wiedenbrück

Beruf: Software-Entwickler

  • Private Nachricht senden

12

10.11.2011, 16:57

Zitat

Nunja, Ogre-Files wären einfach zu laden und es gibt halbwegs verlässliche Exporter dafür. Du musst ja auch die andere Seite bedenken: wer produziert Dir die Files, die Du dann laden willst? Zumal es ja nur um den Datentransport geht, für das alltägliche Laden bei jedem Programmstart brauchst Du eh ein eigenes Dateiformat. Ich würde also ein Format nehmen, für das es für viele 3D-Modellierer vernünftige Exporter gibt. Oder Du nimmst Assimp.


Ehrlich gesagt geht mir dieses Datei-Chaos total auf die Nerven, jedes mal wenn ich etwas neues einbauen will reicht mein Modelformat nicht mehr aus! Dabei dachte ich mit ply schonmal ein sehr gutes gefunden zu haben (Vertices, Normalen, Farben, UV Koordinaten, Materialien). Jetzt fehlen wieder Bones...
Ich glaub ich versuch mein eigenes ASCII Format mit Vertices, Normalen, Farben, UV Koordinaten, Materialien und Bones+Keyframes zu erstellen und dafür dann einen Exporter für Blender zu programmieren.
Die Modelle kommen übrigens von mir. Und mit eigenem Exporter könnten evt. Freunde die mir dann Modelle erstellen mir auch ihre Modelle geben (es bleibt eh die nächsten drei Jahre nur Hobby).

dot

Supermoderator

Beiträge: 9 757

Wohnort: Graz

  • Private Nachricht senden

13

10.11.2011, 17:03

Was heißt rumspielen? Ich will nachher skeletale Animation in OpenGL für Spiele und später evt. auch Physik umsetzen. Das ganze mach ich nicht nur ums mal gemacht zu haben, sondern für mein aktuelles Projekt.

Aber wenn du das alles selber machen willst, dann wärs wohl hilfreich, erstmal die Grundlagen zu verstehen. Und dafür eignet sich ms3d imo sehr gut, weil es nicht nur sehr einfach zu lesen ist, sondern vor allem weil du dort nicht gleich sofort mit Blendweights und Quaternionen hantieren musst...

DeKugelschieber

Community-Fossil

  • »DeKugelschieber« ist der Autor dieses Themas

Beiträge: 2 641

Wohnort: Rheda-Wiedenbrück

Beruf: Software-Entwickler

  • Private Nachricht senden

14

10.11.2011, 17:11

Öhm ok, das ist ein Argument ^^
Ich gucks mir mal an und "entwickel" parallel mein Format...

DeKugelschieber

Community-Fossil

  • »DeKugelschieber« ist der Autor dieses Themas

Beiträge: 2 641

Wohnort: Rheda-Wiedenbrück

Beruf: Software-Entwickler

  • Private Nachricht senden

15

10.11.2011, 18:26

Was haltet ihr z.B. davon (hab ich schnell mal aufgeschrieben, lehnt sich an ply an, Beispiel ist ein Würfel):

Quellcode

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
smf
version ascii 1.0
comment ------- vertices ----------------
vertex_type float float float uchar
vertex_format xyz nxnynz st rgba
vertex_offset 1
vertex_count 8
comment ------- faces -------------------
face_offset 10
face_count 7
comment ------- vertex groups -----------
vertex_group vg_name 0 4
vertex_group vg_name2 4 8
comment ------- materials ---------------
material_offset 18
material_count 2
material_ambient_type float
material_diffuse_type float
material_specular_type float float
comment ---------------------------------
comment Hier kommen jetzt noch (nicht) Keyframe (falls vorhanden),
comment und Bone (falls vorhanden) Informationen hin + dann die Daten im Body!
comment ------- end of header -----------
end_header
comment ------- vertex data -------------
0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 1 1 1 1
1.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 1 1 1 1
0.000000 1.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 1 1 1 1
0.000000 0.000000 1.000000 0.000000 0.000000 0.000000 0.000000 0.000000 1 1 1 1
1.000000 1.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 1 1 1 1
1.000000 0.000000 1.000000 0.000000 0.000000 0.000000 0.000000 0.000000 1 1 1 1
0.000000 1.000000 1.000000 0.000000 0.000000 0.000000 0.000000 0.000000 1 1 1 1
1.000000 1.000000 1.000000 0.000000 0.000000 0.000000 0.000000 0.000000 1 1 1 1
comment ------- face data ---------------
q 0 1 2 3
q 4 5 6 7
q 8 9 10 11
q 12 13 14 15
q 16 17 18 19
t 20 21 22
t 23 24 25
comment ------- material data -----------
material m_name vg_name
material_ambient m_name 0.5 0.5 0.5 1
material_diffuse m_name 0.3 0.3 0.3 1
material_specular m_name 0.1 0.1 0.1 1 1
material m_name2 vg_name2
material_ambient m_name2 0.5 0.5 0.5 1
material_diffuse m_name2 0.3 0.3 0.3 1
material_specular m_name2 0.1 0.1 0.1 1 1


Ich glaube ich muss nicht viel erklären oder?
Die "comment"´s wurden bereits in die offsets mit einberechnet.
Das ganze ist super einfach zu lesen, unterstützt alles was ich brauche (Animation muss ich mir noch Gedanken zu machen) und ist hoffentlich auch nicht allzu hart zu exportieren.


(Link)

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »DeKugelschieber« (10.11.2011, 18:55)


dot

Supermoderator

Beiträge: 9 757

Wohnort: Graz

  • Private Nachricht senden

16

11.11.2011, 00:12

Wenn es ein Format für eine Engine sein soll, also für die direkte Verwendung durch ein Spiel, dann würd ich es auf jeden Fall binär und möglichst einfach machen, damit du es möglichst schnell laden kannst. Im Idealfall einfach etwas, was du praktisch nurmehr 1:1 in den RAM packen musst und fertig,

Schrompf

Alter Hase

Beiträge: 1 470

Wohnort: Dresden

Beruf: Softwareentwickler

  • Private Nachricht senden

17

11.11.2011, 11:15

Dot hat Recht. Was ich Dir eigentlich sagen wollte: Du brauchst zwei Formate. Eins, um Modelle aus den 3D-Grafikprogrammen rauszubekommen, und eins, um bei jedem Spielstart schnell alle Daten eines Modells zu laden. Ersteres kann eins der gängigen Austausch-Formate sein, es darf beliebig komplex sein, weil Du Dateien ja nur einmalig lädst und dann in Deinem eigenen Binärformat abspeicherst. Das sollte dann aber im Idealfall Byte für Byte Deinen internen Engine-Strukturen entsprechen, damit Du es im Turbo-Tempo laden kannst. Wir reden hier durchaus von Faktor 100 an Geschwindigkeit. Das ist nichts, was man vernachlässigen sollte.

Ich kann Dir außerdem sagen, dass Du auf Dauer nicht ohne ein bisschen Nachbearbeitung nach dem Importieren auskommen wirst. Sei es zeitliche oder räumliche Skalierung, Umorientierung, Shaderauswahl und Materialparameter oder ein banales Ausklammern bestimmter Teile beim Import, weil der dämliche Exporter z.B. noch zusätzlich einen Quader-Mesh für jeden Bone generiert hat. Daher meine Empfehlung: schreibe Dir ein kleines Zwischen-Tool, dass Dateien aus einem gängigen 3D-Format (oder halt allen: Assimp) lesen kann und in Deinem eigenen Binär-Format rausschreibt. Diese zweistufige Content Pipeline hat sich meiner Meinung nach bewährt. Wenn Du einen Editor oder sowas hast, kannst Du das auch gleich darin integrieren und automatischen Re-Import machen, wenn sich das Source-File geändert hat.
Häuptling von Dreamworlds. Baut aktuell an nichts konkretem, weil das Vollzeitangestelltenverhältnis ihn fest im Griff hat. Baut daneben nur noch sehr selten an der Open Asset Import Library mit.

DeKugelschieber

Community-Fossil

  • »DeKugelschieber« ist der Autor dieses Themas

Beiträge: 2 641

Wohnort: Rheda-Wiedenbrück

Beruf: Software-Entwickler

  • Private Nachricht senden

18

11.11.2011, 13:53

Zitat

Ich kann Dir außerdem sagen, dass Du auf Dauer nicht ohne ein bisschen Nachbearbeitung nach dem Importieren auskommen wirst.


Das ist schon klar, bei meinem ply Importer hab ich z.B. eine reorganisation der Vertices und einen Umwander von Quads zu Dreiecken.
Und das binär schneller ist, ist mir selbstverständlich bewusst, aber es ist für den Anfang schwerer zu überblicken (also die Datei direkt einzusehen) und außerdem lässt sich mein ASCII Format dann doch auch in ein binäres umwandeln.
Zum erstellen würde ich am liebsten einfach einen Exporter in Python für Blender schreiben, erstmal zu ASCII und dann vielleicht ein kleines C++ Programm das mir das in ein binäres umwandelt.

Wie komplex ist Assimp? Und was meinst du mit einfach dot? Es soll schon "alles" unterstützen was man so mit Modellen machen kann/braucht (Vertexdaten, Normalen, Farben, UV, Vertexgruppen, Materialien, Keyframes, Bone Animation).
Meine Grundüberlegung ist halt Header mit offsets und kurze Formatangaben (z.B. Reichenfolge für einen Vertex [z.B. xyz nxyz st oder xzy st]).
Jetzt muss ich eh erstmal ein wenig lernen mit Zeichenketten zu arbeiten, bevor ich dann binär da ran gehe...

Werbeanzeige

Ähnliche Themen