getting the same error with the .fbx interface at the moment

Tested the fix provided by @Cirno (Cirno) and can confirm this works! Attatching a diff for merging in case one of the devs wants to use it.

This is due to the PsyOp Cryptomatte Plugin for Nuke not handling the Metadata names correctly. The latest version of the plugin *should* work already (issue was caused by the space in "View Layer"). However, there are other cases that still don't work (like "." in the View Layer name, or a VL name starting with a digit). See [[ https://developer.blender.org/D5232 | this ]]discussion here for reference.

FYI we are using Nuke for compositing, so the app on the other side doesn't seem to matter.

Same problem on our side. This behavior of Metadata not being attached correctly to OpenEXR does not only affect File Output nodes it seems. Saving from the Image Editor to OpenEXR (MultiLayer) seems to show the same problem. Is the Metadata attached at all? Can someone confirm this?

for the record, commit 340b9c1dfc6e81efc0fb1e1ffff78203ba6aeddc fixed the issue.

From my side there are no more steps to reproduce it, it was fixed somehow in one of the last 30 commits. Todays build does not have the problem any longer, so this report can be closed as far as I am concerned. I'm not the original reporter though, so maybe ask @Ishaq Al Asyja' (McRavenIND) for confirmation as well.

The only thing that seems to work is single pass anti-aliasing

Same thing here on an nVidia Quadro card. Basically, once again the logic for anti-aliasing the viewport has been reversed. I have Viewport Anti-Aliasing samples set to 8. While manipulating the viewport, the model is anti-aliased (it should not be so), while not doing anything (let go of mouse), the anti-aliasing disappears. This happened pretty much over night, didn't see that in yesterdays build.

Guess then it's better to simply close the report as invalid. I won't find the time to setup such a scene that could be shared online for testing. As the problem only arised a few days ago I thought maybe there were changes to BlenderKit that could explain what's happening, but without a trace it will be impossible to track this down.

@Ivo van der Lans (Ivo) please note this proposal is about the compositor, not cycles.

Is this something that's on the ToDo list for 2.81 already? Or is there a workaround for it? Not being able to have modifier keys for custom tools limits the use quite a bit.

updated revision to replace any non-alpha-numeric input

@Bintang Senja Pratama (bintang) The updated plugin half-fixes the problem. However, a more complete fix could be done by updating the plugin following the suggestion here. Currently the metadata matching will still fail, because a View Layer name like "View Layer" (which is the default) will turn into "View_Layer" in Nuke. The plugin at the moment does not compensate that. However, bottom line is, there is no real need to change Blender itself for this, so the revision here can be closed / abandoned. I will update it once today just to provide the exact same fix as I suggested for the plugin, just for completeness sake.

In D5232#118521, @Brecht Van Lommel (brecht) wrote:

What I was thinking of in devtalk was configuration to change not just the metadata, but also the names of the layers themselves.

Otherwise it's writing out EXR files that have inconsistent names for layers and their metadata, which is basically writing an invalid file to compensate for an issue in Nuke or the Cryptomatte plugin.

So I'd really prefer to avoid doing that if possible.

I'm also not a huge fan of hiding the existance of fake users in the UI. While I understand that it confuses new people (trying to avoid the term "new users" here for clarity's sake), it also "forces" them to learn about how Blender handles data in general, and what the concept of user counting is. A fake user IS a second user of a datablock, as long as there is something else referencing the datablock. Not showing that will all the more confuse all the other people who have learned about the user count system.

In T58187#653632, @Sidney Moraes Jr (mangojambo) wrote:

I guess this is related to T62094 as well, since driver/keying would follow similar workflow.
There is a workaround for this: Add Driver to "Properties > Object > Viewport Display > Display as" and set the values 0 and 5.
(0=Invisible, 1=Bounds, 2=Wire, 3=Solid, 4=???, 5=Textured)
Here is an example:

VisibilityDriver_2.8.blend699 KBDownload

I don't know if it is intended but it works.

Cheers.

The same issue happens when you define a complete new tool with a shortcut using bl_keymap. On first Add-on activation, the shortcut works. On restarting Blender, it is non-functional. But if you reload all scripts while Blender is still running, the shortcut works again. I have used this class from the Templates to verify this behavior:

I can't get this branch to compile properly. At the end of compilation, I get the following errors (there are more, but these are the first):

Just tried this patch, this is a REALLY handy addition. In 99% of the cases I want to draw quads anyways.

already fixed properly by Brecht

Eevee LookDev and Wireframe mode are NOT affected by this, this is Workbench only.

@Campbell Barton (campbellbarton) bpy.utils.user_resource(resource_type, path="", create=False) is indeed useful. The bug report however tackles a case which is buried within the AddPresetBase class. There, bpy.utils.user_resource(resource_type, path="somesubpath", create=**True**) is called. The subpath IS then created as it should be, but not within the path coming from get_path_environment. The location it ends up in is unexpected and undesired from a user's side.

The thing came up while following a given answer on StackExchange https://blender.stackexchange.com/questions/134613/can-python-operator-presets-be-shared-between-operators/134620?noredirect=1#comment231376_134620

Poly Build Tool also does nothing when you try to use it

Transform Tool is also affected, but it is less visible. If you set Drag Action to None it still transforms on drag.

Seems to be fine, all properties are back.

@Philipp Oeser (lichtwerk) For the sake of avoiding historical confusion, swapping 'BLENDER_RENDER' with 'CYCLES' would make a lot of sense. At the moment it's a bit like 'Yeah I know, last year Blender Render was meant to be Blender Internal, but now it's Cycles'. Conversations like this can get a bit rough :) Anyways, not related to this. Thanks for the patch, will test it now.

What makes it a bit confusing is that panels which serve a similar purpose (and almost look the same in the UI) are spread across different files. Check for example the camera aperture one. The cycles UI for this is in the file ui.py:

Seems like 'CYCLES' is missing in the COMPAT_ENGINES set in a few UI tabs like for instance the lens panel:

@Brecht Van Lommel (brecht) Jesus, that was indeed the issue. My own builds fail to detect OCIO, while the official ones work just fine. Must have messed that up a while ago. Thanks for investigating!

Output of 2.79b:

Yes, for me the problem still persists. Same if I use the provided syntax above: OCIO=/CustomSoftware/OCIO/filmic-blender/config.ocio ./blender throws the same error for me:

I've got the feeling that commit 5e121c8eab23d3d42745277f9c92617cb0aeb066 by Stefan Werner has resolved this issue. So far I had no more crashes.

Also from our side at the studio a very much longed for modifier! Are there plans to go ahead with this proposal?

Seems like the mouse buttons are swapped - the information banner appears when holding down RMB in Blender 2.8. In the keymap, the image.sample operator is indeed assigned to the right mouse button now. I couldn't find any documentation regarding this change in https://developer.blender.org/T55194 though, maybe that was unintended?

Hm, just tested again under Linux, now I have the same issue there too. Maybe I misremembered.

removing said nodes via a script and re-saving the file has solved the problem. We were not able to re-create the issue, I do remember however that we worked with a patched version of Blender before that IES Shader node was merged to master. Too isolated to follow up on the issue, so closing this. Thanks!

@Jacques Lucke (JacquesLucke) Yes, I ran a few tests with production files we have here in the studio. I can't claim I have done every thinkable test though, just the common operations (Edit Linked, Go back, use_autosave, use_instance)

A thing that might be worth aligning on is if in the target file the collection or object should be selected at all. I'm raising this because the target could open in Modelling Workspace, and then it automatically switches to Edit Mode. This might be a Performance issue on large scenes.

added a few comments

Updated the diff to meet requirements by Jacques Lucke, thanks for the feedback!

@Bastien Montagne (mont29) Thanks for looking into this, if it is a mistake on our side the bug report can be closed. I'll pass on the information to the team and ask them how they got into this corner. Maybe they can isolate the node tree in question. We do mix Blender versions sometimes, so it could have happened that the texture was created in a later 2.79 build, and then the file was modified further in 2.79a or b.

also fixed on Windows, thanks!

Same thing here on Windows. This started yesterday at some point, another compiled version with hash 245065460f3 works just fine. If the user has set that color space in his startup file (like I did), Blender never starts and throws the 'Cannot find Colorspace' Error on startup.

@Philipp Oeser (lichtwerk) Maybe a misunderstanding, it *technically* works, but it's not very convenient from a user perspective, that's what I'm trying to say. So no bug to report there.

@Brecht Van Lommel (brecht) I see. Well, if the exposure story is seen as an issue, I guess we can live with having exposure and gamma settings ignored. I don't want to complicate things too much, I'm just sharing my thoughts from a user/studio perspective. View Transform and Look however are a must-have, but this I gather was agreed already. If exposure and gamma are ignored, there will be a need to deal with this in the UI. Having the parameters there doing nothing will confuse the hell out of people.

@Brecht Van Lommel (brecht) Thanks for your feedback, it's really cool that parts of CM are re-introduced back to LookDev mode. I do understand that the topic is complex, as the Blender Devs are putting a lot of effort into making Blender more accessible and easy to use. As far as I gather the discussion, this is the main reason for the change, so people would find a consistent experience. However, I find it counter-intuitive for LookDev mode.