[Bf-committers] Blender .blend file format and FileGlobal struct
kburjack at googlemail.com
Sun Dec 7 18:32:18 CET 2014
the problem with the 4 bytes not being written is now solved, thanks!
Turned out to be a problem with my program, of course. :-)
2014-12-05 23:19 GMT+01:00 Kai Burjack <kburjack at googlemail.com>:
> I just subscribed to this mailing list, so a friendly "hello" first. :-)
> Currently, I am building a Java tool that produces .blend files for
> consumption by the Blender application.
> Looking at the C code and the struct definitions and the file
> "writefile.c" it really is a straightforward process.
> But, at one point I came to a halt, and that's when I want to write the
> FileGlobal struct, which the Blender source does with the function
> 'write_global' in the source 'writefile.c'.
> This struct, as defined in 'DNA_fileglobal_types.h', defines at its very
> beginning a char followed by two short's.
> My tool writes data according to this exact struct definition, but somehow
> the .blend files written by the Blender application are exactly 4 bytes
> shorter (two times 2 bytes) there. Looking in with a hex editor it is
> exactly at that very beginning where that 'char subvstr;' and the 'short
> subversion, pads;' should be written.
> So, these are 8 bytes. 4 for the char array and 2 times 2 for the shorts.
> Now, the Blender-written .blend file here has only 4 bytes written, instead
> of the expected 8.
> I assume this is due to the fact, that compiler optimization kicks in,
> resulting in the char-array member being simply erased from the struct
> definition, because it is actually never read anywhere in the code.
> Only the char array is read, namely in the function 'read_file_version'
> defined in 'readfile.c'.
> Is this right?
> Otherwise I would not know how Blender falls short of writing the 4
> additional bytes there.
> Best regards,
More information about the Bf-committers