@Campbell Barton (campbellbarton), there is a semantic difference. In those cases "dirty" means data is out of date and needs to be refreshed (or saved) in some way. With this API we are merely informing the script that some data has changed, if the script then needs to refresh something in response to that is another matter. In depsgraph_update_post and RenderEngine.view_update the data has already been refreshed on the Blender side, so is also not dirty anymore.

Asserts here
BLI_assert(pchan_index < MEM_allocN_len(pose->chan_array) / sizeof(bPoseChannel *));

Yes, the error message for not finding a string in an enum is truncated to 200 characters:

Just chiming in here as the OP: renaming is_dirty_xxx to recalculate_xxx without negating the value would seem to just as confusing to me (e.g. moving a camera would trigger with recalculate_geom set to True). But maybe I'm misunderstanding what exactly the flags are supposed to signal to downstream users of depsgraph updates (e.g. a render engine script). I originally expected the flags to indicate for which objects the local (downstream) copy of the scene needs to be updated to match the current depsgraph. But it seems that that is a secondary usage, as the flags actually specify which parts of the depsgraph itself need updating. Which is surprising, because what if the downstream script does not handle the updated depsgraph part and therefore doesn't take any action on them to update?

@Brecht Van Lommel (brecht) as far as I can see dirty applies here: internally ID_RECALC_TRANSFORM / ID_RECALC_GEOMETRY means this data needs to be recalculated, and that the current state isn't ensured to be up to date.

@Campbell Barton (campbellbarton), please revert rB45fdf41be8 and rB6d38d824377.

well, no shading at all, but that's to be expected since you don't seem to have implemented any drawing in view_draw yet.

This is the conventional terminology in computing. Read "is dirty" as meaning "needs cleanup" or in this case, "needs updated".

Confirmed on 168a6a4bfc1 on windows. Running the script AND setting the renderer from the command line does not update which engine is used in the renderer shading mode in the 3d viewport, despite the mode being set:

>>> bpy.context.scene.render.engine
'custom_renderer'

It seems contradictory when something called is_xxx_dirty being True actually means "not updated".

Hmm, more weird behaviour:

The problem is the message does not correctly show all the valid enum values. For example, 'CONSOLE' is truncated.

Thanks for the fix. The operation bvhtree .fromObject now works when executed once. But it crashes on second run of operation each time:
Steps to reproduce:
run in console:

from mathutils.bvhtree import BVHTree
BVHTree.FromObject(C.active_object, C.depsgraph) 
BVHTree.FromObject(C.active_object, C.depsgraph)  #it will crash here (no error)

Seems like VIEW3D_HT_header calls
VIEW3D_MT_editor_menus.draw_collapsible(context, layout)

Please do not merge reports just because they use the same general 'end tool'… applying armature modifier has little to see with applying one using curves.

For the record, the API changed, see e7c3f7ba6f1385a2138862de8568e571fa97b5b4.

For the records, this also causes T58917 to happen. I will see there if I can change the stored data to pointer (don't recall why I used strings in the first place).

This appears to be fixed.

object.hide_render does not tell you if the object is hidden, it only returns the value of the property as set by the user. This is the same as in 2.7x.

Curve shapekey data is more complicated than coordinates, and even more so in 2.8 after rB12788906. I suspect python API wrappers don't take that into account.

Maybe the description of ID.name should be changed.
So we have three types of names in the api now?

• object name
• object name + library part
• prefix + object name + library part

And I do not think prop_search storing extended name is fine, it's just way too complicated to change this to store actual full ID name, so not worth the effort imho.

Making name collision impossible with a single string is close to impossible (guess since ID names have fixed max length, we could force lib part beyond the 67th char to get that result, but would not be very user-friendly display then).

Ok, I think that .prop_search uses the extended names is fine. (If it is documented somewhere what all the letters mean exactly. I have not found any docs for that yet.)

But if you are interested in diving into the search_prop & friends maze to avoid that behavior, be my guest. For now I think we have something that works well and easily in all decent cases. If user wants to start naming their object L Cube [untitled.blend], that’s their issue. Just use Pointer prop to store IDs then.

If you are crazy enough to name your objects that way, there is no miracle indeed. That’s why I said that ID should be stored in Pointer prop, not string one, unless absolutely not possible to do otherwise.

Well, this little trick does not make id names really unique, right? When I have two local objects named Cube and L Cube [untitled.blend] and one linked object called Cube (linked from a file called untitled.blend), then I can't access the linked object object from bpy.data.objects[...].

Eeeeeh… well, thing is, for UI display, we use those three-chars prefixed names (having some info like linked, orphaned, etc.). It will also append the library name in case of linked datablock. This ensures fully unique ID name (identifier, inside of a given ID type) across whole .blend file.

I looked into the code and it seems like these three letters are used to differentiate e.g. linked objects.

It sounds like a bug to me, can't think of a reason why it should be like that.

I can confirm that. Is it supposed to be like that, @Brecht Van Lommel (brecht) @Bastien Montagne (mont29) ?

Oops sorry, I had searched for any "make_single_user" bugs, which did not output anything. Will search for more keywords next time.

@Campbell Barton (campbellbarton) Fair enough. I can see how changing it to work with sys.path could be more effort than it’s worth. It’s good to know what the issue is, this was bugging me for weeks! If I find a solution I’ll pass it along.

@Benjamin Humpherys (brhumphe) if you get this working, it'd be good to apply changes to CMake.

Why is it looking there instead of searching the sys.path of the python interpreter?

@Benjamin Humpherys (brhumphe) On windows it's looking for: C:\ProgramData\Blender Foundation\Blender\2.79\scripts\modules

This is not OSX-specific, I have the same issue on Windows too, most recently with build 84285c1e3440. Here is the system trace from Procmon on windows:

This may be OSX spesific then.

@Campbell Barton (campbellbarton) Using make install does not fix the issue. I just did a fresh build and the results were the same:

git pull
make update
make
cd ../build_darwin
make install

I created a virtual environment using these instructions from @sybren, sim linking both blender/release and boy.so inside of the site-packages directory of the virtual environment:

@Benjamin Humpherys (brhumphe) you need to 'make install'. manually copying bpy.so will give this error.

@Campbell Barton (campbellbarton) think you are still maintaining that experimental feature? ;)

If I get some time before the patch is reviewed I'll test addons, though I suspect the patch has fixed raycasting for them as well.

scene.ray_cast crash in addons running into 3d view too, (since ~1 week - at least 2018-11-14 was ok)
Since the addon is huge (archipack),
i do try into console to make report as simple as possible, so you probably spotted another issue ?

Addressed by D3987.

In T47811#532158, @lexomir (lexomir) wrote:

I am currently using scene_update in my addon to check for object name changes [...]

I don't think we want to start patching our bundled Python to solve bugs or limitations in the Python implementation.

+1 for scene_update alternative.
I'm maintaining live link plugin for Unity + Blender. scene_update is critical for it. also, many DCC tools provide similar callbacks. there should be no merit to be against mainstream.

operator origin_set relies on selected_editable_objects afaict, so adding override["selected_editable_objects"] = [bpy.data.objects["Cube"]] should do the trick:

Thank you, rigify working fine now, assign from some:
//source/blender/blenkernel/intern/cdderivedmesh.c:157:2: runtime error: null pointer passed as argument 1, which is declared to never be null

And if you want a "production" example of this:

• Enable the Rigify addon.
• Add > Armature > Human (Meta-Rig).
• In the Armature tab > Generate Rig (and wait, it takes some time).

Assigning to @Campbell Barton (campbellbarton) but I suspect the issue may be the drawing caches, so poking @Clément Foucault (fclem) as well.

There was also T48096 and T54097, but to be honest: I am unaware of any 'final' decision on this...
Will also talk to @Campbell Barton (campbellbarton) again...

Please also leave me out of this and future conversation. Thanks.

Sounds like your mess. Please leave me out of this and future conversation. Thanks