Welcome to mirror list, hosted at ThFree Co, Russian Federation.

mystery_of_the_blend.html « blender_file_format « doc - git.blender.org/blender.git - Unnamed repository; edit this file 'description' to name the repository.
summaryrefslogtreecommitdiff
blob: 599cb4a05bc976f4e77d7f9b5b6362b5f4a1c5df (plain)
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
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
    <link rel="stylesheet" type="text/css" href="mystery_of_the_blend.css" media="screen, print">
    <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
    <title>The mystery of the blend</title>
</head>

<body>
<div class="title">The mystery of the blend</div>
<div class="subtitle">The blender file-format explained</div>
<div class="contact">
<label>Author</label> Jeroen Bakker<br>
<label>Email</label> <a href="mailto:j.bakker@atmind.nl">j.bakker@atmind.nl</a><br>
<label>Website</label> <a href="http://www.atmind.nl/blender/">http://www.atmind.nl/blender</a><br>
<label>Version</label> 06-10-2010<br>
</div>

<a name="introduction" href="#introduction" ><h2>Introduction</h2></a>
</a>

<p>In this article I will describe the
 blend-file-format with a request to tool-makers to support blend-file. 
   
</p>
<p>First I'll describe how Blender works with blend-files. You'll notice
 why the blend-file-format is not that well documented, as from 
Blender's perspective this is not needed.
We look at the global file-structure of a blend-file (the file-header 
and file-blocks).
After this is explained, we go deeper to the core of the blend-file, the
 DNA-structures. They hold the blue-prints of the blend-file and the key
 asset of understanding blend-files.
When that's done we can use these DNA-structures to read information 
from elsewhere in the blend-file.

</p>
<p>
In this article we'll be using the default blend-file from Blender 2.54,
 with the goal to read the output resolution from the Scene. 
The article is written to be programming language independent and I've 
setup a web-site for support.
</p>

<a name="loading-and-saving-in-blender" href="#loading-and-saving-in-blender">
<h2>Loading and saving in Blender</h2>
</a>

<p>
Loading and saving in Blender is very fast and Blender is known to 
have excellent downward and upward compatibility. Ton Roosendaal 
demonstrated that in December 2008 by loading a 1.0 blend-file using 
Blender 2.48a [ref: <a href="http://www.blendernation.com/2008/12/01/blender-dna-rna-and-backward-compatibility/">http://www.blendernation.com/2008/12/01/blender-dna-rna-and-backward-compatibility/</a>].
</p>

<p>
Saving complex scenes in Blender is done within seconds. Blender 
achieves this by saving data in memory to disk without any 
transformations or translations. Blender only adds file-block-headers to
 this data. A file-block-header contains clues on how to interpret the 
data. After the data, all internally Blender structures are stored. 
These structures will act as blue-prints when Blender loads the file. 
Blend-files can be different when stored on different hardware platforms
 or Blender releases. There is no effort taken to make blend-files 
binary the same. Blender creates the blend-files in this manner since 
release 1.0. Backward and upwards compatibility is not implemented when 
saving the file, this is done during loading.
</p>

<p>
When Blender loads a blend-file, the DNA-structures are read first. 
Blender creates a catalog of these DNA-structures. Blender uses this 
catalog together with the data in the file, the internal Blender 
structures of the Blender release you're using and a lot of 
transformation and translation logic to implement the backward and 
upward compatibility. In the source code of blender there is actually 
logic which can transform and translate every structure used by a 
Blender release to the one of the release you're using [ref: <a href="http://download.blender.org/source/blender-2.48a.tar.gz">http://download.blender.org/source/blender-2.48a.tar.gz</a>
 <a href="https://svn.blender.org/svnroot/bf-blender/tags/blender-2.48-release/source/blender/blenloader/intern/readfile.c">blender/blenloader/intern/readfile.c</a> lines 
4946-7960]. The more difference between releases the more logic is 
executed. 
</p>

<p>
The blend-file-format is not well documented, as it does not differ from
 internally used structures and the file can really explain itself.
</p>

<a name="global-file-structure" href="#global-file-structure">
<h2>Global file-structure</h2>
</a>

<p>
This section explains how the global file-structure can be read.
</p>

<ul>
<li>A blend-file always start with the <b>file-header</b></li>
<li>After the file-header, follows a list of <b>file-blocks</b> (the default blend file of Blender 2.48 contains more than 400 of these file-blocks).</li>
<li>Each file-block has a <b>file-block header</b> and <b>file-block data</b></li>
<li>At the end of the blend-file there is a section called "<a href="#structure-DNA" style="font-weight:bold">Structure DNA</a>", which lists all the internal structures of the Blender release the file was created in</li>
<li>The blend-file ends with a file-block called 'ENDB'</li>
</ul>

<!-- file scheme -->
<div class="box-solid" style="width:20%; margin-left:35%; font-size:0.8em;">

    <p class="code"><b>File.blend</b></p>

    <div class="box"><p class="code">File-header</p></div>

    <div class="box-solid"><p class="code">File-block</p>
        <div class="box"><p class="code">Header</p></div>
        <div class="box"><p class="code">Data</p></div>
    </div>
    
    <div class="box" style="border-style:dashed"><p class="code">File-block</p></div>
    <div class="box" style="border-style:dashed"><p class="code">File-block</p></div>

    <div class="box-solid"><p class="code">File-block 'Structure DNA'</p>
        <div class="box"><p class="code">Header ('DNA1')</p></div>
        <div class="box-solid">
            <p class="code">Data ('SDNA')</p>
            <div class="box">
                <p class="code">Names ('NAME')</p>
            </div>
            <div class="box">
                <p class="code">Types ('TYPE')</p>
            </div>
            <div class="box">
                <p class="code">Lengths ('TLEN')</p>
            </div>
            <div class="box">
                <p class="code">Structures ('STRC')</p>
            </div>
        </div>
    </div>

    <div class="box-solid"><p class="code">File-Block 'ENDB'</p></div>

</div><!-- end of file scheme -->

<a name="file-header" href="#file-header">
<h3>File-Header</h3>
</a>

<p>
The first 12 bytes of every blend-file is the file-header. The 
file-header has information on Blender (version-number) and the PC the 
blend-file was saved on (pointer-size and endianness). This is required 
as all data inside the blend-file is ordered in that  way, because no  
translation or transformation  is done during saving. 
The next table describes the information in the file-header.
</p>

<table>
<caption>File-header</caption>
<thead>
<tr><th>reference</th>
    <th>structure</th>
    <th>type</th>
    <th>offset</th>
    <th>size</th></tr>
</thead>
<tbody>
<tr><td>identifier</td>
    <td>char[7]</td>
    <td>File identifier (always 'BLENDER')</td>
    <td>0</td>
    <td>7</td></tr>
<tr><td>pointer-size</td>
    <td>char</td>
    <td>Size of a pointer; all pointers in the file are stored in this format. '_' means 4 bytes or 32 bit and '-' means 8 bytes or 64 bits.</td>
    <td>7</td>
    <td>1</td></tr>
<tr><td>endianness</td>
    <td>char</td>
    <td>Type of byte ordering used; 'v' means little endian and 'V' means big endian.</td>
    <td>8</td>
    <td>1</td></tr>
<tr><td>version-number</td>
    <td>char[3]</td>
    <td>Version of Blender the file was created in; '254' means version 2.54</td>
    <td>9</td>
    <td>3</td></tr>
</tbody>
</table>

<p>
<a href="https://en.wikipedia.org/wiki/Endianness">Endianness</a> addresses the way values are ordered in a sequence of bytes(see the <a href="#example-endianess">example</a> below):
</p>

<ul>
    <li>in a big endian ordering, the largest part of the value is placed on the first byte and 
    the lowest part of the value is placed on the last byte,</li>
    <li>in a little endian ordering, largest part of the value is placed on the last byte
    and the smallest part of the value is placed on the first byte.</li>
</ul>

<p> 
Nowadays, little-endian is the most commonly used.
</p>

<a name="example-endianess"></a>
<div class="box">
<p onclick="location.href='#example-endianess'" class="box-title">
Endianess Example
</p>
<p>
Writing the integer <code class="evidence">0x4A3B2C1Dh</code>, will be ordered:
<ul>
<li>in big endian as <code class="evidence">0x4Ah</code>, <code class="evidence">0x3Bh</code>, <code class="evidence">0x2Ch</code>, <code class="evidence">0x1Dh</code></li>
<li>in little endian as <code class="evidence">0x1Dh</code>, <code class="evidence">0x2Ch</code>, <code class="evidence">0x3Bh</code>, <code class="evidence">0x4Ah</code></li>
</ul>
</p>
</div>

<p>
Blender supports little-endian and big-endian.<br>
This means that when the endianness 
is different between the blend-file and the PC your using, Blender changes it to the byte ordering 
of your PC.
</p>

<a name="example-file-header"></a>
<div class="box">
<p onclick="location.href='#example-file-header'" class="box-title">
File-header Example
</p>

<p>
This hex-dump describes a file-header created with <code>blender</code> <code>2.54.0</code> on <code>little-endian</code> hardware with a <code>32 bits</code> pointer length.
<code class="block">                               <span class="descr">pointer-size  version-number
                                     |             |</span>
0000 0000: [42 4C 45 4E 44 45 52]  [5F]  [76]  [32 35 34]        BLENDER_v254  <span class="descr">
                      |                   |
                  identifier          endianness</span></code>
</p>
</div>

<a name="file-blocks" href="#file-blocks"><h3>File-blocks</h3></a>

<p>
File-blocks contain a "<a href="#file-block-header">file-block header</a>" and "file-block data". 
</p>

<a name="file-block-header" href="#file-block-header"><h3>File-block headers</h3></a>

<p>
The file-block-header describes:
</p>

<ul>
<li>the type of information stored in the 
file-block</li>
<li>the total length of the data</li>
<li>the old memory 
pointer at the moment the data was written to disk</li>
<li>the number of items of this information</li>
</ul>

<p>
As we can see below, depending on the pointer-size stored in the file-header, a file-block-header 
can be 20 or 24 bytes long, hence it is always aligned at 4 bytes.
</p>

<table>
<caption>File-block-header</caption>
<thead>
<tr>
<th>reference</th>
    <th>structure</th>
    <th>type</th>
    <th>offset</th>
    <th>size</th></tr></thead>
<tbody>
<tr><td>code</td>
    <td>char[4]</td>
    <td>File-block identifier</td>
    <td>0</td>
    <td>4</td></tr>
<tr><td>size</td>
    <td>integer</td>
    <td>Total length of the data after the file-block-header</td>
    <td>4</td>
    <td>4</td></tr>
<tr><td>old memory address</td>
    <td>void*</td>
    <td>Memory address the structure was located when written to disk</td>
    <td>8</td>
    <td>pointer-size (4/8)</td></tr>
<tr><td>SDNA index</td>
    <td>integer</td>
    <td>Index of the SDNA structure</td>
    <td>8+pointer-size</td>
    <td>4</td></tr>
<tr><td>count</td>
    <td>integer</td>
    <td>Number of structure located in this file-block</td>
    <td>12+pointer-size</td>
    <td>4</td></tr>
</tbody>
</table>

<p>
The above table describes how a file-block-header is structured:
</p>

<ul>
<li><code>Code</code> describes different types of file-blocks. The code determines with what logic the data must be read. <br>  
These codes also allows fast finding of data like Library, Scenes, Object or Materials as they all have a specific code. </li>
<li><code>Size</code> contains the total length of data after the file-block-header. 
After the data a new file-block starts. The last file-block in the file 
has code 'ENDB'.</li>
<li><code>Old memory address</code> contains the memory address when the structure 
was last stored. When loading the file the structures can be placed on 
different memory addresses. Blender updates pointers to these structures
 to the new memory addresses.</li>
<li><code>SDNA index</code> contains the index in the DNA structures to be used when 
reading this file-block-data. <br>
More information about this subject will be explained in the <a href="#reading-scene-information">Reading scene information section</a>.</li>
<li><code>Count</code> tells how many elements of the specific SDNA structure can be found in the data.</li> 
</ul>

<a name="example-file-block-header"></a>
<div class="box">
<p onclick="location.href='#example-file-block-header'" class="box-title">
Example
</p>
<p>
This hex-dump describes a File-block (= <span class="header">File-block header</span> + <span class="data">File-block data</span>) created with <code>blender</code> <code>2.54</code> on <code>little-endian</code> hardware with a <code>32 bits</code> pointer length.<br>
<code class="block"><span class="descr">             file-block 
           identifier='SC'  data size=1404  old pointer   SDNA index=150
                 |              |              |              |</span>
0000 4420: <span class="header">[53 43 00 00]  [7C 05 00 00]  [68 34 FB 0B]  [96 00 00 00]</span>    SC.. `... ./.. .... 
0000 4430: <span class="header">[01 00 00 00]</span>  <span class="data">[xx xx xx xx    xx xx xx xx    xx xx xx xx</span>     .... xxxx xxxx xxxx<span class="descr">
                 |              |
              count=1      file-block data (next 1404 bytes)</span>
</code>
</p>

<ul>
<li>The code <code>'SC'+0x00h</code> identifies that it is a Scene. </li>
<li>Size of the data is 1404 bytes (0x0000057Ch = 0x7Ch + 0x05h * 256 = 124 + 1280)</li>
<li>The old pointer is 0x0BFB3468h</li>
<li>The SDNA index is 150 (0x00000096h = 6 + 9 * 16 = 6 + 144)</li>
<li>The section contains a single scene (count = 1).</li>
</ul>

<p>
Before we can interpret the data of this file-block we first have to read the DNA structures in the file. 
The section "<a href="#structure-DNA">Structure DNA</a>" will show how to do that. 
</p>
</div>

<a name="structure-DNA" href="#structure-DNA"><h2>Structure DNA</h2></a>

<a name="DNA1-file-block" href="#DNA1-file-block"><h3>The DNA1 file-block</h3></a>

<p>
Structure DNA is stored in a file-block with code 'DNA1'. It can be just before the 'ENDB' file-block.
</p>

<p>
The 'DNA1' file-block contains all internal structures of the Blender release the 
file was created in. <br>
These structure can be described as C-structures: they can hold fields, arrays and 
pointers to other structures, just like a normal C-structure.

<p>
<code class="block">struct SceneRenderLayer {
    struct SceneRenderLayer *next, *prev;
    char name[32];
    struct Material *mat_override;
    struct Group *light_override;
    unsigned int lay;
    unsigned int lay_zmask;
    int layflag;
    int pad;
    int passflag;
    int pass_xor;
};
</code>
</p>

<p>
For example,a blend-file created with Blender 2.54 the 'DNA1' file-block is 57796 bytes long and contains 398 structures.
</p>

<a name="DNA1-file-block-header" href="#DNA1-file-block-header"><h3>DNA1 file-block-header</h3></a>

<p>
The DNA1 file-block header follows the same rules of any other file-block, see the example below.
</p>

<a name="example-DNA1-file-block-header"></a>
<div class="box">
<p onclick="location.href='#example-DNA1-file-block-header'" class="box-title">
Example
</p>
<p>
This hex-dump describes the file-block 'DNA1' header created with <code>blender</code> <code>2.54.0</code> on <code>little-endian</code> hardware with a <code>32 bits</code> pointer length.<br>
<code class="block"><span class="descr">      (file-block 
       identifier='DNA1') data size=57796   old pointer   SDNA index=0
                  |              |              |              |</span>
0004 B060   <span class="header">[44 4E 41 31]  [C4 E1 00 00]  [C8 00 84 0B]  [00 00 00 00]</span>  DNA1............
0004 B070   <span class="header">[01 00 00 00]</span>  <span class="fade">[53 44 4E 41    4E 41 4D 45    CB 0B 00 00</span>   ....<span class="fade">SDNANAME....</span><span class="descr">
                  |              |
              count=1    'DNA1' file-block data (next 57796 bytes)</span>
</code>
</p>
</div>

<a name="DNA1-file-block-data" href="#DNA1-file-block-data"><h3>DNA1 file-block data</h3></a>
<p>
The next section describes how this information is ordered in the <b>data</b> of the 'DNA1' file-block.
</p>

<table>
<caption>Structure of the DNA file-block-data</caption>
<thead>
    <tr><th colspan="2">repeat condition</th>
    <th>name</th>
    <th>type</th>
    <th>length</th>
    <th>description</th></tr>
</thead>
<tbody>
<tr><td></td>
    <td></td>
    <td>identifier</td>
    <td>char[4]</td>
    <td>4</td>
    <td>'SDNA'</td></tr>
<tr><td></td>
    <td></td>
    <td>name identifier</td>
    <td>char[4]</td>
    <td>4</td>
    <td>'NAME'</td></tr>
<tr><td></td>
    <td></td>
    <td>#names</td>
    <td>integer</td>
    <td>4</td>
    <td>Number of names follows</td></tr>
<tr><td>for(#names)</td>
    <td></td>
    <td>name</td>
    <td>char[]</td>
    <td>?</td>
    <td>Zero terminating string of name, also contains pointer and simple array definitions (e.g. '*vertex[3]\0')</td></tr>
<tr><td></td>
    <td></td>
    <td>type identifier</td>
    <td>char[4]</td>
    <td>4</td>
    <td>'TYPE' this field is aligned at 4 bytes</td></tr>
<tr><td></td>
    <td></td>
    <td>#types</td>
    <td>integer</td>
    <td>4</td>
    <td>Number of types follows</td></tr>
<tr><td>for(#types)</td>
    <td></td>
    <td>type</td>
    <td>char[]</td>
    <td>?</td>
    <td>Zero terminating string of type (e.g. 'int\0')</td></tr>
<tr><td></td>
    <td></td>
    <td>length identifier</td>
    <td>char[4]</td>
    <td>4</td>
    <td>'TLEN' this field is aligned at 4 bytes</td></tr>
<tr><td>for(#types)</td>
    <td></td>
    <td>length</td>
    <td>short</td>
    <td>2</td>
    <td>Length in bytes of type (e.g. 4)</td></tr>
<tr><td></td>
    <td></td>
    <td>structure identifier</td>
    <td>char[4]</td>
    <td>4</td>
    <td>'STRC' this field is aligned at 4 bytes</td></tr>
<tr><td></td>
    <td></td>
    <td>#structures</td>
    <td>integer</td>
    <td>4</td>
    <td>Number of structures follows</td></tr>
<tr><td>for(#structures)</td>
    <td></td>
    <td>structure type</td>
    <td>short</td>
    <td>2</td>
    <td>Index in types containing the name of the structure</td></tr>
<tr><td>..</td>
    <td></td>
    <td>#fields</td>
    <td>short</td>
    <td>2</td>
    <td>Number of fields in this structure</td></tr>
<tr><td>..</td>
    <td>for(#field)</td>
    <td>field type</td>
    <td>short</td>
    <td>2</td>
    <td>Index in type</td></tr>
<tr><td>for end</td>
    <td>for end</td>
    <td>field name</td>
    <td>short</td>
    <td>2</td>
    <td>Index in name</td></tr>
</tbody>
</table>

<p>
As you can see, the structures are stored in 4 arrays: names, types, 
lengths and structures. Every structure also contains an array of 
fields. A field is the combination of a type and a name. From this 
information a catalog of all structures can be constructed. 
The names are stored as how a C-developer defines them. This means that 
the name also defines pointers and arrays.
(When a name starts with '*' it is used as a pointer. when the name 
contains for example '[3]' it is used as a array of 3 long.)
In the types you'll find simple-types (like: 'integer', 'char', 
'float'), but also complex-types like 'Scene' and 'MetaBall'. 
'TLEN' part describes the length of the types. A 'char' is 1 byte, an 
'integer' is 4 bytes and a 'Scene' is 1376 bytes long.
</p>

<div class="box">
<p class="box-title">
Note
</p>
<p>
All identifiers, are arrays of 4 chars, hence they are all aligned at 4 bytes.
</p>
</div>

<a name="example-DNA1-file-block-data"></a>
<div class="box">
<p onclick="location.href='#example-DNA1-file-block-data'" class="box-title">
Example
</p>
<p>
Created with <code>blender</code> <code>2.54.0</code> on <code>little-endian</code> hardware with a <code>32 bits</code> pointer length.
</p>

<a name="DNA1-data-array-names" href="#DNA1-data-array-names"><h4>The names array</h4></a>
<p>
The first names are: *next, *prev, *data, *first, *last, x, y, xmin, xmax, ymin, ymax, *pointer, group, val, val2, type, subtype, flag, name[32], ...
<code class="block"><span class="descr">    file-block-data identifier='SDNA'  array-id='NAME'     number of names=3019
                                |              |             |</span>
0004 B070    <span class="fade">01 00  00 00 [53 44  4E 41]</span><span class="data">[4E  41 4D 45] [CB 0B 00  00]</span>  <span class="fade">....SDNA</span>NAME....
0004 B080   <span class="data">[2A 6E  65 78  74 00][2A 70  72  65 76 00] [2A 64 61  74</span>   *next.*prev.*dat<span class="descr">
                      |                    |                   | 
                  '*next\0'            '*prev\0'            '*dat'</span><span class="fade">
                                  ....
                                  .... (3019 names)</span>
</code>
</p>

<div class="box">
<p class="box-title">
Note
</p>
<p>
While reading the DNA you'll will come across some strange 
names like '(*doit)()'. These are method pointers and Blender updates 
them to the correct methods.
</p>
</div>

<a name="DNA1-data-array-types" href="#DNA1-data-array-types"><h4>The types array</h4></a>
<p>
The first types are: char, uchar, short, ushort, int, long, ulong, float, double, void, Link, LinkData, ListBase, vec2s, vec2f, ...
<code class="block"><span class="descr">                                                      array-id='TYPE'
                                                            |</span>
0005 2440    <span class="fade">6F 6C 64 5B   34 5D 5B 34 5D 00 00 00</span>   [54 59 50  45]  <span class="fade">old[4][4]...</span>TYPE
0005 2450   [C9 01 00 00] [63 68 61 72 00]  [75 63 68 61 72 00][73   ....char.uchar.s<span class="descr">
                  |                |                 |           |
       number of types=457     'char\0'          'uchar\0'      's'</span><span class="fade">
                                  ....
                                  .... (457 types)</span>
</code>
</p>

<a name="DNA1-data-array-lengths" href="#DNA1-data-array-lengths"><h4>The lengths array</h4></a>
<p>
<code class="block"><span class="descr">                                                 char    uchar    ushort   short
                                 array-id       length   length   length   length
                                   'TLEN'          1        1        2        2</span>
0005 3AA0    <span class="fade">45 00    00 00</span>   [54 4C    45 4E]  [01 00]  [01 00]  [02 00]  [02 00]  <span class="fade">E...</span>TLEN........
                                  <span class="fade">....</span>
0005 3AC0   [08 00]  [04 00]  [08 00]  [10 00]  [10 00]  [14 00]  [4C 00]  [34 00]  ............L.4.<span class="descr">
               8        4        8       
           ListBase   vec2s    vec2f    ... etc
           length     len      length   </span><span class="fade">
                                  ....
                                  .... (457 lengths, same as number of types)</span>
</code>
</p>

<a name="DNA1-data-array-structures" href="#DNA1-data-array-structures"><h4>The structures array</h4></a>
<p>
<code class="block"><span class="descr">                                                                 array-id='STRC'
                                                                        |</span>
0005 3E30    <span class="fade">40 00 38 00   60 00   00 00     00 00     00 00</span>    [53 54     52 43]  <span class="fade">@.8.`.......</span>STRC
0005 3E40   [8E 01 00 00] [0A 00] [02 00]   [0A 00]   [00 00]   [0A 00]   [01 00]  ................<span class="descr">
                 398         10      2         10        0         10        0  
              number of    index    fields    index     index     index     index
             structures   in <a href="#DNA1-data-array-types">types</a>           in <a href="#DNA1-data-array-types">types</a>  in <a href="#DNA1-data-array-names">names</a>  in <a href="#DNA1-data-array-types">types</a>   in <a href="#DNA1-data-array-names">names</a></span><span class="fade">
                          '                  '----------------'  '-----------------'                                    '
                          '                      field 0                field 1    '
                          '--------------------------------------------------------'
                                             structure 0
                                  ....
                                  .... (398 structures, each one describeing own type, and type/name for each field)</span>
</code>
</p>
</div>

<p>
The DNA structures inside a Blender 2.48 blend-file can be found at <a href="http://www.atmind.nl/blender/blender-sdna.html">http://www.atmind.nl/blender/blender-sdna.html</a>.

If we understand the DNA part of the file it is now possible to read 
information from other parts file-blocks. The next section will tell us 
how.
</p>

<a name="reading-scene-information" href="#reading-scene-information"><h2>Reading scene information</h2></a>

<p>
Let us look at <a href="#example-file-block-header">the file-block header we have seen earlier</a>:<br>
</p>
<ul>
<li>the file-block identifier is <code>'SC'+0x00h</code></li>
<li>the SDNA index is 150</li>
<li>the file-block size is 1404 bytes</li>
</ul>
<p>
Now note that:
<ul>
<li>the structure at index 150 in the DNA is a structure of type 'Scene' (counting from 0).</li>
<li>the associated type ('Scene') in the DNA has the length of 1404 bytes.</li>
</ul>
</p>

<p> 
We can map the Scene structure on the data of the file-blocks. 
But before we can do that, we have to flatten the Scene-structure.

<code class="block">struct Scene {
    ID id;              <span class="descr">// 52 bytes long (ID is different a structure)</span>
    AnimData *adt;      <span class="descr">// 4 bytes long (pointer to an AnimData structure)</span>
    Object *camera;     <span class="descr">// 4 bytes long (pointer to an Object structure)</span>
    World *world;       <span class="descr">// 4 bytes long (pointer to an Object structure)</span>
    ...
    float cursor[3];    <span class="descr">// 12 bytes long (array of 3 floats)</span>
    ...
};
</code>

The first field in the Scene-structure is of type 'ID' with the name 'id'.
Inside the list of DNA structures there is a structure defined for type 'ID' (structure index 17).
 
<code class="block">struct ID {
    void *next, *prev;
    struct ID *newid;
    struct Library *lib;
    char name[24];
    short us;
    short flag;
    int icon_id;
    IDProperty *properties;
};
</code>

The first field in this structure has type 'void' and name '*next'. <br>
Looking in the structure list there is no structure defined for type 'void': it is a simple type and therefore the data should be read. 
The name '*next' describes a pointer.
As we see, the first 4 bytes of the data can be mapped to 'id.next'.
</p>

<p>
Using this method we'll map a structure to its data. If we want to 
read a specific field we know at which offset in the data it is located 
and how much space it takes.<br>
The next table shows the output of this flattening process for some 
parts of the Scene-structure. Not all rows are described in the table as
 there is a lot of information in a Scene-structure.
</p>

<table>
<caption>Flattened SDNA structure 150: Scene</caption>
<thead>
<tr><th>reference</th>
    <th>structure</th>
    <th>type</th><th>name</th>
    <th>offset</th><th>size</th>
    <th>description</th></tr>
</thead>
<tbody>
<tr><td>id.next</td><td><a href="#struct:ID">ID</a></td>
    <td>void</td><td>*next</td>
    <td>0</td>
    <td>4</td>
    <td>Refers to the next scene</td></tr>
<tr><td>id.prev</td><td><a href="#struct:ID">ID</a></td>
    <td>void</td><td>*prev</td>
    <td>4</td>
    <td>4</td>
    <td>Refers to the previous scene</td></tr>
<tr><td>id.newid</td><td><a href="#struct:ID">ID</a></td>
    <td>ID</td><td>*newid</td>
    <td>8</td>
    <td>4</td>
    <td></td></tr>
<tr><td>id.lib</td><td><a href="#struct:ID">ID</a></td>
    <td>Library</td><td>*lib</td>
    <td>12</td>
    <td>4</td>
    <td></td></tr>
<tr><td>id.name</td><td><a href="#struct:ID">ID</a></td>
    <td>char</td><td>name[24]</td>
    <td>16</td>
    <td>24</td>
    <td>'SC'+the name of the scene as displayed in Blender</td></tr>
<tr><td>id.us</td><td><a href="#struct:ID">ID</a></td>
    <td>short</td><td>us</td>
    <td>40</td>
    <td>2</td>
    <td></td></tr>
<tr><td>id.flag</td><td><a href="#struct:ID">ID</a></td>
    <td>short</td><td>flag</td><td>42</td><td>2</td>
    <td></td></tr>
<tr><td>id.icon_id</td><td><a href="#struct:ID">ID</a></td>
    <td>int</td><td>icon_id</td><td>44</td>
    <td>4</td>
    <td></td></tr>
<tr><td>id.properties</td><td><a href="#struct:ID">ID</a></td>
    <td>IDProperty</td><td>*properties</td>
    <td>48</td>
    <td>4</td>
    <td></td></tr>
<tr><td>adt</td><td>Scene</td><td>AnimData</td>
    <td>*adt</td>
    <td>52</td>
    <td>4</td>
    <td></td></tr>
<tr><td>camera</td><td>Scene</td>
    <td>Object</td>
    <td>*camera</td>
    <td>56</td>
    <td>4</td>
    <td>Pointer to the current camera</td></tr>
<tr><td>world</td><td>Scene</td>
    <td>World</td>
    <td>*world</td>
    <td>60</td>
    <td>4</td>
    <td>Pointer to the current world</td></tr>

<tr><td class="skip" colspan="7">Skipped rows</td></tr>

<tr><td>r.xsch</td><td><a href="#struct:RenderData">RenderData</a>
    </td><td>short</td><td>xsch</td><td>382</td><td>2</td>
    <td>X-resolution of the output when rendered at 100%</td></tr>
<tr><td>r.ysch</td><td><a href="#struct:RenderData">RenderData</a>
    </td><td>short</td><td>ysch</td><td>384</td><td>2</td>
    <td>Y-resolution of the output when rendered at 100%</td></tr>
<tr><td>r.xparts</td><td><a href="#struct:RenderData">RenderData</a>
    </td><td>short</td><td>xparts</td><td>386</td><td>2</td>
    <td>Number of x-part used by the renderer</td></tr>
<tr><td>r.yparts</td><td><a href="#struct:RenderData">RenderData</a>
    </td><td>short</td><td>yparts</td><td>388</td><td>2</td>
    <td>Number of x-part used by the renderer</td></tr>

<tr><td class="skip" colspan="7">Skipped rows</td></tr>

<tr><td>gpd</td><td>Scene</td><td>bGPdata</td><td>*gpd</td><td>1376</td><td>4</td>
    <td></td></tr>
<tr><td>physics_settings.gravity</td><td><a href="#struct:PhysicsSettings">PhysicsSettings</a>
    </td><td>float</td><td>gravity[3]</td><td>1380</td><td>12</td>
    <td></td></tr>
<tr><td>physics_settings.flag</td><td><a href="#struct:PhysicsSettings">PhysicsSettings</a>
    </td><td>int</td><td>flag</td><td>1392</td><td>4</td>
    <td></td></tr>
<tr><td>physics_settings.quick_cache_step</td><td><a href="#struct:PhysicsSettings">PhysicsSettings</a>
    </td><td>int</td><td>quick_cache_step</td><td>1396</td><td>4</td>
    <td></td></tr>
<tr><td>physics_settings.rt</td><td><a href="#struct:PhysicsSettings">PhysicsSettings</a>
    </td><td>int</td><td>rt</td><td>1400</td><td>4</td>
    <td></td></tr>
</tbody>
</table>

<p>
We can now read the X and Y resolution of the Scene:
<ul>
<li>the X-resolution is located on offset 382 of the file-block-data and must be read as a 
short.</li>
<li>the Y-resolution is located on offset 384 and is also a short</li>
</ul>
</p>

<div class="box">
<p class="box-title">
Note
</p>
<p>
An array of chars can mean 2 things. The field contains readable 
text or it contains an array of flags (not humanly readable).
</p>
</div>

<div class="box">
<p class="box-title">
Note
</p>
<p>
A file-block containing a list refers to the DNA structure and has a count larger
than 1. For example Vertexes and Faces are stored in this way.
</p>
</div>

</body>
</html>