- User Since
- Dec 4 2013, 8:19 PM (297 w, 5 d)
Jul 20 2016
@Brecht Van Lommel (brecht) , the way I understood, is that the render layers are basically containers or groups for the normal layers, containing render properties, and passes, and display overrides for the layers they contain. they don't actually set layer visibility, that will be determined by the layers themselves.
Jun 26 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.
so I read the design doc, very promising, I especially like the rendering and compositing features working together.
May 29 2016
All that the softimage is doing is integrating the render layers into the layer management directly as the partitions are essentially layers in they're own right. subordinate to the render settings for the layer.
So basically every layer is child to a render layer from the start.
May 3 2016
personally the only thing I use the multiple layers per object for is to keep reference objects or lights visible while I focus on individual layers. This could be replaced by a layer lock that would keep a layer visible until unlocked. I know I could hold down shift and swap layers that way but its just more convenient not to worry about what layer your lights are on.
Jul 28 2015
Settings Shelf ?
I fully support this, the pain of copying colors to each and every editor while fine tuning a theme is approaching the ridiculous.I think this is a great example of where too much of a good thing (flexibility) , becomes flawed in practice.
Feb 12 2015
Here's a little functionality demo I made , that I think would really work well to clean up the properties editor.It separates Scene/organization from object properties. It would also make a practical place for a layer manager, and make it easier to interact with the outliner.
full blurb here:http://wiki.blender.org/index.php/Dev:Ref/Proposals/UI/Properties_Tabs_as_a_customizable_Dock
.. goes and hides under a rock until the war is over
Nov 13 2014
not meaning to 'blur over' the idea but there are some practical issues with it that I don't really think could work.
Nov 11 2014
@michael knubben (michaelknubben), That design would be very clumsy in practice - there's a reason that no popular interface uses a "re-flow" of columns.
Just imagine scrolling with two columns - one would scroll down, while the other scrolled up to flow into it .This would be very confusing to use at best.You could limit scrolling to the last column, but then you have the weird situation of a non-linear representation, with modifiers in between the two ends of the stack being hidden.And then what happens when a modifier is too long to fit in one column.....?
Oct 25 2014
it would be great to see a resurrection of this.
Oct 5 2014
here's a possible solution to the properties editor tabs not fitting into the horizontal space,as well as some other changes,consisting mainly of transforming the properties editor into a customizable dock.The tabs for each instance of the dock can be hidden or displayed independently, so multiple editors can be utilized for specific areas(see mockup) feel free to comment.
Oct 4 2014
moved properties tabs proposal to T41700
Sep 15 2014
isn't this discussion supposed to be happening in https://developer.blender.org/T41700 ?
Aug 16 2014
Personally I think the text really shouldn't have anything to do with the functionality, it's just a label. The respective drag and toggle areas should be independent of text, because of the obvious reasons that you just pointed out - the areas would change size depending on the length of the text.
Aug 14 2014
Now I see what you mean,what I had in mind was just a static sized widget which would overlay the text when necessary, like in the example; but would represent the larger drag area. exactly like the toggle icon represents the entire toggle area.This keeps things cleaner, but there would be no visual division between the two target areas.
Aug 13 2014
Also, the percentage would still lead to an overflow issue when the region is too small
Aug 12 2014
replacing the tools seems fine for me,
@Tillmann Schütz (Ionarn) , I really like the clean look of your mockup, but @Jonathan Williamson (carter2422) has requested that design specific discussion be kept for later; could be as part of T38037
looks good, where do the sculpt tools appear when activated? do they replace the uv tools in the tools tab, or just make additional panels?
Aug 10 2014
@ Karja, that's possible with the copy attributes addon, which I think should be enabled by default.but it's not really a good option for a button- perhaps a drop down menu for the modifier panel could contain options like this.
Aug 4 2014
@ carter2422 - unfortunately , no, my knowledge with coding is limited to some basic scripting(no C experience ). So I'm not really qualified here.I'm hoping to keep learning though.
Aug 1 2014
No problem here, I agree that the debate has gone far enough - sounds reasonable to save the physics integration for later.
Jul 30 2014
Better to say what you *like* from listbox, rather than just blindly rushing to an (imo) >incomplete implementation, that does not really solve the problems billrey's original >and rather brilliant mockup does.
Jul 25 2014
Physics are modifiers too. With the listbox particles and physics could be merged into the modifers tab.
Jul 24 2014
@bassam kurdali (bassamk), right, this does'nt need to be focused on the exact implementation, but the listbox in already a major feature of blender's UI, and would be consistent with many other part's of the interface. Not to say there isn't a better way though.
@Jonathan Williamson (carter2422) -Thanks for the feedback, I agree with the concern about the "top down" being clear but as @xrg (xrg) mentioned, many applications use a layer system that processes top down, so the concept is quite familiar to most users.it's also an option to add a UI element (such as an arrow) that indicates the sequence order.
Jul 23 2014
Ok guys, I hacked together an addon which demonstrates the list box UI in limited fashion; the main limitation being that only one modifier's settings can be displayed at once, and I couldn't (easily) implement every physics type (Particles,Force Field,and Rigid Body).
Jun 17 2014
Why not the V key? I don't see any reason to retain it for vertex paint mode toggle now that we have a pie menu,also it is one of the lesser used modes, so why should it have a single prominent key, while the others modes don't?
FWIW, there's this older mockup for the specials menu (ignore the other toggles) - it could be nice to implement this way, so there's just one handy hotkey for specials.
Jun 4 2014
@Bartosz Moniewski (monio) - that could very well be true, combining layers and groups might add more complexity than it resolves, but after trying to wrap my head around the possible situations, I still think it might be feasible, and actually more flexible.
Jun 3 2014
This task hasn't got much attention lately, but I've been putting some thought into integrating layers into blender's data-block paradigm.Simply put, custom layers can't be referenced by a static numeric index like is currently used, they will probably have to have a dynamic data block type containing the name and list of objects in the layer.Then I realized we have such a datablock already implemented: It's called the "Group". Take a look at this screenshot;
By switching the outliner to the groups type, I've basically achieved a layer manager similar to the proposal - complete with toggles for view,lock, and render.The only thing necessary to make it work in reality is to change the way that these toggles work, so that individual objects stay visible until all groups/layers that contain them are toggled off.
May 22 2014
nice, this is definitely overdue. Do you plan to include the other tools like, pack islands, minimize stretch, mirror, and stitch? they are quit useful tools as well.
May 21 2014
if it's worth anything, I'd agree, just make a dropdown for at least the UV map selection- its too ambiguous working with active uv maps, and selected nodes.
Apr 29 2014
Thanks to all, its a great feature to have!
Apr 28 2014
@Armin Zingler (willi) - actually that's a different property, I'm trying to animate the actual render layer toggle on and off - which worked in 2.69.
attached file didn't work so here it is:
very nice!, I assume this will include moving the render engine selection to the render tab of the properties editor?
That would make more info header room as well as being more logical placement.
Apr 14 2014
Good ideas, but I think the most elegant and fluid solution is still the list box header; this could could effectively extend the concept of placing all the 'global' buttons and settings at the top, thus unnecessarily reproducing them on every modifier.
Mar 12 2014
@ januz, it does rather..
Mar 10 2014
@Diego Gangl (januz) , that looks great, +1 for adding options instead of removing them.
perhaps you could post a screen shot with a more "flattened" theme ? this would make the comparison easier.
Are you using a mapping node in cycles? currently the cycles material view in the view-port does not respect the mapping node.
Mar 8 2014
I modified this for 2.7 tabs, the changes are highlighted in a comments block in the code :
Feb 19 2014
NOTE: It is more important to connect a previously understood action to an easily recognisable visual symbol, then creating an illustrative representation of this action to make it easily understandable in the first place.
Feb 18 2014
But what will you do with Limited Dissolve, Edge Collapse or Edge Loop? How will you communicate that Delete only >Faces won't delete the edges as well? How will you make it consistent with the other delete-menu items?"
the merge icons look great! but I agree with @Jonathan Williamson (carter2422) about the complexity of the delete icons.
Feb 12 2014
version 3 is a nice visual indicator of a handle, without being too obscure or hard to grab.
its also consisten with the drag indicators in the new list boxes(two lines)
Feb 11 2014
nice popup design
Feb 10 2014
@januz- thats true, it could be in the properties panel as well, when the tabs are added it could actually be quite effective.
basically the same advantages of a popup but more persistent if desired.
@Paweł Łyczkowski (plyczkowski) - sorry I didn't make this clear but these two points work together - the popup provides the quick access to layers, while the comprehensive layers manager can provide more integrated features by working in combination with render layers. the location of the layer manager is arbitrary.
I don't have a build environment set up to test, but this is a feature I've though should be implemented for a while.
Here's video from the Tube project, demoing their custom layer manager; it's pretty hacky, but it has a couple of points that I like.
1,2- the cursor icon means lock selection, same as outliner.I agree though, that a lock icon could be an improvement.
Feb 7 2014
@Diego Gangl (januz) - thanks, posted it.
Feb 6 2014
I know its slightly ridiculous, I was just trying to come up with a consistent design. the layer management tab would not have full outliner expandability, just single objects. I don't really understand how is this different than your mockup ?
@Paweł Łyczkowski (plyczkowski) - that would probably work fine,but is it a good idea to have such a different interface(from an outliner type manager)?
or were you thinking that the layer manager could use a list box as well?
Feb 4 2014
After thinking about this some more, I've realized that this goes a lot further than "extending the current system". The advantages of the current system is that is is very fast and compact - if rather obscure. I really can't imagine any faster way to set up render layers, move objects to another layer(hotkey M), and so on.
Feb 3 2014
@Diego Gangl (januz) - right, it seems that the only clear way to display items is singly, perhaps with some indication of hierarchy like you suggested.
perhaps someone could check out how other 3d packages handle layers?
Jan 31 2014
@Diego Gangl (januz) - I get it now, guess we'll have to wait until the UI team has time to review this to reach a definite conclusion, they must be pretty busy with the 2.7 release right now.
Jan 30 2014
@Diego Gangl (januz) that could work nicely on the UI level, but not on the system level; for example - if you want to have a parent on a different layer then its child mesh, which layer would it be displayed in the outliner ? how would you represent hierarchies across layers? maybe both could work , the traditional tree view, and a layer tree view accessed by tabs. though I still don't know how to really use a hierarchy view for layers, perhaps it would simply have to display single objects , with some indication of hierarchy such as an icon.
I agree, the View mode could be considered the UV Mode, but perhaps It should be renamed ?
Jan 27 2014
How about splitting the hair and particle systems into separate modifiers?
This could be done nicely with the list view proposal, and would make for a cleaner, more logical and discoverable system.
personally, I think the image and game properties should be on the right side, as they are properties, not tools. this would be more consistent with the 3d view as well.
Jan 18 2014
good points here, some things I just noticed in the UV image editor; in the paint and mask modes, and uv sculpt mode; the tools are activated at the bottom of the tool panel, making the switch between modes almost invisible. the user must then scroll past task unrelated tools, to reach the primary tools of the mode. this might be improve with the toolbar tabs implemented though.
Jan 14 2014
@William Reynish (billrey) - the nodes already to that don't they? the settings of the selected node are displayed in the properties panel, or were you talking about a proposal for the materials tab in the properties editor?
Jan 13 2014
thumbs up to the ideas here,
Jan 11 2014
this is off topic, but while we're on the subject, shouldn't the monkey be made a manifold mesh ? I don't know how many tutorials and demo's I've seen that add a disclaimer something like "this doesn't work to well because suzanne isn't a closed mesh".
Jan 8 2014
I could be wrong but I don't think its a bug, its just that the inflate brush expands faces based on there normal, so as soon as dynamic topology creates a face pointing downward, it goes crazy with the opposing normals.using the smooth brush frequently during the sculpt helps prevent this.
Jan 7 2014
@Josemaria Rebello de Andrade (josemaria) - the categories I suggested are certainly open for opinion, but as I see it, a tool is something that interacts with or affects/creates another object, while a property is an inherent value of the active object. so.. while the pencil is a tool, its properties go in the properties panel.
I'm sorry for posting on a closed thread, but as the title is "Implement Vertical Tabs for Toolbars and other regions"
I'm just curious if its planned to extend the tabs to the properties panel as well.
Jan 3 2014
I fully agree that this improves the current "3D" look, and makes a much more relaxing interface.
Dec 30 2013
@Daniel Salazar (zanqdo) Wow, I didn't realize you can actually edit the mesh with Animall, very cool work, thanks
I just discovered the point animation features in messiah studio.
Dec 13 2013
could implementing tabs in the 3d view properties panel be a valid solution? I did a rough mockup on the wiki a while back that demonstrated some possible organization; although some of the ideas there have been improved on already: