Assets – FileBrowser Preliminary Work – Experimental Build II

Warning: this post is mostly technical, since nearly nothing changed feature-wise. Testing is really needed though, internal changes are quite heavy!

You may find the builds at the usual place: http://download.blender.org/ftp/mont29/

From the “outside”, user point of view, this build does not differ much from previous one from January. Only changes (outside of master work, like preview size) are:

  • Some data was removed from the detailed view (modes and owner – UNIX-only, and Blender is not an OS file browser!).
  • Columns of compact (default) and detailed views are now fixed-size (among four choices, like for previews view). This is due to internal changes detailed below.

Internal changes were mostly done for future asset engines, but they also improve regular file browser experience, in a nutshell:

  • Smaller memory footprint when browsing directories with huge number of items (several thousands and more) – especially in case of preview display mode.
  • Much quicker display of those previews.

Plan is to merge this branch (or as much as possible of it) into master after 2.75 release.

Now for the technical details!

The main changes are under the hood – a full rewrite of our file listing code, to reduce memory usage and global computing effort. The idea is to keep as few as possible data from actual directory(-ies) listing, and to generate the full stuff needed to draw in filebrowser window only when needed, following the “sliding window” principle.

So, let’s say your file browser is currently centered on item 4000 in a directory containing 10000 files. We do store minimal data for those 10000 files (what’s needed for sorting and filtering), but only generate complete info (detailed types, strings for size, previews, etc.) for items through 3489 to 4512. Then, if user scrolls slightly to center item 4500, we only trash items up to 3988, and only have to generate those from 4513 to 5012… As a bonus, this means e.g. previews are generated for visible areas first, instead of ‘flat’ top-to-bottom process which would sometimes takes several tens of seconds to reach the bottom of the listing.

This allowed us to reduce our `direntry` struct size (it now basically wraps path and stat info). But the main improvement is with previews – since a few days previews are now 256*256 pictures in master. For a directory with 10000 images in preview mode, that means 2.6GiB of ram – just for previews! While with a sliding window of about one thousand items, we can limit this to a maximum of 266MiB – should we be browsing a directory with tens of thousands of items.

This is a rather extreme example of course, but not uncommon (think e.g. to render directories, or one with one or two hundreds of library .blend files read in new ‘flat’ mode…). And there is another reason why this change is needed: future asset engines. One can easily imagine on-line asset repositories with tens of thousands of items, you just cannot generate in Blender items for all of them at once! With that new code, asset engine only gives Blender the total number of entries, and then Blender requests for a limited range of those as needed (note that ordering and filtering will obviously also be deferred to asset engines).

.blend file items preview has also been moved into IMB_thumb area. This was mandatory, as we do not store previews for all items, we could not read them anymore while doing the initial listing. The main drawback is that it means on first run, .blend files will be read twice. However, there are several great advantages:

  • Consistency: .blend library items previews are now handled as any other (image, font, .blend file itself…) – this also means other areas of the code can easily get previews for them.
  • Performances: since they are handled by IMB_thumb, they also use the thumbnail caching system – in other words, .blend file is read once, regenerating the thumbnail later will only be a matter of reading the cached .png file!

Also, one side effect of those heavy changes is that previews should be generated much more quickly, since they now use a much lighter `BLI_task`-based threading, instead of the complex and heavy `Job`-based one.

Assets – FileBrowser Preliminary Work – Experimental Build I

Assets – FileBrowser Preliminary Work – Experimental Build I

So, as some of you may know already, since December 2014 and my three weeks spent in Amsterdam at BI, I’ve started working on the asset topic.

An 'Append' file browser with two blender files showing all their materials, objects and textures. Note the renamed bookmark on the left too.

An ‘Append’ file browser with two blender files showing all their materials, objects and textures. Note the renamed bookmark on the left too.

So far, I did not do anything really directly related to assets (except early designing) – rather, I’ve been improving the editor I intend to use later for assets handling, i.e. the FileBrowser. I have already ported some cleanup/refactor and some minor features (like search field in header, operator to enforce mat/tex/etc. previews generation, …) in master, but most work is still in the dedicated ‘assets-experiments’ git branch, so I’ve made some experimental builds to (try to😉 ) get a bit of testing. In those builds you’ll find:

  • Bookmarks and co using UIlists, with possibility to rename and reorganize bookmarks, plus the default features of UILists (filtering by name, and some sorting).
  • Possibility to list the whole content of a blend file (in append/link mode) at once (set ‘Recursion Level’ setting to 1), and in any mode, to list several levels of the directory tree in a “flat” mode (including blend files content if relevant, set ‘Recursion Level’ to 2 or more).
  • Consequently, possibility to append/link at once several items, either from a same .blend lib, or even from different ones.
  • Also, filtering by datablock types was added (so that you can see only e.g. materials and textures from all .blend libs from a same directory…).
  • Previews were added to object and group datablocks. Generation of those is handled by a python script (note: only handles BI renderer in this build, Cycles is yet to be added).

Note about previews of datablocks like materials, textures, etc., you have to manually generate them (from File -> Data Previews main menu), and then save the .blend file. On the other side, preview generation of objects and groups work with separated automated tasks ran on selected .blend files (which should rather not be opened at that time). This is quite inconsistent and shall be fixed for sure! On a more technical aspect (though it can also have effects on user PoV):

  • Directory listing is now also a background job (like thumbnail generation of images and .blend files), which means listing huge directories, or remote ones, does not lock the UI anymore.
  • Previews of datablocks (IDs) are now exposed in RNA, so third party scripts will also be able to generate their own previews if needed. Not all ID types have previews though (only object, group, material, lamp, world, texture and image ones currently), this is likely to change though.

So, as usual, any feedback is more than welcome! Note too that Windows behavior was not tested at all yet (don’t like starting my win WM:/ ), do not expect (too much) issues on this platform, but you never know with Windows. Cheers, and hope that new year will be full of good things for Blender and all of you!

Duplicated to http://code.blender.org/index.php/2015/01/assets-filebrowser-preliminary-work-experimental-build-i/

Data Transfer – First Test Build

EDIT: This tool is now in master, and will be part of Blender 2.74 release.

So, since a month or two have been working on a tool that we should have had in Blender since ages – generic way to transfer some data from a mesh to another.

Feature is not yet finished, of course, but I think it’s starting to be usable, so made a first set of test builds, available here.

You may also find a first draft of manual on this wiki page.

Usual disclaimers: this is WIP code, it still may change quite a bit before it goes to master, so you should not use it in production (or do it at your own risk!). Please report issues and bugs on Blender tracker.😉

Any testing and feedback is most welcomed!

Custom Split Normals – Second Testbuild Available

EDIT: This tool is now in master, and will be part of Blender 2.74 release.

Here are three links on Graphicall.org for testbuilds of current Custom Split Normals state of work:

Since first of August, most noticeable changes are:

  • A fair amount of bugs were busted (most noticeable being wrong handling of (interpolation) weights, and crash with the modifier when switching target mesh to Edit mode).
  • Data structures were tweaked (WARNING: this means files saved with builds from 08/01 are not ‘compatible’ with those new builds, they will load, but all custom normals will be lost).
  • Some optimization work was done (especially in code computing final split normals, which is now multi-threaded).
  • Modifier UI was reworked, and a new ‘from split normals’ mode was added, which uses split normals of target, instead of its face normals.

As usual, please note that this remains “experimental” code, do not expect on stability of new features yet, nor of the file format (though this one should not change anymore, imho).

Also, if you are doing some nice tests with these builds, I would appreciate some nice screenshots (and even better, .blend files), those would be more than useful for final documentation!🙂

Please report any bug you may (will!) find to our bug tracker, https://developer.blender.org.

Custom Split Normals – First Testbuild Available

So, to change a bit from FBX, something funny this time!😛

Here are three links on Graphicall.org for testbuilds of current Custom Split Normals state of work:

Please report any bug you may (will!) find to our bug tracker, https://developer.blender.org.

EDIT: You can now found this project’s code in a WIP branch on our git repository: temp_custom_loop_normals (note the edits to FBX addons to enable custom normals import are not available this way).

Currently (but those features should not evolve much in near future), you can:

Import custom normals from FBX

Supports both vertex and ‘face corner’ normals. Note other addons can do it as well, but that’d be done once the work is merged in Blender’s master!

Write/read custom split normals into/from .blend files

Those custom  split normals are stored like e.g. vertex colors or any other custom data layer, which means that you can also edit your mesh (deforming should still give reasonably good custom normals, modifying the topology however (adding/removing faces, sharp edges, etc.) can quickly lead to nasty custom normals!).

Please note there is no guarantee about the final format of those data though, in other words, files created with those testbuilds might very well not be usable by later ones or final version (though this is rather unlikely, imho)!

View custom split normals in 3DView or renders, and re-export them

Custom split normals are fully integrated into the process to generate final split normals, so when you use the laters (exactly as in current official 2.71 release or master), you’ll get your custom normals instead of auto-generated ones, if available.

Note that when there are some custom split normals data, the ‘angle’ threshold of AutoSmooth is unused (as if it was at 180°), so you only can use sharp edges to define ‘smooth fans’ (i.e. a set of adjacent face corners sharing a same vertex, and a same split normal).

Add or Edit custom split normals with the SetSplitNormals modifier

It has two modes:

  • Ellipsoid assigns to each vertex the normal it would have at the surface of an ellipsoid (proportions of that ellipsoid are defined from bounding box of the modified object, and you can use another object to define the position of its center). Allows e.g. to realize a simple ‘tree shading’ effect (see http://wiki.polycount.com/VertexNormal ).
  • Object uses another object’s geometry to assign to each vertex the normal that target’s closest face. Allows e.g. to make the ‘fake smooth round corners’ effect – you take a cube, bevel its edges, and add a SetSplitNormals modifier to it using another cube as target.

FBX 7.4 Updates – III

Since last report, main missing feature was added to Export, and Import was greatly improved :

* Shapekeys export has been added, including animation (only for relative shapes, n o support for absolute ones’ animations currently).

* Armatures import was added (though there is a remaining unclear issue about bones’ orientation).

* Shapekeys import was added.

* Limited animation import was added, for loc/rot/scale of objects and bones, and values of shapekeys.

Last point needs some precisions – we currently always read FBX curves assuming linear interpolation. This means that if you FBX file has some fancy Bézier-like interpolated anim curves, results will be rather poor. In a word: bake your animations at export time! Note complete import support for FBX anim curves is a TODO, but not a top-priority one currently…

As usual, a bunch of more minor enhancements and bug fixes was done too.

And as usual, we need testing, testing and even more testing of the whole FBX io addon – complete feature should be in Blender nightly builds within a few hours. Just be kind, and if you find some failures, report them with a tiny FBX file illustrating the issue, not a whole multi-MB project one.😉

Blender is NOT an API – let alone its addons!

So… The other day, a guy spent hours on IRC insulting everyone about “Blender always breaking its API for mere renames”. Today, I got this comment below:

Castano

By breaking the existing script interface and changing the way curves work you have done a tremendous disservice to the people that need FBX export the most.

The fact that you got the funds to do this development in part from Unity Tech, but couldn’t be bothered to keep the old interface intact tells me you are not competent for this kind of work. You don’t understand the priorities, at all.

All you would’ve needed to do is to keep this path to the ASCII code intact:
“io_scene_fbx.export_fbx.save”

You could’ve had named the new export “save_bin” or “save_new”, or something like that, instead of keeping the name but breaking the interface nonetheless. Instead, you expect Unity (and everyone else) to clean up after you. The idea that you couldn’t just easily support this is nonsense.

Secondly, you don’t understand that people absolutely *need* the classic FCurve workflow. The new “baking” workflow is a nice feature, but only if it is optional. It can’t just replace the old workflow, and you shouldn’t be wasting everyone’s time by just changing this without being explicit about it.

I sincerely hope you can be bothered to keep the old ASCII export around, as long as you have these regressions in the binary exporter.

So, to that specific case first. I did not remove nor renamed io_scene_fbx.export_fbx.save, as everyone can see in that history page. So people could first stop talking about things they do not know about. Actually, I added new “bin” exporter in a new py file, with a new name.

Oh, and by the way, FBX export to Unity itself is not  broken at all, the only thing that is broken is a helper script in Unity itself that “hides” FBX exporting, making it looks as if Unity could directly open .blend files…

Nevertheless, it somehow broke that Unity’s script… What the heck? Seriously!

Let’s summarize:

  • Blender is free and open source;
  • Blender is an application, not a library;
  • Blender features several extensions (“addons”);
  • A third party society reuses an addon’s code (free and open source, if I may remind) to provide a feature in its own, closed and (at least for the full version) charged application;
  • Some changes are made in the free, open source addon, which somehow break that third party society’s product;
  • And some guys go reproaching the new, enhanced addon, yelling about breakings, raging over IRC (and, I guess, forums etc.), insulting, …

That does not make me happy. Not at all.

I’ve spent let’s say about three months of full-time work (probably more, actually) on the mess that’s called FBX. I would not wish that to my worst enemy. I’m already really sick of it, I’m pushing myself to complete the last pieces of needed features in new exporter (and importer) for 2.72… All those guys might gain is me dropping completely and definitively this task. They are free to take it over, since they are so wise ans full of knowledge and competent and super heroes and all that, I’d wish them good luck.

Now, back to the general case. Again, Blender is not a library. Let alone its addons!!!

We do have a few pieces of library inside Blender – some helper modules in python, PY RNA interface itself (how properties are defined, how operators are called, that kind of stuff). But! Operators themselves, data access themselves, RNA types themselves are not an API, in the sense they offer a direct acces to Blender’s internals, and Blender’s internals are not, were never meant to be, and will (probably) never be a library. Which means we do not have to twist and tweak to keep compatibility. We do try to do it, to some reasonable level, of course. We rarely do mere renames, and when we do, we keep old names (as deprecated) available at least for one or two releases. When we add a new parameter to a function, we try to make it optional as much as possible. But when we change how an operator works, or remove one, because it’s no more needed inside Blender or was doing bad work, we won’t keep it as a stupid “proxy” just for our py interface. Nor do we when we change data structures inside Blender.

As a side note, let me say you how much a mess can come from trying to keep compatibility – I had to experience it while working on (yes, again!) FBX format, and this does not give a nice result. At all.

So, as a final word: we do not need people which are just yelling, without actually doing anything, not even being constructive, which do not simply know how to talk with others! To those: STOP WAISTING OUR TIME!