You should consider changing the Workspace switching shortcut to Ctrl +Tab (next) and Ctrl + Shift +Tab (previous). It is what all web browsers use for tab switching.
May 8 2019
Apr 7 2019
May 23 2018
Apr 28 2017
Now I see the problem, the scale in Z axis was 0. After applying the scale it works like it should.
Aug 2 2016
This is in the task description, but maybe I'll provide some more info on this. My opinion is that what you render, and what you want displayed, are very often entirely different - that's why merging these two in any way, as mentioned here for example:
I think we should only allow selection of a single render layer per 3D view
will be limiting, and that the current separated system is in the right direction. The way to build on it with unlimited layers could be done like this:
But we could take it even further: Layer trees (the hierarchical list of layers) could be (unlinkable) datablocks so you can have multiple, independent layer trees. It would be possible to copy them and add new clean ones (with all objects on a default layer). That way you can tell the viewport and every other render engine which layer tree datablock to use and you have a big pile of flexibility. It would also be consistent by using an existing approach.
Jun 27 2016
As for the local view override, the solution @Brecht Van Lommel (brecht) proposed is pretty solid: allow a viewport to display a single render layer, as well as in the future, the viewport compositor output. A render layer can contain both the viewport display overrides as well as the render engine settings as needed. essentially, if a viewport is a renderer, then it makes sense to use the render layers to control their output.
In the viewport a dropdown can quickly switch between full scene layers, single render layers, or viewport compositor output. this eliminates the need for a second layer manager in the viewport but still offers a way to customize individual views. This would also be useful to test render layers output in rendered viewport mode.
this way, for example an animator could have one viewport+ render layer drawing a stripped down scene for working and another displaying an full openGL camera render piped through the compositor for effects.
we may have to wait for the viewport compositor nodes to get advanced control but I agree its probably better than trying to integrate "FX layers" into layer manager for now.
Jun 26 2016
Local layer settings override
Hmm, I fail to find usecases for this that can't be achieved using Local View (which is also local to the editor). Examples please?
I really like the design doc but there are many things that I find problematic:
Jun 10 2016
@Julian Eisel (Severin): That was meant for me I guess. Thank you for your answer! By 'current proposal' I meant the initial post on this page by Pawel Lyczkowski. I am glad to hear that you prepared a detailed document and I really look forward to see it. I will definitely look at it and comment if I find some issues with it. Untill then there is nothing more to discuss I guess :) .
@Ejnar Brendsdal (ejnaren): The main point that I wanted to bring up is that there are some serious problems with the current proposal that can cause big troubles in the future. I don't think that my proposal is the only possible solution but I am sure that the current proposal needs a lot of work to be good and future proof. I am a bit disapointed that you are the only one who is willing to discuss it.
About the mulple layers per object issue: IMO this is absolutely essential decision that should be made first. I can imagine both systems and they both have their advantages and disadvantages but they both need different aproach and different tools to manage them. I can't see how a single proposal can manage them both. I think it would be best to make single layer per object - it is easier to manage, the export import is easier and the only big disadvantage is the compatibility of older blend files. It is also crucial to make a new system for saving the visibility settings for all the layers - I called it 'viewport layer set' in my proposal and it should work very similar as the RenderLayers but you would save viewport visibility settings instead of render visibility.
It is nice to have a layer system with unlimited number of layers but it is useless if you don't have the tools to edit all the layers quickly and efficiently. The current proposal just adds confusion and complexity and removes some essential functionality.
Btw.: There are some very good comments by others (especially by Warren Bahler) but I don't see them being reflected in the original proposal.
@Ejnar Brendsdal (ejnaren): I think I get it now - you will be able to override the visibility setting of the layer for each object in each 3d viewport individually. I can't imagine how you would manage all the object overrides (?) if you have thousends of objects in your scene.
What I was talking about is this functionality currently present in Blender for years:
Here is an example how this is used:
In the top viewport you have a camera view with global layer visibility so that you can see the final composition. The bottom view shows only a few layers so that you can easily see your cameras so that you can easily pick the right camera and move it in xy plane.
In current blender it is very easy to setup - just disable the 'use global layers' button and switch off the unwanted layers. In my design proposal the process is the same. How would I set this up in the current design proposal?
Just for comparison here is the same view without the local layers settings:
Jun 7 2016
@Ejnar Brendsdal (ejnaren): This would be a usable solution but you will end with two layer managers - one in 3d viewport for local visibility settings and one in a separate editor for global visibility setting. They will have the same functionality and very similar UI. Wouldn't it be better to keep them both in one place and just pick if you want to set the global or local values?
Another thing to consider: There is already a grease pencil layer manager with unlimited layers in Blender. Why should the scene layer manager have a different UI (the layout of buttons, separate editor x inside N panel)? IMO the UI should be consistent and the grease pencil layer manager is pretty good and fits into the Blender's UI well.
Jun 3 2016
I hope I am not too late with my proposal but I found this thread only few days ago and it took me a while to read through the whole discussion and come with my own approach. Anyway here it is:
I made a google document with some text description.
The main problem in the current approach with new layer manager editor (eventually incorporated into the outliner) is that you can't set custom layer visibility for each 3d editor individually from an independent editor. There is no way how to tell the layer manager editor which 3d view you want to affect. This is essential functionality and it should definitely be kept in blender. This means that you will need some sort of layer manager in each 3d view anyway and I think it would be best if this would be the main editor for layers with all the important functionality.
I am very interested in the new layer manager and I would be happy to help with testing during the development.
Feb 19 2016
This is not (only) a problem with the addon! The problem is that all the scene that have lamps that are generated with the addon are broken in the new buildbot Blender. You don't need the addon active to reproduce the bug.
Feb 18 2016
Feb 14 2016
Jan 13 2016
Dec 8 2015
@Dalai Felinto (dfelinto) Thank you very much! The recent build renders just fine. I found a bug with border rendering but I guess it is better to fill a separate bug report. Anyway, thank you for your work on this!
Dec 6 2015
are there any new builds available? The last build I found is 2.74-d33764b from this article: https://code.blender.org/2015/03/1451/ (which is no longer available). The problem with this build is that it outputs very noisy renders compared to standard panorama made in recent 2.76b (official).
Nov 28 2015
Sep 5 2015
Jul 7 2015
@Dalai Felinto (dfelinto): I can't reproduce this in the Fly View - problem only in the Walk mode.
May 24 2015
Apr 9 2015
Jan 14 2015
Amazing! Thank you so much!!
Jan 13 2015
It was always known but also manytimes criticized (and even wrongly reported as a bug). The camera clipping plane is extremely useful for interior architecture scenes but the sphere clipping is very problematic and it limits the way how to place the camera in the scene. It is also quite difficult to set up the clipping distance because there is no preview in the openGL viewport and using rendered view is difficult because interiors render usually very slowly and it takes a while to see the clipping effect clearly. Sometimes the clipping sphere clips just the edge of the table which is not very visible in preview (noisy) render but it is quite clear in the final (high-res).
I have to deal with that daily and the change to clipping sphere would be huge for me. I can document some "real-world" examples if needed. In my opinion the positives of this change are worth breaking the old files because the fix is quite simple in most scenes and in some it would not make a visible difference anyway.
Jan 10 2015
Oct 21 2014
Thank you Lucas for solving the error!
Oct 16 2014
The numeric input: I use czech keyboard layout and on the numpad there is coma instead of a dot next to the "0" key. Everywhere in Blender it works so that if I input a value using the coma on my numpad (not the other one which is on the main keyboard) it automaticaly inserts a dot.
It is not a big deal but it would be nice if the input of numbers would be consistent.
Aug 19 2014
Aug 18 2014
Maybe it would be wise to make a separate Offset modifier based on the current solidify but without the nonsense option like fill rim, index offset etc. The think is that the simple offset doesnot generate any geometry so it should be in the deform category and not in generate together with solidify.
Jul 16 2014
Same problem for me under Win7.
Solution: Run Blender as administrator and problem is gone. Maybe the ability to set custom folder for presets would be a good solution as well...
Jun 10 2014
I hadn't noticed the previous report, sorry for opening a new one. However I think that if the tool does not work as expected it is a bug. Can't see a reason in bringing more inconsistency into this tool.