Mostly various cleanups, and a few important fixes too (some potential
memleaks, missing writing of UUID struct for ID placeholders of linked
data-block in writefile.c).
This commit is a subset of the asset-engine branch, only adding the uuid
struct to data-blocks, with a basic minimal RNA/Python API to use it.
it does not contain anything regarding asset engines and asset
management itself.
Besides being a first step towards full integration of asset engine work
into master, it is also the 'minimal requirement' from the studio here
for next Cosmos production pipeline (regarding own in-house management
tools).
This still *very* basic, but should be usable as proof of concept for
Cosmos pipeline tests...
Note that the question of where to put all asset metadata remains open,
we could extend AssetUUID struct, and/or add support of IDProps to it,
or just use some special-named IDProp in IDs themselves (like the
_RNA_UI thing for custo; props UI settings...).
Partial merge only, UI in filebrowser has been heavily changed and need
more work...
Conflicts:
release/scripts/startup/bl_ui/space_filebrowser.py
source/blender/blenloader/intern/versioning_280.c
source/blender/editors/space_file/file_draw.c
source/blender/editors/space_file/filelist.c
source/blender/editors/space_file/filelist.h
source/blender/makesdna/DNA_space_types.h
source/blender/windowmanager/intern/wm_operator_props.c
Kinda painful merge thanks to extensive changes to things like Main
listbases names, linking code, etc.
Conflicts:
source/blender/blenkernel/BKE_library.h
source/blender/blenloader/BLO_readfile.h
source/blender/blenloader/intern/readfile.c
source/blender/blenloader/intern/writefile.c
source/blender/makesdna/DNA_space_types.h
source/blender/windowmanager/intern/wm_files_link.c
Rather painful, too much cleanup/renamings in between...
Note that this is not currently functionnal, builds but does not show
AEs in filebrowser selector for some reason. No time to track that now.
Conflicts:
source/blender/blenkernel/intern/library.c
source/blender/blenloader/BLO_readfile.h
source/blender/blenloader/intern/readfile.c
source/blender/blenloader/intern/versioning_defaults.c
source/blender/editors/space_file/filelist.c
source/blender/editors/space_file/filelist.h
source/blender/editors/space_outliner/outliner_draw.c
source/blender/editors/space_script/script_edit.c
source/blender/editors/space_script/script_intern.h
source/blender/editors/space_script/script_ops.c
source/blender/makesrna/intern/rna_internal.h
source/blender/windowmanager/intern/wm_files.c
source/blender/windowmanager/intern/wm_files_link.c
Got lost in big undo refactor.
Note that this is probably (maybe) not how we want to have it in the
end, things like EditMode undo should probably not trigger this check?
This allows asset engine to perform whatever they need on data-blocks
(either linked or appended ones), once they have been added to Blender
data (Main).
This is an optional callback intended for advanced/complex asset
management (and possibly also for generative procesing), basic asset
engines should typically not need it.
Amber uses it just to do some dummy testing prints right now.
Well, real add-on... since we want to keep it in main repo for now, it
still needs some hacks to 'behave' like a regular add-on. :/
Anyway, it's now removed from startup files, and will live in modules
until we go to master itself.
Also, make it enabled by default in factory startup.
We should only set mouse coordinates when we are actually invoked to
link something, not when we are invoked to show filebrowser.
Else (filebrowser invoke case) we have a mouse coordinates sticking
around, which we try to use later in wrong context.
For some reasons, in master that was not an issue, but in 2.8
ED_view3d_give_base_under_cursor() will crash when context is wrong. :/
This is very bold right now - you simply can replace (or add) an action
to an override data-block. Actions themselves are not 'customizable'
through override at all currently (we may at least add
'add/remove/replace fcurves' feature in future), and nothing else in
animdata is overridable currently.
You can now override loc/rot/scale of objects and posebones.
Also added a basic operator to make an override of active linked object,
but this is very limited/wip/testing feature (you have to manually override
object and its armature, and relink to proper local overrides
yourself...). Final 'make proxy killer' will be much more automated of
course.
First real 'usable' commit, will be needed by the 'virtual data-block'
asset feature (i.e. to be able to link a mere image file as if it was a
linked datablock, and generate automatically an override of it to make
it editable).
We could do that in several different way, e.g. adding some tag during
DEG evaluation, etc. But this is not a critical process (it's main
purpose is user feedback), so current solution seems to work well enough
- and it's dead simple! ;)
This is essentially a huge refactor/extension of our existing RNA
compare & copy code, since static override needs more advanced handling here.
Note that not all new features are implemented yet, advanced things like
collections insertion/deletion are still TODO (medium priority).
This completes the ground work for overrides, remaining commits will be
about UI and some basic/testing activation of overrides for a limited
set of data-blocks & properties.
For details see https://developer.blender.org/D2417
See https://developer.blender.org/D2417 for details.
Note that since static overrides rely heavily on RNA, this commit is
essentially invisible from user PoV, more in next commits.
This function swaps the memory content of two data-blocks (of same type
obviously), while preserving most of the ID 'header' itself.
It is intended to be used to quickly and easily replace the data of an
existing ID by another one, presumably a temporary 'working' one,
without having to suffer from things like name changes,
registering/removing from Main database, etc.
Initially there was hope at least part of this work could be used for
dynamic overrides as well... but looks like not, so better be specific
and avoid any confusion.
PS: this commit break any file saved with static overrides, should not
be an issue though.
local and reference are awfully confusing names here, since destination
is a copy of reference that will become local override once applied, and
source is .blend-file-written version of local override...
Main reason here is to make comparison/override_diff/override_store/override_apply
customizable per RNA property if needed.
This should allow us especially to get advanced behavior on case-by-case
basis, when dealing with Pointer and Collection properties mostly.
Note that IDProps remain fuzzy area for now, a big part of the code
tries to take them into account, but it's most likely still missing some
bits, and definitively not tested at all yet!
Not sure why that piece of code stopped working, but now this operation
is pretty much never evaluated... Will have to either dig deeper in DEG
or ask Sergey about it, but not a crucial issue for now.
Animation is by definition another kind of (dynamic) override of properties,
which supersedes static override.
Note that this could be debated in some corner cases ('differential'
animation, like dloc/drot/dscale), but think we can ignore that for now,
and expect user to handle those manually when needed.
Not sure why that piece of code stopped working, but now this operation
is pretty much never evaluated... Will have to either dig deeper in DEG
or ask Sergey about it, but not a crucial issue for now.
Animation is by definition another kind of (dynamic) override of properties,
which supersedes static override.
Note that this could be debated in some corner cases ('differential'
animation, like dloc/drot/dscale), but think we can ignore that for now,
and expect user to handle those manually when needed.
This means that from now own, we work based on Blender2.8!
Conflicts:
source/blender/blenloader/BLO_readfile.h
source/blender/blenloader/intern/readfile.c
source/blender/editors/space_file/filesel.c
source/blender/editors/space_outliner/outliner_draw.c
source/blender/editors/space_view3d/space_view3d.c
source/blender/makesdna/DNA_ID.h
source/blender/makesdna/DNA_scene_types.h
source/blender/makesdna/DNA_text_types.h
source/blender/windowmanager/intern/wm_event_system.c
source/blender/windowmanager/intern/wm_files_link.c
source/blenderplayer/bad_level_call_stubs/stubs.c
Means that from now on, we work based on blender2.8, no more master!
Conflicts:
source/blender/blenloader/intern/readfile.c
source/blender/blenloader/intern/writefile.c
source/blender/depsgraph/intern/builder/deg_builder_nodes.cc
source/blender/editors/interface/interface_ops.c
source/blender/makesdna/DNA_ID.h
source/blender/makesrna/intern/rna_ID.c
Append/link exec code was not handling correctly asset cases in 'single
item' case.
Also, first drag'n'drop code was slitghly too much simple, losing uuid's
on the way, had to make things a bit more convoluted...
There are cases where we'll want to also override the reference pointer
(when we actually switch that datablock itself), but in some specific
situations, like when creating a new override, we need to keep org
pointer here!
Essentially, this reverts most ID_IS_LINKED_DATABLOCK() checks to
ID_IS_LINKED() one.
Idea of making virtual linked IDs editable was nice as a temp hack to do
quick experiment, but was never intended as final solution, correct way
to do that is to use static override, will be implemented soon.
Note that virtual library/virtually linked ID concept remains, it's
mandatory to handle mere files as assets (and potentially other, more
advanced cases in the future).
Also get rid of hack mixing repo and asset uuid into same UUID, now we
do have a real repo UUID in API.
Everything seems to be be back on par with pre-View changes status.
This commit add new 'View' forth layer, below history one (Revision).
It also adds a real UUID for the asset repository (as usual, asset
engines not needing it can just set it to zeros), will make Amber's life
(and all multi-repositories engines) easier.
Also fix one or two issues found on the road.
Code builds and links datablocks from libraries in the 'old way'. Real
test will come when re-enabling Amber and adapting it to new API though.
* Reported number of assets was -1 in list_dir callback, incorrect and
would loop endlessly in case of empty repo!
* Conversion from main asset classes to their propertygroup
representations was not clearing extra entries in proplists.
Since we want to be able to edit repo from within Blender, we'll need
UI-compatible representation of the repo.
Alas, PropertyGroup py instances are regenerated all the time, which
means we cannot store py-only data in those, so we have to go to a
triple representation of repo here (the JSON/dict one, the effective py
classes, and the UI-compatible PropertyGroup-based one).
Note that this is rather heavily WIP commit, it most certainly breaks
several things, but at least the basic repo listing from filebrowser is
working again...
No real reason we keep this only to copying, creating ID outside of
database is handy as well!
Also, add helpers to add/remove an ID from Main, and to set/clear its
'user refcounting' status. Those will be useful in future complex ID
manipulation cases (like static override...).
Not much happy, have to include BKE_curve in BLI_freetypefont to copy
nurbs... Not sure why fonts are in BLI tbh. We are already replicating
quite a bit of nurbs logic there. :(
Those are not actually copying the ID, only its internal subdata (and
other ID-specific handling). Generic processing common to all ID copying
is done by `BKE_id_copy_ex()`!
Makes things much simpler, and more consistent.
Also fix issue with new copying and bloody nodetrees, using same hack as
in original ntree copying code to detect 'root' ntrees that shall never
be put into bmain :(((((((
Note that those are an nightmare to handle correctly, current code is
like a plate of noodle, so... most likeley not fully working, think I'll
have to nuke localize code as well :(
(continuation of previous WIP commit, sorry about that one :/ ).
This commits changes quite a few things, distributing new copying flags
into sub-data copying code (mostly concerns ID refcounting or not).
It also removes ID refcounting handling from Modifiers' copy callback
(this was ugly from the start, proved to be problematic in current
master, and generally bad practice). This is now done by calling code.
Also, it brings back ID refcounting handling to main BKE_library's copy
code, which means in generic ID copying lower-level IDType-specific copy
code should not use it at all. Support at lower-level remains needed
though, unfortunately, to cope with partial copying tools etc.
It tried to assert that
addons/io_blend_utils/blender_bam-unpacked.whl/__init__.py was loaded when
the io_blend_utils module was imported. However, this happens only on
demand, and not directly when importing the add-on.
*Sigh* One more example of why we should keep ID management handling in
as few places as possible! It's impossible to keep more than a few
places in sync regarding which ID pointer is refcounted etc.
Children where always getting at least one segment of fixed length...
Now fully hidden ones (zero length) get no segment at all.
Note that even very short ones keep getting one 'unit' length segment - would
rather avoid changing that at this point, given how complex children
particles 'length' can get with all kind of modifiers... Think we can
live with that for now anyway.
The crash did not happen yet because we always had proper vmemh defined in
the parent scope.
Patch by Ivan Ivanov (aka obiwanus), thanks!
Differential Revision: https://developer.blender.org/D2715
Idea is the same, looks like it will be a tad simpler than with copy
though, since we should not need to change each ID type freeing func, as
ID usercount handling is done in main BKE_library code (would like to do
that for copy as well, but it's not that simple).
Namely, those allowing to link an object to an armature.
Thing is, we cannnot and absolutely do not want to use same trick as
armature proxies regarding deforming their related geometries.
So instead, we'll automatically make override of objects using
overridden armature as deformer, ultimately. This also allows for
several overrides of a same linked data.
Not sure how much good/bad this is, will have to ask artists once it's
ready for testing (cannot think of any non-ugly way to do that 'magic
trick' tbh).
Nothing functionnal for now, just made it possible for override to have
NULL reference ID.
Those overrides would be used as templates (created in original file of
the ID, they define some kind of default overriding settings). They
should also allow to forcefully lock some properties (forbid users of
that library ID to override some properties).
On second thought, modifying real data-block to store diff in it is...
just bad. Because it affects actual data, because it involves complicated
and heavy processes like remapping, and because it stores useless values
in .blend file (i.e. values that would give garbage results if e.g.
opening .blend file with older version of Blender, etc.).
So instead, decided to save an extra data-block in .blend file each time
we have some differential overrides.
Note that for now, we do full copy of datablock into its extra 'storage'
sibbling for .blend file. This is bad (think about double copy of heavy
mesh...) and will have to be fixed. Whole copy process will need serious
work anyway, for that kind of features we need to be able to copy
without increase usercount of IDs etc.
In fact, here, maybe we even need a smarter version of copy that would
only duplicate sub-data as needed by diff-overriden properties...
That way we don't have to add the same stupid few lines to *all*
datatypes writers! Obvious gain on efficiency and security from coding PoV.
Conflicts:
source/blender/blenloader/intern/writefile.c
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader
maybe).
Reviewers: sergey
Differential Revision: https://developer.blender.org/D2510
Typical case: bones having constraints targetting other bones from same
armature. ID swap needs remapping here.
Really have to find something better than regular ID copy + swap + relinking
for override operations, this is horribly inneficient, complicated
and... most likely a nest of bugs and worms.
(pretty sure e.g. we still can generate same pointers during writefile
with current code :( ).
Seems CUDA failed to de-duplicate the array across multiple inlined
versions of the shadow_blocked(). Helped it a bit with that now.
Gives about 100MB memory improvement on a scenes after previous
commit and brings up memory "regression" to only 100MB comparing to
the master branch now.
This commit enables record-all behavior of transparent shadows
rays.
Render times difference goes as following:
GTX 1080 render time
BMW -0.5%
Fishy Cat -0.0%
Pabellon Barcelona -11.6%
Classroom +1.2%
Koro -58.6%
Kernel will now use some extra VRAM memory to store the intersection
array (200MB on my configuration). This we can optimize out with some
further commits.
The idea is to record all possible transparent intersections when
shooting transparent ray on GPU (similar to what we were doing on
CPU already).
This avoids need of doing whole ray-to-scene intersections queries
for each intersection and speeds up a lot cases like transparent
hair in the cost of extra memory.
This commit is a base ground for now and this feature is kept
disabled for until some further tweaks.
Now we break the traversal cycle and then perform volume attenuation
and check with zero throughput. Not sure it makes any measurable sense
at this moment, but in the future it might help de-duplicating some
extra logic here.
Removed unnecessary call to DM_update_tessface_data(). This call is
already performed by DM_ensure_tessface(dm). The call being performed
twice caused a failing BLI_assert().
Reviewed by: Kévin Dietrich
With the new names the arguments (yup, zup) are in the same order as
they appear in the function name. The old names used copy_src_dst(dst,
src), which I found very confusing. Furthermore, now it is clear from
where to where the copy is made.
This makes the function names a little bit longer, though. If that is
a real issue, we can just name them zup_from_yup(zup, yup).
Reviewed by: Kévin Dietrich
I.e. support override of loc/rot/scale of posechannels.
Also implied to add some minimal support of collections in 'diff
generating' RNA code.
Still much to be done of course.
So, now 'proportional' RNA properties (here, Object's scale) is stored
as 'multiply' override op.
Once again, this is mostly testing for now, there are a lot of potential
issues and traps in current code that'll need more background work to
address later if we keep working in this direction.
Main remaining TODO to complete the proof of concept now is sketching
out a bit of UI/UX control over override!
This commit mainly extend/refactor RNA prop copy and equals functions
into more advanced override utils (since equals is a subset of
aurooverride operations generation, and copy is a subset of override
operations application).
And some other work needed on the road...
Still called from pre-depsgraph eval step, does an RNA comparison and
generate overriding rules for changed props...
Note: we most certainly do not want to run this on all depsgraph eval.
Own current idea would be to just tag IDs e.g. in depsgraph callback,
and run actual auto-generation e.g. in a low-priority job, maybe? not
sure... :|
Also, fix stupid mistake in RNA applying of override (used when reading
file to apply static override), and add object's loc/rot/scale as
overridable properties.
Add a 'NOOP' override ruul to prevent any kind of override on a given
RNA path, and an ID flag 'AUTOOVERRIDE' to allow automatic definition of
override rules based on changed data.
Again, just defines, do not do anything yet.
Note that this is dummy empty placeholder for now!
Idea here is that depsgraph is best place to generate our override rules
based on data changes. That way all tools in Blender keep working as
usual, on local data, and overrides are generated when needed just
before IDs get actually evaluated.
Depsgraph has key advantage of only running over *changed* data-blocks
already.
Not sure this is actually valid idea, but for tests will do the work.
If we want to keep it, we'll have to find a way to prevent this running
too often though, especially not during most animation-triggered
evaluations.
Mostly code using override data to selectively update a copy of linked one
with local data.
As said, still totally hackish and experimental, but it works - you can
create overrides of linked Objects, and override their position, yeha! :P
Mostly nasty testing code, only overriding location of object for now.
And of course, we are still missing bits in read/write code to actually
do the override.
Also, add some minimal exposure of override in RNA, here again, most to
be done still.
Could very easily get into infinite loop when comparing Pointer
properties... And in any case, comparing ID pointer should be enough, no
need to dive into all ID properties!
A path valid for a given AE can be invalid with another, we need to
check current path when switching between AEs.
Also do proper check of valid path for Amber engines.
Note that you can link several images in a single run.
Also, images are using current 'link file as datablock' hack, awaiting for propper ID override to get really sane behavior here...
This uuid generation is just temp placeholder anyway, we want something based on actual uuid of Cloud items,
but at least let's avoid generating several time the same ID in current listing!
Rational is, in case of online repo, it may not be practical to decide
whether a path is valid or not from check_dir() callback, which should return
immediately.
So instead, check_dir() can only check whether path **looks** good, and
delegate actual path validation to list_dir (and maybe other similar functions).
That’s what is being tested with Claude engine at least.
Turns out using worker thread to run asyncio loop is not working with pillar, this code is totally
not blender-independent and hence cannot safely work in another thread.
So instead using same technique as in AmberAIO - 'stepping' of asyncio loop, instead of blindly
run_forever() and hoping loop will stop some day...
Note that we may rather call e.g. loop.run_later(1e-5, loop.stop), to actually give a bit more
time to the loop... Time will say what's best option here.
For now it's nothing but an empty shell - but a working proof of concept of how to 'embed'
that ugly asyncio-based stuff into a background working thread for asset engines.
Hopefully more funny stuff to come soon(ish).
This was done to both test asyncio usage in an 'asset engine' context, and wet my feet with this lib.
All in all, am really not convinced by asyncio in this use-case. async and coroutines are much more
complex to grasp and get working correctly (and efficiently!) than mere threading.
Further more, most python lib callbacks (os.listdir, os.ls_stat, etc.) are not async-ready,
so you have to call them through asyncio's executor (aka threads or processes),
which means using asyncio in this context is only adding overhead.
I think asyncio is only really relevant when you have to handle tens (and much more) concurrent I/O tasks,
otherwise threading (or multi-processing if compute-intensive) are much, much simpler to get working,
and also probably lighter in terms of overload?
Further more, asyncio paradigm is not so easy to adapt to the 'AssetEngine' paradigm, i.e. a
python interface that gets called to start, query and finalize jobs that are supposed to keep running
in-between (think event loop should run in a background thread actually...).
Code not really tested (it just builds and does not crash :P ).
Will also have to rethink a bit API and data structs imho... AssetUUID is starting to become a bit annoying.
Basically, due to new 'virtual' libraries & 'path' assets, we consider those 'virtualmy linked' IDs as:
* Local for editing purpose (i.e. they are editable).
* Linked for datablock management purposes (i.e. they can be made local, etc.).
Note: all this is more like a quick hack to test 'file-based' asset repositories (like cloud)
in comming weeks. I really do not think we should use that in the end, an full-featured
'overriding ID' system (as proposed in replacement of proxies for 2.8) would be much saner imho.
Since this file mostly defines/handles interactions with asset engines...
Asset handling itself is more done in library area (will split it too in next commit).
Note that a few sub-data (like animdata) needs to keep option to unlink their
own ID usages themselves for now, this is not ideal, but need some more time
to mumble on this and find an elegant fix. Nothing blocking here anyway.
Idea is to avoid the need for asset engines to generate whole .blend files
with relevant datablocks in case they just need/want to provide files (images, videos, sounds...).
This commit introduces the concept of 'virtual' library, which in fact only exists to store
asset repository data. Datablocks from those virtual libs are then fully written in .blend file.
Much to do still, this is only preliminary/experimental work.
Asset engines are now only selectable and used in link/append case. Makes no real sense to have
those in other cases (like regular file opening, or even worse when saving a file!).
Also allows to get back asset engine persistance accross filebrowser usage.
Dead dummy simplistic test runs (nearly) OK here (only have a memleak from versionning code...),
but obviously will need much serious tests to validate everything.
Also, many things in code will need cleanup/refactor. Not to mention UI/UX.
But we do have asset version check & reload on file opening now! :D
Process summary:
I) Open .blend file exactly as in master, load assets just like any other linked data (add placeholders in case not found).
II) Check all asset engines and ask them whether each asset is OK, needs to be updated/reloaded, is missing...
III) User then can decide to actually reload the asset, or not.
Step II) happens in an async job (since engines using remote storage/database could take some time to answer),
step III) is a locking task (just like initial linking). This should allow user to not be blocked at all by that
asset update process.
With current master this is not an issue, but with all the reload stuff,
a same main could end up going several time into 'do_version', which is absolutely
not desired (multi-allocations, repeating conversions over some values, etc.).
Whole 'database' is rebuilt later anyway, and in more complex 'asset reload' cases
(where we may actually be reloading same asset with same uuid from same lib file),
this creates confusion...
Idea here is to both factorize it seriously (reload and relocate are very similar, let's
avoid as much as possible twice the same code...), and make new `lib_relocate_do()`
much more flexible - now it should be able to reload individual IDs as well
(plan is to use it to reload assets in relelvant branch too).
So far, we were accepting the idea of several repositories per asset engine (e.g. different
directories in case of Amber). However, if this works OK during listing/initial linking,
it makes things way more complicated later in asset management, since asset uuid is no more
enough to unically indentify an asset!
Now an asset UUID is assumed to be really unique inside an asset engine.
For Amber, we 'salt' assets' uuids with new repo uuids (both being only 2 ints long now),
and keep a config 'cache' of mapping repo uuid -> path to repo.
Fetching assets' uuids by engines is now in own func (will be used by update op itself too).
Also, each AssetRef has only *one* asset ID, the first one, avoids us a useless loop!
And early out of update_check op in case we have no asset in current Main, no need to start
job in this case.
So now, jobs callback (async ones) of asset may return a specific job id value in case they actually
complete (or fail) on the first run.
This allows engines that do not need slow async stuff to perform an action to use simpler code
(e.g. imagine an engine able to list its assets from a cached DB, in most cases its list_dir
callback can execute instantaneously (from a user PoV), no need for a listing job then).
Reason is, even if paths returned by `list_dir` are OK, we will also use `load_pre`
during 'reload'/'update' scenarii, where we only have uuids, to retrieve final
.blend datablock paths.
Code only reports which datablocks/assets shall be reloaded etc. so far, actual
reloading needs id-remap code (and hence will be implemented in asset-experiment
branch later).
This commit:
* Fixes bad handling of 'stop iteration' (by adding a status flag, so that we can actually
stop in helper functions too, and jumping to a finalize label instead of raw return, to
allow propper clean up).
* Adds optional recursion into 'ID tree' - callback can also decide to exclude current id_pp
from recursion. Note that this implies 'readonly', modifying IDs while recursing is not
something we want to support!
* Changes callback signature/expected behavior: return behavior is now handled through flags,
and 'parent' ID of id_pp is also passed (since it may not always be root id anymore).
Used this new recursive behavior in ID preview generation as an example, would obviously be committed separately.
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D1869
This commit:
* Fixes bad handling of 'stop iteration' (by adding a status flag, so that we can actually
stop in helper functions too, and jumping to a finalize label instead of raw return, to
allow propper clean up).
* Adds optional recursion into 'ID tree' - callback can also decide to exclude current id_pp
from recursion. Note that this implies 'readonly', modifying IDs while recursing is not
something we want to support!
* Changes callback signature/expected behavior: return behavior is now handled through flags,
and 'parent' ID of id_pp is also passed (since it may not always be root id anymore).
Used this new recursive behavior in ID preview generation as an example, still needs more testing!
We need that info (knowing which non-asset IDs are used by which asset-IDs),
otherwise managing reloading, updates etc. of assets would be impossible
(or rather, would leave a mess of unused IDs behind them).
Only partially done, non-functional yet.
This commit also adds asset repository references in libraries.
Note that this is only very first steps, I think we'll need to 'propagate'
uuid to all data used/linked by asset itself, otherwise most things won't get
updated/reloaded. Still have to think about this.
Note that this is only very first steps, I think we'll need to 'propagate'
uuid to all data used/linked by asset itself, otherwise most things won't get
updated/reloaded. Still have to think about this.
Issue here is again with NEVER_NULL usages: obdata (& co) would be dereferenced twice.
I'm not totally happy with this solution, ideally remap should never leave Main
in invalid state, but for now it will do...
* We need to clear the 'user-one' flags and potential usercount for old_id.
* We need to consider ID usages inside a same lib as **never** being indirect ones.
Also re-enabled proxy checking for now (not sure why I commented it, think testing stuff or so...).
Seems to work for simple cases, but deletion of complex libs from complex files
(Gooseberry ones) still generates lots of assert failures, and crashes in some cases.
This is hacky to make work on Linux, and seems to totally break on Windows.
So now, instead, we define a CollectionListBase (exact copy of ListBase), to be used inside RNA...
Seems to work nicely on Linux, lets see what win buildbot says.
issues with unlinking ParticleSettings.
We now have the option to still decrement user count of old_id, even if we could not
replace it with NULL new_id (aka unlinking), needed to keep proper user count when
unlinking and ID from datablocks it uses, to delete it.
Conflicts:
source/blender/blenkernel/BKE_library.h
source/blender/blenkernel/intern/library.c
Also clears now useless 'bool is_user_one' flag from editors' ID remap callback.
Idea is to add two new flags, one saying 'we need to ensure a real user exists',
the other 'we had to increment user count to ensure we have a real user'.
This allows us to easily control the extra user in release/delete/remap cases,
and also fixes the infamous 'add new image to texture, open image in ImageEditor,
delete image from texture, have a zero-user red image in Image Editor' issue.
There is still much to be done here, more places where we can use those flags,
also clear them when we force usercount to zero, etc.
All this allows us to fix unsolvable issues (like Group being ensure_user'ed
in loading code, but only if they do have objects in them), and to avoid returning
ugly bool from editors' callbacks (this is still to be cleaned up in the branch too).
Bad news - this means we cannot use short ID->flag anymore (not enough flags), for now
added a new int ID->flag2 (replacing pad int), not sure how to best manage change here,
maybe for 2.8 we can totally wipe ID->flag? But this would totally break forward compat.
So, idea is, since mat/tex/scene/etc. nodetrees are owned by their respective IDs
(those nodetree do not exist in Main, they are systematically freed with their ower IDs, etc.),
we should not treat them as IDs in IDlooper, but rather as mere sub-data, and hence directly
loop over the IDs of those nodetrees.
From quick check it seems to work, but this needs to be confirmed as a valid idea!
Heavily simplfies that freeing area, but again a rather risky and likely-to-break change.
At least, NodeTree is known to be a trouble-maker here, due to how it seems to be
'owned' by its mat/tex/sce/etc. Have to dig deeper here, this is still quite unclear
what exactly happens with those, and how to handle them correctly.
(instead of whole Main content).
Could replace maybe things like constraint, rigisbody world, etc. '_relink' func,
but for now it's only intended to replace custom 'id releasing' code in _free()
funcs of all IDs!
Previous situation was pretty much horrible, a few data types having their own coocking to
unlink, often doing more than only unlinking, often doing the same thing two times or more,
often messing with areas they should not have touched (like editors from withing BKE)...
Now we hope to have something generic, working the same way for all ID types
(we do have to add some specific handling for groups/objects/scene unfortunately,
but this remains reasonable).
Needless to say such a change is calling for troubles - I tried to follow and reproduce
as best as I could previous code, but most likely some areas will become buggy. Do not think
previous code was 100% correct anyway, things like Objects have a really big and complicated
usage of IDs...
Also, foreach_id tool has been enhanced, again for complex types like objects & co, we should
cover much better all possible IDs now (e.g. rigidbody & logic bricks were
totally missing from there).
And there is more to come...
Think core of the system is getting pretty much OK, now we'll likely have to deal
with tons of specific cases, given how Blender is totally inconsistent when it comes to
handling user counts (e.g. spaceimage...).
Also, still have to make generic ID_unlink and ID_release_datablocks func to replace
redundant code in BKE we have currently.
Still missing: at least modifiers (have to change all modifiers callbacks, yuck).
AFAIK constraints never refcount thier IDs so we can keep current code here.
Similar changed to those done for mesh/curve/mball.
Also, systematically nullify pointers in `_free()` functions, this does not cost
much and can help troubleshooting later.
And tag `BKE_object_unlink()` as an horrible piece of code...
Renamed their `_unlink()` functions to `_release_datablocks()`, since they do not
unlink anything (not in the sense `BKE_object_unklink()` does, at least)!
Also, added a `const bool do_id_user` to their `_free()`, for consistency, now
relevant `_release_datablocks()` func only gets called when this option is set.
They would be removed from bmain, but never added again nor freed - in this case
we can simply explicitely reload them in fact, non-linkable is only a user-related status...
We need to append to linklist, or our library indices would be reversed compared to lib list...
As for locking, we need reentrant one here if we want to use it. :(
Performances are not an issue at all here, but it makes code slightly simpler, avoids
a loop over ghash of libs, avoids some potential mem fragmentation, and will be easier
with lib relocate code too in future...
Reason is, on next fileread, proxy will be assigned with its target's data again...
Note that this may not be true about all its datablocks pointers - but proxy objects
are really brittle in current code anyway, they could use a serious work as well.
Basics seem to be working, proving idea is valid. There is much to do yet though,
handling correctly all possible scenarii (especially those including indirect libs
used by several libraries, or libs used both directly and indirectly, etc.)
is not going to be a piece of cake...
Making the code in WM area more generic (will be used by relocate libs feature too in future).
And multi-append/link shall no more close & re-open lib files for each and every idcode!
Also, serious cleanup of BLO_append_... API (renamed BLO_link_..., since it links and never appends!),
main real changes there are removing the bContext arg in favor of scene/v3d (a bit more verbose, but does
not requires a valid context anymore to be able to instanciate ob/groups!). And logic behind instanciating
or not has been simplified, previous code was really obscure and sometimes redondant, from quick tests
it still works as expected.
This is temp branch for until 2.76 is over, shall be merged in master asap then.
Note that this op will have to be moved to WM area in fact, it's way too generic for Outliner only...
and we need to re-use most of append/link operator code!
We have to take care of Object->data aside from main foreach loop, since we can
only replace that pointer if object is **not** in Edit mode!
Also, added a "Remap" action to ID context menu of outliner. This is **very far**
from nice and pretty code/feature, but it allows to quickly test the code.
Only did very quick tests with meshes so far...
This seems to be OK, but will obviously need much more testing - and is useless as-is, we need
the big ID remapping code itself still.
Also, Nodetrees' remapping of Scene IDs is still TODO, not sure yet how to do this.
Needed, since trying to (re)init data already set could lead to many issues,
and handling this is not in the scope of this function.
Note that definition of BLI_memcmp_null stuff is rather bad currently, no good idea where to place this. :|
Just having 'NULL' data as placeholder is not really possible, too much places
to check against that.
WIP commit, still much to be done!
See T43351 for details.
Differential Revision: https://developer.blender.org/D1394
Idea is, instead of ignoring completely missing linked datablocks, to
create void placeholders for them.
That way, you can work on your file, save it, and find again your missing data once
lib becomes available again.
Plans are also to be able to locate missing libs and reload them at runtime.
To support all that, we must be able to make Blender survive those missing data
(i.e. empty datablocks) all over the place. This commit contains some early work
in that direction, but this will need much much more work!
Indeed, though rather unlucky, we may end up handling same source file from
different preview threads, which could lead to conflicts and bugs.
So idea is to add a simple way of locking a given source file path, since
thumb handling of different paths shall never conflict.
Note that this adds some 'generic' stuff to GHash and Threads area, that are to
be committed separately of course.
The task was not so annoying (workers are just sleeping anyway), but having the timer
always checking for updates was not so nice. This remains quite minor optimization probably...
So now, we do not start anymore preview task when enabling previews. This is deferred
to the moment we really need it (i.e. when we cache block of entries currently visible).
Preview timer is started at the same time.
Further more, when preview task has been inactive for about one second (i.e. all
queued previews have been handled, and no new one have been queued), we free it
(switching to some kind of 'standby' mode).
This also allows to avoid stoping/restarting preview tasks on each redraw when user is scrolling.
Classical bool vs char value mismatch... Here it was leading to a constant re-filtering
of the list, which invalidates cached previews.
Strange thing is, it would look as if Windows CMake builds are using 'real' bool,
while scons ones are using fake char-based one?
Instead of computing MD5sum of paths, just use incremental UUIDs!
There meaning and lifetime for internal listing is very limited anyway,
they shall only be unique for a given listing.
Note about using atomic op here: did it because it's nice use case,
not sure it's worth adding atomic stuff to /editors area though?
This commit replaces `filelist_numfiles()` by `filelist_files_ensure()`. The later
also returns number of visible files (i.e. filtered ones), but also ensures filelist
is filetered and sorted.
Otherwise, during listing process, operators could be executed between an update of the listing job,
and the refresh from the file space - i.e. at a time filelist is virtually empty (from filebrowser PoV).
Also, got rid of 'need_refresh', this ended up being unused...
* Do not systematically clear selection_state's uuids GHash when updating filelist
during listing process - uuids used here should remain valid.
Allows to not lose selections during listing background job!
* Use new BLI_ghash_lookup_p to handle selection state setting, symbolic optimization but...
A file which does not have *any* preview is perfectly valid, error is only when there
are some previews, but not the same number as actual datablocks...
Conflicts:
source/blender/editors/space_file/file_draw.c
source/blender/editors/space_file/file_ops.c
source/blender/editors/space_file/space_file.c
NOTE: Tagged some parts in new code to be fixed, rather do that in a separate commit.
This means this commit is broken and won't compile.
Also adds some 'state' flags to AssetEngine, so that custom AE's setting changes
can be notified to filebrowser, as default internal ones are.
For now, we only have 'dirty filtering' and 'dirty sorting'.
With big screens and tiny drawing, we can show much more than 1k items at once...
Also allows to reduce number of cached items in case we show few things big!
Mismatch in 'owner' of job, not giving right one to stoping helper, sigh.
Note that this was also affecting any 'interrupting' task (like changing level of flat listing...).
We cannot keep 'stable' list of items during listing process (each time new
entries are added, we have to filter and sort the whole lot again, which
means rebuilding 'draw' data from scratch - previews included).
Just wait until our filelist is complete to generate/use previews.
* Let asset engine draw most of header bar itself!
* Pass whole FileSelectParams to AE's sort_filter function.
* Move 'use_library_browsing' to params level (this way AE's sort_filter can be ware of it too).
Amber:
* Now supports real basic sorting/filtering modes
* Also basic support of tags (needs a way to refresh though, currently).
this is mandatory, since we do not keep previews for all listed items anymore
(with 10k datablocks would start to take too much mem). So we now generate (read)
them from thumbnailing threaded task as any other image, has several advantages:
* Quicker initial listing of data from .blend files.
* Since thumbnails are cached on disk, re-generating them is rather quick.
* General consistency!
Note thumbnail generation of datablocks could (should!) be enhanced, right now
it reads all previews for a given datatype in a file each time it has to generate
a single datablock thumbnail, we should generate all of those previews in a single
run. But this means handling cache dirty things (TBH_FAIL, outdating, etc.) on another
level so need some more work.
Also, still some memleaks issues with thumbnails, have to track those dose!
Since with internal listing we have no choice but to list everything, store
those data in the smallest possible struct - note we do not even store preview
here, these are only handled in full FileDirEntry cache (re-loading them from
cached thumbnails is really quick anyway).
Still not complete, have to re-do ID previews now, among other things...
And some memleaks again with previews, ugh.
Those were eating quite a bit of bites, not neglectable with thousands of entries...
Also, useless to print those info most of the time, they are not used!
So now, we only store 'raw' stat data, and expose funcs to convert them to readable
strings on demand.
Since we do not store anymore ell entries, we cannot use them to hold selection status.
So we now use a ghash in FileList struct, with entry UUID's as keys.
Also cleanuped up / refactored selection handling, filelist.c now features a nice intern
api and all other code uses it instead of accessing directly entries' selflag!
Conflicts:
source/blender/editors/space_file/filelist.c
source/blender/editors/space_file/filelist.h
source/blender/makesrna/intern/rna_internal.h
Notes:
* asset-experiments branch still needs some work (e.g. entires selection is to be reworked too),
but was more than time to do a first merge...
* This is raw merge, code is hence broken and needs more fixes to take into account new changes!
Get rid of cache iterator code (not needed, and don't think we'll need it later,
easy to add back if needed). Also comment some debug prints.
New preview (thumbnails) handling seems to be working pretty nice now.
* Full path is no more static, so we need dynamic tooltips to use it (still an
issue with drag stuff here :| ).
* Remove timer would attempt to free timer's customdata, which is mere int-in-pointer
in case of new notifier timer, so we need a special tweak on remove here.
Start to looks good... This commit adds a new timer helper, that only send notifiers
(kind of very restricted subset of wm_job stuff), since using jobs for previews
would be now counter-productive and way too much heavy.
Also fix/enhance how previews are generated (order), etc. etc.
Still WIP though, having some weird crashes and such lurking around.
Note this is rather stupid anyway, we need to rewrite this from scratch,
using a job for that makes no sense now, we should stick to a lighter
threading schema with a queue, or something like that!
Core part seems to be working, but this is still heavy WIP, much to do
to resume complete features from existing code. Mainly:
* Previews (those should only be ran on cached items now).
* Use block-caching to load in-display entries.
* Rework things like selection (cannot store selected states in entires anymore).
Also, internal listing is stupid currently (since it still stores everything
as FileDirEntry & co), not really crucial currently, but ultimately it'll
use its own, compact struct to keep full listing!
Also did some minor cleanup/renaming.
That code is currently pretty stupid, but we need to clearly separate
what is handled by filebrowser itself, and what is by listing code
(be it internal one or future asset engines).
Plan/idea is to have a dual cache system (one 'block' of entries - centered
on currently viewed ones -, and one 'random' FIFO for random access to any entry).
This implies filebrowser itself shall now only be aware of the number of (filtered)
entries, and it then requests entries as needed.
Also, made size of columns in filebrowser fixed (ultimately, user configurable),
since it has no more access to the whole list of entries!
Still heavy WIP.
We cannot do that correctly with current listdir system, have to rework again
in asset-experiments brnach first, so that listing, filtering and sorting is
completely "delocalized" to asset engine (will also try to solve scalability issues).
Also, make clear tags are only informative here.
Reason is, if the project is a success, we have to think big and
imagine asset engines managing catalogs of tens or hundreds of thousands
of entries (web ones e.g.), we cannot hold list of those in filebrowser!
So most of filetring will be 'deffered' to asset-engine.
We'll also probably have to implement a 'chunck listing' behavior
(to only list at most n entries in a row), for same reasons.
This will make things slightly more complicated :|
Think issue also exists in master code actually, where some op properties
could be left uninitialized in 'params_to_op' helper func... But it does not
backfire like that for sure.
This will allow asset engines to:
* Actually ensure requested data is available (downloading it, generating it, etc. as needed).
* Change entries generated for user by actual data paths (allows e.g. to present
a set of different paths to load as a single 'asset' to user).
As usual, had to change existing filebrowser code... Seems to be working fine
from quick tests (i.e. regular filebrowser not being broken).
Basically, filelisting code in space_file becomes default, internal 'asset engine',
and user can switch to any other available engine instead.
Note filelisting with asset engines is fully main-thread from C code PoV,
parallelization/asynchronism is responsability of the py code!
Also, added a basic (dummy currently) AssetEngine py implementation.
Not much there, but helps checking things works as expected before
writing whole interface!
All this is very basic early code yet, much much to do before we get anything really usable...
Remove everything not really related to OS representation of file entries.
FileBrowser will now use a complete decoupled version of file representation,
much easier to keep sane behavior this way, easy integration with RNA, etc.
This allows us to greatly simplifies sorting (and avoid recomputing UI name each and everytime!).
Also, correctly free entries/variants names/descriptions.
Was not sure about that (adds two pointers to entries, variants **and** revisions :/ ),
but with the incremental process of listing we are using now, it makes things sooooo
much easy to handle (and also avoids tons of (deep)copy and mem (re)alloc), that it's
definitively worth it.
And since most (if not all) of 'public' access to filelist is done through filtered ones,
we can easily keep this a mere array of pointers, and hence keep quick index lookup.
Also, quite noticiably simplified the whole listing code (less functions, less levels of subcalls...).
Note: for now we stick to mere alloc, we may benefit from either memarena or mempool,
but those are not threadsafe (which means we could not so easily pass mem from worker
thread to main one), so not quite sure it would be worth it.
Note: thumbnail stuff is to be reworked from scratch too, have the feeling it's not yet
100% thread safe, and using a job here is probably way overkill, since we do not show
any progress in UI.
Also, reduce revision's uuid to 64bytes, should be more than enough!
Thing is, we can expect tens (if not hundreds) of thousands of revisions from a
big assets repository with history storage (vcs). So we want that struct
to be as small as possible.
Also, we do not expect to handle several variants/revisions of a same asset within
a same 'context' (there is always only one active variant & rev). So storing
path & co at entry level shall be enough. And helps make code simpler/nicer.
We may suffer a little performance loss here, but would not expect it to be really important,
since rebuilding a full abspath is not needed that often.
Also, get rid of modes/owner crap, this is quite advanced UNIX fs info, not much to
do in our filebrowser imho, and takes time, UI space and Mem space!
Move typeflag and selflag back to FileDirEntry, and add blentype there too,
this will be needed by asset engines, and avoids rechecking lib ID types over and over!
There's much more to do here though. Also, FileDirEntryRevision is going to be
used quite higly, we want to keep it as light as possible (much lighter than
its current state for sure!). Think we can move back to FileDirEntry paths
(and try to get rid of abspath on the run, too), but also most likely
preview (we won't store a preview for all possible revisions anyway),
owner/permissions, etc.
Rev should probably only have its uuid, and date/time.
Also, simplified filetype generation (from extensions for real files, and BLO helpers
for libdata), now it's nicely encapsulated into each reading callback.
Main idea is that direntry had quite a bit of things already absolutely useless
in the mere 'file listing' context (image pointer, void 'data' pointer, etc.).
On the other end, to handle future asset stuff, we need *more* 'meta data' for our 'files'
(tags, variants, revisions...).
Further more, we need all this to be easily usable through RNA, i.e. we need it to
be defined in DNA.
So instead of trying to use direntry in DNA, mixing low-level system stuff like stat
where we do not want to see it, we define our own 'file' representation,
with only what we really need (who cares about chars or block or dev files in filebrowser?
we only need to know whether it's a regular file or a directory, period).
That way, low-level dirlisting remains clean, and we can easily extend our own
data as needed.
Note this new code works, does not crash (so far...) nor memleak, but it
needs quite a bit of work still, we are still storing useless stuff in direntry
(all those strings representing modes, size etc.!), and mem handling
during dir/lib listing is confusing at best (would like to use a memarena
or mempool here, but it's not that easy).
Passing around ID's themselves is not safe - they may change their mem addresses.
Yet, I had no issue on linux, but on win build this is still not enough,
have to use a super strange hack (add an 'import sys' line just before where error happens)
to get things running...
Batch preview generation can now also generate 'internal' previews (materials, textures etc.),
as well as scene ones. Also, some basic Cycles handling is there now.
You can now chose which kind of data to generate previews for, and whether the files are
trusted or not (for py autorun and drivers).
And rendering happens in background again, issue was actually a bug in creator.c, fixed in master.
Main TODOs reamining here: OpenGL rendering, and find a way to prevent '.blend1' when
saving over (either as a new option of save op, or simply by removing those files in script?).
Added a batch cleanup of previews too.
Also, added path of files as their tooltip 'image' button in main filebrowser view,
quite useful with the 'recursive' option...
Now, recursion 0 = previous behavior,
recursion 1 = only show content of immediate .blend files, do not recurse in actual dir hierarchy,
recursion >1 = complete recursion!
This will allow us to keep op panel independent, and have tabs for future assets tools!
Note 'conversion' from previous file area (channels) is not perfect, you have to hit 'T'
twice currently if you had a filebrowser in your .blend file...
Consider blendfiles and 'categories' inside them as regular dirs, but with this hierachy:
real dir > blende file lib > category in a blend lib.
This gives a much better sorting (among other things, gives more importance to
blend files!).
Got completely rid of C code for those panels.
Added full path in ttips of each 'bookmark' entry, as in current master.
Note this forced me to make tip in uiBut dynamic (like label). Not so sure
about this, but seems to me forcing tooltips to be static is actually quite
bad and limitating? we'll see...
Only remaining TODO (new feature) is reordering of bookmarks, should be easy now.
Also fixed some stupid (again!) mistake with RNA access to paths of bookmark entries.
* When overlaying icon, we have to also ensure background pict is always the same size
(else you get usgly icon size changes). Still not perfect though, suspect some more issues
in filrdraw code, probably should systematiacally run the 'ensure size' code during thumbnail
generation?
* Sharing of img ImBuf between thumbnail job and main thread could still happen,
leading to random crashes.
Note: unlike in current master, path is checked immediately when setting it
into filelist (simpler now that filelist building itself is threaded).
`filelist_setdir()` modifies in place given path if this one is not valid.
`BLI_fnmatch_strncpy_add_endswildcards()` will copy and add '*' wildcards on both ends of given string, if needed.
`BLI_fnmatch_strcmp_ignore_endswildcards()` is same as strcmp, but ignores any '*' wildcards on both ends of given strings.
New code shall be more easy to maintain and extend.
Sorting is now handled quite the same as filtering, and all filtering parameters
are now packed into a sub-struct to help extending it later.
Also done some optimizations in filelist refresh, and sorting/filtering area.
Now we should avoid re-sorting and re-filtering too often, also removed
calls to those in read_xxx funcs.
Note thumbnail job is still started basically on each call to `file_refresh()`,
will be addressed in next commit.
Doing it mostly because I need some update work done here so far to get py uilists/bookmarks working.
This exposes/moves part of bookmark code to ED_ area, so that it becomes available from e.g. RNA.
And adds RNA struct and such to represent a bookmark entry.
Also, Bookmark format is ammended to store optional custom names.
All this is still *very* crappy, should probably take some time soon to cleanup the whole branch!
See also T42777.
* Do not render cameras, lamps etc. for now.
* Generate bbox in camera local space, gives much better results.
* Add an op to clear previews from files.
Now for any object, we have an rna func to call with a set of (flatten :/)
coordinates, and we get back location this object should be to 'see'
all given points.
Would need more refinements, but will do for now.
First expose a method in Object RNA to get camera projection matrix (done).
Then, expose a method to get camera position (and scale for ortho) so that
it fits a given set of coordinates (still unfinished).
this among other things implied rewriting `BKE_camera_view_frame_fit_to_scene()`
underlying logic so that it uses `CameraParams` system, instead of `BKE_camera_view_frame()` one.
Note since this gives python possibility to change those previews,
we add flags to PreviewImage to tag as user_defined.
TODO: replace all those shorts-used-as-bools by bitflags!
Previuosly, we would only write existing data - and big previews were
nearly never generated by default.
Now, if saving previews is enabled, `wm_file_write()` will ensure
all 'common' previewable datablocks do have up-to-date previews
(brushes remain TODO here for now, they have both a preview **and**
an icon_imbuf, sigh...).
This implied adding an 'immediate' non-job-background version of
`ED_preview_icon_job()`.
Note this does not include objects/groups/etc. It's not simple to generate
previews for those, will probably go for a user-launched py operator here...
Also, cleanup some debug prints!
Previous implementation was uglyly relying on button using a specific
icon (VIEWZOOM) to enable this feature. Now we have a dedicated button flag
(UI_BUT_TEXTEDIT_UPDATE) and a dedicated RNA subtype (PROP_SEARCH) for that.
Also, if no icon is specified, it automatically set VIEWZOOM for it,
which saves us explicitely defining it in UI py code!
NOTE: this is to be committed asap in master, but has to wait for
after 2.73, so storing it here for now.
Also, try to make brushes also save their previews.
Anyway, something fishy is going on here, in theory we should get
previews for brushes, worlds, lamps... for free, but so far looks like
lib 'peek' code only handles mat/texture previews correctly?
Doing nothing useful yet, though!
Note: ultimately we may want to move that preview stuff to ID struct,
so that we get a real basic generic handling of it, but for now
simpler to keep it as is.
Also, definitively removed 'G.main.name protection' from lib reading
code. I do absolutely not see how listing a separate blend file handle
could possibly affect that anyway - and we do not want to access
G from non-main thread I'd bet...
Now it works reasonably OK for filesystem, and also for .blend libs.
Code is even quite simpler than previous one. Now it needs some serious cleanup,
and find where (new) memleak comes from too.
Only very partially working in this state, still needs some work.
Proof of concept seems rather interesting though.
Also, only pure filesystem stuff is implemented for now.
Also:
* Changed BLO_library_path_explode, now r_group and r_name must be pointers of char pointer,
if found they will point to right place in r_dir 'memspace'.
* Select everything in IDTypes filtering by default.
Nothing really magic here, just grouping the imports by libfile/grouptype.
We could probably get better code (loop less on given list of 'files' to import)
but not sure it'd be worth it, this is not supposed to be a performance-critical point.
* Delete filelist when changing flat setting (so that we get immediate update when changing that setting).
* Disable flat when going up in tree (we ;ight actually want to do this everytime).
Not much to add, we'll likely add more filtering options (tags, categories...) later,
maybe for now we just need an 'exclude' option for name filter...
Main goal is to see whether we can use existing filelist to handle that
(by default it is 100% tree-oriented).
Also, getting some strange issues with ID name currently...
2014-12-03 15:29:18 +01:00
7840 changed files with 461881 additions and 738718 deletions
option(WITH_CLANG_TIDY"Use Clang Tidy to analyze the source code (only enable for development on Linux using Clang, or Windows using the Visual Studio IDE)"OFF)
mark_as_advanced(WITH_CLANG_TIDY)
endif()
option(WITH_BOOST"Enable features depending on boost"ON)
option(WITH_TBB"Enable features depending on TBB (OpenVDB, OpenImageDenoise, sculpt multithreading)"ON)
@@ -470,14 +423,6 @@ if(WIN32)
option(WITH_TBB_MALLOC_PROXY"Enable the TBB malloc replacement"ON)
endif()
# This should be turned off when Blender enter beta/rc/release
if("${BLENDER_VERSION_CYCLE}"STREQUAL"release"OR
"${BLENDER_VERSION_CYCLE}"STREQUAL"rc")
set(WITH_EXPERIMENTAL_FEATURESOFF)
else()
set(WITH_EXPERIMENTAL_FEATURESON)
endif()
# Unit testsing
option(WITH_GTESTS"Enable GTest unit testing"OFF)
option(WITH_OPENGL_RENDER_TESTS"Enable OpenGL render related unit testing (Experimental)"OFF)
@@ -528,10 +473,10 @@ if(CMAKE_COMPILER_IS_GNUCC)
mark_as_advanced(WITH_LINKER_LLD)
endif()
option(WITH_COMPILER_ASAN"Build and link against address sanitizer (only for Debug & RelWithDebInfo targets)."OFF)
ADD_CHECK_CXX_COMPILER_FLAG(CXX_WARNINGSCXX_WARN_NO_OVERLOADED_VIRTUAL-Wno-overloaded-virtual)# we get a lot of these, if its a problem a dev needs to look into it.
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
