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.

@Philipp Oeser (lichtwerk) Well, when scene lights are enabled from the Shading Popover, Color Management is fully applied to the viewport in LookDev mode. Thanks for pointing this out. The problem is, in my scene I have a lot of area lights illuminating an interior like LED strips. The viewport becomes unusably slow if they are enabled, so that's not really a route for me to take. I fail to understand the benefit of not applying the selected View Transform if scene lights are turned off. Especially because there is zero indication in the UI that the transform is overridden, and neither is indicated by what it is being overridden. Maybe the decision was clever and I just don't see the reason yet, that's why I'm asking the question.

I agee with Troy here in terms of having unclear creative hacks around will make it more difficult to develop the compositor further towards a tool that can handle arbitrary color spaces of input and output elements, which is essential for (not only but in particular VFX) compositing.
I might open an off-topic can of worms here, so I apologize in advance, but the reason for us at Kiska to *not* use Blenders compositor at all for final comps is the fact that there are no View Transform or Look nodes available. Having them in a scene based dropdown list (currently the Scene tab of the Properties Editor) is a very inflexible choice. It effectively means that Blender Devs were forced to evaluate both the View Transform and the Look at the end of the compositing chain at all times (what else shall they do?). This leads to users not being able to use a single node *after* those transforms have happened. But the image data, when comping .EXRs or RenderLayers, or any other scene referred input, is - surprise - scene referred. Using nodes that contain display referred math unfortunately produces mathematical gibberish, unless the users craft their renderings to anyways always fit inbetween a 0 - 1 value range. Which they did before Filmic emerged, and thank god those times are over.
So the wish from our side is that there are nodes implemented to the compositor that allow to correctly deal with color spaces and their conversions. We are willing to accept a certain performace drop if that is necessary to get it done. I'd really see that as a priority over other surely creative but playful features.
Same wish goes for any code in Cycles or Eevee that assumes sRGB illuminants, but this is really off-topic here.

The first one to check with when external Add-ons don‘t work is the manufacturer. Did you get in touch with the CrowdRender team already?

@Antonio Vazquez (antoniov) Just seen from a user perspective, maybe it‘s not even needed to have the option Link To Object available for Grease Pencil objects. It makes a lot of sense for mesh objects, as it allows instances to receive different materials, but for Grease Pencil strokes this might be overkill. What do you think? Should Grease Pencil simply ignore that setting in the User Preferences?

Is there any way to remove / deactivate a default keymap item via Python? I've asked this question in two places, once here https://blender.stackexchange.com/questions/110742/how-can-i-modify-the-default-blender-keymap-within-my-add-on-module-registration and once here: https://devtalk.blender.org/t/how-to-modify-the-default-keymap-at-add-on-registration-time/983

side note: same behavior in current 2.8 builds

moved RNA functions outside of loop, please check

Part of this Task T54643

Many users are concerned about the ability to switch between what we at the moment know as layers - in the future collections - in the viewport using hotkeys. At the moment, you can use 1, 2, 3, Alt+1, Alt+2, etc to quickly show and hide layers. Do you think it would be possible to implement something flexible into your design approach? When I look at your mock-up, it makes me think if it was possible to simply assign a hotkey to them, defined by the user. That way, you would not need to hard-code stuff in, instead you put the responsibility to assign the desired key-stroke to the users.

It must be buried somewhere in the code that handles the material link type (i.e. if it is set to 'OBJECT' or 'DATA'). In the given file, the material link is set to 'OBJECT'. If you set the link to 'DATA' on all cube instances, the slot can be removed without a crash. I have done that material link change in the file provided here:

Please note that this isn't a bug in Blender. Animation Nodes have been redesigned recently to use a specific version of Cython. The reason was the massive speedups you were able to get with this. But as a result, AN is now dependent on a specific Python version (which is why you get that error). At the same time, the current development version of Blender has been upgraded to use Python 3.6, while the stable 2.79 still uses 3.5. Recompiling AN yourself using Python 3.6 *should* fix the issue for you, alternatively I believe that Blender can also be forced to use good old Python 3.5. Both is IMHO out of scope of the Blender bug tracker.

@Sergey Sharybin (sergey) Ups, thanks for clarification. Guess this can be closed then as invalid.

I've tested this with a Blender version from the 18th of September, unfortunately didn't work for me. Same as Jan stated, if I copy my template the the AppData/Roaming location it works, but from my custom locations, neither user nor system template folders work. We're using the portable versions of Blender, and redirect unified settings to a server location so everyone shares the same install.

@Brendon Murphy (meta-androcto) Indeed this has been silently fixed somewhen, that's good news! Not sure when it has been adressed, but no crashes any longer

@Thomas Beck (plasmasolutions) I Just checked out the master Branch and patched it with the current version of this patch here (and a few others in addition, like the SurfaceFollow Modifier one). But I haven't changed any ifndef defines due to the total lack of C++ experience. I was only dealing with Python and C# so far.

FYI: Currently the patch fails to apply in three modules (tried applying in blender-v2.78b-release branch on commit c727bc7):

I meant this guide: http://www.gizmoplex.com/wordpress/compile-blender-as-python-module/

Just verified the suggestions. Using the raw Pyhton console made no difference, import errors would remain the same. But following the guide here **http://www.gizmoplex.com/wordpress/compile-blender-as-python-module/** (especially the part of copying the needed libs over to the Python35 directory) made it work. Can now successfully use the bpy build!

Thanks for your feedback,I will try your suggestions next Monday when I am back in the office.

@Bastien Montagne (mont29) HEAD BUMP You can close the report I guess. For one, the crash doesn't appear in newer Python versions, but further more my date format was nonsense. The formatter should have been:

@Vuk Gardašević (lijenstina) I've tested a version which I compiled on the 23rd of November (reports as 2.78.4), it crashes, but with some more latency. Testing VS2015 build, downloaded right now: WORKS! no crashes there!

Wasn't able to reply before as client projects kept me busy, sorry for the inconvenience.

would propose the following fixes:

Hi Sergey,

Maybe even skip the "named", as afaik unnamed objects don't exist in Blender. Otherwise people might ask how to name them...

@Julian Eisel (Severin) I tried to apply this as a patch today, but it failed for me (didn't find the lines to change). To I need to target a specific commit to make it work?

applying the patch currently fails, the kernel_types.h.rej file says:

accidentally created ot twice, please delete this one

Hi Bastien,

found this dirty hacky workaround here:

I'm working on a script that will add some additional input sockets to a node group based on output socket names from another node (input image) in the Compositor. This is the script so far: