Hi Bastien, checked it, fixed also my issue :-)
thanks, Daniel! On Sun, Aug 9, 2015 at 10:16 PM, Bastien Montagne <[email protected]> wrote: > Hi Daniel, > > No, it was not intended at all - trying to fix bad logic (and a crasher) > in our mesh customdata writing code, I ended up created that even worse > situation (which, for some exotic reason related to order of reading, > did not affect Blender reading itself). > > This was bad for sure, and has been fixed since a few weeks now (see > https://developer.blender.org/rBff3d535bc2a63092357533acbe7289556af956a0). > > Cheers, > Bastien > > Le 09/08/2015 21:34, Daniel Balster a écrit : > > Hi, > > > > I'm importing 3D data directly from .blend files for a few years now. > Today > > I found out that if a scene was saved with version 2.7.5 it is creating > > non-unique block pointers: > > > > - the .blend consists of blocks, each of them has the "old pointer" from > > the last session, and data is using these pointers as keys > > > > here's a small C code that lists all these pointers: > > > > // works only with le 64-bit blend files on le 64-bit machines > > #include <stdio.h> > > #include <sys/stat.h> > > #include <sys/mman.h> > > #include <fcntl.h> > > typedef struct { char code[4]; int size; char *pointer; int index; int > > count; } block; > > int main(int argc, char **argv) { > > struct stat st; > > int fd=open(argv[1],O_RDONLY); > > if (fstat(fd, &st)) return 1; > > size_t size = st.st_size; > > void *addr = mmap(0, size, PROT_READ,MAP_FILE+MAP_PRIVATE, fd, 0); > > block *b = (block*)((char*)addr + 12); > > for (;;) { > > if (b->code[0]=='E' && b->code[1]=='N' && b->code[2]=='D' && > > b->code[3]=='B') break; > > printf("%p\n",b->pointer); > > b = (block*) (((char*)b) + sizeof(block) + b->size); > > } > > return 0; > > } > > > > compile it as blenddump and use it like this: > > > > blenddump file.blend | sort | uniq -d > > > > and it will show you duplicate pointer keys. > > > > This behavior started with v275, if you load any older version and save > it, > > it will suddenly have these non-unique keys. > > > > The data blocks causing this are only the CustomDataLayer's > > > > so if you have a mesh with ldata, pdata, vdata, etc the back-reference to > > another block should be impossible, but it's still working for blender. > > Haven't checked why it's still working, just want to put this here. > > > > Any clues? Intended behavior? Could this cause problems? > > > > -daniel- > > _______________________________________________ > > Bf-committers mailing list > > [email protected] > > http://lists.blender.org/mailman/listinfo/bf-committers > > > > _______________________________________________ > Bf-committers mailing list > [email protected] > http://lists.blender.org/mailman/listinfo/bf-committers > _______________________________________________ Bf-committers mailing list [email protected] http://lists.blender.org/mailman/listinfo/bf-committers
