Commit Graph

5 Commits

Author SHA1 Message Date
897e97f078 ID-Remap - Step one: core work (cleanup and rework of generic ID datablock handling).
This commit changes a lot of how IDs are handled internally, especially the unlinking/freeing
processes. So far, this was very fuzy, to summarize cleanly deleting or replacing a datablock
was pretty much impossible, except for a few special cases.

Also, unlinking was handled by each datatype, in a rather messy and prone-to-errors way (quite
a few ID usages were missed or wrongly handled that way).

One of the main goal of id-remap branch was to cleanup this, and fatorize ID links handling
by using library_query utils to allow generic handling of those, which is now the case
(now, generic ID links handling is only "knwon" from readfile.c and library_query.c).

This commit also adds backends to allow live replacement and deletion of datablocks in Blender
(so-called 'remapping' process, where we replace all usages of a given ID pointer by a new one,
or NULL one in case of unlinking).

This will allow nice new features, like ability to easily reload or relocate libraries, real immediate
deletion of datablocks in blender, replacement of one datablock by another, etc.
Some of those are for next commits.

A word of warning: this commit is highly risky, because it affects potentially a lot in Blender core.
Though it was tested rather deeply, being totally impossible to check all possible ID usage cases,
it's likely there are some remaining issues and bugs in new code... Please report them! ;)

Review task: D2027 (https://developer.blender.org/D2027).
Reviewed by campbellbarton, thanks a bunch.
2016-06-22 17:53:50 +02:00
77e6a001a9 Fix T44376: Buttons context, invalid data access
Removing a scene from the buttons window would crash from a Python operator.
2015-05-04 16:01:20 +10:00
0cd49fde56 Make blenderplayer compilable again after recent commit b7f085d9c1 by Tamito.
Inserted a stub in stub.c and added the struct keyword to make gcc happy
2014-05-03 12:51:51 +02:00
b7f085d9c1 Patch D246: Texture Marks for freestyle strokes, written and contributed by Paolo Acampora.
Reviewers: brecht, kjym3, #freestyle

Reviewed By: brecht, kjym3

Differential Revision: https://developer.blender.org/D246
2014-05-03 18:54:59 +09:00
9d567dd366 This commit addresses the somewhat weak handling of stackless textures in Blender with default (BI) renderer. To do so, it's defining an "other" texture context, and when in this one, it switches to using the "new shading" texture handling already known with Cycles engine.
So now, in the new "other" tex context, you can (depending on active data) have direct access to modifiers', force's or brushes' textures...

I also refactored a bit how texture contexts are handled (once again, we had some quite similar code in both space_buttons and RNA sources). This should also solve some harmless glitches like "no texture context selected in UI" sometimes when you remove data related to current texture (see e.g. after removing the material from default cube, in startup scene).

This usage of two different systems for textures, and the handling of switches between them, has been a bit tricky to get working right, but it is OK now I think. I also had to add a bool flag to buttons space, SB_TEX_USER_LIMITED (use_limited_texture_context in RNA), which indicates "new shading" texture code whether it has to ignore materials, lamps etc. (BI) or not (Cycles).

Btw, pinned textures from modifiers/force/etc. were also broken (showing nothing), now it should work too.

Thanks to Brecht for reviewing.
2013-05-17 07:10:10 +00:00