Hi Bastien,
Same problem here. I tested on the Pixar texture library: https://community.renderman.pixar.com/article/114/library-pixar-one-twenty-eight.html and I had no thumbnails in the first folder, in the second one, it flickered for 2 seconds and then crashed Blender. On official master, thumbnails are shown and it doesn’t crash in any folder.
Something really missing is the possibility for the search function to look inside .blend files. There is no file manager on windows or Linux which can do something like that, so we have to manually look in every .blend and it’s folder at the moment. Having this in Blender would be awesome.
@matali thanks for testing too, I guess you are under windows as well? That set of textures previews perfectly well here on linux, looks like I’ll have to use my win VM again…
Something really missing is the possibility for the search function to look inside .blend files.
. Eeeeh, not sure I understand that? Filtering works well with .blend datablocks too, just enable ‘Blend File’ recursion level (first dropdown in header) in append/link, and type in your search?
COOOOOOOOOOOLLLL!!! yep it works Just have no preview of those datablocks, but I guess it’s due to the Windows bug. Sorry for you having to start your VM. Where are the Linux testers? I personally had to much problem with Linux (drivers making the machine impossible to boot, no universal installer, old versions of many programs, etc…). Blender is the only program I know which you can just unzip in Linux and run it out of the box all other are nightmares if their is no ppa.
This is a very strange thing… I do can reproduce the crash on win VM with the testbuild, but not hen I build from branch!!! Still investigating (takes time, building on win VM takes ages). PS: you can only have previews of datablocks if the .blend file has a preview of them (which is usually not the case with current .blend files), see File->Data Previews menu.
Not so far, unfortunately. Issue is, I can easily reproduce the crash with builds from the buildbot, but not with my own ones… No idea about what’s hapenning here so far, and rather hard for me to investigate.
No, I mean that the testbuild of asset-experiments (which is built by buildbots, with same ‘environment’ as regular builbots’ builds and official releases) does crash, while when I start my win VM, checkout asset-experiments branch and build it myself with own MSVC, it does not crash (neither release nor debug builds)… Not being able to reproduce on own build makes it really hard to investigate.
did you use “python scons\scons.py” in blender source folder or did you build from MSVC GUI? The Scons method does like buildbot if you want to reproduce. I had same problem when switching from linux, I tried to build with CMake (because of make on linux) and it did completely different builds (slower with less features). Scons does all in one command.
Yeah… more and more strange - own build with scons does behaves badly (no crash here, but no preview and other strange things).
I really do not understand this mess, the patch only touch one CMake/scons file, and aonly adds one includ path to those! very weird (I would bet for some mess on atomic operations for some reasons, but no clue at all why it would afect scons builds and not cmake ones).
Even with latest decision of moving to cmake for windows, the cmake builds are still much more instable than the scons ones and slower at rendering in cycles (about 15%). For why Scons does the instability, maybe some -O options which are different from CMAKE? would explain the speed difference with cycles. But for the file browser, speed is really not that essential, so disabling some optimization regarding your part of the code (while keeping the ones for cycles as is) could help?
OK, win/scons bug should be fixed now. Also tweaked a bit more icon generation stuff, new builds are available at usual place (http://download.blender.org/ftp/mont29/).
Yep, it works here. If you list the improvement/changes you made, I can test them and report here. I couldn’t find any list myself so I don’t know what to do.
But in fact, pretty much all aspects of the filebrowser can be checked, changes in this patch are mostly internal (i.e. no so visible by user), and can potentialy affect pretty much everything (file rename, selection behavior, etc. etc.).
As I said, it’s really fast, but I have the impression it’s a bit slow on HDDs. Is the file reading also multi-threaded ? Looks like the head is seeking a lot. It may be more efficient to make sequential reads and make only the processing part multi-threaded ?
Found a bug. With “level one” the flickering is still there (.blend preview come and go really fast and lead to crash). Strange enough, with level 3 it didn’t happen (also this level really heavy is tens of thousands of datablocks were listed).
I need to save some files with preview for materials etc… but I’m afraid to use beta functions that can write to disk. Did you do some testsuite to ensure some level of reliability? I don’t have any VM to protect my datas…
Hrmmm… modern OS are supposed to be smart enough to serialize and optimize concurrent disk access (this does not only means between threads, but also between different processes) - and modern HDDs also are supposed to optimize that on a more basic level… In any case, all data must be read, and thumbnails must be written, so yes, on huge collections it can use the disk quite a bit. I really think this should not be a problem at our level (in fact, threading when it comes to file operations is a great way to gain speed, since limiting factor here is often precisely disk access through the OS API).
Grr! xD will check (does not happen on linux afaik).
This build/branch adds nothing to writing process of Blender, it just adds some more data ‘chunks’ to some IDs, that’s all. There is absolutely no need of using a VM or any ‘OS-level’ protection mechanism here. The worst thing that could happen (albeit very unlikely) would be a corrupted .blend files, so you for sure do not want to replace production files with versions generated by this branch - but this is common sense with any testing build anyway.
I have a HDD with NCQ and the driver supporting this, but it is slower anyway, particularly on a 16 threads processor. Disabling HT helps but make Cycles slower. Also, Network drives and USB drives really suffer from this (2.72b is much faster in this case). I can understand you really want to submit the patch, so if you can’t now, maybe for the next release it would be good to at least think about it. No disrespect to your work, just a user point of view.
Just have no preview of those datablocks, but I guess it’s due to the Windows bug. Sorry for you having to start your VM. Where are the Linux testers? I personally had to much problem with Linux (drivers making the machine impossible to boot, no universal installer, old versions of many programs, etc…). Blender is the only program I know which you can just unzip in Linux and run it out of the box all other are nightmares if their is no ppa.
I do can reproduce the crash on win VM with the testbuild, but not hen I build from branch!!! Still investigating (takes time, building on win VM takes ages). PS: you can only have previews of datablocks if the .blend file has a preview of them (which is usually not the case with current .blend files), see File->Data Previews menu.
