Collection Manager #69577
Labels
No Label
Interest
Animation & Rigging
Interest
Blender Cloud
Interest
Collada
Interest
Core
Interest
Documentation
Interest
Eevee & Viewport
Interest
Geometry Nodes
Interest
Grease Pencil
Interest
Import and Export
Interest
Modeling
Interest
Modifiers
Interest
Nodes & Physics
Interest
Pipeline, Assets & IO
Interest
Platforms, Builds, Tests & Devices
Interest
Python API
Interest
Rendering & Cycles
Interest
Sculpt, Paint & Texture
Interest
Translations
Interest
User Interface
Interest
UV Editing
Interest
VFX & Video
Meta
Good First Issue
Meta
Papercut
Module
Add-ons (BF-Blender)
Module
Add-ons (Community)
Platform
Linux
Platform
macOS
Platform
Windows
Priority
High
Priority
Low
Priority
Normal
Priority
Unbreak Now!
Status
Archived
Status
Confirmed
Status
Duplicate
Status
Needs Info from Developers
Status
Needs Information from User
Status
Needs Triage
Status
Resolved
Type
Bug
Type
Design
Type
Known Issue
Type
Patch
Type
Report
Type
To Do
No Milestone
No project
No Assignees
12 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: blender/blender-addons#69577
Loading…
Reference in New Issue
Block a user
No description provided.
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
{F8771884, layout=inline}{F9263928, layout=inline}
Location — 3D View (Object Mode)
Menu Location — Object->Collection->Collection Manager
Shortcut — M
BlenderArtists feedback thread:
https://blenderartists.org/t/release-addon-collection-manager-feedback/1186198
Workflow Video by @1D_Inc
https://www.youtube.com/watch?v=yiti0xWO7Wg
Latest Zip Downloads:
(minimum required blender version: 2.80)
Present in Blender 2.93:
Collection_Manager_v2_21_3.zip
Current Development (will go into Blender 3.0+):
Collection_Manager_v2_23_1.zip
Overview of Current Features:
Modifier Shortcuts:
Expansion Operator:
LMB - Expand/Collapse sub-collections.
Ctrl+LMB - Expand/Collapse all sublevels
Shift+LMB - Isolate collection tree.
Alt+LMB - Discard history.
Set Object Collection Operator:
LMB - Move object(s) to collection.
Shift+LMB - Add/Remove object(s) to/from collection.
Local RTOs:
LMB - Toggle collection RTO on/off
Shift+LMB - Isolate collection RTO/Restore previous state.
Shift+Ctrl+LMB - Isolate collection RTO leaving children unchanged/Restore previous state.
Ctrl+LMB - Toggle collection+children RTOs on/off.
Alt+LMB - Discard history.
Remove Operator:
LMB - Remove collection.
Ctrl + LMB Remove collection+children. (Not Yet Implemented)
Global RTOs:
LMB - Enable RTO for all collections/Restore previous state.
Shift+LMB - Invert RTO state for all collections.
Shift+Ctrl+LMB - Isolate Collections of Selected Objects. (2.92+ Version Only)
Shift+Alt+LMB - Disable Collections of Selected Objects. (2.92+ Version Only)
Ctrl+LMB - Copy/Paste RTO state from/to all collections.
Ctrl+Alt+LMB - Swap RTO states for all collections.
Alt+LMB - Discard history and copy/swap states.
Renumber QCD Slots:
LMB - Renumber the QCD slots from the slot designated 1 (breadth first)
Alt-LMB - Reset numbering and start from the beginning.
Ctrl-LMB - Switch the renumber pattern to linear.
Shift-LMB - Constrain renumbering to a branch.
(All options can be combined with each other)
QCD Shortcuts:
Move Widget:
V - Open move widget.
LMB - Move object to slot.
Shift+LMB - Add/Remove object to/from slot.
0-9 - Move object(s) to slot from 1 to 10 (0 = 10).
Alt+0-9 - Move object(s) to slot from 11 to 20 (0 = 20).
Shift+0-9 - Add/Remove object(s) to/from slot from 1 to 10 (0 = 10).
Shift+Alt+0-9 - Add/Remove object(s) to/from slot from 11 to 20 (0 = 20).
3D View:
0-9 - View QCD slot from 1 to 10 (0 = 10).
Alt+0-9 - View QCD slot from 11 to 20 (0 = 20).
Shift+0-9 - Toggle QCD slot view on/off from 1 to 10 (0 = 10).
Shift+Alt+0-9 - Toggle QCD slot view on/off from 11 to 20 (0 = 20).
Shift+= - Enable All QCD Slots.
=- Isolate Collections of Selected Objects.-- Disable Collections of Selected Objects.Shift+Alt+= - Disable All Non QCD Slots.
Ctrl+Alt+= - Disable All Collections.
Shift+Ctrl+= - Select All QCD Objects.
Alt+= - Discard QCD History.
H - Disable selected objects. -- If enabled in the preferences. (2.92+ Version Only)
Shift+H - Disable unselected objects. -- If enabled in the preferences. (2.92+ Version Only)
Alt+H - Restore disabled objects. -- If enabled in the preferences. (2.92+ Version Only)
3D View Header Widget:
LMB - View QCD slot.
Shift+LMB - Toggle QCD slot view on/off.
Ctrl+LMB - Move object(s) to slot.
Ctrl+Shift+LMB - /Add/Remove object(s) to/from slot.*Alt+LMB -*Select objects in slot.Ctrl+Shift+LMB - /Add/Remove object(s) in slot to/from selection.
3D View Header Widget - Quick View Toggles:
LMB - Enables all QCD slots.
Alt+LMB - Discard QCD slots history. (2.92+ Version Only)
LMB+Hold - Pops up a menu with all of the Quick View Toggles.
{F8424226}(Passive objects are objects that are selected but not active.)
Planned Features:
Potential Planned Features:
Glossary:
Chaining: Dependent on parents for whether an RTO can be active.
LMB: Left Mouse Button.
QCD: Quick Content Display.
QVT: Quick View Toggles.
RTO: Restriction Toggle Option.
RTO Short Forms:
EC: Exclude Checkbox. (Excludes the collection from the current view layer -- affects both 3d viewport and render -- non-chaining)
SS: Selectability. (Disables selection for the collection in all view layers -- affects 3d viewport -- chaining)
VV: Visibility. (Hides the collection from the current view layer -- affects 3d viewport -- chaining)
DV: Disable Viewports. (Disables the collection in all view layers -- affects 3d viewport -- chaining)
RR: Renderability. (Disables the collection from being rendered in all view layers -- affects render -- chaining)
HH: Holdout. (Masks out the collection from the view layer -- affects render -- non-chaining)
IO: Indirect Only. (Makes the collection only contribute indirectly (shadows/reflections) to the render for the current view layer -- affects render -- non-chaining)
Original Concept:
This is a collection manager that I created for my larger addon Advanced UI Menus (https://blenderartists.org/t/addon-advanced-ui-menus/592865). I believe I read somewhere that blender was looking for a better way to work with collections in the 3D Viewport; so, this is my solution to that problem.
This addon provides a popup window that includes a treeview (made out of a UIList and operators) with functions to add collections and subcollections, rename collections, move objects to collections, exclude collections, restrict selection on collections, hide collections, and remove collections. It correctly handles collection chains and allows you to isolate collections by shift-clicking, and you can move objects to multiple collections via shift-clicking as well. The addon will also show you what collections are visible and what collections the selected objects are in. In addition it will not allow objects to be removed from all collections entirely. All of the functionality is documented by tooltips, so if you open the collection manager and just hover over stuff you will be able to easily learn all of it's advanced functionality. And as a final note, the window will size itself based on the depth of collections so nothing gets squished.
Collection_Manager.zip
Added subscriber: @Imaginer
Added subscribers: @WilliamReynish, @BrendonMurphy
hi, this looks quite good, I'll test it out shortly :)
@WilliamReynish is this something you would be interested in?
Added subscriber: @1D_Inc
Well, Brendon, nice to see you are interested in solving an issue, thank you for invitation.
We are really appreciate that!
But there is a problem - to solve the problem, you need to determine exactly what the problem is.
This is not a “discomfort”, it is complete workflow problem and includes several issues that allow to perform complex work processes of a certain type in Blender, inaccessible to any other software.
Deep historic restoration relates to that workflow type, so several museums, like Smithsonian and Hermitage are currently involved in negotiations about multiple issues of complex workflows in 2.8
This solution, (like Pablo Vazquezwidget ) seems to solve nothing of them.
Sorry.
If to speak in collection management terms, without special workflow context - it feels much better than default.
We love ability to filer name - this is what we consider necessary by default for scenes that can easily contain thousands of collections.
It works only for disclosed paragraphs, so don't allow to find a collection in entire scene (like materials filtering does), but filtering idea it is a very nice step!
Also we love solid design of it. It is looking good, and handy. A good job!
It's UI confidently holds up to 7 levels of enclosure, and this is pretty much enough for most of cases. Default solution provides better unlimited capacity, but in a less presentable way.
Don't know if window resizing can solve that, it will also have a limit, so it is a usability solution vs capacity solution issue.
Isolating ability by pressing shift+hide (eye) button is also nice idea, but the problem is that it doesnot restores previous setup on second click.
There are several ways to view everyting in blender, but switch back to previous setup requires undo (which is dangerous and need accuracy) or managing View layers (which is long way, and also needs accuracy).
So there is no way currently to quiclky check up what is in some collection, and return to previous configured state, which is quite critical since there are dozens of them, and their content needs for attention.
Same thing for exclude collection checkbox .
Also would be nice to have "Restore on exit" checkbox, that will bring ability to eliminate all changes on window closing, like AutoCAD LAYWALK function's window have.
It also have numeration addressing broken, so M5 shortcut to send object to collection, visible by pressing 5 is also not working yet. We call this "M5" issue.
It is essential for creating temporal layouts, raking tons of unnamed items from imported scenes, or quick separation of exact contexts in complex projects.
Finished editing post. Sorry about my english, it is foreign for me)
Hi @1D_Inc I'm the creator of the Collection Manager addon. Thank you for the compliments.
This addon was designed with artists in mind, not deep historic restoration; however, since it sounds like the Collection Manager is close to what you are looking for, maybe I can work with you to improve it to accommodate your workflow.
First off the window will size its width to fit the collections accumulated depth, but blender does not allow it to do that while the window is open. If you manually add more child collections than the width will comfortably accommodate it will start to squish up, but if you close it and open it again, you will find that it has resized its width to fit its expanded contents.
You are correct that the second shift click does not restore the previous state, but enables all collections. It would be easy to make it restore the previous state, and would probably make more sense to do so. If no one objects to this behavior, I will implement it. If it does get implemented I will probably add a button to enable all collections at the top, The same goes for hiding.
I'm not familiar with AutoCAD, so I don't know about "Restore on exit". If you can describe it to me more in depth (what does it restore exactly? Visibility? Collections select status? New/deleted collections undone? Something else?), I can see about adding it.
I have no idea about this "M5" issue and I don't know if it's a problem with blender or my addon. If you can describe it in more detail I would be willing to see if something can be worked out to fix it.
The filtering is a byproduct of using a UIList. I didn't even expect it to get used (which was probably naive on my part). That said, I think there may be more that could be done to improve it. Again, if you can describe what you want in more detail I may be able to implement it.
You were right when you said that "To solve the problem, you need to determine exactly what the problem is." I don't know what the problem is. But if you are willing to explain it, I'm willing to try to solve it.
Hi! Nice to meet you)
Of course, a lot of things are designed for average workflows) It's whatever.
Average don't need all those proper tests with timings, actions per second, perception speed and so on.
However, hard workflows design includes averages, but average workflows design can't support hard.
Don't know, what about horizontal scrollbar? Is it possible?)
Well, I thing it would be nice mostly for outliner, as it allows to navigate the scene.
Check up this proposal , it can be interesting and fresh.
It works simple - checkbox allows to decline all visibility changes, that was made since window was open.
When M window closes - visibility changes made in M window has gone.
You can find video about LAYWALK command in Layer Maniphest topic post.
That's easy. Create 5 boxes, put them to 5 collections - press 1 2 3 on top row of keyboard numbers.
You will see that some collection, numbered as 1 2 or 3 is isolated when you pressing number key.
Those 1 2 3 thing are "slots". They are needed for a very important thing, called "Concave workflow".
So, selecting some box and pressing M5 should send that box to collection, that is visible by pressing 5.
Pressing Shift+M, 234 should also add it to collections in slots 2,3 and 4.
That's it)
Well, you already made an "Expand" button, that technically solves filtering issue - so we are already able to find matching pattern is all scene's collections, and even see it's enclosing level. That's good job!)
I guess you understand how useful it will be in 1000 collection's file. I think, it will allow to survive in such files at some point =)
Well, complex systems requires proper proposals and tests.
We've spent a year to define what's wrong with QCD system and how it can be repaired in an easiest way.
We've spent a decade to finally bring proper snap proposal.
You are making a nice job, fixing things at some point you can observe. You are already doing your best)
hi @1D_Inc thanks for the feedback. It's appreciated.
I guess as addons devs we can only do so much until proper decisions and functions are in place. I saw this some time ago with the original layer manager addon by fourmadmen. My argue then for the Layer Manager addon was simple: We don't have this functionality, here's something to help users on the way until it gets built in. It's incredible that it was 10 years ago. https://developer.blender.org/T18565
I'm about to remove the old Layer Manager addon from Blender as it's broken and unmaintained in it's current form. It was with this in mind that I asked @Imaginer to submit his addon here.
I see this as a good opportunity to both examine the new methods and make a reasonable attempt to provide something if needed. No doubt the core devs will come up with a solution and all will be well at some stage. Possibly they may use some of the elements in "Collections Manager" addon, maybe it will be completely different. Here we are providing thought and working concepts.
I would say unless there's anything else planned that we could promote this addon to Addons Contrib for wider testing and feedback in nightly builds some time in the near future. with the aim of supplying functionality until it's built in. Not to replace or be a complete solution to the layers issue. Just as a helper for users who might need or make use of some of the functions early.
Thanks
Added subscriber: @nokipaike
guys, if you can create "the old quick layer visual grid" ... you're riding.
an addon would not bother anyone, and would be very useful to those who manage many models and collections to "catalog quickly"
@1D_Inc
Not to my knowledge; at least I don't think I've ever seen a horizontal scrollbar on a UIList or popup. It would be a good solution, though. Maybe someday.
Yes, it's interesting. I think you've stated most of the points here and it seems like a lot of them will fit in nicely.
Neat post! The situation here is a little more complicated because of the way popups work and because you can add and remove layers, but I think I can come up with something that will satisfy. How about a button to clear visibility changes?
Some of the things in that post are out of the scope of this addon, but I may be able to add some of them into my addon Advanced UI Menus (it's my personal playground for anything that makes blender better/faster UI/Workflow wise)
About M5:
I think I understand, but I'm not sure yet how this can be integrated nicely into the collection manager, so I'll come back to that later after I've implemented some of the other improvements.
Nope! Total serendipity! :)
With the expand button I just thought someone might want to be able to look over all the collections without manually expanding stuff. Now that you mention it, I can see how it and filtering is useful in files with 1000s of collections. And speaking of filtering, I'm not sure where I saw this, but if you want to be able to filter on various collection attributes other than the name I think I could find a way to facilitate that.
@nokipaike
That may or may not fit in with this addon, I'll have to see, but I can always add it into Advanced UI Menus or submit it as a separate addon.
@BrendonMurphy
@1D_Inc has given me a lot of good suggestions for improvement. If it's alright with you I'd like to develop it outside of contrib for a while longer. I feel that I'll have more freedom to make large changes if I don't have to worry about keeping everything really tidy for blender.
Well, at least it will be a nice issue for reasearch)
Good to know. It allows to expand management flexibility drastically, but I think that it mostly fits to outliner, to make Blender 2.8 management better by default.
Thanks) There are multiple realizations of such ability possible. If you will make some, that you can, it can be tested for usability issues. You've got an idea, and this is a good point to start from!
Well, it's also Blender internal problem - M5 is an issue of Quick Content Display system (QCD) integration, that interconnects Autonumeration, Acces system and GUI with workflow semantics, that allow to perform a wide range of constructive workflows, so we are trying to fix it in core.
Lol, that was powerful sensitivity! That's awesome)
Yep, filtering after expand allows to filter everything, filtering works in a wildcard match way, so, basically, it is a very nice solution for managing heavyweight scenes)
I am not sure, that filtering collection attributes is needed, as far as collection's name stands for direct address access, and M filtering provides exactly that.
I am not a supporter of complication unless it is mandatory, so I’d better try to think about it some more.
Widget is also part of proper QCD system. It is related to those complex/constructive workflow problems from my first post.
As it was told, it seems to be impossible to solve it without interconnecting all three parts - Autonumeration, Acces system and GUI, so we really need it, but I agree with you - I don't think, that it can be solved as addon.
At least this particular one.
It is quite simple to solve, but Blender need to have people that performs complex constructive workflows in contact with core development.
I am a concept designer of wide range of tools, so I agree - any kind of research in development is best done in the sandbox, becuse it is hard to predict how deep research will go.
So we are making sandbox development and workflow tests all the time)
Update.
Made changes so that the previous state is restored when collections are un-isolated for the exclude and hide operators (Note: if you manually isolate a collection shift-clicking will restore all).
Added "restore all" operators for exclusion, select, and hide.
I'm thinking maybe it would be a good idea to allow isolation of selection and add in render visibility. Thoughts?
I will continue to implement the other improvements as I have time.
Concerning the QCD system/M5, I don't think it's out of the realm of possibility that an addon could provide a workflow similar to what you describe in your Layer Maniphest post. I may play around with some solutions.
Collection_Manager_1.zip
HI!
A way better, a way more useful! That's next achievement - now we have ability to quickly look through content of set of collections!
You've got a suspicious collection? Now you can check up what is in it - one click in, one click out. A shift-toggle isolation!
However, you can't navigate viewport while window is opened, so it would be nice to have as outliner ability, but I guess you feel how much control it already gives to you)
If you want to send object to some collection - now you can simply check if that collection deserves to accept that object by fast and furious checking it's content. Or find appropriate one by set of simple isolations by that shift-toggling feature.
What do you mean about "manually isolate"? I tried several ways, but can't get it.
Turning off all collections manually except one?
Anyway, Shift-toggling seems to be working great)
First of all, let's us give short names to all that Restriction Toggles mess to make conversation more clean =)
Exclude from layer checkbox - EC
Selectability - SS
Hide in viewport - VV
Disable in viewport - DV
Disable in renders - RV
Holdout - HH
Indirect only - IO
A bit about what we are managing.
I am in doubt about selectability (SS) and Renderability (RV) presence because they are not related to visibility,
but, as far as your addon yet is the only way to check up collection's content by shift-toggling isolation, so their presence can be useful at some point.
Basically, visibility shift-toggling isolation allow you decide if collection deserves turning SS or RV off by checking it's content. And this is good and useful!
There are three ways to control collection's visibility in Blender 2.8 - Exclude checkbox (EC), Hide in Viewport (VV) and Disable in viewport (DV).
We has got just two of them (EC and VV) in Manager™.
And that can be tricky - turning on VV hiding eye will not appear collection's object in viewport, because it can be disabled by DV.
So, turning on VV have to also influence DV, or it is needed to provide DV in manager, or... even both?
Hard to say. But observing and isolation of DV in the same way as VV is also needed, as far as it influences visibility - and requires same type of control.
That's just awesome! You are making a great job, and your progress is astonishing, thank you for this!
I would like also propose some default changes -
Open Manager in expanded state by default. This will allow filtering immediately, and it is easy to collapse if needed.
Remembering it's last expanding state would be gorgeous in case of multiple operations with the same collection, for example sending to same collection 10 different objects one by one, by opening Manager 10 times, and closing it for obtaining viewport navigation.
Make the Filter Field constantly open, since it does not take up much space, only one line. So hiding it does not save much space)
There are solutions in Blender that hides filtering line - for example, in materials list.
But there are the only way in our practice to make list of materials so long, that it's filtering is needed - it is our "All mats to active object" and "Selected mats to active object" scripts, that allow to create entire scene's material library from selected cube to manage materials and copy between scenes. By the way, together with "Mats Unclone", that solves ".001", ".005" mats suffixes, it is a handy solution, that solves all material management issues, but even it's result don't requires filtering so often.
On the contrary, collections are all about long lists of names to filter.
Your filtering is good, so there is no need to hide something that is so good.
I know. That's why we have a long negotiations with core developers about that misconception. So I am not sure if it will be even good for you to spend much time for this.
That's for your consideration.
A bit about Restore buttons naming and behavoiur.
I think your restore buttons also requires for shift-toggling control to be called "Restore" (otherwise, they are "Turn on" buttons).
But it is often needed to look up for entire scene, and go back to setup.
I would like to propose their behaviour in some other way, without shift, taking VV button as example.
I will try to explain:
This way we've got quick toggling switch between global VV=ON and stored VVX setup - so we can observe entire scene and go back to setup just pressing single button. In a toggle way.
2 States GIF:
So next pressing will turn VV=ON globally, and write new VVX to switch between new VVX and VV=ON.
This way we has got ability to reset visibility globally and create new VV layout to switch.
That behaviour will look like this:
5 states GIF:
I think you'll find that if you isolate a collection, close the window, do stuff, open the window again, and shift-click, it will restore the collections to the previous state. 😄
Yep. That one.
Then when you shift-click, it will enable everything.
Excellent idea!
The goal of my addon is to manage collections, not just visibility. Selectability (SS) needs to be there at least to some extent, and given that you make a case for swapping Hide in Viewport (VV) and Renderability (RV) I'm inclined to think that Renderability (RV) belongs in the Collection Manager as well.
As you have stated, this is kind of a mess that blender has given us and I'm not sure what the best solution is to keep things feeling light and quick, but still provide all the needed functionality.
I'll try to figure something out that nicely handles it.
I think it would be better to keep it non-expanded by default, so the user is not flooded with detail. I think I can get filtering to work without expanding, but if I can't, I'll try having it expanded by default and see how everyone likes it.
This is tricky because the window will close if you move the mouse out of it (so it's very easy to make mistakes), even if I change the popup window to not close until you click outside of it (unfortunately this adds a giant useless ok button at the bottom) the usability doesn't get much better because neither allows you to interact with the 3D View. The same problem would exist for a simple operator; however, if I make an operator where the first click saves the visibility/selectability? (need to decide what this should affect) and the second click restores the saved state, that might work. It's not an ideal solution, but it would provide consistent results and allow interaction with the 3D View. Thoughts?
I think I can do that 😄, but unfortunately I don't think I can restore where you had scrolled to. Note: this will make the above point about initial expansion state mostly inconsequential.
Sure. I hid it first because I didn't originally think it would get used, and I didn't know if it would work properly; since this is not the case I'll try having it open by default.
Yes and no. The outliner provides a right-click menu that allows you to perform some actions even if you haven't enabled that Restriction Toggle and it allows easy enable/disable of Restriction Toggles; mine doesn't.
If I provide a way to enable/disable the Restriction Toggles from the Collection Manager then it might make sense to do that, however I would like certain things to be available by default, so I'm not sure if that's viable or not. I'll play around with it.
This sounds like good functionality. But I'm not sold on the highlighting and the highlighting may get out of sync with the outliner, so I'll have to see.
Well, we are in the research development now, so we can freely create any experimental solutions, including overloading the user interface for testing purpose, in order to subsequently achieve minimalistic design by refactoring.
Also, as far as we are addon, we are not obliged to be synchronized that tight with the outliner.
This provides an additional degree of freedom at that point.
Still thinking...
I guess, first it can be "quit without saving changes" prototype button called "Restore Quit", placed somewhere, that will allow to feel the behaviour and test it.
It is hard to say how much useful it can be without having such prototype to test.
Update.
Fixed top row of buttons so all of them toggle between all enabled and restore to what you had. This should implement everything for that, except the highlighting.
Added a way to show hide the restriction toggles (just like in the outliner, but it isn't synced to the outliner).
Added restriction toggles and their all enabled / restore toggles above, so now the possible restriction toggles include:
Exclude from layer checkbox - EC
Selectability - SS
Hide in viewport - VV
Disable in viewport - DV
Disable in renders - RV
*note shift clicking works on all the restriction toggles
Expanded state is now remembered
Filtering is shown by default.
Filtering will now work regardless of what is expanded.
Added basic View Layer manipulation including: enable view layer for rendering, switch view layer, rename view layer, add view layer, remove view layer.
The reason I added View Layers is because excluded status depends on view layer and I found setting up compositing in a sane manner to be a complete pain, now it's much easier 😄
Yeah, the "quit without saving changes" button is a tough one. I'll probably tackle that next.
Collection_Manager_2.zip
Mein Gott, you made it, and das ist gorgeous!
Now we can observe scene and restore what we had just in a few clicks, to compare what is visible with entire scene!
It is incredibly powerful and flexible now with shift-toggling isolation ability, that allow to observe single collection's content))
A bit about what we've done. Here is simple picture.
There are 3 main states possible for any Restriction Toggles Option during scene setup.
By default, in Blender, it was too easy to lose the current setup in order to see the contents of one element or to see the whole scene.
So we made that actions reversible (as toggles), protecting current setup from being lost, providing an additional degree of freedom to scene setup process, which gives us full control over it.
Let's call them isolation toggle (shift-clicking isolation on icons) and enabling toggle (clicking on turning everything buttons)?
I think that's good decision at this point, since View layer became an essential part of scene setup, and your addon allow to overview such setups in way more flexible way.
It is not clean what "enabled of disabled rendering on this view layer" checkbox influences, or maybe I'm lost in the interface to find what it is related to.
Currently I've spotted that enabling toggle ignores nesting elements for EC, other Restriction Toggles Options (RTO?) seems to behave ok.
I need time for testing, but I'm so glad that we already have so much control)
By the way, I wonder if you like what we got.
Are these features useful for your workflow?)
That checkbox controls whether the view layer will be rendered when you do a render or press F12.
Let's say you have a scene with two collections and you want them in separate View Layers for compositing, you have to isolate them in each View Layer, but now you can't see your entire scene. So you make a View Layer that shows you everything, but you only need it in the viewport, not for the final render (and you don't want the added render time). So now you can easily disable rendering of the View Layer with that checkbox (you can also find that checkbox in the View Layer Properties tab under the View Layer panel in the Properties Editor).
Yeah, it seems that's because of the way blender automatically changes children when you exclude/un-exclude. To fix it I had to have it loop through in reverse order when making the restore point and then reverse the history so it would be in the correct order for the actual restore. Thanks for finding this.
I also found and fixed a couple other bugs relating to the enabling toggles and I've tentatively added the highlighting.
Let me know if I've introduced any new bugs or regressions :P
I'm very happy with what we've got. Thanks for asking 😄
I think these features will be useful to everyone's workflow, but yes, I can see myself using many, if not all, of them.
Collection_Manager_3.zip
Removed subscriber: @WilliamReynish
Got it, found it! A wise solution)
Yes, EC enabling toggle work awesome now.
It is very useful, as EC seems to be the only way to check single collection's content regardless of it's nesting level.
Highlighting is also great - now we can be sure what RTO's was turned on manually in order to observe their content, reducing chances to lose initial setup.
I don’t know how tricky it was to do it, but I'm glad you nailed it!
Completely agree. That's just gorgeous.
It seems that our work has the same level of complexity, which allows us to observe problems on the same wavelength, this is a rare luck in development.
Thank you for this)
Slight Update.
Fixed a regression with the enabling toggles where you couldn't look around the scene without losing the history.
Collection_Manager_4.zip
hi, I think we need to expose this to more people. I would suggest we promote this to addons contrib tpo expose to a greater number of people and gain more feedback.
@Imaginer your free to add this to contrib. thanks for the hard work your putting into this.
I'm happy with the maturity that this addon has attained, and so I've added the Collection Manager to the addons contrib repo, per @BrendonMurphy's suggestion, and created a blenderartists page for additional feedback from the community https://blenderartists.org/t/contrib-addon-wip-collection-manager-feedback/1186198. This doesn't mean I've forgotten about the feedback and suggestions here and I still intend to continue development as usual. For now here's a new picture in case anyone's interested, but hasn't downloaded it yet. The current plan is to start experimenting with the "restore on quit" feature next.
Added subscriber: @MetinSeven-1
A small organizational request.
While I with python developers working in sandbox, we keeping version numeration, and also providing some short latest update description in commented section.
For example, 1D_Scripts header for 0.10.22 version:
Can we have version numeration? It is very useful for testing.
For example, I've got that ignoring nesting EC behaviour also for isolation toggle, trying to investigate it in previous versions, but all of them are displayed as 1.0, (not, for example, 1.0.4), so it is hard to be sure what version I am currently running)
Removed subscriber: @MetinSeven-1
Sorry about that. This was taken from a larger project and I completely forgot about version numbering. I'll start increasing the version numbers :)
I'm not keen on having the history at the top of the init file though, it's already got a gpl license header and I find files that start with a huge comment section are hard to read. If it's found absolutely necessary I'll add it, but it's in contrib now so any changes from now on will have git logs.
Thanks)
Yes, we are making history header because our toolsets are multytools in single python file, so it was necessary for understanding what tool was made or fixed in downloaded file.
Git logs are ok for Bollection manager case)
So, it seems isolation toggle also have EC nesting issue, that was fixed in enabling toggle.
Keeping testing.
A question - can you fix EC issue for isolation toggle? I can try to make a video about addon's functionality after that.
I think so. I had tested it a while ago on a simple case and it seemed to work fine, but after your last comment I tried it on a more complex setup and I think I see the bug. So far I have left the EC toggle with the same behavior as in the outliner, but it's proving to be a real pain so I'm going to override the default behavior and make sure that only the checkbox you click on gets activated/deactivated. The default behavior also makes it harder to tell if there are bugs, so that's another reason I'm trying the override.
A video would be awesome! Thanks!
I haven't had much time to work on this in the last little while, but I did implement a suggestion from the blenderartists feedback thread and found a bug in blender's python api in the process. Bug report is here: https://developer.blender.org/T71112
So the next update will have the new feature from blenderartists and then the one after will have a fix for the EC issues.
Update.
Changes:
New collection is selected on add.
Remove collection button has moved to the far right side.
Collection_Manager_5.zip
Update.
Changes:
Hopefully fixed the exclusion toggle's behaviour.
Added the shortcut to the location in bl_info.
Collection_Manager_6.zip
Yes, seems to be working properly now!
I will think about how to demonstrate such features. I guess it will require some complex scene setup.
Thanks)
Great!
Update.
Changes:
Sync UI List selection to active collection.
Fix bug with operators and the undo stack.
Collection_Manager_7.zip
Update.
Added a new "Phantom Mode" to mimic the "Restore on quit" functionality requested by @1D_Inc.
Note: I've put in some safeguards, but it may still be able to get out of sync and do weird stuff if you make changes outside the collection manager while in phantom mode.
Collection_Manager_8.zip
Sounds nice!
Meanwhile, I've spotted that collection filtering works in case-sensitive mode.
For example, "Rim" and "rim" are different search requests.
Can it be changed to non-case-sensitive?
Also, an interesting implementation of a Phantom mode)
I will test it)
I'll look into the case-sensitive filtering. What's your OS, and do you know if your file system is set to be case-sensitive or case-insensitive?
I am not sure that this is OS-dependent.
I use Linux Mint, Arch and and Win 8.1
Testing on Mint
I'm pretty sure it is OS-dependent. See blender has a helper function for filtering by name, UI_UL_list.filter_items_by_name, which internally uses python's fnmatch.fnmatch, and that internally uses os.path.normcase to normalize the string. But here's what's in the documentation for os.path.normcase:
https://docs.python.org/3.7/library/os.path.html#os.path.normcase
So I believe it's case insensitive on Windows, but case sensitive everywhere else. (I'm pretty sure I tested it on Win 8 and it's insensitive. I mainly develop on Arch).
Also, I think blender follows the OS for case sensitivity, so I'm doubtful blender will want to change this.
The good news is that UI_UL_list.filter_items_by_name is pretty simple and I can just re-implement it to be case-insensitive.
So do we want to enforce case-insensitivity everywhere?
Wow, that OS-dependency was completely unexpected)
Well, Blender already use such insensitivity everywhere, and it works pretty much well.
Also, Collections works in a static context, collections filtering is used to navigate in a static context, which means that the semantic meaning of a word to filter is more important than its spelling.
If we need to find, for example "house"-related items, we will be interested in any of them, regardless of the way they are written - this way we are filtering not for just regular string (set of characters), but for a context.
So, yes, I think case-insensitive systems work better for the contextual (high) level of abstraction.
I know, right?
Update:
Fixed a bug with filtering where it wouldn't pick up a name change until after you closed and recalled the popup.
Made filtering case-insensitive.
Collection_Manager_9.zip
@1D_Inc Interesting UI tweaks by Bookyakuno over on blender artists: https://blenderartists.org/t/contrib-addon-wip-collection-manager-feedback/1186198/21 (a second version is a couple of posts down).
I'm thinking it might be a better idea to combine all the buttons on the row under the view layer like Bookyakuno did (although ordered more like the second version), but as to the collections in the UIList I think it would be better to keep all the visibility controls next to each other in a group. And I'm not sure that displaying the number of objects in a collection is actually needed, or at the very least it needs to be more explicit telling the user what that number represents.
Thoughts?
I think it is too early to compress the interface. It looks weird.
Your design is now more understandable, accurate and consistent.
Interesting, that he puts VV visibility on left side. This isstructural display misconception
Here are our RTOs (restriction toggle options)
About ability to place some of them in vertical linear column:
Also, does Bukyakuno's design just seem to ... duplicate the outliner?
We don't have a goal to "put proper outliner to M button", so we are "asking for proper outliner" and "making collection management addon".
I'm currently busy with global proposal about Collections and QCD content management systems .
How to define if outliner is designed properly? It's simple - the more proper the outliner, the easier CM addon will be.
Currently CM addon is prety much heavyweight, but this means that we are solving too much problems, left over core development.
Wouldn't it be better to ask core developers just to finally make a proper outliner rather than persistently making our own?
In the end, we are all interested in allowing Blender to be used out of the box)
I was mostly thinking about just moving the add collection operators and phantom mode operator to the top bar and condensing it like this (not touching anything else layout wise):
This would reduce the amount of vertical space used and maybe make it feel a bit cleaner, but if you think it's to early for that I'll leave it as is. The other thing I was considering is the greying out of collections when they're hidden in the viewport.
Now that you mention it and compare them directly, I can see a lot of similarities.
No, I'm definitely not trying to replace the outliner with this, but by the same token, a proper outliner wouldn't negate the need for a collection manager. And yes, the less hoops I have to jump through to get the functionality I want in the CM addon the better.
Well, if we are faced with the need to almost completely copy the outliner into an addon for convenient collection management, this proves that the collection management system in the Blender has serious problems.
We have got very good solutions to problems in the course of research that deserve implementation at a core level. I think your development deserves that.
As for the addon, this will greatly facilitate it, allowing you to get rid of at least the phantom mode. We'll see.
I think it’s worth a try, so I will take on this task.
Another task to solve.
While working with complex scenes here is a problem to define what is hidden in order to manage and observe hidden content.
We has got RTOs buttons, that allow to temporairly show entire content of a cathegory via single LMB click.
Is it possible to make another behaviour for Shift+LMB click to invert current cathegory state?
Here is a picture:
I know that it can be tricky for VV and DV, since they are structure dependent, but any kind of invertion implementation will make it possible at least to test such a solution.
I think so; it should be fairly easy. I'll take a look at it soon.
That would be awesome! Thanks)
An else one feature, that can be interesting.
Filtering by name gives us strong static contextual separation. I think, dynamic contextual separation support is also needed.
That means, that it would be nice to have ability to filter collections by selection (the "Filter Selected" button) to review the list of collections that contains current selection. Expand/Collapse button resets filtering.
Nice example - select all objects that forms car, filter list by selection to be sure that all selected objects belongs to car-related collections, review content of non car-related collections if filtered list has got some.
Filter collections by selection should be possible, but I'm not sure about having the Expand/Collapse button reset filtering. I'll look into this too.
Yes, that's one can be doubtable, but this is only an assumption.
There have to be some ability to reset selection filtering, it can be a second click on "Filter Selected" button, which makes this button work in toggle mode with blue highlighting.
By the way, I noticed that this cross does not clear the filter field.
Can you confirm?
I like this idea better. It'll be more in line with official blender if I add a toggle button to the right side of the filter bar.
Yes. I've noticed that too. But it seems to work on other UILists, so I'm not sure if it's a blender bug or if I'm missing something in my code. I've also noticed that filters on things like vertex groups or materials update immediately, but mine only updates after you press enter.
Update.
Changes:
Added full view layer support to restoration/isolation toggles and refactored their histories to facilitate this. (Ironically, blender seems to have a bug in 2.81 with view layers and toggles)
Fixed a bug with histories not being properly saved/restored in some toggles.
Added invert functionality to the restore toggles when you Shift-Click.
Updated Tooltips to be more consistent and explanatory.
Collection_Manager_10.zip
Aww, that's amazing!
I alredy like it)
I love how clean the result is from the inversion of structurally independent EC operations.
But it looks like I missed some control clarity - we has got Shift action for isolation ability, it is easy to remember, but inverting ability is a separate type of behaviour, that is not perceived as an "alternative shift operation".
So, maybe it will be better to set Control instead of Shift modifier on inverting ability, I will try to investigate whether my premises are reasonable, based on amount of mistakes I will make during tests.
Meanwhile we are trying to investigate why Collections are so hard to manage by default.
In fact, to depict that fact to make it clear, to see the essence of the problem.
We said earlier that there are too many RTO options per se, so I tried to make a scheme of their typing and relationships.
And yes, here we go (I also decided to rename RV to RR):
From a business point of view, any management system is characterized by at least two parameters
The dependence is almost linear - the simpler the system, the more effective its management, and on the contrary, the more flexible the system, the more complex and multi-level management it requires for effective circulation.
It also directly, through speed, affects the amount of product produced.
As far as I can tell, when creating the Collections system, the main task was to provide for the maximum possible flexibility of the system.
Flexibility was taken as the only good, but such a rating system is somewhat far from practical.
This is why we have never encountered such complex systems in other software, and therefore we need an effective collection management system.
That is the reason we are here.
I wouldn't worry too much about using Ctrl/Shift, they're just modifier keys. If we had it so that you did Shift for EC and Ctrl for VV then that would be bad, but they're used consistently within they're own little groups. I'm also thinking that I'll add an Enable/Disable All Children function to the isolation toggles using the Ctrl key. Currently blender does that by default for EC when clicking, and while I find they're current implementation annoying, I think it's useful functionality to have.
For sure, nested isolation is needed, but suddenly there is a default outliner collection Ctrl+LMB isolation ability.
It works pretty much weird, as far as it works only for 4 RTO's (marked as dark blue on typing scheme), works as single LMB for EC in inverted way and loses current setup during unisolation, so I thought that it have to be reconciled.
It's a question of unified behavior.
Previously I thought about suggesting it like this:
Thus, the Shift-containing combinations apply to both isolation modes (simple and nesting), Ctrl allows to control entire level, Alt playes negative, alternative role.
But the problem is in differences of stucture-dependent and structural-independent RTOs behavior.
Im still trying to design proper behavior for invert action of VV and DV visibilities, it is hard as they are structure-dependent.
For EC nested isolation is possible in pure form, starting from desired level, so its behavior is nice and predictable.
For VV or DV it will isolate entire collection starting from core, and I can't say it is bad or useless, as it will give ability to observe the entire collection branches.
Since we have three types of visibility control that behaves differently, it is hard to say if it will work properly, or make any kind of predictable design.
It seems, such solutions can be only tested on practice.
What do you think about this?
There were another thoughts about unified behavior - this one don't include Alt, don't contain toggle action for Ctrl, but allow to add or remove some branches to/from current setup (D and E pictures are changed).
I am not sure if it can works similar to current Ctrl+LMB isolation in outliner.
We are trying to design a viable management for a complex system, so here we can easily create a sophisticated system or miss something.
Yes, your second one is what I was planning, current setup plus Ctrl-click turns nested on/off. I hadn't thought of picture C, but it looks useful, so I can look into adding it after D and E.
Here is a dilemma.
If to make it as an isolation (other collections will temporarily turn off), it will make impossible to add/remove nested visibility to current scene setup (outliner-compatible behavior).
If to make it as local nesting control (other collections will stay intact), it will make impossible to check up entire collection's content in toggle way (simple control behavior).
Support for both - more complex shortcuts, or maybe checkbox.
I can't solve this system at the moment.
No, we can't solve these kinds of usability problems in the abstract without implementing ideas, testing them, and then further refining them. I'll put out an initial implementation of the nested toggle and then we can go from there.
As for the collection chains of VV and DV visibilities, I agree, invert is going to be a problem. I forgot about the collection chains when implementing it for those controls. And you're right, their structure makes it hard. We'll just have to try to find a way to make it as predictable and useful as possible, but it may end up not being very useful for those toggles.
I also added invert to SS and RR, and they share the chain problem. I'm not even sure if inverting them would serve any benefit.
Well, okay. In any case, there is only one way to test the solution - practice.
About SS and RR - we are trying to make a solid system, so it may not be effective in all aspects, but it definitely should be predictable)
Chaining and nesting management solutions are always challenging.
I will try to design proper invert behavior for chaining RTOs.
Yeah, sounds good. I'll think on it as well.
After all these dilemmas, I tried to create an action map that could contain all the components for any possible action.
It looks like this, can be interesting to see.
Still thinking about invertion of Chaining RTOs.
I think that this task can't be solved mathematically, so we can't make its behavior better that it is now.
From the usability point of view inverting Chaining RTOs (like VV or DV) gives us an idea of if the scene has visibility disabled root collections, that contains objects, so let it be like this.
Not sure I entirely understand your action map (all I could find with that name was Cathy Moore's business training, which I don't think fits?), but it's sorta interesting.
And if you think the visibility RTOs are good like this for now then I don't mind leaving them, but I don't see any value to inverting things like SS or RR, so maybe we should remove their invert functions?
Also, what's a good ballpark for heavy collection use in a project? 1000? 2000? More?
The problem is to determine possible situations that we may encounter mathematically, determine our opportunities, and prioritize opportunities over possible situations.
In this picture, I tried to collect all the possible options that can be involved in some action with the collection. To map what we basically can do with collections. To define our opportunities.
Inverting is useful for any kind of massive actions, for example to make invisible (unselectable, unrenderable, irradiantive, masking) 490 collections of 500, by setting up 10 collections and inverting scene state.
Inverting SS and RR (and other Chaining RTOs) are useful for linear (unchained) collection structure (a scene of 500 non-nested collections that is easily possible).
We provide predictable opportunities, which gives us confidence that if we encounter such situations, we will cope with them.
There is no need to remove the inversion locally, since it does not conflict with anything, and literally, don't take up space.
We are confidently working with 4000-8000 layers in AutoCAD just daily.
Blender can handle up to 50,000 objects, but with current problems with the default management system, handling even 50 collections can be quite a challenge (got a collection - can't check it's content without losing scene state).
The problem is that the number of collections in projects is growing not because of plan or free will, but because of situation.
Thus, when performing complex projects at some point, the user simply faces the fact of the need to manage hundreds/thousands of collections. Just like in AutoCAD, just like everywhere else.
We are currently working on expanding management limits, so the number of collections for reliable management depends on our success.
I think, if we will be able to handle 200, we will be close to be able to handle any amount, as far as rules will be the same.
The limit of 500 fits into the situation, but it looks like an extreme case.
However, It's like copying 50 assets with 10 collections in each into a single scene. Can’t say that such a situation is far from being possible.
I think we are really missing the ability to clone a View layer.
You make some good points, so I'll leave the inversion alone.
I'm interested in this so that I can keep an eye on how well the collection manager performs under heavy, but realistic, loads. In case you're interested, here is a little script I made to quickly setup thousands of collections to test with. It doesn't have a hotkey so you'll have to call it from blender's operator search menu (just typing 1 should bring it up) or call it from the python console (bpy.ops.view3d.add_thousands_collections).
add_thousand_collections.py
It turns out that collection operations like isolation in blender are currently very slow with 1500 collections in a flat list, but if they're in a nested configuration with each collection only having 5 or 6 children it's much faster.
This seems to be a blender problem, not a problem with my addon.
Blender seems to be having problems with View Layers and their Restriction Toggles at the moment, so I'm going to leave this alone for now. If it's needed, I'll look into adding it when those are fixed and they have more stable and consistent behavior.
Well,
Before entering the boss’s room, the very first desire is to save the game’s progress.
Before editing a complex setup of multi gigabyte scenes containing thousands of collections made by someone, the very first desire is to make a copy of the setup for modifications, leaving the original as a backup.
This is the basic self-preservation instinct for survival in complex projects, kind a strange to hear silence around this)
I almost finished the alpha version of my Collections proposal, I will include view layer copy and perfomance problems in it.
It's nice that we noticed them on time.
Ah! Cloning the View Layer is how you'd save the collections' view state. Good Idea!
But that won't work until the View Layer bug is fixed (see below). I don't want to support it with a hack unless absolutely necessary.
I've also submitted a bug with regard to RT performance for things like isolate and enable all.
View Layer bug report: blender/blender#72084
Performance bug report: blender/blender#72086
Yes)
View Layer concept fits so beautifully there, as if it was created specifically for this by design)
Well, I can see, that some of your reports were claimed as feature request, not a bug.
It's ok, there is the difference in bug detection:
So most of issues that we can face during making CM can be claimed as feature requests.
This is normal, because they are considered from the point of view of the design of the current system, so, at first, we need to offer a system update that will better satisfy massive production needs.
Some issues may require deep core changes, so there must be a deep reasons for this.
That's why I preparing global proposal, that contains complete description of a robust collection management system, that will hopefully clarify the reasons behind the solutions.
Meanwhile, it's nice that you make such reports, they will be useful in any case.
hi, It's time for some decisions.
Do we go with what we have now for Blender 2,82?
Given there's some "Limitations" that may or may not be resolved in the near future or for quite some time, we can document these.
It's easy to add a warning "beta - see preferences" and describe the limitations there.
"May not work with view layer visibility"
"May take time to compute on scenes with over 500 collections when hiding visibility"
It seems some of the issues are somewhat outside of the addon, being limitations in how it can work with Blender's internal structure. These issues are in Blender also without the addon.
So what to do here?
Initially I was looking for a replacement for the older Layer Manager addon. We had this in Blender from 2.4x to 2.7x to fill a gap, improve usability and offer functionality until we moved on to collections.
Now we have CM, offering new functionality and usability that may end up being all we have in this area for 2.8 series. I would like to see it in release sooner rather than later. By exposing CM users will have an opportunity to use this new functionality and provide feedback that may help the future decisions.
Well, I think it is kind a political question in some way.
During CM research we discovered a series of serious issues considering collection management design and behavior at the Blender's core level.
I am currently preparing global Proposal about content management systems in Blender, generalizing all of such issues, it takes almost all time.
This way the Proposal supports CM development and CM proves the Proposal's concepts.
The Proposal's alpha is almost ready, so I plan to launch it next week for consideration by the developers.
Do we have this week?
About feedback - the subject area of the addon is so complex that it took us a whole year only to formulate the basic concepts that need to be satisfied for the needs of massive production.
It is quite difficult to find users who can be involved in production of such a scale to be interested in solving problems of this level, and we still have a nice ideas to realize, that allow to form a solid core of an addon (like filter selected, nesting control, etc).
Anyway, we made a nice progress considering collection management, and we already have realization, that solves some critical issues.
Do you like the solutions that CM provides?
@1D_Inc From what I understand, from talking to @BrendonMurphy in irc, we have until the end of bcon 1 (Dec. 12) to submit it for release, but he would prefer it to be submitted a little earlier (around Monday, Dec. 9) so that it has a chance for a little review.
I'm thinking that we're pretty close to having the basic features for effective collection management implemented, and that what we have would be very useful to people. For me, the only must-have feature for an initial release would be the basic toggle children functionality (which I've implemented, but not pushed yet). Is there any must-have functionality you can think of for a first initial release?
I'm still undecided about whether it should be included in this release, so I look forward to your thoughts and your Proposal. And if it does get submitted, there's still about 8 weeks for polishing and bug fixing just no new features for 2.82. However, we can continue to develop new features here (I'll upload zips), just not add them to the release (I can setup a separate git repo for further development and then include new features for 2.83)
hi. If you can add and push the toggle children function to contrib. thanks.
Both @1D_Inc and yourself have already invested significant time in this. You've both worked well during the design process and showed a willingness to seek and solve issues as best as possible. Currently I believe you have done near as much as is possible to ensure a valid and useful tool. I'm very happy with the results and as discussed in irc, my feelings are we should release with 2.82. It's obvious that your prepared to address any issues over the coming release cycle progression. We can only put forward the best that we can. I'm also aware of the design limitations through no fault of the addon. again, we are putting forward the best we can.
If you can get the final committed to contrib, we can work forward from there.
Hi. I think CM can be commited to the contrib.
Some conditions I would like to propose.
It's better for familiarization, it has a lower entry threshold, also looking good enough. There will be no problems for users to start using compressed version if it will be made in further.
I thought about placing the EC on the left in a straight column, as it is global and non-chaining, but it will not change much, and need/can to be tested later.
It is an experimental behavior, so realization is currently unclear, and it also contradicts default behavior. I'm not sure that we will find the best implementation by the deadline, it will take more time for additional workflow research.
We know that we need it, but we don’t know how it will work best. I would suggest postponing the implementation so that users are not used to a dubious solution. Global shortcuts/behavior is needed to be discused with core devs,
during the discussion of the Proposal. It will also take more time.
I think it deserves attention, because (on my opinion) it can be made to the Dec 9. Are you ok with such a plan?
@BrendonMurphy
Ok, I've pushed the basic toggle children function to contrib. I didn't push immediately because I had been thinking about including another commit in the push, but it isn't finished and I may not include it anyway.
@1D_Inc
It's already in contrib. It's the 2.82 official release we're looking at now :)
Yeah. No arguments there. I do like the compressed version, but that can come anytime.
I think this needs to be in the release. It's behavior matches what's default for EC in the outliner and it's really useful.
This I think is experimental and needs testing and I would prefer to leave it out of the initial release.
I think I can do it. No promises, but I'll try.
Well, okay then)
By the way, here is a picture about how Action map is supposed to be used.
Currently, each action that we have provided or plan to provide can be associated with it as a combination of components.
This does not mean that we must provide all possible combinations - if we have a map, this does not mean that we must visit every village.
This means that we can predict a better route in further.
Update.
Changes:
Add basic toggle children functionality.
Add Filter By Selected functionality.
Collection_Manager_11.zip
It occurred to me that the isolation toggle should be highlighted, the same as the enabling toggle, when there is history to restore. This makes it much clearer what state you are in and will help us to spot any bugs that may crop up with how isolation is handled. Because this is a somewhat large change I wanted to have it tested here before committing, so I'm posting a zip with the changes here.
While testing this I found that the SS RT did not chain properly, so I've also fixed that.
Collection_Manager_Isolation_Highlight_Test.zip
@BrendonMurphy found a bug with phantom mode with the isolation highlight test. Please change line 1169 in operators.py from:
phantom_history[rto+"_history"] = history.get(view_layer,
- [ ]).copy()to:
phantom_history[rto+"_history"] = history.get(view_layer,
{}).copy()A very nice idea with highlighting!
Actually, didn't know that this is possible.
Also tried selection filtering. Indeed, it is as useful as I imagined - now we can check the selection for consistency!
I like how it discovers object's cumulativity (if it is placed in several collections).
Definitely love it =)
Replaced my token.
As it turned out, fire here means "Burninate", instead of "Hot!", sorry =)
hi, this is now ready to land.
@Imaginer first remove from contrib, 2nd add to release same as brush menus.
Any issue let me know and I'll commit for you.
Changed status from 'Open' to: 'Resolved'
closing as resolved. any further updates may happen as general maintenance. Major new functions and we can create a new task.
tagging: #71560
Changed status from 'Resolved' to: 'Open'
re-opening as a design task for any future changes and discussions. at the request of @Imaginer
Thanks @BrendonMurphy
Thanks!
The toggles are actually just operators that are icon only (emboss=False), so they can have the same features as any other operator.
Wonderful :)
No problem! I actually didn't know what "Burninate" meant until I looked it up today (for anyone wondering, basically "Kill With Fire").
I had just thought it meant something like "You're on fire!" i.e. doing great, so you learn something new every day.
It seems, I found a bug - disabling Phantom mode removes all RTOs from GUI until new subcollection is created.
Can it be confirmed?
Currently, a Phantom mode is a hack, a "temporal clone of a Vew Layer for modifications" that we made because we can't clone View Layer for modifications legally, because cloning View Layer in a regular way requires some hacks.
@1D_Inc I can't seem to trigger it on my end. From your gif, it kinda looks like it's getting an error around when the exclude checkbox would be drawn and so it cuts off everything after it too. Are there any python errors in a terminal?
Yes and no. Yes, cloning the View Layer and switching to a new "Phantom Mode" View Layer might be a bit easier and more expressive than manually saving it, but all the toggles histories are being saved as well. The real hack with Phantom Mode, and all the histories, is that regular blender doesn't know about them, and so could corrupt their states.
Wow, yes, actually, writing. 2.82, linux mint
Yes) Also, I mean that the ability of making legal clone of View Layer can replace Phantom mode by its scope.
If we will get those changes in API that will allow regular cloning a View Layer, Phantom mode can be realized as a regular rewritable View Layer called "Phantom mode" or, better " CM= [View layer name used as base for creating temporal state]".
We made such a thing for transformation orientations - instead of using default feature that makes a lot of separate transformation orientations, we made an addon that works with single rewritable transformation orientation, called "1DTEMP".
This way will be able to store our temporal view layer data legally.
I think it will be ok to temporairly remove a Phantom mode if it will take too much efforts to make it work reliably, because we can explain the necessity of VLayer cloning feature concept in words.
@1D_Inc Actually, it turns out that bug was already fixed in master, I just hadn't released a new zip yet.
I don't think there's any need for that. It's had a couple small hiccups, but overall I think it's been remarkably stable.
Changes since version 11:
Add isolation toggle highlighting.
Fix bugs associated with isolation toggle highlighting and Phantom mode.
Small cleanup of a missed print statement.
Collection_Manager_12.zip
Installed v12 (1.8.1)
I think, it may be better to name them respestively to direct versions, or maybe both, like
Collection_Manager_1-8-1_v12?
This will allow to see what file is installed)
Phantom mode now don't disable buttons, but disables their functionality.
Launching addon - ok, entering PM - ok, exit from PM - every option is broken and unaccessible, but global RTOs (enabling toggle) are ok.
Update:
Fixed bug with toggle buttons broken after leaving Phantom Mode.
Fixed bug with rto history not being properly restored after leaving Phantom Mode.
@1D_Inc How about this for naming?
Collection_Manager_13_v1_8_2.zip
Yes, now it works nice) Thank you!
Much better! Now we can be sure which version is installed.
Can I ask you to put a BA feedback tread link into description?
https://blenderartists.org/t/release-addon-collection-manager-feedback/1186198
Also, what about Ctrl+Shift respective nesting isolation toggle? Can we give a try?
Done.
Yes. I'll add it to a future dev branch and post a zip here. I can't promise that I'll have time over the next couple days, though. I'll just have to see how things go.
Ok, for sure.
Well, here is a huge problem of a system type definition .
The problem is that Collections system and Layers/QCD are completely different types of systems .
In 2.79 there are only Layers/QCD - so there are only RAM system, that was designed to be a RAM system and works nice like a RAM system, just like any Quick Content Display system (QCD).
The old Layer manager add-on was an attempt to remake RAM system into some limited HDD system, giving static names to dynamic context slots.
You know, sometimes HDD systems in computers are used as a RAM, for swap files, so there was a reverse example, and this is always a compromise solution.
At some point a lot of people started thinking, that Layers/QCD is nothing more than a bad limited HDD system, because they never used it properly - for handling dynamic context during complex multi-referenced modeling in combinational access way, as far as Layers/QCD was the only system for making scene setup - that is completely different goal, that differs from complex multi-referenced modeling.
So a strange thing happened in 2.8 - HDD (Collections) system replaced RAM (Layers/QCD) system, instead of adding HDD to a RAM=)
Here is an explanation between differences of purposes of those systems, and how they are usually combined together.
https://devtalk.blender.org/t/layers-maniphest/6578/115?u=1d_inc
In this topic, we are trying to improve the Collections system so that it better matches its main goal - the complex scene setup.
@1D_Inc Here's the test of nested isolation. It's implemented for all the toggles.
Collection_Manager_future_dev_1_9_0.zip
Oh, yes, it works just awesome)
Now we can isolate not only single collection, but also entire branch, or subbranch of collections in toggle way)
So, we has got the ability to explore collections scene setup in much more deep and flexible way)
Also like shortcuts, I think it was a nice idea to assign simple isolation to Shift+LMB, nested isolation to Shift+Ctrl+LMB, and control nested to Ctrl+LMB.
I tried it, it feels natural, and, on my mind, is pretty much easy to remember, as complex action requires more complex shortcut, and everything, that contain Shift is about isolations.
It also makes me doubt Shift + LMB for enabling invertion, because we are definitely forcing Shift for isolation actions.
That's why I was proposing Ctrl+LMB for enabling invertion. This is not critical, but will look more appropriate in my opinion.
Currently it takes some additional memory to remember, that Shift key modificator behaves differently for local and global RTOs.
Do you feel the same?
Excellent! :)
Good. I agree.
I don't really have a preference. Something else to think about is that currently everything that uses Shift as a hotkey remembers history, while if you Ctrl-Click on an isolation toggle it's a permanent action.
A good point)
I will think about relevancy)
Well, anyway, it seems, we has got free CTRL+LMB shortcut for Global RTOs.
How about to fill it with something breakthrough?
As you may know, currently it is pretty much hard to predict what will be rendered after you press the render button, because RR state is totally implicit - there is no way to see it in viewport.
From other side, VV is totally explicit, as it is dislayed in viewport, and also is controllable by hotkeys there - H, Alt+H, Shift+H hotkeys allow to setup VV states directly.
But VV is not renderable at all, excluding preview render, so VV is temporal by it's nature.
So, RTOs like RR has got only renderability, while VV - flexible setup and display without any influence to renderability.
I think, that would be nice to have ability to view, setup and control implicit RTOs (RR, HH, IO) with states of explicit one (VV, DV, EC).
The workflow I propose is pretty much simple - setup scene visibility, and then just copy it to renderability to get predictable result on final render.
And all we need for this is the ability to copy RTO values between columns, and I think it is nice ability to fill CTRL+LMB shortcut.
Basically, this is the Photoshop eyedropper tool used to manage global RTOs setups:
I can see here a couple of troubles, for example,
But, in general, I think the ability to see just immediately in viewport what you will get after pressing render button deserves that research)
What do you think?
I like breakthrough things. :)
There's some interesting ideas here.
I think having the option to copy is a great idea, but I wouldn't use highlighting for it. Copy - Paste is such a quick operation that you don't need an indication, plus it could be confused with a history state.
I don't see a use for swapping, but if you have a use for it I can add it. Swapping brings up another potential issue - applying states. Currently, when you isolate something, or do an enable all, it sort of locks in the history of the last state. And while you can clear this by clicking on a toggle, it would be nice to be able to use e.g. ALT+RMB to forget history/apply state. Also, with the multi-color highlighting, it would be nice, but I don't think it's currently possible. And with the "Tracker Curfew" in effect I doubt a patch to allow it would get accepted right now (but if you do come across a way to get multi-color highlighting, let me know).
For this, I think it would be better to have a "show what will be rendered" function, rather than copying and pasting. The problem with this, at the moment, is the application to objects - like you mentioned. Objects aren't really supported right now, but they may be in the future. For now I would suggest the Collection Manager should only operate on collections, except for special cases like removing collections with objects, and if/when objects get proper support we can include them in things like "show what will be rendered" and copying.
On a slightly different topic, I need to spend some time bug fixing and polishing what will go into 2.82, so I won't get to the stuff above for a bit. But I think things are developing nicely. :)
Thanks)
Yes, I also think it would not be critical, because such kind of actions are too quick.
Aw, let me explain this technique.
The difference between copy and swap actions is the same, that between destructive and non-destructive actions.
Copy action is a single direct action = setup > copypaste.
Swap is a double action = swap to see > setup > swap back.
Here is a scheme with all possible actions with copy and swap.
As you can see here, swap allow to make changes to implicit RTO, keeping explicit RTO values untouched:
Well, we will do our best - I will propose this and explain the concept behind it.
Well, that is a nice idea for separate mode, I guess)
But the goal of copy/swap is a bit deeper, than to see what will be rendered.
The main goal of this tool is the ability to observe and edit implicit RTOs as explicit RTOs, including such unobvios things like HH and IO, and, of course, without loosing an actual setup, due to the swap ability.
I understand.
Is it possible to reach objects RTOs, if to make a separate addon, that contains only global RTOs with copy and swap abilities, for concept testing purposes?
We will need some realization as proof of concept at some point, just to show that it would be useful to have such abilities.
For sure, it is going great!
Since copy/swap is a sandbox research, we can't have any deadlines for that, unlike the situation with 2.82.
So the only thing I would like to know if you like such kind of idea.
I made a gif about swap action.
Hope it will explain the mechanics behind it.
We are making implicit setup temporarily visible with first swap, then editing setup while it is visible, and then deploying it back with second swap, keeping things non-destructive.
Thanks. That clears things up nicely. I'll put swapping on my new features list.
Thank you)
Update.
Unless any major bugs are found, here is a zip of the version that will be in the official release of 2.82. 😁
Bugs fixed/polish added since the last zip (v1_8_2):
Fixed the popup window’s auto-sizing when it’s first opened.
Fixed an error when popping up info notices.
Simplified the remove operator.
Fixed a minor error regarding selection.
Thanks to everyone who provided feedback/reported bugs. Now it’s on to 2.83. 🙂
Collection_Manager_14_v1_8_8.zip
Updated the task description here to better suit a Design task. Let me know if it works or not.
Such a gorgeous news!
So much work has been done here.
I like new description, so accurate, short and consistent now)
I would like to propose to add a appropriate hotkey modifier to functions description, because most of such functions can be accessible only that way.
Maybe, as separate list of shortcuts in Shortcut - Description form to keep basic description clean, like that:
Local RTOs:
//LMB - simple collection on/off operation
Shift+LMB - single isolation toggle
Shift+Ctrl+LMB - nesting isolation toggle
Ctrl+LMB - nesting control***Global RTOs:***LMB - Global enabling toggle
Shift+LMB - Global inverting toggle
[ Ctrl+LMB - Copypaste column values ]
[ Alt+LMB - Swap column values ]//
[...]- planned / to do
Such list will be also short, useful, pretty much consistent, and will allow new users to dive into the addon's functionality.
About bugs - I keeping testing, but already found that nesting local isolation on Shift+Ctrl isnt working on 2.82 beta, it makes just single isolation.
Can you confirm that?
Good idea. I'll add that.
Probably my fault. The latest zip (v1_8_8) I posted is what will be in 2.82 and doesn't include nested isolation. And I forgot to include the zip for v1_9_0, which does include it, under the current download section of the task. But v1_9_0 and any zips with new features will be for 2.83 and beyond. I'll update the task to better reflect this.
If you are referring to v1_9_0, I did find a bug in it regarding isolation and I hope to have a fix out soon.
Okay.
About description - it can be a bit unobvious what are, actually, local RTOs, global RTOs, expansion operator and so on, so I guess it would be helpful to mark with frames and sign them on a special addon's screenshot.
Maybe it will be better to put clean screenshot with downloads in the begining of a description before overview (to see it without scrolling, as far as it is a face of the the addon), and add a special screenshot in the end, righ after shortcuts, to explain the anatomy of the addon.
How do you think?
Let me try it with having small cutouts next to the categories and see if that works. If that's clear enough I don't see a problem just having the screenshot at the bottom with the downloads.
How's that?
Well, here is a problem - a lot of things are visually doubling each other.
For examle, all RTOs, select object collection operator versus filter collection by selection, and all those 50 shades of gray crosses over inteface ...
I think it is important to show exact location
I would like to propose it that way
I'll admit, that looks better. I'll add it to the task description with a few tweaks, for example, what you term "filter by name" actually inverts the filtering.
Yes, with this screenshot it looks more loud and clear)
I am not sure about red Invert filtering, because we have invert actions that works in other way, that can be confusing.
Also, it is name-related one, so it is more like "search by name", or "find by string" or maybe simlpy "search" or "find"?
Nope. It's a built in blender function we get for free and when you press it it inverts the UIList's filter. So for example if you're filtering collections by selected objects and you press the invert filter button it will show you all the collections that don't have the selected objects. The text field before it is what filters by name, so maybe it needs some red text in the image too.
Aw. Maybe, I got something wrong, I will check it)
By the way, I've seen a request for "find and replace" renaming function for collections, because new default find and replace works with objects names only.
It can be fixed one day, but anyway such functionality can be interesting in terms of collections management.
No worries!
Not sure how exactly that'll work, but I'll add it to the list of potential features.
Yes, it will be a nice place for it.
At least, it deserves to be kept in mind this way)
Update for 2.82:
Changes:
Fixed tooltip for local render RTO.
Fixed bug with isolate/restore state when there is only one RTO to restore.
Collection_Manager_15_v1_8_9.zip
Cool!
Meanwhile, we are trying to hack cloning view layer concept, to define possibility conditions and obtain some kind of a realization in research way.
It is tough one, so we decided to make it separately from CM addon paradigm at this point.
I will tell, if we will get some nice results)
Also known issue - view layers are not preserved when copying a scene.
Maybe, problem of copying view layers influences a bit deeper...
Cool. Sounds like you'll have an interesting time ;)
Let me know what you find out.
Update:
Official addition of nested isolation.
Integrated fixes from the 2.82 release branch.
Fixed bug from previous 1.9 version with setting RTO isolation status.
This will be going into official blender 2.83+:
Collection_Manager_v1_9_2.zip
Hooray!
That's awesome news)
Hard to say, we are also trying to get Blender 2.8x selection finally fixed.
It is completely offtopic, but here is a solution we've found .
It can be interesting since it influence almost any kind of mesh editing.
Continuing our view layer cloning research as well as part of a MASC addon
https://youtu.be/REfhZMdqV8k
Remember that we have v1.8.9 in 2.82 already. It's just the new development that's now all going into 2.83+. But yes, I think what we end up with for 2.83 will be a real powerhouse. :)
Yes, that is interesting. I'll have to remember that. And it occurs to me that Ctrl-Right Mouse (extrude to cursor) would benefit from being a press event as well.
Looking good.
Exactly! But unfortunately, it breaks lasso selection.
I using it with press event, and thinking about proper proposal. Maybe, delay threshold to lasso.
Thanks. Since QCD system is almost completely destroyed, and there is no more ability to control slots combinations with perception speed providden by the subitizing ability, people are trying to retrieve combinational control even with such unobvious way.
It is pretty much weak concept, in comparison with a proper QCD system, since you cannot control what is actually hidden in view layer (by obtaining combination information directly, without scrolling all that lists in outliner), and useful view layers number is very limited (more than 5-7 is hard to use, remember and control), but such an implementation at least raises the issue of copying view layers to explore.
Ah, I see. Try setting it to a release event then. That should work. I actually don't know why the click event is causing trouble; I suspect it's a bug.
I'm actually working on a test implementation of a QCD system for the Collection Manager in a separate branch. Thank's for reminding me, I'd kinda forgotten about it with everything else going on recently.
@1D_Inc Here is a test implementation for QCD to try out. It has hotkeys and allows you to manage QCD Layers to some degree from the QCD tab in the collection manager. This is just a basic proof of concept for now.
Hotkeys:
Collection_Manager_QCD_test_v1_0_0.zip
Wow.
I didn't found more examples of successfull implementation of such a system in entire industry.
A QCD system research? I think it will be definitely just as epic as tough one. I am glad to hear even that it is going)
Blender 2.8 already have a QCD system (when pressing number corresponding collection is displayed)
Everything that has a limit of 20 - refers to the QCD system (hotkeys, autonumeration, widgets, etc)
There are ruins, but they works, and it has got some huge inconsistences.
For example
Those things cannot be fixed with addons, it is a core workflow design problem, and it is completely separate task, considering dynamic context management.
All I can propose at the moment is to try to fix M5 issue, to make objects sending to a collection that is invoked by pressing correspondig number in CM.
That will help to solve that issue, that just ruins our workflow.
Test example - open a new scene, create a cube and 6 simple flatlist collections.
Disable CM addon.
Select cube, press M5 - cube has gone
Press 5 - collection 5 appears, there is no cube
Press 4 - collection 4 appears, here is a cube. It has gone to a wrong collection.
Correct behaviour should be - press M5 to send a cube, press 5 to view collection to see a cube.
That's M5 issue.
You currently made a separate"layers", that can contain objects, but it will be hard to control them, since such "layers" is a completely separate paradigm.
QCD is better to build on a collection engine - it already works like this (some collections has got predictable numbers, assigned by autonumeration, you can access them with those numbers, and it is ok), such a system is just needed to be polished, clarified, specified, and get proper GUI to shine in glory.
In short - you've tried to build it on much deeper level than it actually needs)
It is not a problem to build a proper QCD system in current Blender 2.8 realization - we already have some significant part of it that works.
It is a problem to take a few simple right steps to make it work properly, so it is more workflow design issue than, actually, development problem.
Just like clunky LMB selection issue that can be fixed with couple of lines, but breaks any kind of organic hardsufrace modeling, and lasts a year.
Did you know that SS, DV and RR are, actualy, not stored in view layer?
Yes, I'm looking forward to it.
I think these can be fixed fairly easily with an addon, actually.
I'll try a second approach more closely built off of collections.
Well my first approach allows for a lot of flexibility, so maybe it's more than needed, but it might prove useful. We can compare once I've built the second.
Yes. That's why I've been a bit hesitant with cloning and it's related to my bug report: blender/blender#72084
New version of first QCD test:
Collection_Manager_QCD_test_v1_1_0.zip
Look in the top right corner of the 3D View for the new ui. See tooltips for instructions. It's based off of that link to collection_quickies you mentioned earlier, so thank's for that :)
@nokipaike You might be interested in this latest QCD test as well.
I've tried it)
Well, I am not sure that there should be a dedicated QCD mode - default behavior is nice.
Let me explain why.
Almost every kind of work in CG contains or even consists from converting a dynamic context (ideas, concepts, sketches, references, versions and other temporal data) to a static context (final models, scenes or products):
So, basically, every production process can be expressed using this scheme:
QCD as a system is needed for very a special task - complex multirefrenced modeling, and Collections management is needed for complex scene setups.
And, as it is shown on a sheme, this is completely different steps of a production.
When you modeling a complex asset you don't care about scene setup to get slot access speed, and when you assembling final scene, you don't care about slot access speed to get scene setup.
So those production steps are made in different files.
Complex modeling requires a lot of reference trash around to navigate between them, such as pictures, photoscans, drawings, LODs, variations, model parts, retopology objects, that should never get the final scene.
This way, making a separate QCD mode makes no sense, it just have nothing to presevre, as far as scene is prerared exclusevly for such kind of a modeling.
From other side, complex scene sometimes needs a cleanups, so QCD there is used for qick sending objects to a specified prepared collection, that will be placed somewhere in complex scene setup later.
Like sorting content or filtering it out. This way, dedicated QCD mode is harmful for that purpose.
So I would like to propose to split QCD and CM addons, because they are needed for different steps of production, and have completely different requirements to a realization.
I believe, the best way of making proper QCD system is focusing on default QCD abilities, providden by default numeric input and autonumeration - we were fighting to preserve its best realization a lot ,
because switching modes is pretty much distracting, and it will be hard to design a invoke keymap behavior better than we has got.
The only thing I would like to propose for Collection Manager is to try to fix M5 issue, to provide ability to send an object to a proper collection.
So do you have an access to autonumeration result in API?
Can you obtain a name of a collection, that is isolated when pressing number 5, for example?
GUI is nice by the way, its like meetin old good friend that helped a lot)
But Alt keys are swapped. It is needed to be fixed for consistency - alt+3 should be under 3, alt+8 should be under 8.
It is needed for excluding counting them from a workflow.
I've only done small scenes, but I have often just done everything in one. So I think we should try for something that allows you to work with whatever level of detail is needed at the time.
For now it's of more benefit to keep them together. If, when we decide on the final implementation, it makes sense to separate them we can do it then.
I don't think so. But I can probably calculate the correct numeration myself. I'm actually not really a fan of autonumeration.
Potentially. I'd need more information on what you're hoping to do.
Sorry, I'm not sure what you mean here.
Overall you've made some good points, I'm not sure I agree with all of them, but this is still just the beginning of development. Let me do my second implementation and then we'll hopefully have a better idea how to go forward.
And I'm glad you like the GUI :)
Well, I currently thinking about QCD abilities, trying to design proper workflow.
Some of my thoughts at the moment:
For example, you can invoke some slot with N(number) andAlt+N
but can't add slots to visible with Shift+N and Alt+Shift+N to quickly form or modify a Combination of slots, that is our main goal.
We are making QCD to setup and control combinations.
So, I would like to propose just make a QCD Collection with 20 numeric collections in it without any kind of special mode.
It will be clean as concept, slots will be easy to access both from Nums (because of fixed addresses) and Outliner, and accesible in Blender even if addon is not installed.
Special button will create such Collection.
Let me explain a beautiful logic behind that.
First five are hot slots - they are commonly used, have smallest integers and the best key locations.
First Alt+five slots are cold slots - it’s nice to store here some data corresponding to hot slots.
Hot slot is above cold, so it is a pair, and it is fluent to set or invoke them.
For example, if hot slot 2 contains mesh, cold slot /2 (alt+2) contains it's retopo or base mesh, or reference, or part that may be needed - some data corresponding to the hot slot.
This way, QCD system consists from 10 pairs of 20 slots.
Other 10 slots (6-0, /6 -/0) are reserved slots.
They also have pairs, so slot 8 is above slot /8, and it is fluent, but they are used mostly for keeping everything that is not that important, due to less accessible keys.
So you can move pair from hot+cold (for example 2/2) to reserved (for example, 9/9) without losing the logical connection between them, if it is not urgently needed anymore.
As a result, pairs are extremely easy to set with numbers and detect visually.
This is the way it works)
Ah, I see now. Thanks. I've fixed this for both implementations now. (And yes it is beautiful)
I'm not going to do this right now because it's functionality is very close to the first implementation.
Here is implementation #2 (which I think I prefer). I believe it solves most of your problems, except maybe auto-numeration could use some work. :)
Features:
Collection_Manager_QCD_test_v2_0_0.zip
Wow! That is, actually, a very close solution!!
I need to use it for some time, but I already love how much direct it is.
Yes, since we are using EC, which can be stored in View Layer, we can use QCD system even in complex scenes, just creating empty VL for QCD session, keeping scene setup untouched, if it is needed at some point)
Awww, that feeling of combinational control... like feeling power ))
I need to dive in it, but the only thing I can propose already is about holding M.
What about to left M completely for collection manager, and use V for assigninig QCD slots, with separate domino GUI and keys reading?
It looks unoccupied and innocent in object mode, since vertex paint has gone from it.
CM and QCD systems are both content management systems, but they are semanically separated, as far as they follows different goals. I think that semantic difference can be also realized as hotkey difference, because both systems are used for different ways of content management.
😀
Switching hotkeys is easy. I can separate it out to two different ones. Having it all on M maybe has little more meaning as a hold over from 2.7 and it's one less key to remember, but I'm not set on it. And I'm not exactly sure what you mean by domino GUI.
Aw, domino GUI is a QCD GUI. It was called domino, because it also using subitizing ability to percept numbers.
When we are using CM we assigning collections with boxes
Via pressing V we can bring a separate window with QCD GUI to assign slots to a selection.
Because it is a bit... complex to set, for example, 2 3 /5 slots to a selection via holding M and pressing 2 3 alt+5 buttons.
This is definitely a two-handed type of operation, I would like to propose to avoid that.
ok, that's clearer. But why not just Shift-Click on the QCD GUI in the 3D View, that will move objects, rather than bringing up a new window? And I know Shift-Click is probably a bad hotkey for that, we can change it later.
Well, here we need to build an actions map.
I will make it to show all possible cases of interactions with a system (assigning slots, invoking slots), and we will place it to a relevance tree (because speed of access is important for QCD systems), to clearly see what we can get mathematically.
That will show us if we can do such a thing without loss.
Well, since QCD systems belongs to quick access systems, their action maps are pretty much simple. That's why we love it.
We will monitor the integrity of access to slots using the mouse and keyboard, using an example of cold Alt slots, and this way we will satisfy hot slots as well, because they are just simpler.
There are two groups of actions - Vew and Set
View - We are starting from simplest one - View slots in order to get familiar with its content. It is simplest isolation action. So, this way we are figuring combination of slots we want to obtain, looking throug them.
Add to View - Then we add slots to the view to get the combination that we figured out - this way we are forming desired combination to work with it.
Same behavior can be extended to Set actions, this way we can send object to a slot, or send it to a combinations of slots (like if we need a single image reference for multiple objects in different slots)
I greyed out hotkeys for Set in case if we don't use V popup for this mode, and here is a problem.
We have to add Ctrl modifier in order to satisfy all cases, and, as you can see, we run out of possible hotkeys combinations, ending with monstrous Ctrl+Shift+Alt+N to send object to a multiple cold slots.
For sure, it is possible to make so, but it will be definitely not the best way of using it)
Also, as you can see, V popup menu mode allow Set mode just copy View mode corresponding shortcuts for the same types of actions, that is pretty much fluent as part of the quick access paradigm.
Now I feel myself like Numberphile =)
What do you think about such solution?
Your action map does a good job showing the different ways of interaction. For the mouse shortcuts I'll agree that having a popup come up under the mouse would provide a slight improvement of speed. The number shortcuts, however, have a problem. I can see that doing it from M is a bad idea because it requires two hands (plus some keyboards may not correctly send all the key combinations. Mine doesn't send M-Alt-6 and M-Alt-7 correctly), and if we try to just use the regular modifier keys it becomes very hard to accommodate the move object operations (even Shift+Alt is somewhat difficult). So your option of V, Alt+3 (just like the widget in 2.7) makes a lot of sense, but now we come to the problem: the widget in 2.7 is custom and not built in python with a regular UI. I can have a regular widget pop up, but I can't think of any way to override the view shortcuts with move object shortcuts while the widget is up and return the shortcuts back to normal when it closes. One thing that might be possible is to draw it all with Blender's OpenGL, but that's outside my current skill set. Now, maybe someone else knows how to achieve this, so I'll ask around, but for the time being I think the best option is to forget the move object shortcuts and just use the mouse on the V popup.
New version that more closely matches your action map.
Collection_Manager_QCD_test_v2_1_1.zip
Thank you. As an engineer, I love ways to see systems transparently.
Yeah, this is exactly the problem I'm trying to fix.
There is not so much needed to obtain proper QCD system for multirefrenced modeling workflow, so I'm trying to overcome it directly.
You provided Crtl modifier hotkey for Set actions, and it is the best you can do, because it makes such system complete and useful.
So, you are a life saver!
A great job, thank you so much for this!!
p.s. I will test a solution for some time before showing it to other users that need it)
Good idea. Let me know if you find any bugs or think of any improvements.
Thanks! My pleasure! :)
And who knows in time I may find a way to recreate that widget and workflow. Regardless, now we have a reference implementation that we can point to and say: this is the general idea. And it's already a good QCD system for anyone who wants to use it.
A couple things I think potentially need further development are: auto-numeration (Does the system I chose work well for you, and should we stick with a button to re-numerate?) and move to (Should we allow objects to be moved again after they're moved to a non-visible layer). And one final thing I need to add is saving the QCD layers to blend files, but I'm working on that plus saving the other isolation/enable all histories (Do these need to be saved?).
Once we're happy with the above I think it's worth it to include the QCD system in the next official release (2.83).
Thoughts?
I am in testing process.
You already made so much to allow our company to survive.
Can you answer pesonal question on BA?
Yes. Done.
I'm happy I could help. :D
Hi!
Sorry for delay, I am deadly busy with my animation project.
I think I've got an interesting solution - what if to add a button near widget that will swap widget mode from View to Set and back, with ability to assign V shortcut to it.
This way we will not need a separate menu with separate gui, we will be able to use existing one, but for clearly splitted modes.
For example, to send selection to /2 slot it will be needed to press V, Alt+2, V (to enter and exit Set mode respectively)
Also it will be possible to use widget with only Shift and LMB for both modes and any possible cases.
I would definitely like to give a chance and test such a solution.
Do you think this is possible?
No problem. I've been busy with stuff as well.
As to your solution, I think it's possible. I'll work on it.
I've been thinking more about the possibility of recreating the move widget from 2.7, and I think that it is possible with a modal operator and OpenGL. The main problem here is my unfamiliarity with OpenGL, but in time I think I can do it. It probably won't be done soon though, so I'll work on it slowly in the background.
@1D_Inc Here is a test of your most recent suggestion/solution.
Enjoy!
Collection_Manager_QCD_test_v3_0_0.zip
Aw, that's so more fluent now!
Addiction will take some time, but the same short shortcuts in both modes succeeded)
Keeping testing, I think about visibility problems - for example, do we have to operate on EC if we are using enumerated list, or should we see a collection we send object to.
Sending to a single turned off slot feels a bit clunky, since we are loosing selection from sight of view.
I try to investigate if it is reasonable to keep the receiving slot disabled if it was (for single or multiple sending)
Can we make such test for research purposes - add slot to visible when we are sending objects to it?
Good!
I've felt that as well, but I haven't known which direction to go with a solution or whether a solution to that is actually needed.
Sure, that's easy, but I think it will quickly mess up your viewing state.
Another possibility would be to allow movement regardless of whether they can seen.
I'm about 90% sure this can be done, but I haven't tested it yet.
Added subscriber: @CobraA
Just found out about this great addon from the 2.82 release page,I wish if we could have something similar for "Bone Layers", cheers.
Hi. We are currently trying to cover complex production needs. We are working on Quck Content Display system.
Yes it will.
But it is hard to say if it will be that harmful.
I think this problem occurs because its easy to loose an active object due to indication limits, so it is hard to say if selection has gone to correct slot if a few are already taken.
Maybe another button for additive sending next to mode switch to test a solution?
Also nice design with crosses on nonexisting slot, didn't thought that is possible)
@CobraA
Something similar for Bone Layers has always been in the back of my mind and it's been requested before, so I'll probably end up doing something, but it may end up as a separate addon. I'm also not quite sure how it should look and work, so if you have any ideas let me know. Glad you like the addon! 🙂
@1D_Inc
Thanks. I needed something to keep everything aligned properly, so I thought an X would work nicely, but it could be anything. 🙂
I'd prefer to keep buttons to a minimum, but I have got a new version that adds the view layer when you move the object for you to test.
I'm thinking from my limited use that it's not great, but it does allow you unlimited movement. I'll see if I can find a solution to let you move selected objects from non-visible collections.
Collection_Manager_QCD_test_v3_1_0.zip
Thanks)
For sure, we will try to reach minimum ui elements, so such buttons are temporal, just for testing solutions without reinstalling addons versions back and forth)
I've tested for some time. Suddenly, such behavior feels... smoother)
I need to test this some more time to understand why the slot display seems to be better.
I would like to propose to turn off a slot from where selection has gone (in which the number of objects was reduced after the Set operation),
this will make possible to find appropriable slot to a selection via several switches, if it is possible to reproduce.
Also, it seems, you removed Ctrl hotkey modifier for Set operations.
I don't think it is needed to be removed - it is pretty much clean alternative way to work with ui widget directly.
When objects are sent with mouse operations, slot is selected directly with mouse, so it is possible to afford Ctrl and Ctrl+Shift hotkeys modifiers in that case, to get ability to Set without entering special mode.
QCD mode button (with V key assigned) is handy for numeric input to indicate Set and View modes split to keep shortcuts the same for that type of input, and also get around the separate popup ui problem.
It is also possible to use this button for mouse input operations, but operations with Ctrl hotkey modifier can be faster in some cases.
So, when objects are moved out of a layer and the layer has no objects in it we hide it? That could be done, I think.
Yeah, I did it to unify it with the keyboard state and present a clear representation of the modes to the user, but I can easily add the Ctrl modifier back to the GUI.
The separate modes may not be required anyway. I've been doing some experimenting with OpenGL (turns out blender's python bindings of it are fairly simple) and I think I'll be able to recreate the functionality of the widget from 2.7
The main problem I'm seeing is the loss of selection when moving objects to hidden QCD layers. I'm hoping I can find a way to preserve them, but we'll just have to see.
There are also a couple bugs I found when I downloaded a couple of the new demo files blender released, so I'll be fixing those, but other than that the Collection Manager and QCD system worked really nicely with one of the scenes from Spring.
Speaking of test files, do you know of any good ones I could download so I can get a feel of how the Collection Manager/QCD will handles in real world scenarios?
Hopefully I'll have some good stuff for you to test soon.
I think, that it will be interisting to hide slot that will still contain objects but has got lesser objects after Set operation - that will mean that objects has gone from it.
That would be nice)
It is a shortcut, that also don't take any space, so if to chose between have it or don't, it will be nice to have it)
Yes, losing active/selection is definitely the issue. That's why I thought about switching back from EC to VV operations, but VV is not stored in View layer, so we are trying to make EC behavior better providing unhiding/hiding slots on Set opertions.
I already feel how tricky recreating 2.7 functionality can be)
So I tried to ask devs to make some API improvements to make it easier, but with no luck.
Well, we are using 2.79 on most product-dependent tasks since January, to avoid workflow issues of 2.8X to ruin our production process, 2.8X is banned in our company.
The good news is that there is no rush, and we have enough time to evolve solutions, proper design and testing.
About QCD using scenarios - it is intended "for handling dynamic context", and this range of tasks indeed is pretty much abstract.
But a nice case example to feel how it works is multirefrenced modeling , that covers almost every critical need of using such a system.
This post contains GIF of using QCD in a real production multirefrenced modeling workflow.
So, to simulate this case you need to get some simultaneous references in one place (like photoes, drawings, photoscans, laser scans, retopology objects, basemeshes, etc)
and try to navigate between them and their combinations as fast as possible, trying to concentrate on a model, it's references, and differences between them in fullscreen because of details.
I am thinking about example scenes, because I can't share our working files because of NDA, and placing 5-7 random objects in one place just can be far away from self-explanatory.
It just heavily depends on workflow process, since it is a workflow issue =)
In fact, the QCD system is the answer to the question "how complex model can you build in your software without getting ripped"
Good news, I've fixed it so this doesn't matter anymore. I can now move objects to multiple non-visible layers in sequence, just like 2.7x.
Interesting. I don't think this will be necessary anymore with the above solution, but we may want it as well.
Excellent.
Hopefully collections and QCD will soon no longer be an obstacle anymore :)
Yeah, I suspected NDA might be an issue. I'll just have to keep my eyes out for complex scenes. Maybe I'll try blendswap. Because the thing is, I think I understand the abstract concepts quite well, but it's a different thing to get a feel for how well a technology implements those concepts, what it feels like to actually use the addon on a production scene, what works well and what little problems you run into that you wouldn't expect. This is for the whole addon of course, not just QCD.
But no worries. For the most part things are easy enough to test.
Yes. I also see no obstacles here)
A kind of syntactic sugar applied to a workflow.
For sure. It is mostly about speed of access, just in heavily distracting modeling conditions, so there should not be problems with testing process.
We also have time-tested 2.7 example which works pretty well.
You really give us hope)
Alright, here is a new version with the selection problem fixed and a QCD move widget drawn in OpenGL with hotkey support. Let me know what you think and if, after trying it out, you still want to try out the auto enabling/disabling of QCD layers on move. Fair warning, the OpenGL widget is crude (I'll see about refining it later), but it should serve as a good prototype for the functionality, and proof that it's possible. Moving objects via V, LMB, V, Shift+LMB, V, Alt+3 and V, Shift+Alt+3 is now possible.
Collection_Manager_QCD_test_v2_3_1.zip
Wow!
It looks nice enough and it works!
I love bigger size of slots, it is better for mouse operations, square shape make it better for subitizing, but maybe gaps between them is a bit huge. 1px gap should be enough, since they are bigger.
I would like to propose to grey out slots indicators that don't contain a selection, if it is possible. Yeah, I think we will face those detecting/indicating active/selection problem many more times)
Also love Ctrl direct combinations back, indeed, works like a syntactic sugar. It is definitely "nice to have" feature!
Switch mode button has gone, and I think we made enough to get rid of it)
In general, this GUI It is definitely a step forward in terms of usability)
Nice to see such realization)
Thanks! I'm probably going to keep it a fairly simple flat theme, but hopefully it'll get a little more stylish. :)
Not exactly sure what you're asking here. Do you mean you want the button greyed out if there are no objects in that layer or is it that it should be greyed out if there are objects but none are selected?
If it's the latter I was planning on doing a filled circle/outline circle for selected objects/not selected objects similar to how it's represented on the widget in the 3D View header.
And actually, now that I think of it, I think I'm going to change the 3D View header widget so that you get a filled circle for all selected objects instead of just the active object.
As you might have noticed from the version number, I actually just went back to the branch with the regular popup and switched it out for my custom OpenGL one, so no need for modes and I got the Ctrl combination back without any extra work! :)
Here's a new version to test with a few improvements to the OpenGL drawing, and a new feature/bug fix that allows you to mark collections as non QCD Layers. The re-numerate button on the collection manager now will respect user defined non QCD Layers by default, and so won't assign them a number, and it now has a hotkey (Ctrl) to allow complete re-numeration discarding user defined non QCD layers. Plus a bug fix with the integration of QCD with the Collection Manager histories.
Collection_Manager_QCD_test_v2_5_0.zip
Aw. I need to think about this concept for a while.
Upon further consideration I'm going to keep the filled circle to indicate the active object, because you need that indication to work properly when adding objects to a layer as opposed to moving them.
I've done some polishing of the OpenGL widget and the object indication, and I think it works really well now. Oh, and if I didn't mention it before, we can technically draw just about anything in opengl for the popup move widget.
Another thing I think I forgot to mention is that you can move objects to whatever layers you want now (and keep moving them) regardless of whether the layers are visible.
Not trying to push you, feel free to think about stuff for as long as you want. :)
And if you could keep an eye out for any hangs or performance problems with the new OpenGL widget that would be great.
Collection_Manager_QCD_test_v2_6_0.zip
I think it is reasonable, because this is how it works all this time, and already solves a problem.
Anyway, we have the ability to check other solutions as well, to have a chance to bring some enhancements to that behavior, but it will always require a workflow tests.
Yeah, OpenGL is actually, a freedom, because if you are making something in OGL, you have only OGL limits.
That is a very powerful step, that brings a lot of consistency and control to a system.
Thank you so much for this!
I didn't spotted such a thing yet, but I will try to do my best)
Well, my thoughts about system that we've got, and some issues I would like to mention and clarify.
Let's call them QCD Slots, because QCD system is not related to a "common layer sytems", used in max/maya/autocad/photoshop/SPainter and other software.
Layers entities are used for storing static context data, that can have a short name, that represents it context (like "car" or "house"), so Collections is a representation of a common layer system in Blender.
Layers are something constant, so they are about scene setup.
Numeric slots are far away from such kind of concept, they are part of a "quick access system" which handles dynamic context, that cannot have a name to represent context directly (like "some part of a mesh that I need to work separately at this moment" or "retopology object that I have to brought into coordination with several references" or "a bunch of heavyweight objects from imported scene to fix and simplify, moving already fixed objects to another slot to control vertices count I saved")
Slots are something temporal and fickle, so they are about modeling process and preparations.
Previously, 2.79 layers were removed because they were called "Layers" without providing the ability to perform work intended for layer systems.
Calling those things as Slots, we are making clear that they are not intendent for any kind of work intended for any kind of layer systems.
I would like to propose soften gamma (that's the thing I meant by "graying out")
Here is a mockup and explanations:
As you can see, you can easily percept the difference between 2 and 3 hatches, between 3 and 4, but 5 is a problem, so you are crossing 4 and starting next mark.
Also, you can easily percept that every crossed mark have 4 hatches, and you didn't missed something. If every mark will contain 6-7 hatches, you will have a problem, and you will need to count each of them, to be sure if they are correct.
That's the way to feel the actual limit of the human perception subitizing ability =)
(Also row of 5 is nice to handle two packs, but that's the limit, because it there will be 3-4 packs, that would be a problem.)
I used to be opposed to being able to assign numbers manually, because of the teamwork issue - if someone assigned slots, they are lost and cannot be reassigned without project coordination.
They cease to be temporary with this approach - you spread 20 slots over 500 Collections, and that's it, they can't be touched, because were assigned by some reason, that is obvious only to one person.
But you made the button “Re-numerate QCD layers (slots)”, that makes it clear that their assignment is temporal, so I think this is a kind of solution)
Personaly, I like the ability of manual numeration, so that was mostly the question of a realisation, I will try to explore it for some more.
Thank you for this)
Your welcome :D
Wonderful, that's what I'm hoping for. :)
Sure, and I agree it makes more sense, this isn't a hierarchical layer system.
Sure, that's easy, and it looks much better in your mockup.
I agree with what you've said. I've always been in favor of at least partial manual numeration because auto numeration will only work on the first 20 collections leaving you without a way to apply the QCD system to other collections. I imagine that you would want to change the slots target collections multiple times in a project, if not multiple times in the same session. I think we've struck a nice balance allowing for easy numeration to just be there in the beginning, but flexible enough to allow any configuration you need as a project progresses. I have seen a couple projects where they use blank collections as groups for other collections with objects, so it makes no sense to force a blank collection to be a slot. And I think it's turned out to be very temporal and fluid.
I can do all of that, but I'm wondering if we should hard code the colors for the entire widget or have them follow the current theme?
Finished editing. Apologies for the accidental early posting of the above comment.
This is ok, I do the same often because of the language barrier)
I didn't thought about hardcoding theme, but we can get all those colors from blender theme, I guess.
I will look for corresponding theme colors.
Currently, it is possile to setup visual appearance of header widget with UI prefrences (Themes - User Interface - Tool)
We can use Toolbar Item palette instead to decrease overall theme changes (Themes - UI - Toolbar Item)
This will make the toolbar text (left-side T key toolset) color dull, but at a level where your modeling is so complex that you need a QCD system, you already know all this text and do not need to display it constantly.
I think it is suitable solution to start from for both header and popup widgets at this point.
Okay, I've changed the terminology from Layers to Slots, updated the layout to have wider gaps, and implemented theme support. I have set it up to be consistent with how floating panels are themed, so the user can style it in an expected manner just like any other popup. However, I have also included support for the one non standard feature you wanted, having the icons other than the one denoting the active object fade slightly into the buttons background (this is hard coded and was accomplished by simply setting the icon to draw semitransparent with a value from 0-1 and can be changed easily if needed). While implementing theme support I found that there were times when you would move selected objects, but because no object was active there was no indication of movement from the UI. So to fix this I've updated the icons so that a line indicates the slot has objects, an empty circle indicates the slot has selected objects, and the filled circle still indicates the slot has the active object. If you have an idea for better icons I'm all ears, but I would like the the header and popup icons to match, and because the buttons on the header are so small, and the icons don't scale, the number of icons that work for the header is extremely limited.
The following theme elements are linked to the OpenGL widget.
The theme implementation can be modified if needed, but I think overall it works nicely.
One thing to note is that while this works properly with blender 2.82, blender 2.83 has changed stuff with it's color management and so currently the OpenGL widgets colors will be slightly off in intensity. This is known and being discussed here: https://developer.blender.org/T74139. When a course of action is decided on I'll make sure my addon conforms to it.
I also fixed a bug when adding objects to a slot (Shift-Click) where if there was no active object you could add it, but not remove it.
Let me know what you think.
Collection_Manager_QCD_test_v2_7_1.zip
Nice!
Thats an interesting idea, if to take into account that we work with EC, so we can say how objects that will be sent with Set operation are distrubuted over slots. I will try to investigate the workflow behind it)
But instead of line I would propose a dot, sharing same color with empty circle, and size of an inner diameter of the empty circle.
(Empty, occupied, selected, active)
Sorry, but I didn't spotted changes in theme setup. It seems to be completely linked to UI - Tool.
The problem is that QCD widget used to have dim colors, because of precise contrast setup, so if it will use UI - Tool colors, a lot of things will turn dim in overall UI.
I colorized it to random colors to show how it influences overal interface
That's why I proposed UI - Toolbar Item instead UI - Tool, it doesn't spread so much over interface)
That's also interesting, thanks) Hope such issues can be brought to a consistency in a single release, and there will be no more of them.
Indeed, works like a charm)
I also like that it can be sent to a disabled slot and back.
Also like it does not turn into active if an active one has been defined.
Spotted an interesting issue - popup QCD widged is about 1.2x larger on Windows (tested 8.1), and looks normal on Linux Mint where it have the same width as header widget.
I'll give a screenshots later.
Linux:
Oh, no, it seems, I just messed up with overall UI scale (Preferences - Intrface - Resolution scale) on different machines.
Popup equals heard at 1.4 UI scale, usually I use 1.2 - 1.3. My bad =)
By the way, what scale of the user interface do you prefer to use?
While that works to some degree in the OpenGL widget, it does not work well in the header widget. They are just too similar, even with the color difference in the OpenGL widget I think there could be situations where you could mistake one for the other, but when it's on the header there is less of a size difference because everything's smaller and there is no color difference. Now, obviously we aren't required to keep the OpenGL widget and header widget in sync, but I think it's a good idea.
So, if we're keeping things consistent, that leaves us with two options I can think of, use the default blender icons that take the theme colors and fit in the header widget, or add a custom icon for the active object. The downside with the custom icon is that it won't take the color of the theme like the default blender icons, so I would probably have it as white with a black outline, but I don't think that is a major problem because it denotes something special anyway. If we go the custom icon route I was thinking of using a five pointed star to denote the active object and having the non selected objects as the empty circle and the selected objects as the filled circle.
It is mostly. Because the OpenGL widget mimics a floating panel very closely it should use the same theme as well (that's what I think a user would expect). I think it's a bad idea to usurp another UI element's theme, aside from potentially ruining that element's colors, the user will have no idea that that's what controls the OpenGL widget's colors.
I don't think most users will mind the OpenGL widget conforming to the standard floating panel theme, but since you want more flexibility I suggest we provide a set of overrides in the addon's preferences. This will allow it to follow whatever theme is in use as well as allow for greater customization if a user wants it.
Me too.
Great. This whole issue with the selection and moving objects to non active slots is very finicky. Hopefully, I've got everything working in a nice and consistent way now.
Not entirely. Currently the OpenGL widget is drawn in absolute pixels and doesn't scale with the interface or monitors with different resolutions at all.
I should probably fix this.
On Linux I use a Resolution scale of 1.0. Interestingly, I tried it on Windows (8) and even though it was set to 1.0 blender's ui was a different size (I'm thinking blender also takes the systems font dpi and maybe size into account).
(Although it's hard to tell, I'm sure the OpenGL widget was the same size on Windows because it's drawn in absolute pixels.)
Yes, we are keeping sync and related to defaults icons/resources, trying to investigate what we can possibly get following that path. How much it allows us to reach.
By the way, what is line - is it an icon, or a text symbol, maybe? How did you made it?)
The same question about crosses for unexisting slots.
Color theme has got some special requirements, so it makes sense to make it local, because it is hard to find any kind of system in Blender that could have the same requirements to a visual appearance and contrast.
Is it possible to make local color override in addon prefs that influences both header and popup keeping their themes in sync?
Yeah, I spotted the problem in a wrong way)
Yes, it drawn in pixels, so not a widget, but entire ui scale looks different in comparison to a widget on different monitor sizes and pixel density)
So the question is - can we make system ui scale preference influence widget size, or, for example, provide some fixed size values?
What are our possible abilities in resizing custom OGL stuff?
Can it be multiplied to some value or something?
I think it will be nice to reach sync also for width of header and popup widgets, or at least, keep their widths corresponding)
Good. And you're right a custom icon just doesn't work well (I tried it).
For the header widget, both of those are icons. Unfortunately, text messes up the button sizes on the header widget and so can't be used. I use the Icon Viewer addon to get a nice grid view of all the available icons.
For the OpenGL widget all the "icons" are just shapes I draw in OpenGL.
No. The header's colors are taken directly from the theme.
OGL stuff can be drawn at any size. I just need to add some code to take the UI's Resolution Scale into account. I think I know what needs to be done and I'll try it out and get back to you.
Yeah, I'll keep them about the same size.
Added dpi/scaling support. Some widths and gaps may need a little tweaking, but it's pretty close to what we had previously and now gets sized according to the Resolution Scale in the preferences.
Added addon preferences with overrides for the OpenGL widget's theme. By default it will follow the theme for popups exactly, but you can override that and customize just about anything. You can even set how visible the non active icons are.
(check the check boxes to enable and allow you to edit the overrides)
Collection_Manager_QCD_test_v2_9_1.zip
A very nice progress here!
Indeed, it is better that the gaps remain 1px regardless of the scale of the UI scale (maybe with 2px option for 4k monitors) othervise they are corrupted by aliasing, but it is nice to see popup respect UI scale.
Not sure about color overrides - popup is large enough to have a problems, but I will prefer to have such options yet, and try to figure out if they are really needed.
I really like that the system is fully operational and only tiny design issues are left.
That's just awesome)
Lovely!
Also spotted some dots.
Can we try to use them instead of minus?
DECORATE icon
I like minus because it is not round, so you can clearly see where active/selected is, but it makes harder to see empty slots in my opinion.
That would be nice to make a comparison.
Thanks :)
I'll see what I can do.
You want a very specific custom theme for the widget. I think that using the regular popup theme works well in most cases, but there are times when part or all of the theme is not ideal. Overrides allow you to customize as much or as little as you desire.
So everybody can have what they want :)
Me too. And on that note, I would like to propose committing this to master. We have lots of time to polish it once it's in master, but the cutoff for adding major new features to master for 2.83 is March 12.
@BrendonMurphy What do you think about this?
We can try it, but I have doubts.
On full size buttons it would be fine, however, I don't think there is enough of a difference in size on the small buttons. I'm pretty sure what you're showing in your picture is the DECORATE icon with the RADIOBUT_ON and RADIOBUT_OFF icons, but the icons we're currently using are LAYER_ACTIVE and LAYER_USED not RADIOBUT_ON and RADIOBUT_OFF. Here is a comparison between DECORATE, LAYER_USED, LAYER_ACTIVE, and DOT.
This brings up the question of do we want to expand the buttons to full size to allow the use of any/all of the icons? Currently the buttons are scaled on the y axis so they will fit nicely with everything else in the header, but they could be bigger and hang down.
Mostly disregard that last question. The header widget can only have slightly larger buttons. It turns out that blender will only allow the header to take up a specific amount of vertical space, anything past that it cuts off.
Yeah, I've spotted LAYER_USED issue on my second screenshot, when I was trying to figure out what icons can be possibly used for slots.
I tried to make a mockup to get how dots will look like, and how much they will mess with perception recognition, but image I've got is far away from being self-representative)
So I'm in doubts)
I think that such progress definitely deserves to reach master, because multiref modeling in particular (and handling dynamic context in general)
is the reason we are using Blender daily to solve various complex problems that other programs don't allow, including entire "industry standards" family.
ps
the only issue I can see that it redefines nums keys to make QCD system actually work.
Some users that don't need QCD may not like that.
How do you think, is there a solution for that problem?
Maybe an option in prefs or something...
I think I can add a checkbox in the preferences to allow you to enable/disable QCD.
Good news! I've found a way to make custom icons respect the theme. This means we can have any icon we want for the active object. Example: (this started off as a white star)
What I ended up doing was multiplying the icons pixel data with the theme's color and essentially rebuilding the icon every time the theme changes. Took me a while to figure out, thankfully blender allows access to the pixel data of custom icons, but I got it working and now we have a lot more freedom.
Update.
I'm also including a "dots" zip that uses DECORATE, LAYER_USED, and LAYER_ACTIVE for the header widget
Upon further consideration this could be more trouble than I first thought. How big a chance is there that someone would use those hotkeys, but not need a QCD system?
Collection_Manager_QCD_test_v2_9_4.zip
Collection_Manager_QCD_test_v2_9_4_dots.zip
Thank you)
I checked them, they are interesting to investigate)
Well, first - star is kind of a strong shape symbol, and it is not as neutral as circle, so I would prefer to not to use it.
I think that most of CG programs don't have stars in UI because of the same reason. It's too attractive.
Also filled star / filled circle system have lower contrast than expected. Shape contrast type have low contrast value on a scale of contrast types.
I checked the dots solution, it is nice to see both solutions together, very handy by the way - and yes, this contrast is also too low.
Basically, I think that minus/empty circle/filled circle works the best way. The only thing I would like to propose to change in that scheme is to try to make minus shorter, I will try to make a mockup to figure out if it works)
Yes, I guess there will be troubles.
The problem is that QCD system is built into Collection Manager, and those systems are needed for different stages and types of work.
QCD system is needed for complex modeling, to handle limited dynamic context with quick access, while Collections management is needed for final complex scene setup, to handle unlimited static context.
So there will be a lot of scene setup atrists, like visualizators, that will never perform multiref modeling, and they may not like hotkeys autoreassigning.
Personally, we will use slots keys a lot, even in edit mode, like in 2.7.
We are using
(~ tilda) button for **wm.call_menu** [VIEW3D_MT_edit_mesh_select_mode] for decade for switching vertex-edge-face pressing1 - vertex mode2 - edge mode3 - face modeWay better than ctrl+tab from 2.7 and almost fast as 1 2 3 from 2.8, but supports multiref modeling due to direct access to slots even from edit mode, and keeping slots access keys the same for both object and edit modes.
That's the most consistent solution we discovered.
But Im trying to avoid further negative reports from other users. I don't know how serious autoreassigning issue is, just know that there are people that will not like it.
I've tried, and it seems it is possible to map edit mode numeric keys to slots maually.
That's nice)
So, only object mode map can be provided with an addon.
Yes, I was also surprised at how the star performed, and I agree the minus/empty circle/filled circle works the best for subitizing. Because the star is a strong symbol I thought it would be perfect for the active object, but it seems that theory did not hold up in practice :)
Currently the keymaps are only added to object mode by default. I hadn't thought about adding them to other modes, but I guess it makes sense. From what you've said above it's probably best to provide a preference to completely disable QCD, both hotkeys, and UI. Or are you only worried about hotkeys in edit mode?
I've added a custom shorter minus icon to the header widget and fixed some bugs with undo.
Collection_Manager_QCD_test_v2_9_7.zip
I think the best option is provide the ability to disable QCD completely, including gui and object mode keys, and do not influence edit mode keys since there is no problem to set them manually, if they are needed.
Its operator is pretty much easy to setup, so I am not worried about edit mode.
But can they be disabled independently, as two checkboxes, for example, where gui checkbox influences keys checkbox availability? I know people that uses QCD as gui only, for keeping stuff around, and they were asking for this.
Personally, we will use it at full throttle, including edit mode manual setup. The only thing we need about edit mode is to keep slots that contains edited objects turned on during slots switching.
Update for Master.
Added an isolate tree feature. This allows you to shift-click on an expansion operator (the little triangle) and it will collapse all other collections except for that collection, and its parents. It leaves the descendants unchanged. Expand/collapse all sublevels has been moved to ctrl-click.
Collection_Manager_v1_10_0.zip
Okay, I'll add an option to disable QCD completely and a sub-option to just disable the hotkeys.
I'll see what I can do to make this possible.
A very nice feature)
I like the consistency it brings to a long lists handling.
Thank you! Maybe defaults should be GUI is on (to show that we have it) and keys are off (so as not to interfere with user settings)
That would be nice, because, unfortunately, edit mode is not a protection for a collection to be turned off anymore.
It can make troubles, for example, for searching suitable references, located in different slots, or LOD states comarisons, because allow to loose an actual setup.
Update.
Finally committed this to master with a few improvements:
There are still some improvements to make to the QCD system, but now that it's in master there should be lots of time to make them, and I will hopefully be able to get a couple non-QCD related features in too.
Collection_Manager_v2_0_0.zip
@1D_Inc
I think it would allow easier discovery of the hotkeys if they're on by default. If users don't want them it will be easy to turn them off.
Nice! That's just awesome news)
Yes, it is important, since QCD numeration can be assigned manually for sending objects to a specific slot from any collection in a scene)
This will allow you to quickly clean complex scenes.
That's actually intersesting how it is organized. Are they stored as numeration to some kind of a custom data?
Yeah, we've got some tasty things to do in Collection Management. They are long term though.
Well, I agree if this could be done easily.
I tested latest version a bit, and spotted an issue considering object mode - if selection contains no active objects (passive objects only - empty circle sign) it is not shown when it is sent to disabled QCD slot (from blue slot to black).
Its turned to minus, so it makes it hard to check if they were sent to a right slot or what is their slot distribution. Can it be fixed?
Here is GIF
Considering edit mode, collection visibility locking protection during switching collections is highly appreciated, regardless if collection is QCD or non-QCD.
This can be challenging, since 2.8x supports multiedit, thus, objects that are in edit mode can be located on several collections.
Currently they're stored internally as a python dictionary of key/value pairs like this: {"1": "Collection Name", "2": "Another Collection Name", "3": "And So On"}. It's then turned into a string (along with slot overrides - also a dictionary) and stored in a blender StringProperty on save, and then read and converted back into a dictionary on load. This works quite well, but the numeration gets lost if you tell blender to reload scripts, so I will probably refactor this to use internal blender properties (as a bonus they will get automatically saved).
Actually I'm hoping to get a couple easy ones in before the end of bcon1 (March 18). After that we've got a month for improvement and stabilization, and then another month for bug fixing, but if I don't get things in now they won't get into the 2.83 release.
I think that's a regression actually. I'll see about fixing it soon.
I'd forgotten about multiedit. That will be interesting.
About hotkeys for RTOs, I found that I can only work with the left mouse button, which cuts down the number of possible key combinations and so I was looking over the proposed features and hotkeys and noticed that some of them use Alt. I just realized that Alt + LMB is potentially problematic because of both Blender's Emulate 3 Button Mouse and because Linux window managers often reserve Alt + LMB for moving windows. The best ideas I've had to allow for more features without using Alt are pressing and holding the RTO to call a menu or adding in a menu arrow button beside each RTO. I thought about adding stuff to the generic RMB context menu or having a menu pop up on Ctrl + Shift + LMB, but stuff added to the RMB context menu can be overridden by other addons and Ctrl + Shift + LMB is already used for nested isolation.
Another thing I'm wondering is if when viewing a slot we should enable the VV and DV RTOs as well as EC. This would corrupt their previous state, but it would prevent the user from switching to a slot with objects without being able to see them.
Thoughts?
No no no, I meant protecting visibility of collections that contains objects in edit mode only for switching QCD slots action, as far as QCD is intended for modeling process.
We need to keep editmode objects visible during pressing nums or using widget to compare model with multiple simultaneous references.
Its all about enhancing QCD slots switching operator.
From other side, Collection Manager is intended for complex scene setups, and complex scene setup is the task to control and organize a system, it is for object mode only, and it is way more about long lists and names and complex hierarchies, so there is no need to support edit mode because of no reason)
Well, fortunately, our "long terms" are that short)
Update.
Fixed some bugs/regressions with QCD. @1D_Inc hopefully fixed your movement problem - works for me with your example, so let me know if it's still not working for you.
Added swap RTOs feature. Current hotkey Ctrl-Alt-Click.
Added copy/paste RTOs feature. Current hotkey Ctrl-Click.
Added discard history and copy/swap states. Current hotkey Alt-Click.
Added preferences to disable QCD and the view hotkeys.
Collection_Manager_v2_4_1.zip
@1D_Inc
Not exactly sure what this is in response to, but if it's to the second of my two questions, I was mainly asking about object mode not edit mode.
Aw, sorry for that. It seems, I've got it wrong.
We are in deadline now, I will try to test and make proper response later.
Wow.
So massive improvements there)
Yes! It now properly handles passive selected objects as well, their distribution is so clear now. Thank you)
By the way, there was a problem with the "passive" term, during direct conversations with devs. The problem is that in Blender selected objects (as selection) officially consists from active and... selected objects (selected except active).
It is not always clear what the term "selected objects" refers to when referring to the entire selection or all selected except the active one.
We has got recursive terminology at this point, therefore, instead of official scheme
Selected objects = active object + selected objects
we stick to another terminology in our company
Selected objects = active object + passive objects.
Just to make things clear)
Works like a charm! Now we can setup and control implicit RTOs as explicit)
Speaking of global RTOs I think it's hard to find a better assignment for these hotkeys.
Nice control. There seems to be a tiny issue - its description is different in different RTOs.
Do you have the same?
That's good.
I like that they can be turned on/off immediately, a very clean solution!
It feels lightweight, usually, even manual keys setup is pretty much painful process.
Nice to see it can be automated like this.
Yes, I faced same situations, when collections are disabled by several RTOs, but this situations are, basically, workflow dependent.
You provided nice manual slot numeration engine, that makes QCD system suitable not only for complex multiref modeling, where such ability would be handy, but also, actually, for collection management during scene setup.
We are operating on View Layer dependent RTO (EC) because it can be stored in View Layer, so temporal VL can be created for content management operations during tasks like complex scene cleanup.
So, you have expanded the scope of QCD that much!
I think that autoenable multiple RTOs will take away this ability, as it will affect VL-independent RTOs that indeed will lead to corruprting actual setup, reducing the scope of use of QCD system back to tasks like multiref editing.
This behavior can be achieved if all RTOs are kept in VL, that will allow creating temporal VLs (that will allow to simplify Phantom mode realization and also allow cloning View Layer), but we know it is a problem.
So I think there is no problem to turn everything on manually once with global RTOs during tasks like multiref modeling, allowing to expand the scope of the QCD system to the task of setting up the scene.
Excellent.
Sounds good.
Great. There are a few minor things to sort out, like right now the swap and copy icons override each other. It would be nice to have an icon to show that they're both applied to that RTO.
The hotkeys are great if you're working with a mouse and you don't have Alt+LMB set to drag windows on Linux (so works great for me, but maybe not for everyone). I'm going to experiment with bringing up a menu with actions when you click and hold the button. This will solve the problem of hotkeys and also allow more fine grained control for things like the discard feature.
Yes. It seems that blender's tooltips have a maximum length, and I'm past that. Not sure what to do about it yet; I'll probably ask about it in blender chat sometime, but for now it's not a huge problem.
Yep, I could even add a checkbox for edit mode hotkeys once we get QCD in edit mode developed.
Okay, I'll leave it just affecting EC. That's easy :)
I can not consider this as an addon problem, mainly because we usually buy equipment / peripherals and configure the system for production needs, therefore we remove system default settings such as moving the window to alt + LMB and buy mouse with scrolls.
It is difficult to predict how the system should work at a limited hardware / peripheral level in advance, so I would recommend waiting for some real cases to satisfy.
That's, actually, interesting)
This will bring us to the ready from the box system )
Maybe as a third checkbox.
Its also the best that we can do at this point I guess)
Also interesting news)
Well, CM is mentioned in BlenderToday!
https://youtu.be/2rAteWtqvNQ?t=315
We created a pretty solid system, you put so much effort, hopes that we are ready to be announced)
Can we add V hotkey and other QCD hotkeys description to a special section of description of CM addon in this tread?
Added subscriber: @RomboutVersluijs
Wow this addon expanded quickly, looks nice but looks way more complicated then before. Perhaps it is mentioned earlier, but is it perhaps an idea to have a simplefied GUI like how it looked before? Currently it looks quite overwhelming with all the buttons and short names. I understand its a complex topic, but the simple GUI it had prior was super nice for simple stuff.
PS im on OSX 10.11.6 and i see a "huge" spike in my CPU since going from 2.82 to 2.83. I noticed that weird old layer system is brought back. Why not leave those X icons, that is really cluttering the the overall GUI. If nothing is there dont show it?! All those X's look weird.
But anyway, something in the addon is doing a lot of work NON-STOP in the background. Though its not much, my fans are kicking in. If i turn the addon off it goes back to quite.
I recorded a bit using 2.83 and also 2.82 to see the comparison. in Bl 2.82 Blender cpu is around 7-8% idle. In bl 2.83 now it spikes to 50-70% all idle??
Looks like v2.4.1 does fix it in bl 2.83, CPU is now steady around 5%
Hi.
Indeed, addon's GUI is a complex topic, since it is based on complex production demands.
Unlike Collection Management system, that is needed for complex scene setup, Quick Content Display system (QCD) is intended for complex multirefrence modeling workflows.
It is based on quick access slot system and consists from numeric slots, that contains collection for quick access.
The symbol X means that there is no collection in the slot because the collection was not created.
QCD system (both GUI widget and shortcuts) can be turned off in addons preferences.
@1D_Inc
That's what I was thinking.
Yeah, this is really nice. And QCD's usable enough, so why not have it announced.
Yes. Thanks for reminding me.
@RomboutVersluijs
Yes v2.4.1 fixes it. See cdf338ca3e: Collection Manager: Fix update loop. Task: #69577 for more details.
Yes it has. It's been in heavy development for 6 months, so I'm going to need something a little more specific than before or prior. :) If you mean from what's in blender 2.82, then the GUI actually hasn't changed much, except for the QCD stuff which like @1D_Inc said can be turned off in the preferences.
Spotted task description update)
What about placing QCD system previews into a single image like that?
It is a bit unobvious at first glance why there are three screenshots and what elements they refer to.
That will probably make things cleaner, two systems - two screenshots.
Good idea. I was also unhappy with the three screenshots, but couldn't think of a better way. I'll replace the two QCD screenshots with your image in the task description.
Nice.
A better version then - the same image aspect as Collection Manager screenshot, to make composition equal and accurate
Great! Thanks.
Indeed i did not think about it thoroughly, you need to be able to target an empty slot. But why not empty dot instead of that big X
I believe you already due the filled dot, so why not the empty one for empty QSD layer/section? That is less dominant that the current X
@RomboutVersluijs
Because an empty dot is already used for something else.
The X symbolizes a potential slot that has not been created yet (it's just an icon, you can't interact with it). Each button indicates a slot. Buttons with no icons indicate that there are no objects in the slot, while buttons with icons show that there are objects in the slot in one of the three states of selection. A horizontal line icon indicates that there are objects in the slot, but none are selected. A circle icon indicates there are selected objects in the slot, but not the active object (these objects are what's been termed passive objects). A dot, or filled circle, icon indicates that the active object is in that slot.
All of these indicators have been chosen so that it's easy to see at a glance the exact state of the QCD system.
Sorry for the long absence of updates. I've been tweaking and experimenting with stuff. So here's a new zip with the latest improvements I've committed to master.
Changes include:
Collection_Manager_v2_4_9.zip
Hi!
It seems, something happened with renumerating slots in latest version?
Hi!
Yeah, sorry, that happened because I renamed stuff. I'll have a fix out for it soon.
Update.
Changes:
Collection_Manager_v2_5_1.zip
I don't think there's anything I can do about the length limit on tooltips, so I'm thinking now would be a good time to shorten and standardize the Local and Global RTO tooltips. Here is what I've come up with. Thoughts?
Local RTOs:
Global RTOs:
I think that it is possible to repalce all the "/restore previous state" to "toggle".
Toggle is a pretty much straightforward term, especially if to take into account that it is already used in some tooltips.
Also they are just tooltips, reminder of what actions the tool has, not the manual, so I would recommend to shorten tooltips that way, and just expand description at this topic if it is needed.
For instance:
A tooltip:
Shift+LMB - Isolation toggle
Description (at this topic):
Shift+LMB - Isolation toggle - Isolates collection / restores previous scene state.
A tooltip:
Alt+LMB - Discard history.
Description (at this topic):
Alt+LMB - Discard history including swap/copy state.
Also I would like to add abbreviations to tooltips, since (as we already tested) they are handy to use during conversation in production process, and also because it is hard to incline original names.
I always catch myself in what I think in "EC" and "DV" terms while thinking about scene setup, rather than "Excluding from view layer" and "Disabling collections in viewports" because it is more memory efficient.
There are too much excludings and disablings in a program already, and the differences between those terms are really fragile to a non-english user, so it makes hard to think about complex setups with such complex terms.
We are an addon, so I think we can afford such kind of system improvement:
Local RTOs:
Global RTOs:
In general I like your ideas, but I have a few thoughts.
Agreed. And we have an entry in the blender manual as well as this topic.
I get the idea, but it kind of seems unnecessary to put toggle behind many of them and it doesn't make a distinction between those that have history and those that don't.
I'm also thinking of removing the history state from the Invert functions because all you have to do is click it again to get your previous state back anyway.
And I'm sorry, but I think Control Children toggle isn't very easy to understand what it does.
I like this idea, especially for the Global RTOs.
I like the succinct way you've done the first line of the tooltips, but I'm wondering if VV should be "Hide from View Layer" because it's one of the few that actually is view layer dependent.
That's cool) That can help to explain the reasons behind tools.
I've spotted that PDT addon have such a manual, and, honestly, PDT is the case I like manual more than addon.
For sure, toggle is just a way of converting a destructive action to a non-destructive to keep an actual scene setup available.
Fair enough. It will be more consistent because invertion is a specific type of action, that always have a backup of itself)
It's non-destructive by its nature.
Sure. Perhaps I would recommend sticking to its original name - Control Nesting.
Yes, it should be so, but this is its official name from the official tooltip.
Just trying to show that there were no changes applied to a concept of that RTO, and all RTOs are the same things as initial ones.
:)
While technically accurate, it seems like an obscure term. However, I've yet to come up with something that really fits this action, so it's a possibility.
Yeah, you're right. As much as I'd like to give it a more descriptive name it's better to be consistent with blender.
Update:
Fix crash of blender when loading templates.
Collection_Manager_v2_5_2.zip
Well, I got this term from AutoCAD , since I have been an AutoCAD user and programmer for a long time.
I was trying to figure out proper term for "sub-somthingness" in english for a long time, and didn't found better one at that moment.
Translator I hired to translate Data Management Maniphest also said that this is exact but weird.
"Cumulativity" term is another one I trying to figure out, when you can place single object to a multiple collections, but it is a completely new concept of data management, so there are no any kind of analogues to borrow.
It is always hard to find proper hierarchical terms, because usually they have to represent something highly abstract, and you may need just to invent them at some point.
We can, probably, but it this case the difference can be confusing)
I've done a lot of thinking about various tooltip wordings and here are the three I like best: (in no particular order)
1
2
3
Each of these has strengths and weaknesses, but I think all of them are clear enough. And I don't think it matters if we use nested or children as long as we're consistent.
My main thoughts are that #1 is slightly clearer about what each shortcut does, while #2 & #3 are clearer about which actions have a history or copy/swap state associated with them.
If I had to pick, I think I'm leaning slightly towards #1; although I can't decide if I prefer Discard states or Discard history for the Global RTO.
I like the second one (because of no kindergarden).
I mean, we already have Childrens in Parenting, and it indeed works there like family tree with straight relationships.
So "children" term is not only about the descending part of hierarchy, but also about a type of hierarchy.
Due to the cumulativity ability, a collection may have multiple "parents", that makes relationships not straight, and may require another term.
A bit confused about toggle term.
It seems, using multiple software, I used to the meaning "switching with the ability to restore previous state", not just "switching". Need to remember where is it from.
Fine with me, lets go with the second one then. We can always change it later if necessary and we have the manual entry and this task for a deeper explanation of what everything does.
Yeah, toggle can have slightly different meanings depending on context.
Update.
Collection_Manager_v2_5_4.zip
By the way, a very nice issue we solved with manual QCD numeration for sending objects.
It adds more determination.
https://developer.blender.org/T75610
Yep, manual numeration works well :)
And I'm very glad that neither the Collection Manager nor QCD suffers from blender/blender#75610.
Hope it's a quick and easy fix.
Update.
Collection_Manager_v2_6_0.zip
Wow, you already making QCD edit mode keys)
Since it is heavily workflow-dependent,I guess, it is time to explain a specification for it.
Lets try)
QCD system benefit is multirefrence editing - when single object have multiple refrences of different types (such as images, pointclouds, drawing, photoscans - simultaneously, at the same time)
For example, in historic restoration there can be multiple photos, drawings and photoscans of the same fragment of the element, that was obtained from different sources.
So, model and its references are stored in different QCD slots to navigate between combinations of visibility states (or "slots combinations") during modeling.
Here we have two problems to solve.
Default 2.8 controls of vertex/edges/faces mode on
123keys is designed for regular modeling, so fast switching mesh mode with QCD Edit Mode Hotkeys is lost, because those keys are stored for slots control in multireference modeling.That means, that default 2.8 mesh mode controls is incompartible with multirefrence modeling.
The solution that we use is to assign
(tilda) key to wm.call_menu (VIEW3D_MT_edit_mesh_select_mode)  This way we can access hot QCD slots via1keys (keeping slots access keys the same both for object and edit modes, that is useful for motorics and consistency), and switch mesh mode via ``12`3keys, that is almost fast as 2.8 defaults, but is compartible with multireference editing, and still way better thanCtrl+Tab+1,Ctrl+Tab+2,Ctrl+Tab+3` from 2.79.In edit mode, fast mesh mode control is just as important as fast QCD slots navigation, and this setup allow to access both of them at high speed and without inconsistencies.
That's why we would like to see this setup as part of QCD Edit Mode Hotkeys as well.
Ability to switch QCD slots in editing mode is necessary to bring the model in line with several references, located in other slots, so models that are currently in edit mode are needed to be always visible during switching slots operations.
So we would like to know - is it possible to lock visibility of slots, that contains objects that are in edit mode during slot switching?
It is important, because editmode objects can be placed in multiple slots, and you need to control current combination of them more thoroughly, or always use Shift+Num and Alt+Shift+Num just to find proper reference that fits better,
without losing the model that is currently being edited out of sight.
Locking visibility of slots that contains objects in edit mode during slot switching can make such operations way more convenient.
Given that there has already been a bug report filed about
123keys getting lost, I think I should switch the edit mode hotkeys to off by default.This is easy to do, but then we have another hotkey conflict because ` (tilda) is used for the view pie. What I could do is have it as a separate sub-preference under the edit mode hotkeys one, then it can be toggled on/off depending on preference.
Potentially. This differs from default blender behavior, so we need to be careful how we approach this.
I'll have to think more about this and get back to you. Another idea, instead of locking slots, is to move objects you want always visible to the
Scene Collection(I know you can't do that with the collection manager yet, but that may change soon).Added subscriber: @Vyach
@1D_Inc How do you feel about current QCD auto-numeration? Currently it assigns slot numbers based on the collection's position in the tree, but would it be better to have it just increment up to 20 and ignore the tree position? The current auto-numeration can sometimes result in numbers being missed and so gaps appear between slots. Doing a re-numeration fills in the missing ones, but it feels awkward to me.
@Imaginer ok, subscribed.
Despite it` configurable, it should not override main keys.
May be someone want It for very specific pipeline. But not by default.
Yes, QCD Edit Mode Hotkeys is a heavily workflow-dependent preference, that refers to mulireference modeling. It should be available, but turned off by default.
Yes, it replaces view pie assignment because of relevancy - there are several ways in Blender to set up view that duplicates such functionality, including num keys and also holding Alt during viewport rotation.
So there is no problem to set up view in Blender, but there is a problem to quickly switch edit modes, having numeric keys assigned to collections slots control.
Also, since this entire setup will be turned off by default, it should cause no problems, and also no sub-preferences are needed - it will be used in full or not used - at will.
That's why this preference is special - it provides complete optional solution.
Yes, that differs from default behavior, because 2.8 defaults were created without taking into account multireference modeling workflow.
That's the problem we are trying to solve - to make Blender compatible with multireference modeling again.
Basically, such locking ability was broken in 2.8, previously it was impossible to lose the model from the sight if it is in the edit mode.
And it is difficult to imagine really useful cases when you need to disable the object that you are actually editing)
We do this when we have one model and several references to control.
But the problem is that such cases are rare in our case, and slots are always occupied not only with references, but also with multiple parts of a complex model - an assembly parts, each of which has its own reference.
If to move part to the Scene Collection every time just to edit it, it can cause more troubles than solve, because you need to remember from which slot it was taken to move it back after editing.
So, it would be nice if you could investigate the possibility of locking edit mode slots.
It is really appreciated.
Update.
Scene Collection.Collection_Manager_v2_7_2.zip
@Vyach
This is off by default now, so this shouldn't be a problem anymore.
Blender allows you to exclude a collection while in edit mode with the outliner. All I've done is preserve edit mode when switching QCD slots.
@1D_Inc
I noticed that you can also switch select modes in grease pencil, but there doesn't seem to be a menu for it. Honestly, I'm wondering if we should even provide hotkeys to grease pencil. What do you think?
Yes, I can investigate it. I'll see what it's like if I prevent a slot from being disabled when its objects are in edit mode.
With the support for the
Scene Collectionthere is also a slightly more difficult, but slightly more customizable option available.Scene Collectionto add the objects to theScene CollectionScene Collection(if needed)Scene Collectionto remove the objects from theScene CollectionI feel like pressing Alt+LMB on the Global RTOs should bring up a menu with options to discard all, only copy, only swap, and only history instead of just discarding everything. Anyone have thoughts on this?
@1D_Inc
First test of locking QCD slots when in edit mode.
Note: This works for all modes other than Object Mode for all types of objects.
Collection_Manager_qcd_lock_slot_test_01.zip
Wow, so many changes here)
I like to see the representation of the initial idea of Scene Collection RTOs, that provides global scene control.
At the beginning there was a Scene Collection without RTOs and the need for Global RTOs to control the massive scene setups, so the idea was that it would be nice to combine them together, filling the void.
But I was afraid that it could be confusing, and decided to propose the idea of Global RTOs at first (as it turned out, not without reason - the idea did not pass through there).
Now it looks like this idea has reached full cycle, and I really like the design - it clearly splits Global RTOs from Local ones, and also provides Scene Collection accessibility.
It looks like the puzzle has come together, and everything fell into place, taking up just single UI line.
You outperform this, and, damn, I really like the way you made it =)
This is a masterpiece, a fusion of functionality and design, thank you so much for that!
Well, I think that it would have sense if those data were reusable or at least, accessible, like copybuffer or something.
As far as I understand, we do not have the need to observe or control this data, that makes it strightly temporal, so in my opinion it's ok to delete it with a single option.
Wow, that's going really intense!
I need some time to test the solution and provide complete feedback.
Thank you)
😄 You actually gave me the idea when you said you thought of the Global RTOs as being the Scene Collection's version of the regular collection RTOs. I realized that if I made it a row across the top and incorporated the Global RTOs it would fit well with the rest of the collections, but bypass all of the internal problems of it being a pseudo-collection. And it's so nice now to be able to move objects to and from it.
Sure, and if you need to clear it singly you can always just click on the original RTO. I have been considering allowing multiple uses of copy, but that would require a paste hotkey or menu entry somewhere.
I realized that if I made it a row across the top and incorporated the Global RTOs it would fit well with the rest of the collections, but bypass all of the internal problems of it being a pseudo-collection.
Yes, thoughts of such pseudo-collection internal problems also drilled my brain for a long time.
That's why I'm so excited about such a convenient solution)
The problem is that content of this type of data is not transparent to user to be actually used. It is way more easy to copy data multiple times by hand (in simple pairwise operation sets) rather than provide special menu for such kind of operations.
There are not too much global RTOs - only 5, and copying even all of them takes seconds, therefore, possible menu operations just will not save enough time or efforts to be relevant.
Tested QCD edit mode keys.
Thats so awesome to know they are possible!
Got two issues at the moment)
This makes it harder to find a suitable reference - every num key is needed to be presses twice (to show and hide) during search.
Basically, the behavior should be just like in object mode, with the only difference - slots that contains edit mode object should stay intact (visible).
Can you reproduce that?
You'll like this then, the global Scene Collection's name is
Master Collection, but since it's outside of the regular collections the name checking doesn't apply, so you can have a regular collection namedMaster Collectiontoo. It was fun trying to workout a way to differentiate the two. :P (I did though, so no problems)Me too! I've been wanting to support it for a long time.
Yeah, you're right.
Yeah, I noticed that when doing further testing too. I'll fix it.
I hadn't noticed this, but I'll look into it. It shouldn't be doing that ;)
Update.
Collection_Manager_v2_7_8.zip
Added subscriber: @Znio.G
Hi, is there away to disable the QCD in the header?
I like the addon but i don't want those 20 collections crowding it. Thanks.
For sure, a checkbox in addons preferences in addons section.
This affects the Collection Manager as well: blender/blender#75679. Do we want to disallow editing of RTOs if there are objects in Local View?
@1D_Inc
Couldn't seem to reproduce your bug, but here's another version of the locked edit mode slots for you to test. :)
Hopefully everything's good now.
Collection_Manager_qcd_lock_slot_test_02.zip
That's seems to be the same issue as loosing edited objects from sight. This mechanics seems to be just not designed properly.
But I think that this particular one is not so harmful, as loosing editmode object, and may even be useful in some cases. It is inconsistent, but this inconsistensy does not interfere anything, because local view is non-hierarchical temporal operation.
I need to think some more about it.
The only thing we forgot to support considering local view is remove from local view button, because M key is permanently occupied with Collection Manager.
I tested a bit and, indeed, it is different - objects in hot slots (regular num) are superstable now (I'm so excited), but, unfortunately, objects in cold slots (Alt+num) are super unstable - they are lost as if for them there is no lock.
I am using 2.82_official for tests, does it meet the requirements of the addon version?
My bad, i enabled the addon a long time and didn't check if it had options in the preferences, thanks.
It's not harmful to scene setup, but it could cause confusion to the user and when toggling excluded collections you can end up seeing all objects, but still be in local view.
However, I'm not keen to add a whole bunch of checks into my code when the outliner is still susceptible.
Didn't know about "remove from local view". Yes, that should be supported somehow in the Collection Manager.
This is super weird; I don't get any of that no matter whether I use 2.82 or 2.83. There is no internal difference between hot and cold slots. Maybe it's another addon that's conflicting, or some setting? Could you try disabling all addons except the Collection Manager and see if the problem persists? If it does, could you try loading factory settings (you shouldn't lose your setup so long as you don't save after) and trying it? Or if you're worried about losing your setup and don't already have 2.83 you can grab a copy of it and just not transfer your previous settings.
For sure! There are way more significant issues to fix and support than that.
I made full reset of 2.83, and it worked!
Guess, that was not because of addons (I use 2.83 mostly for locating design issues and inconsistencies), but because of a custom keymap, which I made trying to make b3d multiref comparible.
I will try to setup 2.82 from scratch as well. (It is needed to setup keys from scratch every time, because of the issue of loosing those peferences when importing keys)
Great!
This is weird. The only thing I can think of is that your custom keymap overrode the cold slot hotkeys with a similar operator that happened to switch to the same collections as the QCD slots.
Hopefully, everything's good now.
On a different topic, I know I designed the QCD slot auto-numeration off of a specification that you gave so that slots would start off in specific known positions, but with my current implementation of this, with allowing manual numeration, it can result in slots not getting numerated even though there are less than 20. I see two solutions to this: 1. Introduce a flag to the QCD slots to show whether or not they are user modified and if they aren't, then auto-renumerate the slots (this would result in slots jumping around). Or 2. Forget the position based numeration and just auto-increment until we have 20 slots.
And of course we could just leave things as they are and fill in the missing slots manually or by hitting the "Re-numerate QCD Slots" button, but I thought I should bring it up for discussion.
@1D_Inc And I forgot to ask, what do you think of the locked edit mode slots? Are they good to be included or do they need more tinkering? I kind of think that for toggling on and off references it would actually be better to have the
123keys toggle slots and theShift+1Shift+2Shift+3keys isolate slots, but this would be exactly opposite to how we have it everywhere else.Indeed. I would propose to use both of them in one solution - to start autonumeration from the collection with the least user defined number with autoincrement until we have 20.
In theory this will give ability to autonumerate some part of hierarchy down from a specific basepoint, and it will be needed just give number 1 to the very first collection and press renumerate to reset a system.
That could be pretty much controllable and predictable solution in my opinion. Everything will depend on what collection you will numerate as 1.
They are awesome. Close to perfection)
Yes, keeping editmode keys equal to object mode brings the consistency - same motorics for both modes.
Speaking of references isolation, it is more relevant operation than toggling (from my personal workflow experience), so everything is relevant and correct - more frequent action requires more simple hotkey.
I need to reset 2.82, setup it from scratch and perform some tests for proper check. It will take some time.
Currently I am in deadline on our main project, I was planning on taking a couple of weeks off after this sprint in order to get busy with the video and perform some proper tests.
In addition, the complexity of the project that I am currently doing has forced me to come to animating the references atlases by keyframes in order to have a better view and also keep them in a separate slots for quick access.
However, it feels surprisingly fluent, but I knew we'd get into that rotten stuff pretty soon.
Removed subscriber: @Vyach
Interesting. Let me play around with this and I'll get back to you.
Great!
Okay, good.
Since it seems like the edit mode slot lock is solid (and it's simpler and works better than what's in master now) I'm going to commit it it to master and 2.83. Unless you've found any new bugs or any old ones that are back?
Wow, that's a lot of complexity if you're using both QCD and keyframes. Good luck; if it's anything like the last one it'll be awesome! :)
It is also interesting to me, think it will be flexible and handy.
It seems to be working nice in 2.83, so why not.
Thank you)
Yes, that's the dirty truth behind Blender.
We are pretending that using it because it is free, but in fact, we use it because there is no other software that would solve the problems of our level of complexity.
And yes, that work is so complex, that animating 100% quads baroque modeling is my hobby to relax after work.
@1D_Inc
I think I found your bug. But if I'm right, it doesn't have anything to do with hot or cold slots, but with sub-collections. Putting objects in sub-collections and then switching slots seems to result in the behavior you described. Thankfully it happened to me in a final test before committing it. I'll let you know when I have a fix.
Here's the new version with the fix. Hopefully, it works properly now.
Collection_Manager_qcd_lock_slot_test_04.zip
Wow! Now it works properly in my 2.82 version without reset)
Thank you!
That explains a lot - after 2.83 reset I didn't provided any nesting collections for test.
That's why making and testing hierarchical systems is so difficult - it is hard to know what to expect, preparing test cases.
Everything can be important.
So that Good luck you wished for us with our project actually worked)
Also I found that Ctrl+Shift+Num in object/edit mode works as default - switching VV, allowing to hide editing objects, but I think it is okay and can be useful in some extreme cases.
It follows relevancy concept (complex action - complex shortcut) and we didn't got any actions left to occupy this shortcut, so let that additional degree of freedom be.
Excellent!
Ah, I thought that might be the case.
The problem here was that I forgot that each time you set the EC property for a collection it propagates to its children. This makes complex actions even more difficult.
I didn't even know about this hotkey! Since it's not getting in the way I'm quite happy to leave it.
QCD Numeration Test 01:
Collections auto-increment from 1-20 with no missed slots.
Renumerate button starts from the slot designated 1 and numerates from there in a breadth first pattern.
Alt+Renumerate button starts from the beginning and numerates in a breadth first pattern.
Thoughts?
Collection_Manager_qcd_numeration_test_01.zip
Update for blender 2.83:
Collection_Manager_v2_7_12.zip
Active Collection Control:
Currently the active collection is synced to to the selected row in the treeview, but this has problems.
Scene Collection.To solve problem one, the easiest option is to disallow selection of excluded rows; however this does nothing to prevent accidentally changing collections. The other option is to add a
Set Active Collectionoperator, which is what I'm demonstrating here. This allows you to always know which collection is active and makes it so that you have to explicitly change the active collection. Currently my test does not automatically set the active collection to the new collection when added.Another potential issue (that I haven't tried to solve yet) is with toggling QCD slots. Where should the active collection be set when toggling QCD slots on and off?
The new
Set Active Collectionoperator has replaced the collection icon to left of the name field (same place as theScene Collectionhas it).Collection_Manager_active_layer_collection_test_01.zip
Wow, so many improvements here)
It intensifies insanely in my opinion)
Aw, yes)
Precise and powerful like carpet bombing, covering array indices. Do you feel that?)
Interesting Alt reset solution, by the way.
I like reset works also when there is no №1 collection, that allow to avoid possible inconsistencies.
A very nice idea!
So now we can control where we are creating objects)
I like that it correspons to QCD slots toggling, since it allow to create objects in dynamic context, finding appropriate collection by content - with navigating slots. That type of control is very useful for complex modeling like assemblies lowpolyzation.
That's too much I can handle at the moment)
Sorry, it goes really intense)
Yeah, I really like it. 😄
Well, with the new type of renumerate I can't preserve overridden slots; so since the previous alternate action for renumerate was basically "start from the beginning" I thought it was a good fit.
Not sure about the hotkey though, because:
I added another option to renumerate to try. Depth first renumeration (currently Ctrl+LMB, but it might make sense to switch this with Alt?).
So I'm not sure what hotkeys should go where.
Collection_Manager_qcd_numeration_test_02.zip
The active collection was previously synced to the selected row in the tree view, so technically, you always could. But I realized that it was kind of a hidden feature and it was causing some problems, so now it's more explicit.
What I'm still not sure of is:
123) or left as its current collection. (It seems to me if it was left as its current collection it would be harder to lose where it is)** (isolate QCD slot (
123) is good and should definitely set the active collection to the isolated slot)Scene Collectionnow that the selection doesn't control the active collection, or should we just leave it selected. (currently it deselects)Apologies if you've answered about QCD and I just didn't understand.
Tree Structure Display Test:
Here is a test to more explicitly show the relationships of the collections in the Collection Manager popup. I know it needs better icons, but I thought I would post it here and see if it's useful or just clutters things up.
Collection_Manager_show_tree_structure_test_01.zip
Don't worry about that, it's just a few small bug fixes to provide more stability, and the QCD edit mode support which you've already tested.
It was mostly just a housekeeping update.
Don't worry about it. Take your time; no rush. :)
@Imaginer mentioned this in 3970006315: Collection Manager: Fix QCD numeration. Task: #69577 .
I think Ctrl is good, because it more about control of the numeration way, while Alt is more about negative alternative - anti-action, like reset, and Shift is more about misc actions, like local shifting.
We use Ctrl for controlling nesting for local RTOs, so it feels like similar action for numeration. I think we are controlling the way nested collections are numerated.
Yes. Here is how I think:
New collection usually is created for such a things:
So in two cases this will not interfere, an in one case it is strightly needed. I didn't found other cases, that can require not setting active, like creating empty collection without immediate actions with it, and I would like to know if such cases exists.
Yes, it allow to control active collection via visibility. The collection that was turned on last becomes active, this way we can control active slot without any GUI during QCD navigation sessions.
For example, if we want to add a lowpoly object version to the slot that contains lowpoly objects, we need just to turn it on last.
It also allow keep logics the same both for isolating and adding. The single rule - what you saw in the last one is active - makes handling active collection predictable in dynamic context, because content represents context there by itself.
I am not quite sure what is the function of selection highlighting. What is the functional difference between highlighted collection from not highlighted?
Highlighting adds an add-on GUI responsiveness (you can select something without changing something, so you feel more "safe", also you can be sure that you are editing right RTOs, because entire row is highlighted, so you can set highlighting, when you found appropriate name, and then concentrate on RTOs operations without fear accidentally edit the wrong line, so it is a bookmark), but is there anything else behind this, that I may not to know, that makes it not strightly temporal?
I think, the question behind this question is "can we afford to loose bookmarked collection when we are switching to Scene Collection?"
I think both answers are appropriate (yes - it is temporal, no - it is a bookmark), and more tests are needed to get the best from them.
I think that keeping highlighted different from active can be used for sending highlighted collection to an active in imperative way - set source, set goal, perform (without outliner realtime dragging that requires motorics and luck), that can be useful in long lists or filered lists for scene organizing.
Well, dividing a task from a concept into points is a very wise decision in development that helps to clarifiy the situation and satisfy certain conditions. A nice move!
It is nice temporal mockup to display a concept.
At this point of development CM have nothing to do with collections hierarchies - it doesnot influences them (yet), working as a static shapshot list.
We've got skew to control hierarchies for operations we perform with RTOs, I need to think and test some more to find cases when it is strightly needed and solves some existing problems.
Currently I would definitely like to propose to remove angle sign for 1st level collections. They are hosted by the Scene collection, and we know it so much that their designation is not required, so they are just messing with triangles readability)
Okay, thanks =)
That's what I ended up deciding about Alt too. I decided I would only do breadth first for the fix/cleanup for 2.83 because that's what everything has been based on. But I'll add in "depth first" on Ctrl for 2.90.
I can't think of a case that would require the collection to be not active, so I think we're good. And it's nice and easy to see which collection is active now.
Ah okay, so everything should be good then. I hadn't thought about that, but it makes perfect sense.
Selection Highlighting currently controls under which parent a new collection will be added (hopefully later it will control which collection it's added after too).
Thanks. :)
For me it solves the problem of showing the hierarchy correctly. Skew works, but it's easy to miss what depth something is at in big complicated trees.
I kept them around because they made things consistent, but they do add a lot of visual noise. So I'll try a version without them on the top level. And I'm hoping to try one with custom icons that aren't so intrusive.
Update.
Note: You always had some control of the active collection (it was synced to the tree view selection), but it was very buggy and misleading. Now simply click the collection icon to set the active collection.
Collection_Manager_v2_7_16.zip
Object selection test based on suggestions from the blenderartists thread post 108 and on.
(See the post for details and hotkeys)
Collection_Manager_object_selection_test_01.zip
Hi!
Found a typo in the description.
Alt+Ctrl for Swap action.
Good catch!
Fixed.
Operator alignment test:
Collection_Manager_multi_align_test_02.zip
New object selection test:
Collection_Manager_object_selection_test_02.zip
See the blender artists thread for more information: https://blenderartists.org/t/release-addon-collection-manager-feedback/1186198/127
Aw, enabling all QCD slots?
Yes, there is such kind of need.
We are using Shift+' combination for toggling between all slots and actual slots combination, I was about to propose it to edit mode slots keys.
This allow, for instance, quickly check slots content in order to expect it during navigation, or quickly figuring out what slot you need to add to actual combination by making selection.
Its all because of dynamic context.
You are spreading context by slots, you are joining context by slots, the work flows, and you don't care about remembering where is what, because you have ability to temporairly turn everything on and make sure what you need or may need)
What about Shift+{key =} ? It's on the same row as the rest and it represents the plus key which seems like a good way to remember it.
I probably should have done this to begin with, but with the changes in blender/blender#74157 I guess I'd better add a menu entry for the Collection Manager, and maybe for other things, for 2.90.
The problem of Shift+= is that it can't be pressed with a single hand.
So when you need to temporairly view everything, paying attention to a scene, you have to interrupt that attention and search for = key.
So we are using
1`2``3for switching edit modes and Shift+` to toggle all slots between actual layout and everything turned on - this way tilda button is always in control.I think it would be nice if you will provide an operator to test the better shortcut option.
Also, it can be reassigned to any shortcut manually, so let it be Shift+= by default at this point, since it is free =)
So I think it is nice solution.
General Update:
Collection_Manager_v2_7_19.zip
General Zip Update:
Collection_Manager_v2_7_23.zip
Hi All,
I just found a bug with QCD and armatures that are in Pose Mode. If you try and switch to a collection that has an armature in Pose Mode you get a python error. Now this can be solved in a couple ways, but since I don't do that much animation I thought I'd get peoples opinions. Here are the options:
A similar problem is present with Weight Paint Mode (although you don't get the python error, there is a problem toggling slots) with the same possible solutions.
Another thing I just realized is that the default
1,2,3, hide collection shortcuts that I've overridden with QCD shortcuts in Object Mode are present in Pose and Weight Paint Mode as well. I'm thinking that the Pose and Weight Paint ones should be overridden too. Any objections to this?And finally, I'm sorry to mention this, but bcon3 (bug fixing) for blender 2.83 ends on May 27, so if I could get your thoughts on this sooner rather than later, that would be great!
Thanks!
Hi.
I think that everything that is not object mode is similar to edit mode, since you focused on one object in that modes.
Also not sure that QCD is useful in weight paint mode, but it can be useful in pose mode for switching environent visibilty.
Hope these thoughts are helpful.
@1D_Inc Thanks, this helps.
Here is a test of option 2 with the hide collection shortcuts overridden for Pose and Weight Paint:
Collection_Manager_qcd_fix_pose_weight_paint_test_01.zip
Given the time sensitive nature of this I will likely use this fix for 2.83 unless anyone has any objections.
I tested a bit and I liked it.
It feels natural regardless of QCD edit mode keys checkbox on or off.
Nice solution)
Since no one had any objections to my proposed fix and @1D_Inc approved of it, I have committed it to blender 2.83.
Zip Update:
Collection_Manager_v2_7_26.zip
Well, we can use an active for bookmarking collection, I guess)
Found an issue with linked collections (linked with ctrl+LMB drag in outliner). They are not displayed properly in hierarchy, and inherits level position of one of them.
Here is file with 3 linked collections called LINKED for example.
Is that issue known?
LINKED_COLLS.blend
I know, I wish it could have been possible to use the selected row as a bookmark, but the jumping around was just untenable and changing the selection was the only way I could find to solve it. But using the active collection as a bookmark is a good idea.
No, although this isn't entirely unexpected, I hoped we'd never run across this. Thanks for finding it (and for providing the blend). Unfortunately, skew is just one of the symptoms of the root problem.
See, I've been using the collection's name as a unique id because I haven't been able to find an actual unique id for layer collections and it's worked reasonably well until now. I actually hadn't thought about linking collections, so we'll probably have to fine tune their behavior as well after fixing the bug.
Yes, hierarchical structures like collections in Blender are hard to be represented properly.
At least we will know about that, since absence of ability to handle collections by unique id is kind a collections system design issue.
The collection system was not designed to complement hierarchical management.
I guess they were only focusing on managing collections with the Outliner.
Currently, I'm thinking I might be able to make this work by getting the memory address of the collection with
as_pointer()and using that as an id.How about mentioning it here?
https://developer.blender.org/T68974
A very nice news, view layer cloning )
https://developer.blender.org/D6862
Yeah, that's probably a good idea. Will do.
This is wonderful!
@1D_Inc Here is a test fix for displaying linked collections. It doesn't support saving and loading QCD slots, but should hopefully be as stable in everything else as the current release. During testing, I found that both it and the released version have a bug where QCD slots can swap collections when renaming and undo/redoing. This bug is unsolvable without actual unique ids on LayerCollections. Depending on whether addon fixes are allowed in 2.83 updates, I may be able to add it to the 2.83.1 release, but moving forward I hope to be able to get a real unique id for LayerCollections. Given that this is a fundamental change, I'm not even sure if it should be added to 2.83 when it's (hopefully) going to change for 2.90.
(Unfortunately this will mean that after switching over to proper unique ids (not the test fix) the addon will be entirely incompatible with any versions prior to 2.90)
Collection_Manager_id_test_01.zip
Since this is such a fundamental change, there will be much more limited development on other features until this is sorted (whether that's a more complete version of this fix, or hopefully, real unique ids).
So, to help pass the time, here are some tests (old and new) to play around with.
Collection_Manager_advanced_rto_menu_test_01.zip
Collection_Manager_horizontal_scrollbar_test_01.zip
Collection_Manager_multi_rto_alignment_test_03.zip
Collection_Manager_object_selection_test_06.zip
Wow! Well, I don't think proper linked collections display deserves attention, since it is dependent on API limitations.
We made our best with defining the reasons)
Better this will be a known issue until a unique identifier appears.
For sure, because if api changes.
That's interesting, thank you)
But currently I am busy with finishing video.
As it turned out, the screencast and ending parts are not as simple as it seemed, I preparing separate scenes for demonstrations that lasts seconds, and still don't like the result. It takes almost all the time.
It needs to be completed, so I took leave from work. I use default CM, supplied with 2.83 for demo.
Yeah, I've kinda been leaning that way myself, but on the other hand people could be using 2.83 for two years, so I'm not sure what the best course of action is.
Right, well, it will give other people something to play with then :)
Wow, yeah getting something you like can be hard. Thanks for all your hard work on this.
I've thought of some more feedback, so I'll try to get that to you soon.
I've started a patch for LayerCollection IDs.
D8024
That's wow!
It goes really deep, that's awesome news!
Added subscriber: @Harvester
@1D_Inc has finished his workflow video on the Collection Manager. It's awesome.
Check it out here: https://www.youtube.com/watch?v=yiti0xWO7Wg.
Thankyou!
I think it would be better to place it in the subject post)
@1D_Inc Done. I did that in the blenderartists thread, but forgot about doing it here. Thanks for reminding me.
Zip Update:
Collection_Manager_v2_9_0.zip
Nice!
I like that alternative numbering is now available, and breaks the limit of the branch.
But how about to make it completely hierarchical independent?
Let it just count 20 collections down from the first one, like if list is flat - this is the only numbering method that can afford such behavior.
So there will be hierarchical numbering as default, that respects hierarchy, and linear numbering as alternative, that doesnot respect hierarchy, and seeks to fill all 20 slots in a linear way.
So you want to replace depth first ordering with non-hierarchical? I'm not sure it's a good idea to replace it. I think it would be a better idea to add it as an option and use a new hotkey (Ctrl+Shift?), but regardless, I think it might be possible. I'll have to experiment a bit.
Cool idea ordering pattern, though.
Okay, yep, that ordering pattern is possible.
I just don't see the reason to limit new alternative linear numeration pattern, available at Ctrl+LMB, with some hierarchy - since it is strictly linear)
This numeration pattern affects collections on higher levels as well, so it may not always be desired. I'd like to first see if anyone on the blender artists thread has any objections before changing it. Another thing which might help is if I add a "limit to branch" function on shift (so only the collection designated 1 and its children are numerated) for both breadth first and whatever depth stuff we decide on.
I am not sure how limit to branch function can affect both hierarchical (breadth first) and linear (whatever depth) numeration. I mean - mathematically.
Yes - in linear numeration, when we are numerating lines, it affects collections on "higher" level, but there is not a big choise - to not to numerate them, saving numbers (like it works now - it saves numbers ...for what?) or numerate them and don't use in case they are not needeed.
I do not see much benefit from this kind of non-numbering during the restriction of linear numbering, which numbers lines, with such a hierarchical dependence as the branch level.
What I was thinking, is that if you want to focus on a branch then numerating the others just adds clutter, but I could be totally wrong. Anyway, I'll put out a test with just the non-hierarchical depth first ordering and see how people respond to it, and maybe a limit to branch function, and we'll go from there.
Lets test it, it is the best way to be done)
Yes, it adds a clutter, but since it is linear, it is easy to track which numer is the last you are interested in.
Also it is easy to remove the next number manually to form a gap in slots locating desired branch, so there are several options to quickly fix a clutter if it takes place in my opinion.
I updated the diff for LayerCollection IDs. It now works for all View Layers and is much closer to being functionally complete, whether the main devs are happy with my implementation, well, we'll just have to wait and see :P
And I found a bug in the Collection Manager while I was at it ;)
For more info see https://developer.blender.org/D8024
Awesome news! This will help to represent collections list completely and correctly in any form, maybe even treemaps =))
(sometimes I trying to figure out what is the best way to represent such complex structures that collections allow to form)
(still have no idea)
Zip Update:
Changes:
Collection_Manager_v2_9_1.zip
As asked for on the BlenderArtists feadback thread.
Here is a test of removing all empty collections. Let me know if everything works right and if everyone’s ok with the ui.
Collection_Manager_remove_empty_collections_01.zip
Bug fix for the remove all empty collections test that I posted to the BlenderArtists feadback thread, but forgot to post here.
Collection_Manager_remove_empty_collections_02.zip
Remove Empty Collections:
Collection_Manager_remove_empty_collections_03.zip
Undo Test:
Collection_Manager_undo_test_02.zip
(and no there was no undo test 01 that you missed) :)
Test of replacing depth first renumbering with non-hierarchical, plus a test of constraining renumbering to a single branch. So now LMB renumbers from the slot designated as #1, ctrl switches the renumbering pattern from breadth first to non-hierarchical (similar to depth first), shift will constrain renumbering to a single branch, alt will ignore the slot designated #1 and start from the beginning, and all of these can combine with each other.
I modified the tooltips to hopefully, better reflect this and because there wasn't enough room to list all of the key combinations.
I don't know if all of this is useful, or if replacing depth first with non-hierarchical is a good idea, so let me know what you think.
Collection_Manager_non_hierarchical_constrain_01.zip
I like the way he behaves, especially if you take into account the collection designated as 1.
It works like an anchor, so you can just quickly iterate over all options/shortcuts until you will find appropriate one.
So I think the whole concept works well. Nice job)
Thanks. It doesn't allow you to completely replicate the depth first renumbering pattern, but it's close and probably more useful, so as long as no one complains we should probably just switch to this. I'm wondering though, if it would be better to switch things around so that non-hierarchical is the default and breadth first is the alternative? I'm also wondering if there's a better term to use in the tooltip than "Non-hierarchical".
You haven't mentioned anything about the second remove empty collections test I put out, so I'll assume everything's fine with that. And having undo should hopefully make moving objects to collections less risky, and so allow object selection to be grouped with moving objects. At least, that's what I'm hoping :)
I forgot to post this condensed UI mockup here (I posted it in the BlenderArtists feedback thread). This is just a couple of ideas, none of it is set in stone. The only thing I think we should definitely have is the Global Actions menu, next to the Display Options, for things like the Remove Empty Collections operators.
edit: This is a gif, so click on it to play.
@1D_Inc I won't be offended if you don't like it (I'm not even sure if I like all of it). And I know that this would be a radical change to the UI, and your workflow video has just come out, so even if you do like it, we may want to change stuff over slowly.
What about "Linear"?
Also "Reset" seems to be the best description for Alt action in my opinion. It feels and behaves like reset, because this is the only action that affects an achor - the very first collection.
I didn't found it in the inteface. Tested version looks like that:
Well, you know my opinion about condensed UI.
Nice mockup anyway, good point to start from to evolve somewhere)
The only thing that I found inappropriate - placing Renumber button to that list. This is not a “one-action” function, since it has modes.
Linear and Reset sound good.
That's very weird. It should look like this:
Here is the zip of it.
Collection_Manager_remove_empty_collections_03.zip
I know, but we're starting to run out of room, so it's time to start experimenting.
Thanks. Maybe we should start with just the Global Actions menu and condensing the Collapse/Expand All button? That will give us more room without changing the UI too much.
You can actually trigger all of the modes from the menu with the regular shortcuts (I tried it), But that's definitely non standard UI behavior, so we probably shouldn't put it there. Though the extra space was nice.
Nice!
Yes, it looks like this now.
I've got issue with linked collections (in that file that I sent some time ago)
I guess, it also requires unique id's?
Also I would like to think about better names for deleting collections functions.
Currently those names forces to think much before using.
In fact, the choice that is made before the function launch is to delete only the final collections (collections in the end of hierarchical branches that contain no objects) or in the middle as well.
It is hard to define which one will remove more collections, and which one is safe)
I think their names should represent this, because it will make the choice intuitive, but I don't know how yet.
Maybe give them different names like "Purge empty collections" to remove any empty with no objects, and "Remove empty collections" to remove collections with no objects and collections.
The main issue is that the result is expected in the main window, and it is more fragile even than exand/collapse or maybe even add collection/subcollections, because they does not require checking the result that carefully.
You always carefully check the result after numbering, so I think that numeration has the least usability being placed in popover from the most functions presented in CM =)
I would like to propose Specials name, or something different from Global Actions for one simple reason.
We have Global RTOs, and some RTOs, that are not stored in view layer, perform Global actions (for example, DV description is Globally Disable in Viewports)
There are too many Globals with too many contexts already =)
No, that's just a regular bug, and affects the regular remove operator too. Blender doesn't allow two links of a collection to exist with the same parent, so if you try to move them side by side in the outliner the one you're moving gets discarded. I just need to make sure I don't try to link a collection to one that already has another link of it. It should be an easy fix.
Sorry, I think those names are too close to each other and would cause even more uncertainty. Both of them say to do "something" to "empty collections", so you would expect them to act on the same set of collections.
Yeah, we should keep it on the main window, plus going into the popover multiple times to try out different numeration patterns would be annoying.
You're right. I didn't realize how many Globals we had until you mentioned it.
Specials would be okay, but I was thinking something more general would be better because it'll probably end up as an overflow so the main window doesn't become too cluttered. If nothing else comes to mind we'll go with Specials.
Remove Empty Collections Test 04:
Collection_Manager_remove_empty_collections_04.zip
Since nobody has complained about my Undo Test I'm planning on adding it to master tomorrow, so there will soon be undo buttons on the top row as well as the specials menu.
Thanks, I'll see it later.
What kind of undo test? O_o
The undo test in post #975745. It adds undo/redo buttons beside the Renumber QCD Slots button on the top row. This allows you to undo and redo things right in the popup.
Here is the zip again.
Collection_Manager_undo_test_02.zip
I tried both, and all of them are looking good.
I like the appearance of Specials, its placement and also names of deleting functions - the difference between names work nice, it is easier to remember that Purge is longer and more destructive, tooltips are helpful and clear.
About undo - it don't influence isolated or global blue highlighting, maybe it needs to be considered.
I like the concept, it is nice to have the possibility to control list changes without popup session interruption.
By the way, how undo works? Via redirect to regular undo?
Excellent! :)
Yes, that should definitely work, bcon3 is tomorrow, so I'm going to add it anyway, but that will be fixed soon. I think I just need to add in a check/reset for that.
Yes, and this way mistakes can be easily recovered from.
Yes, I created a wrapper which calls the regular undo operator and regenerates the UIList. I guess I need to add a history check/reset to it now, too. :P
Well, it turns out that there are more issues with the undo operators than I initially thought, so they probably aren't going to get in for 2.90.
Well, okay. Undo is pretty much complex thing, thats why heavy professional hierarchical systems have separate undo engine as well, which was commonly ignored during collections engine design.
Lets concentrate on stable features)
Zip Update:
These are the final new features that made it into blender 2.90 (it's bug fixing only now), but I'll continue working on new features, they'll just be going towards 2.91, though.
Note: this makes no difference for anyone who downloads the zips, you can use them with any blender version, it only affects the daily builds.
Collection_Manager_v2_12_1.zip
@1D_Inc Here is a test for Holdout and Indirect Only RTOs. Since they act in an opposite fashion to all the other RTOs I'm not sure exactly how they should behave with regard to the advanced operations.
It seems backwards to me, but maybe this is actually correct? Anyway, let me know what you think (especially about copy/swap).
Collection_Manager_hh_io_test_01.zip
Wow, so many approvals have been consolidated in one release. Thank you, it will definitely take some time to test)
Indeed it feels backward, its action is inverted - options that are turned VV on turns HH off (VV on = HH off).
I can understand why such decision has come out - HH and IO have inversed behavior by their nature (turning on both of them makes objects invisible on render), but this should not be reflected in management.
There is an example, that contradicts usability of such a solution - swap case or backward copy, when we set explicit RTOs setup from the Implicit one in order to check it.
In current solution (VV on = HH off) those action disallow to detect objects that are masked or indirected - as a result of those actions we see the "the rest scene without them", that is not actually useful, because requires invertion of a whole VV state to detect what exactly is masked or indirected, or "guess" what is masked or indirected.
In direct solution (VV on = HH on) we can detect such objects directly and immediately, and, I guess, it is the most interesting for user in using this feature - to set /see what objects will be actually masked or indirected in order to have the ability to observe and control them, taking into account all the possible hierarchical complexity.
In short, I think that direct solution (VV on = HH on) is better, because
I made some express test, and overall it look nice.
Tested Apply Phantom mode, it is gorgeous and look superstable)
I am not sure about "permanent" word in the tooltip. Maybe "Apply changes and quit Phantom mode" will be better, but I am in doubds.
Renumbering is cool and fluent. Maybe, Ctrl+Shift combination should be mentioned in the tooltip as "Constraint to branch linearly" or "Linear, constrain to branch".
Found that purge all collections delete one linked collection (from that LINKED_COLLS blend file), even if all of them contain objects.
I still use 2.83.13, maybe it influence that issue, and I should update my Blender in order to provide testing better?
What is the current state of development for unique identifiers?
I was thinking that too, but I wanted to be sure. :)
Both work. "Apply changes and quit Phantom Mode" may be a little clearer, so if you want to change to it we can.
We only have a limited amount of space in tooltips, and all hotkeys for renumbering can be combined with each other, so I would rather not single out a key combination. Maybe "Switch to linear pattern" would be clearer than just "Linear"?
This is expected. A parent can only contain one "link" of a child, so during the purge one of the LINKEDs tried to shift into a collection that already contained a LINKED and got discarded. It's a quirk of linked collections and the hierarchy.
2.83.13 is fine. Theoretically, the addon should work with Blender 2.80.
I talked to Brecht about the problem, and while he isn't willing to accept a uuid system for LayerCollections, he would condone improving the stability of LayerCollections (which would fix other LayerCollection bugs) and converting them to ID properties. So it's kind of back to the drawing board code wise, but at least I know what they'll accept now.
In case you were wondering, ID properties won't solve our problem on their own, they don't actually contain ids (well, they contain an id that's valid for a single session, but it's not available to python), but they do allow you to store custom data, so I can assign them ids from python which will be persistent. But the first problem I have to tackle is making LayerCollections stable.
So, it's going to be a while yet, but hopefully, everything will work out and we'll get a few extra bugs fixed in the process.
Nice)
I think it deserves to be changed. Phantom mode is a special mode, so "making permanent" sounds suspicious.
Like DV RTO - it have "Globally disable in viewport" tooltip, so you have to decrypt "Globally" is for yourself like "is not stored in VL" in order to define proper conditions of use.
"Making something permanent" sounds like making something completely unchangeable, so it can be easily interpreted wrong.
Yes, I guess there will be no serious consequences if we miss that shortcut combination in the tooltip)
Both of them are out of being self-representative - you have to try this mode to understand what is means in both cases.
So I think that short word will make it look less confusing - this way it doesnot look like "some complex thing that we've tried to explain".
I thought a bit about that and I found it is logical from the point of using - I didn't found proper cases when you need to protect such hierarchical structures from purging, so I think it is ok to purge them like that.
Also I think that the "Purge" word fits nice for such kind of behaviour, so I am glad we named deleting functions differently.
Nice) You will let us know when we need to update.
Wow. That's deep!
Yes, I suppose it will take a lot of time and effort, since this is the material on which the whole system is built, and stability is the very first requirement.
Thank you for the answer)
Okay. Will do. :)
Okay, I'll leave it then. That's easy :)
Excellent! :)
Definitely. If the minimum required version increases from 2.80 I'll announce it here and on the BlendarArtists feedback thread, immediately.
Yes!
And here is a new test of the Holdout and Indirect Only RTOs:
Collection_Manager_hh_io_test_02.zip
Hopefully, everything is useful and working properly now.
Plus, I found out that neither [HH] Holdout or [IO] Indirect Only are chain dependent. They're both like [EC] Exclude. (If I've missed something subtle that makes them chain dependent, please let me know)
Yes, it works nice! Now we can easily distinguish holdouts and indirects via swapping with EC!
Indeed.
I checked several 2.80, 2.82 and 2.83 blenders I have - HH and IO are non-chaining there. Maybe I used some other build, or, I guess, I decided that because of design flaw - HH and IO icons grayed out when chaining collections are off,
so visually they behave similar to chaining RTOs, but, in fact, they are non-chaining, and that icons graying means nothing to them.
So, all "collections only" RTOs have non-chaining behavior.
Well, yet another UI design confusion. Not surprised though.
Yes! I didn't realize how much it was needed until I tried it out! It's very nice to swap them for a quick preview/setup.
I wouldn't be surprised if that's it. Greying them out like that is very confusing. A patch fixing that would probably be accepted, so maybe someone will submit one someday.
Yeah. Another thing with these two, is that they only work for cycles, but they are still present when you set the render to eevee (and workbench) even though they have no effect!
I would much rather they were omitted when a render engine other than cycles is selected.
Yeah, that's the power of viewing/editing implicit as explicit - direct control over setup)
By the way, what do you think about implementation object selection functions?
I mean collection/QCD slots object selection and Select all cumulative objects Special.
Select all cumulative objects Special seems to be the very first tool that will allow to control cumulativity in Blender in any way.
Cumulative objects can be viewed/controlled this way, and filtering such a selection in CM will bring the list of cumulative collections as well.
In my opinion, the ability to controlling cumulativity is important for making predictable scene setup, since cumulative collections sharing the same objects can have different RTO settings.
Thus, cumulativeness is a non-hierarchical solution applied to a hierarchical system that cannot be controlled in any form at the moment.
I'm happy to add in the ones to the QCD header widget, but I want to hold off on the ones for the CM popup. I was never happy with having them attached to the active collection operator, but my solution for including them beside the set object operator requires undo support, and further testing.
Sorry, but what is this supposed to do? I think you've only mentioned it in passing or I've just forgotten what it is, but, what is a cumulative object?
Aw, that's simple.
A "cumulative" object belongs to several collections.
The collection containing such objects also becomes "cumulative".
This way, being "cumulative" means being "out of regular hierarchical dependency", "crosshierarchical", since the same object here belongs to several collections that may be on different nesting level or even branches, and have different RTOs setups.
So, select all cumulative objects special will select all objects that belong to multiple collections (objects with more than single collection assignment)
Ah, okay! This should be easy to add. I'll look into adding selection stuff after I finish up with #78985 (which should be soon).
Zip Update for 2.90:
Collection_Manager_v2_12_4.zip
A very nice design movement)
Indeed, QCD widget is small enough to fit such condition)
Yes, it looks better in my opinion - it is short and pretty much straightforward.
O M G.
This is glorious.
I've tested it on 10k objects and the performance difference is just insane.
Such a beautiful optimization, how did you even made that??
Added subscriber: @OlegBondarev
Thanks :)
Excellent.
Short Version
get_move_selectionandget_move_activeto use and return python sets instead of python lists (sets are much faster in this case).get_move_selectionI switched from looping through the selected object names, appendingbpy.data.objects[name]to a list of objects thatget_move_selectionwill return (very slow), to a hybrid method that uses the old method if only a couple objects are selected, but if more are selected then it loops throughbpy.data.objectsonce and creates a set of any selected objects and returns that (this is much faster with medium - large numbers of selected objects).get_move_selectionandget_move_active.Long Version
Well, first off I have to thank @OlegBondarev for making me aware of the issue, I don't know if other people mentioned it and I just missed it or what, but I didn't realize the addon was slowing things down that much until @OlegBondarev reported it as a bug.
After checking the performance with 10k cubes, I was able to trace the slowdown to the
get_move_selectionandget_move_activefunctions that I created to allow for moving objects to and from excluded collections. It turned out that there were two problems with these functions, 1. they were very slow, and 2. they were getting called much more often than needed.Let's take a look at problem #1
Solving the slowdown in
get_move_activewas easy, I just had to add an option toget_move_selectionto return a set of names instead of havingget_move_activerebuild it from the list of objectsget_move_selectionreturned.Optimizing
get_move_selectionwas a little trickier.Originally, I looped through a list of names of the selected objects that had been stored and retrieved each object by name from
bpy.data.objects, this is because I can't store the objects directly because they sometimes get invalidated. But unfortunately, it turns out that the data structure that isbpy.data.objectsseems to find your requested object by looping through the whole list of objects and going "is this the object we want? no. ok, let's check the next object", and so on until it finds the object that was asked for. So the more objects you have, the longer it can take to find the one you're looking for depending on where the object is in the list, and you end up looping through most of the objects many times, further decreasing the performance. To improve this I ended up looping once through everything inbpy.data.objectsand checking if the object is in the list of selected items. And because all object names have to be unique I could use python sets for everything, which makes checking for membership much faster. But there were still cases where looping through the selected object names and getting them by name frombpy.data.objectswas still faster (like when there are no selected objects), so I made it so that if there were 5 or less selected objects it would loop through the selected object names and look it up by name.Now for problem #2
This one was simpler, I made it so that the calls for the get selection and active functions were only called once for each draw of the QCD widgets. For the tree view in the CM popup, usually everything is done in a separate draw call for each item, but I realized that I could use the draw call for the main popup to get the selection and active object once and then set class variables for the UIList and access it from each item so the selection and active functions only had to be called once for each refresh.
I know this is long and somewhat confusing, but hopefully my explanation makes some sense, and I thought your question deserved an in-depth answer.
Also, keep an eye on the selection status indicators. Everything should be fine, but after a change like this I want to make sure there aren't any regressions.
Such a nice solution, thank you for the explanation!
I also faced this issue, for example, during making footage, but I didn't recognized it as an addon's problem - I thought it was Blender collection engine perfomance troubles (like undo issues, for example)
It is so great it was detected correctly and fixed)
Yeah, stuff like this is very easy to miss. Hopefully there aren't any other issues like this. :)
Added subscriber: @renderluz-2
I think I have found a bug, I will make an official report later but I wanted to inform you of this as soon as possible as its a rather strange problem, the QCD hotkeys are still active even if the addon is turned completely off in the addon manager, this is to say in 2.90 and 2.91 current builds if I click any of the numbers of my key board the layers assigned to the QCD will turn off and on, even if the addon is turned off, also while its turned on I tried to un tick the Hotkey option, I looked into the hot keys in the preferences and it indeed creates or deletes the hotkeys, however even if the hotkeys are deleted by un ticking the option in the addon, if I happen to click any of the numbers of my keyboard the layers will become invisible, its like the hotkey system is embedded into Blender some how, which is really frustrating as I dont really use the hotkey system so I rather have it off, but now if I accidentally hit any of the number keys my layers go away without me wishing to do so.
Ah! I found the problem, this was driving me nuts for a while, there are some hot keys that are not related to the manager, that serve the purpose of hiding the QCD layers, and they are by default in the key binds even of if the addon is not active, maybe those hotkeys should be controlled by the addon instead of just being there by deafult? go into the key binds and search for "hide" you will find this lists of hotkeys called: "Hide Collection", the operator coding string is: "object.hide_view_set" "Collection index 1" 2, 3, 4..etc... there's one for each of the number keys of the keyboard, after I disable all of them I no longer make the QCD layers visible or invisible even if the addon was off, or the option for the hotkeys was ticked off.
Hi.
There is no problem, this is default blender behavior.
It was presented before CM addon in order to satisfy Muliref modeling.
If you don't need to manage collections visibility via hotkeys, feel free to redefine numeric hotkeys to whatever you want or need for your workflow, or even remove their assignment.
This issue with default Blender's behavior (using the same keys for different actions in different modes) was also shown in the Collection Manager video.
Hi @renderluz-2,
Thanks for your interest in the addon. As @1D_Inc said, those hotkeys are part of the default blender keymap. As you found out, the default hotkeys are for the
object.hide_view_setoperator and not part of the Collection Manager and its QCD system; the addon overrides them to provide a similar, but more stable, implementation for Multiref modelling.I hope you're enjoying the addon, and if you have any questions/concerns/ideas/feedback just let me know! The more workflows and use cases I hear about the better the addon can become.
Thank you for the explanation :) from my own user experience the fact the Collection Manager has an option that fully disable the QCD system while Blender still has some part of the functionality regardless if the addon is active seems like an unnecessary redundancy, I get this hotkeys were there as part of the legacy systems of Blender, but if the add-on is mean to controls the QCD and it's now shipping as part Blender then having those hotkeys by default seems unnecessary, and can cause confusion to the user, this is just my opinion tho, if the hotkeys stay where they are I can just deactivate them like you mentioned, still the way I see it they could be removed entirely and just use the addon as the main controller for that kind of behavior. Unless this hotkeys offers something in terms of functionality that the Collection Manager does not... but it does not seem like that, maybe Im wrong tho, cheers!
Hello, thank you for explaining this as well, for a few months I was puzzled as to why while I had deactivated the hotkeys on the Collection Manager I would still have my collections deactivated and activated by them, I would rather have all this type of behavior merged into one single system to avoid confusion to the user, the addon works very well so far :) but I dont like to use hotkeys to access my collections, I mainly use the addon to move objects from one collection to another, but for some people using hotkeys might be very useful, so by no means I'm of the idea to remove that option, I just thought it would be better to sort of merge this whole set of behaviors into one single system. I also understand you are not directly involved in the legacy systems of Blender, but since your addon is related to the same functionality as those Multiref systems I thought this would be a good thing to mention.
They allow to manage collections via visibility (VV RTO), which is chain-dependent, unlike exclude checkbox (EC RTO) which is used by CM.
So, the default behavior approach allow to hide entire branches, which is more useful for scene setup, while CM approach is focused on Multiref modeling.
We are trying to make better design for this difference (like some kind of switch inside CM, that will allow control branches via QCD system on demand) , and currently we has got several possible solutions, but all of them have issues, that are claimed to be critical.
This task was not as easy as it seemed, so it was left as it is.
Yes, this is a community addon, so even if we came up with some combined system, I don't think the default keymap would be changed. I could be wrong though.
Zip Update for 2.90:
Collection_Manager_v2_12_5.zip
Zip Update for 2.91:
Collection_Manager_v2_14_1.zip
Just updated the Planned Features and the Potential Planned Features sections of the task. Let me know if there are any ones that are useless and I should forget. ;)
A very wise decision to make such a list, there were a lot of ideas!
A very useful for scene setup workflows, will allow to quickly fix mistakes by misclicks and will provide better control over setup process.
Will fix a design issue in Blender where selection is not flexible enough to match the complexity of systems/setups that are possible to create from collections (carving selection issue).
Will enhance QCD abilities as well.
A small digression that I would like to make considering cumulativity.
Cumulativeness is a type of cross-hierarchical issues class, that allow to create cross-hierarchical entities.
Cross-hierarchy always brings more possible flexibility to the system, but doesn't respect hierarchical rules, making problems to setups, therefore, it must be handled properly and separately to be able to predictably set up the scene.
I can remember 2 members of cross-hierarchical class presented in Blender at the moment
Common Groups (afaik they are currently under discussion) are usually have cross-hierarchical realization, and are usually handled separately as well.
Selection of all cumulative objects will allow to control how much cumulativity is presented in the scene, and also will allow to get the list of cumulative collections by filtering obtained selection.
Maybe it will make sense to provide the ability to select all objects that belongs to linked collections as well (filtering such a selection will allow to get list of linked collections), and make both functions additive (that adds objects to selection instead of replacing selection).
This way we will be able to handle both cross-hierarchical types separately or together, by demand, launching single function or both of them, controlling the entire cross-hierarchical class of the scene.
So there will be
add cumulative objects to selection and
add linked collections objects to selection functions.
Nice)
I don't think that CM can be useful in Local View, they are mutually exclusive, so it will be nice to have default Move from Local View ability in that View.
I think that one needs some explanation - the purpose or usecase)
This will be gorgeous to have as a Shift++ toggle - this ability is needed to quickly check the content of all QCD slots to be sure what objects we are manipulating at the moment.
Also it is nice to limit it with QCD slots collections, because we can turn all collections as global EC RTO on demand.
But should it influence non-QCD collections (maybe turn all of them off)? We need some time to think about it.
In short, I don't think I can come up with a better list.
Thank you!
Thanks!
Selection seems like it will be very complex and require lots of tweaking to get something that really works well, especially with wanting to carve out selections. I think for this we will want to have simple selection operations as hotkeys with a menu to have more complex ones like reduce selected objects to only ones in collection X (intersection), and I'm sure there will be more we'll think of.
Well, you can still toggle exclusion of collections in Local View, so they aren't entirely exclusive. I might be able to filter the tree view to show only collections with objects in Local View, this would allow you to tweak the visibility of objects in different collections in Local View without having to exit and re-enter it. I was thinking I'd just have an entry in the specials menu for removing selected objects from Local View, but I could just popup the default menu when in Local View instead of the CM popup.
That's easy. You know the Delete Hierarchy option in the right-click menu in the Outliner? That's the functionality I'm talking about. It's just a time saving thing, so you Ctrl-Click on the remove X in the tree view and it deletes the collection and everything under it.
I'm not sure if it's actually all that useful, but since main Blender has it, I thought the Collection Manager should have it too. It should be pretty easy to implement, but it's not the highest priority.
Yes, this is the last basic part of the QCD system and it's overdue. Somehow I always seem to get distracted and never get around to adding it. As to whether it should affect non-QCD collections, I'll start with it just influencing QCD collections and we can evaluate further.
I'll work on this next.
Here is a test of enabling all QCD slots. There is one known issue, currently the toggle button on the header doesn't show that it's been invalidated after changing the name of a collection in the outliner until after you mouse back into the 3d view.
The code's also pretty messy at the moment, but it should be enough to give us some idea as to whether the non-QCD collections should be influenced or not.
Collection_Manager_qcd_enable_all_01.zip
Nice realization, it is already very useful!
I also was planning such a button in my early proposals, but didn't know if it worth it)
Well, I still can't define it.
The problem is in the Scene collection.
Influencing non-QCD collections (by turning them off) is needed to make it clear what objects are distributed over QCD slots. If Scene collection contains objects, they will stay visible anyway.
So, I guess, we will need several shortcuts with different behaviour to test it on practice to satisfy all possible conditions
Shift++(single button click) - turn on QCD slots with no non-QCD collections influence (current behaviour, toggle + highlighting).Shift+Alt++(Shift+Alt+ button click) - turn on QCD slots with turning non-QCD collections off. Suitable for Multiref modeling, to be sure what objects are operable with QCD slots. (toggle + highlighting)Shift+Ctrl++(Shift+Ctrl+ button click) - turn off all non-QCD collections. The same behaviour and shortcut as CM isolate branch function (toggle + highlighting)Alt+Ctrl+(Alt+Ctrl button click) - turn all collections off to locate Scene Collection's objects. This action will be useful at wide range, because will allow quickly locate Scene Collection objects without loosing actual scene setup. (toggle + highlighting)Alt++(Alt+button click) - select all visible QCD slot objects (?) This can be useful for both operations and location.Highlighting is useful for "just watch and toggle back" actions, it is important for indication of temporal states, that mean that all those actions are for temporal watching / checking current state.
I think a better hotkeys, behaviour design and proper testing will be needed since QCD is a system based on another system with higher capacity, but this is the best I can provide at the moment.
Wow, that's a lot of functionality. I have a couple of thoughts on this.
I'm not against adding this, but it seems like it would be more appropriate for the Global RTOs in the CM popup, and you can already achieve this by enabling all and then inverting (it's not as easy as a single click, but it's possible).
Sounds like good functionality, but I would prefer we use a different hotkey.
For every other toggle with history I've included a discard history function on
Alt+Click, I forgot to mention that I included it in this test as well, and I think it's a good idea to have this functionality here and that we keep the hotkey for it consistent.We're ending up adding a lot of shortcuts for different behavior (especially to QCD stuff) and we only have so much room in tooltips and so many modifier keys, so I think this is the perfect place to try adding a menu on a hotkey (or maybe on click and hold) and limiting the hotkeys to one or two functions and leaving the more advanced ones for the menu (This is only for the button, we can have as many keyboard hotkeys as we want).
So, I'll keep your hotkey list in mind, but, at least for now, I'll add a menu to the button with the more advanced functionality.
Yes, please, this is needed for testing to make sure what functionality from above can be truncated.
Okay, here is the menu test.
All the keyboard hotkeys are the ones you've suggested. For the button I've only added the Alt hotkey for the selection. All of the other functions can be accessed from the button by clicking and holding it to bring up the menu (you have to keep holding LMB to keep the menu open and releasing LMB executes the highlighted menu item, so watch out).
For the select all visible QCD slot objects, I've made it so that if they are already all selected it deselects them.
Let me know what you think, and how the menu works for you (I'm not sure if I like having to keep holding LMB down for the menu, so maybe calling it via shortcut would be better).
Collection_Manager_qcd_enable_all_02.zip
And all of the functionality seems useful, so I'm not sure it needs to be truncated, although, maybe not all of it needs hotkeys and can just live in the menu.
Thank you!
Well, you are right. They all indeed seems to be useful...
Damn. I guess, that's the consistency price for interconnecting systems with different capacities.
Also suddenly love the shortcuts, despite the fact that they were invented offhand, they are easy to remember and following relevancy principle (complex action - complex shortcut).
At the moment I don't think some of them really need to be limited with the only menu presence, since they occupy only free combinations (so they take no space and do not conflict with anything) and the shortcuts can be reminded using menu.
It is also pleasant to cycle through all shortcuts during work to quickly check current layout.
I definitely see myself using this realization on wide range of workflows, including muliref modelling.
Maybe I need some time to define possible flaws, but at the moment I just can't find anything critical or add anything valuable to this system.
It is very useful, looks good and works well.
So I am totally ok with it.
If you are ok with current realization, the further step can be providing support / checking for consistency for editmode as well.
This way the entire issue can be claimed as solved.
Hello, I tested the addon a bit today, I haven't really explored it to its full capacity, but one thing I would like to have on the re number section is one option to delete all numbering (so the user can add its own numbering manually) I looked around on the options but I only got: Renumber from slot 1 left click, Mouse+ctr-linear, Mouse+alt-reset and Mouse+shift-constraint to branch, I think there should be one more option: Mouse+ctr-shift delete numbering for all slots; a warning for the user could be implemented so you are not caught of guard the first time you use it, but if you already know where things are I think you should be able to toggle the warning off.
I just thought of some other things that might be useful,
So far the addon is very stable, and I like it quite a bit, but I still think it needs some tweaks on its workflow.
If you have several nested collections (my current scene has tons of meshes so I have a lot of collection folders) one thing I would like to be able to do is to have the same QCD collection number assigned to more than one QCD slot, if part of the aim of the system is to simplify the endless collections the user can some times end up having, then I think this could help quite a bit to make sense of a large scene:
Say I have this setup, a hypothetical 3d map of a continent:
World Coll Global (20)
That's how I would like to number my scene in the Collection Manager.
So that when you hit 1 or 2 or 3..etc in the key board you enable all the collections you associated to
that slot, this way you have an easy way to sort the location of items of a complex scene.
You also would need to have a system in place that would conserve the collection selectability, visibility, viewport visibility, rendering status and hold out status i.e. all the status changes you can assign to a given collection in the outliner, i.e. the outliner will need to be freezed, so you dont reset those each time click a QCD, a toggle to freeze those and use the collection manager system in a viewer capacity way that does not disrupt a large outlier heavy scene would be nice to have, so that then you can only alter those in the outliner.
By separating this task (the status of the collections) from the Collection manager making sense of a large scene becomes simpler to me, as I dont have to worry about messing my scene setup for render layers because I hit the wrong QCD slot, however having the option to alter the status on a collection in the Collection Manager is cool, but I think having that freezed as a default would be nicer for the user so you can start using the Collection Manager with out the worry of messing a carefully render layer setup.
They way I used to use the QCD slots in older versions of Blender was that I had several objects grouped (on the old groups that Blender had) and parented to empties on my scenes, then I would grab all of those and move them to a QCD slot, then when I wanted to toggle on or off all those items that were part of interrelated part of the scene I would just click that slot to isolate, make visible along the others slots with shift click a new non active slots, or deactivate with shift clicking over an already active slot just that one would not be visible while leaving the rest of the slots active (which is part of what you are going into at the moment).
I checked all the new hot keys you just added and for the most part they look like they work just fine so that part of the functionality looks covered.
Since right now you can't assign the same number to more than one slot when I hit M, drooping many collections, groups, and general items into a QCD with ease is lost.
By begin able to assign the same number to more than one collection you give the user then that functionality back.
The way I use the slots is like a huge set of bags to hold all the literally endless little bags the outliner can allow you to create, one thing I begun to note as I was writing this is that if the Collection Manager was to become too complex it would defeat its purpose to some degree, the way I see it its a system to make things simpler, so the simpler its usage the better.
Not that I dislike the numbering options the system has right now, or the fact you have the option to turn the layer status of a collection from the Collection Manager it self, I think those are great UI additions, but I think those are secondary to the functionality of being to reliably drop a lot of objects or collections into one of the slots of the Collection Manager, so the user has a simpler visual representation of his scene.
I haven't read all the comments on this thread so this suggestion might have been thought up before, still I thought to share this in case the way my workflow could give you some ideas as to how to make the Collection Manager as user friendly to as many users as possible :)
I just thought how to make the numbering I want possible in automation (in concept, since Im not a Programmer) so what I thought is to add an option in auto numbering maybe called: re-number: same number to selected collection hierarchy, this way the user does not need to add the same number to a long chain of collections, you just select the top most part of a hierarchy and all the collections nested below become part of that QCD slot.
@1D_Inc
:)
Sure.
I'm pretty happy with it. I'd prefer you didn't have to keep holding the mouse button to keep the menu open, but it's probably better, and easier for users to discover, than adding another hotkey.
There are a couple corner cases that aren't accounted for and I might add in a couple separators to the menu, but overall I think it's good.
I had forgotten about editmode. Of course that needs support too. Unfortunately, there may be more performance degradation for large scenes in edit mode than in object mode because of the hoops I'll likely have to jump through. :(
I'll add that next and we can see how much the performance is affected.
@renderluz-2
Yeah, this isn't a current feature, but it sounds like a good idea. Since all the hotkeys can be combined for renumbering, the one you listed isn't free, so I'll have to put it in a menu.
Interesting idea. I think this would be fairly difficult to implement, though.
My addon can currently be used in exactly the same way. QCD slots are just aliases for collections, so you can have as many objects in them as you want, and you can move objects to them by simply Ctrl+(Shift) clicking on the slot in the 3D View's header or pressing V and then clicking on a slot in the window that pops up.
Ah, M is for general collection management, what you probably want is V which will allow you to move objects easily to QCD slots. You can't move collections into QCD slots, but everything else, including collection instances, can be. You can also just press V+(slot number) to move your selected objects the QCD slots (press shift before choosing a slot to add it to multiple).
This would be a good option. As I said above, I think the implementation of multi-collection QCD slots would be difficult (although this renumber option would probably be easy), but it's an interesting idea and I'll keep it in mind for the future.
The QCD slots should only affect the exclude checkbox and don't change any of the other Restriction Toggles. If they are affecting the other Restriction Toggles on your system then this is a bug and should be fixed.
If you mean that you can't see any of the other Restriction Toggles in the Outliner with the exclude checkbox off then that's just how the Outliner works (I have no control over that). You can see all the Restriction Toggle states in the Collection Manager popup (M) regardless of whether the collection is excluded or not.
I don't think you forgot about edit mode, because you was concentrated on mock-up to prove the general concept, and object mode support is pretty much enough for that purpose.
It worked nice, so exploring editmode is just the next step.
Well, okay, let me share our company thoughts about Multislot QCD realizations.
Multislot QCD management realization can be very useful for scene management process, but all of the realizations have the same issue - it is hard to define active collection to send objects to.
Multislot brings that kind of uncertainty to the QCD system, limiting it to mostly viewing abilities, that doesn't correlate with Multiref modelling workflow, where all the slots have to be defined straightly in order to have reliable access.
However, it can be solved with the paradigm switch.
Since QCD system is a quick access system that is built on top of a system with higher capacity (Collection system) with focusing on quick access, it can represent (convert) its structural data to the quick access slots the way we want, and the behaviour of such a conversion will be expected depending on current paradigm.
So, technically, it is possible to provide such an option in add-on's preferences, that will switch QCD engine between two modes.
This way, when we switch the paradigm, the behaviour of the QCD system within the chosen paradigm will be expected, and therefore not confusing.
This is the result of our research about possible Multislot QCD realization to this time.
We think that such a realization is pretty much possible, but it will take a lot of time and efforts to build and test, as it affects the the entire QCD engine.
So, that's why we are following current list of CM updates, and trying to design possible stable Multislot realization concept in the background.
Ryan Inch (Imaginer)
Thank you for considering my proposal :) I will give V shortcut systems a try I was not aware of that functionality,
as far as the complexities of the multi-collection QCD slots, I completely understand that will be complicated to implement, and I thank you for considering the idea for future features for the addon after other systems are ironed out.
Aside that I agree the current system can do most of the same tasks the older quick slot system used to do,
the functionality I would like to have then boils down to the only thing the current system can't do i.e. sending multiple collections to a slot because of the inherent problems with mixing a system of higher capacity (outliner hierarchies) with a system with lower capacity (QCDslots).
Paul Kotelevets (1D_Inc)
The idea you wrote would work to get the type of workflow I would like to have:
Multiref mode (current mode) - all numbered collections have their direct number (adress) for exact direct access.
Multislot mode(viewer mode) - QCD displays the entire nesting branch part of numbered collections during set slot visibility operations, and sending selection to a single numbered collection during send objects to slot operations (because it can be defined as active). This will not allow objects to be sent to any of the displayed collections, but will allow you to operate with the visibility of complex hierarchical structures.
I have an idea that might allow the system to still be able to send items to a QCD slot even on Multi slot mode, Im not sure if would work from a programmatic point of view tho, still maybe it will give some ideas that could work.
So say you grab one of the hypothetical hierarchies of the 3d world scene I talked about on my previous post, so you have:
World Coll Global (20)
Coll continent1 (1)
Coll continent2 (2)
Then slot (1) of the QCD is being used for Coll continent1, but if you try to send an object of any kind,
it becomes a problem as to where in the hierarchy should the object land.
(Collection them selves, are added to the QCD slot by being part of a given hierarchy so you have to do that in the outlier, and assign the proper number in the Collection Manager)
So then to avoid confusion as to where the object will be sent when onMultislot mode you send the object always to the top of the hierarchy, so if you send an object to slot (1) the object will automatically be sent to
Coll continent1
To avoid confusion the user cannot decide to which collection the object will be sent when you send an object there using the Collection Manager inMultislotmode, but with this idea the user can quickly sort his objects, and you do allow him to send object to that QCD slot system even tho the objects will always land into the higher collection of the hierarchy assigned to that slot.
After that the user can organize that hierarchy of collections that are assigned to slot (1) in the outlier,
so that the object(s) he sent there to being with are placed inside the nested collection of his choice.
So you start with this:
"Mesh cube" is first in the World Coll Global so its not assigned to slot (1), or (2), is part of slot (20) but
you want it to be part of slot (1).
World Coll Global (20)
Coll continent2 (2)
"Mesh Cube"
So you use the hot keys to sent it to slot (1) and you get this behavior, the mesh is now in: Coll continet1
World Coll Global (20)
Coll continent2 (2)
You can send as many object into that slot using the Collection manager they will always end up on that top
most collection: Coll continent1
Then afterwards you can go into the outliner and place the meshes you have sent there into the nested collections you have inside Coll Nation1 to organize the hierarchy better.
So after you tweak the position of that item in the outliner you have this, that mesh has been part of the (1) QCD slot the moment you sent it there via hot key, but, you have to place mesh be in the collection you intended it to be for good manually in the outliner.
World Coll Global (20)
Coll continent2 (2)
You dont have as much flexibility as with Multiref mode as to where the object lands to begin with, but if the goal is to aid the user to quickly organize a complex scene with this method you always know that if you send mesh to slot 1 of the QCD system all you objects will land into the top most hierarchy of that slot, when you are working with large amount of objects some times what you want to do first is to move large amounts of meshes that you know belong to an interrelated part of you modeling setup to a collection to being making sense of the scene, and after all those parts are on the top of that hierarchy then you create many sub collections to organize that collection hierarchy better.
So to summarize If you wish to use theMultislot worflow you cannot use The Collection Manager to organize where you object will be in detail, but it would allow you quickly send meshes to the top of an assigned hierarchy, and it will allow you quickly see what that hierarchy has, also while on this mode the exclude status of the collections inside any hierarchy assigned to a slot should not be altered by The Collection Manager.
So if if you have this setup:
World Coll Global (20)
Coll continent1 (1)
Coll continent2 (2)
if you toggle QCD slot (1) all the exclude and other attributes of status of the collections will remain the same,
This is what I meant by freezing the ability of the QCD system to alter the status of the collections (I was referring to the exclude status mostly), when in Multislot mode only the topmost exclude tick box is toggled on or off when you select that QCD slot, all the rest of the exclude options are not changed when you select that slot, and neither are other status of any given layer, the user will need to do that in the outliner for that hierarchy to avoid confusion.
As a side note, while trying to make sense of the workflow I want to have, the message kept growing and growing :)
so I understand making something like this will not be easy to implement.
Thank you for creating The Collection Manager, and for considering my idea as a potential feature for the addon.
Cheers!
Yes, this proposal is perfectly in line with our vision of how the Multislot QCD paradigm can be implemented.
Thank you for your feedback)
You can use the Collection Manager to set exactly what collections an object belongs to. Simply select the object, press M to open the Collection Manager popup, and click on the box icon for the collection you want to move it to (shift-click to add/remove the object from the collection) . It doesn't matter whether it's a QCD slot or not because the Collection Manager popup is designed to work with the whole collection hierarchy.
Press shift to only affect a single collection. So pressing 1 isolates the QCD slot (1), pressing Shift+1 toggles the slot on and off.
My first instinct would be that if you were to move an object into a slot representing multiple collections it would be added to all of the collections represented by that slot.
Also, there's no guarantee of a hierarchy. Someone might want to set multiple collections on the same level to be represented by one slot.
Another possibility would be to have a menu or window come up when you send an object to a multi-collection slot that allows you to pick which collection(s) to send the object to.
It was a mistake, I guess he meant
this way, you cannot use The QCD slots to organize where you object will be in detail from all collections that are displayed by slots,
For sure, CM popup can control every available collection)
Well, it will bring just an insane amount of cumulativity into the scene with no particular reason. That's why Multicollection slot (Multislot) mode is mostly viewer mode.
Less abilities to send (but with no loosing sending completely), more abilities to view hierarchical branches. A reliable workflow-dependent compromise, oriented to the scene setup/view workflow.
We also considered such a case, and possible solutions - that's why our proposal exclude that cases.
They are impossible to solve for sending objects because it is impossible to define active collection from visual appearance.
Menus contradicts quick access paradigm of a QCD system, so if you have to use menus for QCD slots at some point, it is highly questionable approach (because of main CM popup window).
In overall, we design possible Multislot paradigm in the background for a half-year and avoid its public discussion without proper presentation and explanations, because it is a complex workflow approach with indeed a lots of first instincts to exclude, many details to explain, discuss and take into account.
This is all a bit premature (taking into account deadline I am currently in), but if it was mentioned, well, okay.
You can ask a questions if Multislot approach is interesting to you, I will try to answer them )
UPD: I decided to make a picture to show the difference between Multiref and Multislot behavior
Well, okay. Despite my attempts, not all of the functionality in the Collection Manager is obvious, so I just wanted make its capabilities clear.
No hard feelings were meant.
You're right. Sending the object to all referenced collections is a bad idea, but Multicollection may not have to switch to a mostly viewer mode for all cases.
Not necessarily. If you'll remember, you can type a number to execute a menu item. So handling multislot with a menu is easy as long as you have less than ten collections. Using @renderluz-2's example, to move an object to a multislot collection you can do V + 1 + 2 to move the object directly to Nation1 with a menu.
No worries. This is all future stuff. But since it was mentioned, I'm trying to wrap my head around it.
It is interesting. And thank you for the picture, it helps.
It turns out that supporting editmode was easier than I thought.
Here is a test with editmode support.
Collection_Manager_qcd_enable_all_03.zip
Nice to know)
Like that exiting toggle takes any ++ shortcut (for example, you can exit from entered Shift++ mode with Alt+Shift++ shortcut), it is safe behaviour in my opinion.
It seems to works well, except editmode shortcuts and except several selecting (Alt+Button) action issues in cases when the active object is lost.
To reproduce such an error - in working scene (loaded with collections and objects) create cube, make it active and delete it. This will mean that active object is lost and cannot be defined (tab button doesn't switch to edit mode).
In this case menu have no option to select all QCD objects, but Alt+button action is working and gives error.
To reproduce such an error - press Alt+Ctrl++, Alt+Ctrl++, Alt++
That's the question of the paradigm shift.
We are comparing two possible realizations:
For example, Multislot B is way more useful for case
rather than
because in the first case you can detect proper group of bolts by colour (visual appearance), and in the second case names are just too abstract, and those objects cannot be accessed from QCD system directly without proper mapping like
which will be the same solution as for the Multislot A or Multiref.
So Multislot B is too much case-sensitive - menus will worth it when scene is already properly organized so main CM window will possibly benefit more in that case, and most of times they will just slow down and will require too much attention.
In my practice "bolts ABC" are presented way more often than "colored", where names represents context.
That's why we asked for the entire QCD system to handle dynamic context, and also things like collection isolation to have ability to check static collection content for consistency.
In my opinion, at this point the usability of possible mutislot realization between Multislot A and Multislot B cannot be determined without proper testing on practice, and it is hard to imagine Multislot C which could be more useful than them.
Hope it will be helpful =)
Right, editmode hotkeys. I forgot those. Here is a new version with editmode hotkeys, the selection error fixed, and a fix for the disable all operator not respecting editmode objects.
Collection_Manager_qcd_enable_all_04.zip
Yeah, as always we'll need to test everything out when we get to adding multislot. But I think we'll be able to find something that's really fluid.
Also, should the select all qcd objects operator be expanded to work with armatures in pose mode?
Thanks)
I got an exception in edit mode - when active edited object belongs to non-qcd collection (because of loosing the active one), on Ctrl+Shift++ and Alt+Shift++ actions.
If such an edited object is passive (and active belongs to QCD collection), everything is ok.
I am not sure how to handle such a situation.
Maybe, stop function and drop a message "Active edited object belongs to non-QCD collection"?
This can be a solution, because it will show what is going on.
I am not sure it is needed. Pose mode is more about setting pose rather than selecting objects.
The same issue is about selecting objects in edit mode - it is way more about editing, that's why it is nice to have the QCD slots selection ability blocked in it (especially if to take into account 2.8x multiedit feature).
So let's follow the same line here - everything except object mode is an edit mode, keeping selection option blocked in it.
Thanks, I'll look into it.
Great! That's easy. Will do.
That's one way of handling it, but depending on how important the active object is, there is another way.
If the active object is not important then we can set an arbitrary edit object as the active one and continue on. This works nicely, but loses the active object.
What do you think?
I think that active object is important.
There are too many possible operations that requires the active one be strictly defined)
Ah, sorry, I should have been more clear. Yes, I know it's important to have an active object defined, but I don't think we actually care which object is the active one in this case.
By arbitrarily setting an active object if the active object is no longer visible it allows it to work very smoothly and the way, I think, a user would expect.
I actually do this in another part of the QCD code to allow you to add a selection of objects to a slot when there is no active object.
Here is a test of this functionality:
Collection_Manager_qcd_enable_all_05.zip
Let me know what you think.
Thank you for test version)
I've tested current behaviour and it feels smooth, but here is an issue - this system can be solved only if QCD-related slots have a selection to move active one there.
So pure non-QCD collections objects selection ruins that behaviour, so we will be forced to handle that case separately in any way.
But user usually don't have the ability to check where active object belongs, so we has got 3 possible cases we can get after running function.
I think it is too much random to be consistent.
I think it is important because of this
During assembly editing you can, for example, temporarily rotate selection using this type of pivot for better editing, then perform editing/viewing selection that will cause changing the active object, and then rotate back selection back using wrong active object, messing up the whole assembly by accident.
Loosing an active object in Blender 2.8+ makes me sad, so you have to remember which one was the active one before operations with collections, but changing like this it is too dangerous.
I will definitely prefer
Okay, yes, I see that in this case we shouldn't override the active object.
I'll add in a message for when the active object isn't in a QCD slot.
@1D_Inc Losing the active object also occurs in Object Mode when isolating QCD slots or disabling non-QCD collections (there just isn't a python error). Should we disallow and drop a message in object mode as well? I think this would end up being more of a nuisance than a help, but it's probably also a good idea to keep the behavior consistent with edit mode.
It might be possible for me to store the active object (at least in edit mode) for the duration of the isolation and then restore the active object when the disabled collections are re-enabled.
If this works, I think it would be more useful than making you switch the active object, because even with the message you have to change the active object to one that's in a QCD slot, so you loose the active object anyway.
Yeah, me too. :(
But I kind of get why you loose the active object when disabling EC.
Thank you for updating list)
It is more handy to overview it, finding possible request patterns.
That will be superuseful)
But it is hard to imagine how it is possible.
Getting the logic right will be a little tricky, but I do something similar when moving objects, so I think I'll be able to work something out.
@1D_Inc
Here is a test with the QCD All toggle preserving the active object.
Hopefully this should work properly and everything should be stable, but try it out, see how it feels, and try to break it :p
Collection_Manager_qcd_enable_all_07.zip
If this works out, I may try incorporating active object preservation into other areas.
Hi!
I see that it changes active object, but swaps it back.
I'm not sure if this is a suitable solution, because while working in isolation mode, you might forget you went into it and use the QCD slots by number, so mode and active will be lost.
It is easy to forget about mode when you are concentrated on complex object or scene.
So I think dropped message is the most stable solution to not to loose the active object.
Meanwhile, when I started my test I remembered about another functionality seems to be missed. I am discouraged that I could forget about it.
Isolate collections of a selection.
Currently, using CM, we can filter collections names of a selection to check objects per collections distribution for consistency, but, it seems, we cannot quickly isolate collections of a selection.
Meanwhile, it is pretty much common operation, that is used with complex setups, and such a functionality falls under the scope of the tool that we are currently making - it supposes the same type of toggling action!
Damn! It seems I am that much overloaded now if I can miss such a things)
I am not sure about if it need only EC (what) or VV (where) too, should it influence nesting depending on QCD Multiref/Multislot mode (probably yes, because why not),
we are already out of shortcuts on ++ button and it is so cool that deserves to be placed even on on Asterisk (*) button, and hiding collections by selection... there are so much things to think about.
Correct me, please, if I'm wrong, but CM or Blender already has this by default?
I'm so embarrassed and confused I can't be sure of this.
Well, both the active object and the selection are very unstable in blender by default, so I've changed my mind and don't think dropping a message in object mode is needed, but you might be right about dropping one for edit mode. I need more time to think about it. And, sorry, but what do you mean by isolation mode? Are you referring to Local View, having a QCD slot isolated, something else?
Yes, this sounds like good functionality. I think it would probably work best if added to the Global EC RTO because this can be applied to any collections.
Not sure about VV, but I could see it being useful for RR so you can just select objects and render them for a quick test. It'll probably end up being added to all the RTOs.
This is why I tried out the menu for the QCD All toggle, and I'm thinking of other ways to allow access to our growing feature set (we're quickly running out of space, but the ideas for new features are only growing. Lol). I'm also thinking of attempting to find a way to allow the user to customize the hotkeys on buttons so that they can have fast access to their most used functions, while using a menu as a fallback for less frequently used stuff.
Blender has none of this by default, but CM has a "filter collections by selected objects" option in the main CM popup.
Don't worry overly much about this. We are designing extremely complex systems for controlling the management of collections and objects. Confusion is to be expected and practically a requirement. :)
It's going to take time, and there will be lots of hurdles, and pitfalls, and likely mistakes as well, along the way, but we're doing well so far and just have to keep going.
We'll get there, eventually.
By isolation mode I mean function that we are currently making (currently it is named "Enable all QCD slots", but I think it will need another name, maybe like "Quick View toggles", because its functionality overgrow QCD)
I think it is nice to avoid behavior that require special terms of using, like remembering who is active before running function and so on - it is hard to keep such things in mind during work)
Yes, it is awesome. We have it for almost every software we are using, and we made such a thing even for 2.79, called Isolate layers
because you cannot detect the entire selection from layer slot visual appearance there, unlike in CM's QCD (right click to open in new tab this GIF)
So, apparently, I'm so used to the fact that it exists, and that this issue has been resolved everywhere, that I simply forgot to form a need for such a functionality.
Truly, we are rebuilding the usability of collections from scratch...
I agree that it should operate at least on common EC RTO, and should not be dependent from QCD slots limitations.
At the moment I can see such a list of toggles to test:
Main:
Additional:
I can't say if additional will be useful, but I guess so, they are hierarchical. Only tests can reveal results here.
I am not sure about RR, because it is an implicit RTO, and you can't predict a result from visual appearance (Unless you are running viewport render mode to see the changes? It is not that useful for heavy scenes, for example),
but it makes sence to suport VV and then just use CM Global RTO copy function, as we usually do for converting explicit RTO setup to the implicit one - they are both chaining.
I am not sure about customization abilities, because it causes problems during teamwork, or using several Blenders (work/home or during migrations to a newer versions)
In my opinion, nice defaults based on relevancy are pretty much enough and predictable as well.
Yes, it seems we can't handle visibility of collections of a selection in Blender yet. And I can't remember such a requests to this time, by the way.
Maybe because of systemic blindness issue.
Indeed) Thank you!
I hope we will be able to clean up the resulting system in further.
Ah, okay. Thanks.
Nice!
Well, when working in the 3D View you have no concept of hierarchy, and these actions are entirely dependent on hierarchy, so I can't see them being of any help because you can't tell what they'll do.
Perhaps this is a failure of imagination on my part.
To me the relationship between collections, QCD, and the 3D Viewport can best be visualized by saying that the collection hierarchy is the complete 3d model of a building, QCD is a blueprint/floor plan, and the 3D Viewport is the actual building itself where you walk around and look at the objects in the rooms (although actually, it's more like the building has been compressed to a single story/one room, but I digress). So these additional functions (not the main ones) seem like walking into a room, picking up an object or two (which may actually be from different rooms/floors) and saying "Okay, I want you to show me all the objects from the rooms these objects came from, plus the objects from the floors immediately beneath them and/or above them." , which seems nonsensical to me. But again, this could just be a failure of imagination on my part.
Well, it would be more of a help if applied to objects, which don't have EC, but I honestly forgot for a moment that EC also affects whether a collection is rendered. And RTO stuff is mostly code once ,apply to all (with a few tweaks for chaining/non-chaining), so if one gets it I don't see a reason why they all shouldn't.
I don't think this would be a problem because if this gets added there would always be a menu (probably on click+hold) to fall back on. The benefit would be that you could set your most used functions for that button to hotkeys (faster speed, less clutter), and the menu allows for more discoverability and longer, more descriptive, tooltips for each function.
Your welcome! And I'm sure we will.
Yes, working in 3D View without outliner means dynamic context - no lists or names, only visual appearance.
Interesting point of view =)
I see it in a bit different way - branches control, similar to that we made for CM RTOs.
For example, if you have a car, which is split to several collections, you will be possibly able to isolate the entire car by selecting some part of it.
Here is Select-UP addon , written on my demand (one of my first attempts to handle collections usability, before participating CM), it allow you to grow selection over hierarchy (sort of a "pickwalk", like with parenting).
May I ask you to try it /watch video about it and tell me what do you think about such a concept?
Looking at it today, I realized that I would modify it, but it is still usable and working nice.
Maybe we can replace additional functions with just growing selection like this. to make hierarchical actions explicit.
I feel that additionals can be useful, but can't explain in words how exactly.
Indeed, it is hard to say without proper testing.
Well, maybe, it is hard to me to imagine such kind of a realization, I haven’t looked further than EC.
Okay)
I'm afraid to imagine that it will be difficult to do, but you are surprising me all the time)
Ah, but that "possibly" is the problem. Since there is no representation of hierarchy in the 3D View you can't know for sure what effect your actions will have, so this functionality would introduce undefined behavior.
This looks very nice! Yes, I would definitely get behind a "pickwalking" concept (both up and down) for visibility, and also for selection if you want.
With this approach you have a clear premise to work with, plus it's incremental so you have complete control over everything.
Since RTOs are just boolean values the same operation can apply to all of them fairly easily (there are a couple quirks between the different RTOs, but I know how to handle them).
It's just an idea I've been thinking about, so I'm not 100% sure, but from my experience I think it's got a good chance of working nicely.
Okay, here is a version of the QCD Enable All functionality that doesn't switch the active object, but drops a message if you're in edit mode and the active object would be disabled. I've also fixed a lot of corner cases related to QCD slot toggling in both the new functions and the regular slot toggling. And I fixed a bug when there are linked objects where not all objects for QCD slots would get selected. Plus, I changed the tooltip of the button to have Quick View Toggles instead of QCD Enable All because you're right, that fits better.
I'm liking the way everything's working and it seems nice and stable, but let me know what you think and see if anything breaks. :)
Collection_Manager_qcd_enable_all_08.zip
Well, I like it. It feels so much more confident than all above, when function does not try to trick you, so you don't have to remember in what particular case it can happen)
It feels truthful now. After some tests, I can say that this is approach I would like to use during work with complex assemblies.
Wow, how did you even detected such a thing? That's deep))
What are you planning next?
Anchestor names for subcollections? Selection collections isolation and control? They are a little off the list, but I think they deserve to be given priority.
And thank you for all your efforts for solving usability problems!
Yep, I'm quite happy with how it works now. It feels good. And I'm glad we tried out the switching even though it ended up not being useful.
I never suspected how finicky this would be when I first started. :P
But I think it's turned out to be an improvement all around.
The usual way; by accident. I had been testing other things and ended up with a setup with linked objects, and I thought things were looking pretty good, so I was giving everything another pass of testing and I saw that when I tried selecting all objects in QCD slots it missed some objects. So, I investigated.
One other potential bug I found with QCD slot toggling (not related to Quick View Toggles), is that when an object you are editing is linked into multiple QCD slots all of them are locked on. Depending on how you look at it this could be a problem or it could be expected behavior. What do you think?
Well, I need to clean out all the leftover tests in this branch and merge it into master. After that I'm going to fix a bug where the active object gets lost if you toggle off the parent collection's EC RTO (don't worry, no tricks required).
Then ancestor names sound easy, so I'll give that a try. And I want to see about the hiding bug. I'm thinking that adding a checkbox in the preferences to replace the hiding operators with disable operators is the best idea for now.
And finally, since you say it's a basic requirement, and I can see it'll be useful, I'll see about adding the isolation of the selected objects collections. I'm not going to get into the pickwalking yet because I think it'll be a fairly big project and I want to work on some UI improvements so we don't run out of space for new features.
Your welcome! :)
I think that this is just a cumulativity, in a nutshell. Working with cumulativity always feels unusual, because it is cross-hierarchical, but such a behavior is justified logically.
I see no problem here)
Nice plan! Sounds great =)
I also don't think that we need pickwalking yet, because we have S-up, and we can combine it with collection isolation to expand collection isolation's use cases range, this should be enough for testing system capabilities.
S-up and collection isolation are looking good together, so maybe we will implement modified version of S-up some day.
Trying to find a shorter name for "Isolate selection collections", "Hide selection collections", they are horribly long. Maybe it will be reasonable to end up with a term, but it has yet to be found.
Great! That's easy. :)
Hm, I don't know. I'll give it some thought.
Ah good. I'm not sure how much testing I can do with S-up because I don't think it's license is compatible with GPL, so I probably shouldn't download it, but I'll take your word on how it works. :)
I'm not sure about all the legalities.
One new potential issue I came across, should we clear the history on the Quick View Toggles if the QCD slots numbering changes? i.e. when slot 1 is renumbered to 5 and/or slot 3 is changed into a non-QCD slot.
Currently we don't and if you make changes to the QCD it just restores the collections view states to the last configuration, so you're returned to the original state, but that state may not match the current QCD setup.
Understandable.
I am its concept designer, not a programmer, so I will contact it's author to clarify the issue.
That's interesting question.
The meaning of toggling action is return you back whatever it takes - to the know state, defined by user. If initial conditions changes in the middle of the process, that mean that we've lost our state, and it should be depicted.
This is how all toggles works in CM - they all loose history on manual changes. So I think that yes, it should reset Quick Toggle when numeration changes.
Also another interesting question about states - can main Quick View Toggles button remember the latest action?
For example, if you performed "Disable all collections", this makes this button perform this action until another option is selected from list. I think it can increase usability for such a tool with lots of options.
I asked developer, he answered that royalty free was the only option for Blendermarket, but, in fact, the code from Github uses bpy, so automatically inherits Blender GPL license,
because don't contain proprietary core and opensource bridge to it, like Octane or Mesh Machine addons.
So it is opensource, it is safe to download and use.
Okay, I don't have a great understanding of licenses and legal things, so I'll take your word for it. :)
Yes, it is an interesting question, and when I started off I intended to make it lose the history if QCD changed in the middle, but as I was looking stuff over for the final commit I realized that I had never done that and I also realized that because QCD is basically a tagging system, you can always return to the previous state successfully (because the underlying collection structure hasn't actually changed). So on the one hand it makes sense that if you change the QCD structure you should lose the history, but on the other hand it feels kind of weird to lose the history because you can always get back to your previous state. So I guess the real question is: which is more important? Consistency, or the ability to get back to your previous state.
My first inclination (as was yours) was to choose consistency, but then I wondered if I was just being somewhat petty and controlling for no good reason.
Interesting idea! I think it's important for LMB to remain Enable All, but we could definitely try this functionality out on a hotkey. Another idea that I could see being useful is being able to save a state and then switch between the current state and the saved state. Also, I can't remember if I mentioned this but, when there is history, just clicking on the button will always apply that history no matter which function the history came from.
Looks like the Outliner is taking notes from the Collection Manager. D8928
Zip Update for 2.91:
The Quick View Toggles can be accessed from the eye button to the left of the QCD slots in the 3D view header.
Button hotkeys:
LMB - Enables all QCD slots.
Alt+LMB - Selects all objects in QCD slots.
LMB+Hold - Pops up a menu with all of the Quick View Toggles.
All Quick View Toggles and keyboard hotkeys:
Enable All QCD Slots - Shift++
Enable All QCD Slots Isolated - Shift+Alt++
Disable All Non QCD Slots - Shift+Ctrl++
Disable All Collections - Ctrl+Alt+=
Select All QCD Objects - Alt+=
Discard QCD History - No Hotkey
Collection_Manager_v2_15_2.zip
Just thought of something regarding naming new collections after the ancestor/selected collection. If we do that it'll end up looking very similar to duplicating the collection. I'm not sure if this is actually a problem or not.
Thoughts?
Hi. Sorry, I have a heavy work attack, up to 20 hours in a day.
I will be offline for some time.
@1D_Inc Okay. No worries, and good luck.
As I was experimenting with naming new collections after ancestors it occurred to me that changing the names isn't what we really want. What we really want is for new collections to be visible when added regardless of filtering (until that filtering is modified). So here is a test that does exactly that and also prevents collections from being added if the selected collection isn't visible.
Collection_Manager_filter_new_collections_test_01.zip
Hi. I'm still trying to survive through deadline. It is still a lot of work here, maybe in November I'll be freer.
No problem at all. I post things to keep everyone updated and in the hopes of some feedback. I know you're busy, so I wasn't really expecting anything from you, but I was hoping some other people would step in. Regardless, I really like how things are going and they can always be tweaked later if need be.
I hope everything goes well with your deadline and things calm down for you. Your feedback has been excellent and very much appreciated!
Zip Update for 2.91:
Collection_Manager_v2_17_1.zip
Zip Update for 2.92:
Disabling objects is needed to preserve their visibility state when excluding and unexcluding collections.
This makes it easier to disable objects, and disabling objects prevents QCD slot switching from resetting
the objects visibility state.
Hotkeys for the new disabling operators are the same as for the hiding operators:
H - Disable selected objects.
Shift-H - Disable unselected objects.
Alt-H - Restore disabled objects.
Collection_Manager_v2_18_0.zip
Oh my god, you are trying to solve that design flaw? This is amazing!
A very interesting solution)
DV RTO is not stored in View Layer, but whatever, we desperately need to make EC preserve hidden objects from sight of view for most of work we perform to work with anything that is more complex than a sculpted character.
Thank you so much for this!
I am so embarrassed that I failed to explain it to core devs though. Still don't know how to handle such a workflow issues.
Maybe this checkbox deserves to be called "Disable objects instead of Hiding" to make clear what exactly it overrides.
Yeah, well, it's kind of a major problem. And I really don't like problems ;)
Yes, I know it's not an ideal solution. Another possible solution I looked at is to store and restore the objects' hidden status when switching QCD slots, but this is complicated and could have performance issues.
So this is what I'm trying for now. Hopefully, it'll be good enough, but if needed, we can look at other options.
Welcome! :)
The core devs have strong opinions on how things should work, so I'm not surprised. I wouldn't worry too much about it.
We'll do what we can here, and if the core devs help then that's a bonus.
I think the tooltip makes it pretty clear, but I can change the name if you want.
Zip Update for 2.91:
Collection_Manager_v2_17_3.zip
Zip Update for 2.92:
Collection_Manager_v2_18_5.zip
Test for isolating collections of selected objects.
Implemented for all Global RTOs as well as QVT.
Global RTOs and QVT don't share the history.
Hotkey for QVT is Shift+*
Collection_Manager_isolate_sel_objects_collections.zip
Oh, god, it is so nice to see such a functionality!
It is so great to have it now! A power to control visibility in a dynamic context =)
But here is a problem - it uses Shift+8 (instead of num* or Shift+num*) shortcut, so it conflicts with QCD Slot Shift+8 operation (it adds/removes slot 8 from visible layout)
The reason of using "num*" key for collection isolation is the same as using "num/" key for object isolation - they are near, and num* seems to be free.
I can have in a vision
using num* for simple/direct collection isolation of selected object - so you can control direct distribution, for example, checking if object is in appropriate collection, and it's collection's neighbours are correct.
using Alt+num* for simple/direct disabling collections of a selected objects - because sometimes it is definitely easier to turn off "walls" and "windows", than "isolate all the rest of the building".
using Ctrl+num* for nested branch collection isolation of selected objects.
using Ctrl+Shift+num* for the entire branch isolation of selected objects - those two can be replaced with Select UP, to grow the selection over hierarchy and isolate ability with simple/direct isolation, but I would like to mention them anyway, just in case. They require additional design, because, as you can see, such a functionality can be obtained in several ways =)
What do you think about taking the num * key?
Doh, sorry about the hotkey. I was rushing to get it released, because it was really late, and I totally missed it. Fixed now.
I love the disable idea, but not the hotkey because it can't be executed with one hand. For now I've done isolate on
num *and disable onCtrl+num *, however what would you think about having them as isolate=and disable-? (or keep isolate as*and just switch disable to-)As to the branch/nested isolation, it's interesting but I do have some doubts about its design/would maybe prefer the pickwalking idea. Either way, I want to deal with hotkeys preferences/UI changes first before getting into this as we're running out of hotkeys and tooltip space. :)
Yeah, this is really nice! I love how easy it is and the control these two functions give you.
Collection_Manager_isolate_sel_objects_collections_02.zip
Yeah, this is a nice example of simplicity x power = efficiency workflow design equation.
Yes, I also think that pickwalking solution can be more demonstrative in case of a dynamic context manipulations.
Wow, it is, actually, a very interesting solution! I was so focused on the Shift+= and Ctrl+Shift+= keyboard shortcuts that I completely lost sight of the fact that the
=and-keys are somehow free yet =)In fact, local view object isolation has got a Frame Selected option, that controls zooming while entering local view, but sometimes you need to perform framed selection as well as unframed selection local view, so I thought about assigning
/and*keys to them respectively, but didn't tested it yet.So I think that occupying
=and-keys is a great consistency+relevancy solution, that keeps the entire QVT functionality at the same keys.The only thing I would like to change is switching
Shift+Alt+=andShift+Ctrl+=actions, at the moment I constantly confuse them during tests.This way all the disabling shortcuts will contain Alt key, so you can be sure that you are running a "disabling action", if your pressed shortcut contains Alt key.
Sure, I can do that.
Great! After thinking about it some more I'm wondering if it wouldn't be better to have Enable all on
=and Isolate Selected Objects Collections with a modifier key instead of the other way around?I'm also wondering if it would be a good idea to switch some other QVT hotkeys around to make it easier to activate with one hand. Not sure if it's a good idea or not, but if we were to do it maybe have something like this:
Enable All:
=Enable All Isolated:
Ctrl+=Isolate Objects:
Shift+=Disable Objects:
-Disable Non QCD:
Shift+Alt+=Disable All:
Ctrl+Alt+=Again, I'm not sure rearranging the hotkeys is a good idea, but I think it should be considered.
I made some tests, and here are some of my thoughts
We are using Enable all QCD slots as
Shift+~shortcut during multiref modeling, we are reassigning it manually, so for us it's initialShift+=shortcut is temporal.I can't say there is much use in Isolated enabling QCD slots - it i easy just left a single slot turned on and use regular Enable all QCD slots in order to get the same result.
It seem like this way is pretty much ok for muliref modeling, so we can remove Isolated enabling at this point.
I would recommend to rename Isolate selected objects to Isolate selected Collections, because it sounds truthful.
Terminology like Isolate Collections and Disable Collections sounds shorter and better - it makes clear that it is about actions that are related to Collections, and tooltips like "Isolate collections of selected objects" will clarify its functionality.
Also I would recommend to keep Collections isolation and disabling keys as short as possible, because they are HOT - sometimes several iterations of toggled switches are needed to get proper selection that covers all necessary collections both for isolating and disabling. I like the idea of having them on
=and-buttons respectively, however, this will require a few more practical tests.Good to know.
I kinda dislike removing features, how about we just remove its hotkey for now?
I'm a little confused here, what do you want to rename Isolate Selected Objects to?
Okay. I do like the consistency with them on
=and-Yes, everybody dislike removing features, its a trap)
This is why I prefer to come up with well thought out proposals...
I think we need to analyse all the isolations we have.
Local RTOS - Isolate/Restore - is needed for checking where the collection belongs (chaining RTOs) or what collection contain (non-chaining RTOs). The same reason for isolate nested/ Restore.
Global RTOs - Isolate Collections w/selected objects- is needed for scene setup flexibility, as it operates on several RTOs, taking selection as input.
QVT - Isolate Selected Objects Collections - is needed for realtime control in dynamic context and quick temporal setups, for example - for forming proper selection for Global RTO selection isolation.
Everything seems logical/readable to me, especially if to take into account that QVT already contain "Disable all collections" tool, so any names shortcuts can be confusing.
So let's left it as it is now - Isolate Selected Objects Collections, this looks pretty good in general isolations contexts. Sorry for confusion)
I'm not entirely against removing it, I've had a couple doubts about it from the beginning, but you did mention that you are achieving the same result in a different way which leads me to believe it may have some value, plus it is a valid visibility configuration. Let's see how things feel after the hotkey and interaction changes I have planned and if it's not providing any benefit, or is a detriment, we can remove it then.
Fine with me.
No worries. :)
I think we can easily return it if we will find some kind of a impassable obstacle.
I've tried to find some, but failed at it.
Also, it combines Enable all QCD slots, Discard history and Disable all non-QCD collections into a single action, so I am not sure that Isolated enabling even able to have an impassable obstacles.
I would recomment to set Alt+Button press to Discard history, since all alts on buttons are discarding history all over CM.
So, in my opinion, shortcuts that look like this are a good option:
Alt on slots will still select objects assigned to slots, but they are slots, not buttons, so different behaviour seems to be suitable for them.
You're right, it's not technically needed because, as you've mentioned, there are many ways to achieve this; however, depending on how often you need to do this, it could be more convenient. The one thing I can think of that might be a benefit is that by limiting which collections are QCD slots you could make a sort of "local view" that only shows specific slots/collections. (This may be redundant once we get the option to save view configurations/states, but for now it can provide similar functionality)
Excellent! I've been missing having Alt discard history for QVT. :)
Speaking of discarding history, I'm thinking now that having all QVT functions restore the previous state if there is history feels more like a bug than a feature. I think most people would expect that if they Enable all QCD slots and then Disable all non-QCD collections that it would disable all the non-QCD collections instead of restoring the previous state. However, clicking on the button should still restore the previous state.
Thoughts?
I think that Alt for discarding history will largely solve this issue.
QVT stands for Quick Viewing tools, so toggling behaviour is a necessary part of it in my opinion.
Speaking of Enable all QCD slots and then Disable all non-QCD collections sequence - the best way to perform it is to click any slot and then perform Enable all QCD slots.
Or we can left Enable all QCD slots isolated, but remove a shortcut from it (leave it without a shortcut), so shortcut can be assigned on demand manually on case if it will be needed often.
I think it will be pretty safe and flexible this way.
Toggling is definitely necessary, but try using the menu to enable all slots and then using the menu to do something else and tell me if it feels like expected behavior having it restore the previous state instead of doing whatever it was you asked. Because it definitely feels off to me. Bringing back Alt for discarding history will make things quicker, but it won't solve the "not doing what I told it to" problem. I think we should try either limiting restoring to the action that called it (we could indicate this with an icon in the menu) or or trigger some kind of message that blocks and notifies, or maybe just notifies.
The current behavior may end up being the most advantageous, but if possible I would like to eliminate the "not doing what I told it" problem.
I like this idea for now. If needed, we can revisit this after the hotkey/UI changes.
Well, yes, if it is supposed to be used like this.
Sounds interesting! I need to think about it)
Also, about licensing, third party and using code.
As far a I know, in Blender addon development, if your code use import bpy - your code inherits the Blender GPL, so it's safe open source.
I think there's the potential for it to be used like this. It seems like a fairly obvious case for user interaction now that I think about it, but it'll need some testing to make sure it doesn't do more harm than good.
I've heard differing opinions on this and don't know who's right. :P
I'll take the stuff you send me on good faith, though. :)
Zip Update for 2.92:
=, CM popup global RTO button hotkey:Shift+Ctrl+LMB)-, CM popup global RTO button hotkey:Shift+Alt+LMB)Removed the keyboard hotkey for Enable All QCD Slots Isolated.
Changed the keyboard hotkey for Disable All Non QCD Slots from
Shift+Ctrl+=toShift+Alt+=.Removed the keyboard hotkey and QVT button hotkey for Select All QCD Objects (was
Alt+=andAlt+LMB).Added a keyboard hotkey and QVT button hotkey for Discard QCD History. (keyboard hotkey:
Alt+=, QVT button hotkey:Alt+LMB)Collection_Manager_v2_19_1.zip
Zip Update for 2.92:
Collection_Manager_v2_19_2.zip
I think it is nice approach, also like selection collectioning technique available now due to isolating/disabling selected collections ability.
I will try to explain - here is a car I want to isolate, without dealing with its component's hierarchical collections distribution, navigating outliner, searching names and other static context stuff.
It is possible to turn its parts temporary off with set of
-actions to collect proper selection for further isolating by=action.As a result, you can "dig" to the proper selection pretty fast:
Cool! I never thought of using it that way :D
I've also been thinking there should be an option to disable without keeping history, so I propose that we add that on
Alt+-Yes, it is unobvious, but it is nice solution especially for cluttered scene setups, because each step provide nice visual feedback.
Here is an example - two variations of shelving at the same place, that can be isolated in 3d viewport using this technique right in dynamic context.
Not sure if it is needed, history discard works pretty much nice. Need to test)
Yeah, that's a very nice example showcasing the power of this feature that you discovered.
Yup :)
In my opinion everything is working nice.
What do you think about implementing the ability to select collections objects from M menu (with the dot sign icon)?
Right, selecting objects, I'd almost forgotten about that. I still need to do something with hotkey preferences, but I'll look at the selection stuff too.
How's this, I integrated one of my old selection tests into the current collection manager. I think the functionality is good and the UI is decent. I changed the icon to the dot as you requested, but I think something like this {F9803669, layout=inline, size=full} might fit better.
Let me know what you think.
Collection_Manager_object_selection_CM_Test_01.zip
Yes, it works nice, shortcuts are solid and useful.
But, if you remember, its placement close to Set Object collection button is dangerous, like playing with fate, so you can easily missclick and accidently send everything selected to some collection)
Maybe something like that?
This way there is no chance to accidently send a selection to some random collection, and you can clearly observe what collections are already selected.
Interesting solution. What do the grey dot, white dot, and arrow symbol signify?
And yes, I remember that it's dangerous, I had hoped to have undo support in first, but it has problems. (I should take another look at it)
I'm also wondering why an icon to the left of Set Object collection is more dangerous than the icon (exclude checkbox) to the right. (Apologies if I've asked this before)
I think of white dot as "selection is applicable" and grey as "not applicable" like it works right now - it allow to detect if collection is enabled by RTOs.
Arrows symbol (or another large scale symbol) stands for "all objects in that collection are selected".
Forth icon can stand for "some objects are selected" if it is possible.
The "Exclude" checkbox has a large icon, so its size is clearly defined and also visually separated by a separator.
I can't say that this neighborhood is perfect, but at least it is not that critical as in dot case.
Hm, seems like it's mostly duplicating the information reported by the set object collection button.
I think if we used the large scale arrows symbol next to the set object collection it wouldn't really be any more dangerous than the exclude checkbox.
However, if you're really worried, we can place the arrows symbol next to the active collection button for now with the intention of moving it next to the set object collection button once the undo buttons are in.
I don't think the additional indications on the selection button are necessary, but again, I can put them in for now and then remove them later when undo is added.
Yes, it seems like this, almost the same sets, but appeared by different reasons.
However, selecting states set do not have much to do with depicting active object and sending set don't care about selection completeness.
Also you can send objects to empty collections but can't select anything in empty collection.
Maybe it will work if to add an else one vertical delimiter between selecting and sending buttons? This can help to visually separate the button space.
I need to think about all of this and do some tests.
Sure.
I think that's probably depends on items shape centres recognition.
Currently I see them like that
Okay, how about this?
I've combined undo support in the CM popup with the object selection UI that I personally prefer.
There is a known issue with undo support currently that copy/swap state and RTO history is not preserved on undo/redo (let me know if this is a minor inconvenience or a major blocker).
Collection_Manager_object_selection_plus_undo_01.zip
Interesting approach.
But is it does not look overloaded? That icon looks pretty... massive.
Undo/redo UI looks great.
Not sure if I understood copy/swap issue properly - it seems to work nice for me, may be I am missing something)
It seems that Renumber QCD slots also maps 21th slot, which does not exist. Can you confirm that?
Yes, the icon is a bit big, but it was the only icon from the default blender icon set that seemed to fit well as a selecting objects icon.
Unless you have one from the default icon set that you prefer, we could go the custom icon route and do something like what's pictured here:
{F9878897, size=full}
Thanks :)
Not sure if I understood copy/swap issue properly - it seems to work nice for me, may be I am missing something)
The issue is that if you copy RTOs (but not paste), then undo, then redo, the RTOs will not be recopied. (same goes for swap, and the RTO histories, although the RTO states will be redone, just without the previous state saved).
I think I know how I can solve this, but it requires a structural change to my addon that I'm not sure I want to get into quite yet if this is only a minor inconvenience, however if it is a major issue I'll try to solve it now.
Yes, I can confirm. Don't know why it's doing that, but it's it's also present in my last released version :(
Aw, copying RTO without pasting is not a completed action, because it don't cause scene setup changes.
It is like dragging object without final location confirmation, which you can interrupt at any moment, so this behavior is typical for blender, and there is no issue in my opinion.
About selecting icon - I think that dot icon with vertical delimeter between selecting/sending buttons can be a better design, because currently it is easy to confuse selecting icon and constantly changing sending icon.
Dot design will also look more lightweight, and filled/empty dot is actually a nice idea - as a result you are looking at icon you are actually selecting, instead of checking its neighbour.
I made a mockup, the first line is the part of the current screenshot, left for comparison.
It is easy to distinguish sending and selecting icons by icon's "mass" and they are visually separated so they are perceived as separate buttons due to vertical separator and additional space.
Selecting button in not looking like yet anoter RTO, as a result, such a layout looks more lightweight and clean.
Dot is also closer to collection's name, and that is logical, because selecting is probably the most relevant operation with collections.
Also, it will be nice to have three states of circular icon, it will be enough for quick situation recognition.
It was a very useful and handy idea - to see if collection is not available for selection because it was turned off by some of RTOs - you don't even need to check it's full list, having only what you need - the result.
Awesome UI/UX solution!
Also, I think that sending and selecting icons can be added to RTOs display options list, for the case if you need to turn them off, for example, for better safety on complex projects.
That's easy enough, will do.
Yes the dot doesn't look like an RTO, however it is visually very similar to the "decorator" icon that indicates something can be keyframed, especially when placed so close to the text field like that. It also doesn't expressly relate to selection and since it isn't grouped with the Set Object icon there is no obvious relation, and it's much smaller, making it harder to click on. That being said, it does look very clean and I see now the need for differentiating between objects available for selection and all objects selected, but I really think it should be grouped with the Set Object icon (it doesn't have to be right next to it, we can leave a little space).
I'm not sure if I'm right in all this, and in some ways what you have suggested looks very good and makes a lot of sense, but let me know what you think of my concerns.
I think that the ability to select all objects of a collection in some way, technically, is more related to collection's slot rather than sending objects to it (which is more related to sent objects), or even changing RTOs (which is more related to scene setup).
Selecting is an operation that is performed on multiple collections more often than any other - for example, you almost never send objects to multiple collections during work, but having to select multiple collections is a common thing.
I can easily see design like this, where selecting button is a part of name slot, so you can control name and make selections with searching names in the names list.
I see no critical logical errors when I see this picture - when you need to select some collections, you need to select the whole collections by searching their names, so name list is here, selecting buttons are also here, everything is ready for selection...
Okay, your latest mockup addresses all of my functional concerns, and it does seem to work well, so if that's what will provide the best workflow for you we'll go with that.
Edit: The more I think about it the more I like it and see it's value. You're right about needing to know which collections you're selecting and this allows you to do that while still being able to see the additional information provided by the Set Object icons.
Yes, to select a collection you need to know two parameters - it's name and availability for selection.
The name is provided with a name slot, and the dot icon allows you to control the availability of a selection without having to check the entire RTO list.
You can also check if some objects are hidden, and selection is not complete if dot is not filled as a result of a selection, so you can go to scene and unhide objects if it if needed - this will be useful for collection transformation operations.
Empty collections (with no objects) can be marked with an empty slot (missing dot icon).
I also like the design similarity to the QCD slot, it makes it clear that the QCD slot is a "collection with a number instead of a name", and a collection is a "named QCD slot".
Dot means different things though, but dots set is different, and placement is different, so I don't think it will cause serious recognition problems.
Yup, I really like the design. I initially missed some of the critical features it has to facilitate your workflow, but I see them now. :)
I've added the undo support and selection features to master, I wanted to get it in before bcon2 starts, but if there are any further UI tweaks needed, just let me know.
Here's a zip update that contains these features:
Collection_Manager_v2_21_0.zip
I tried it and I think that our design really works!
The default gray background for an unselected collection and the gaps between setting and selecting buttons look nice - they are no longer so easy to confuse.
Selecting button placement allow to recognise hierarchical position of the collection, this is nice for hierarchical selections.
Shortcuts and the tooltip are clean.
I would like to suggest a slightly different indication to try when a blue fill indicates a selection and a dot icon allows for completeness control:
In my opinion, this will allow better control of the current selection in case it needs to be extended to objects of the entire collection.
The current behavior is returning a result that is difficult to interpret correctly, especially for hierarchical selections like this:
In this case 14th collection contain hidden object, so it contains a selection, but its icon looks like this collection contains no selection at all, and you have to check it's set icon to be sure that it was selected.
If its icon is blue with a blank dot instead of filled, it will probably be much better to describe the current situation.
Also I think this will allow to put the setting button in the display options, since we will need less of it to produce and control collection's selection.
Yup, it does. :)
I had hoped to avoid this, but you're probably right. I'll put something together to test it.
Okay, here's a test version with updated selection state indication.
Collection_Manager_object_selection_04.zip
After further consideration, I'm a little worried that using the QCD icons for a slightly different meaning may be confusing.
An empty circle in QCD means selected objects, while an empty circle in the CM popup means selectable objects, and the select buttons look an awful lot like QCD slots now.
Although not quite as nice, it may be better to go with these diamond icons to reduce confusion:
Let me know what you think.
Now Collections and QCD slots have sufficient visual contrast, while at the same time not losing semantic similarity. I tried it and like it very much.
Diamond icon is bigger, it occupies more space of a selecting button, so it easier to read/percept in the CM window, while circle icon perfectly fits tiny QCD slots.
I love the way selectability indicates availability - it is so helpful to detect what is going on when you tweaking RTOs setup.
The ability to see the "summary" of you setup is essential, especially if to take into account all those possible chaining/non-chaining RTO setups permutations.
I can already feel with my skin how much this will be useful when setting up scenes. In my opinion, this is an important step in the very right direction.
I also like marking selection with blue filling, now situations like that are way more recognisable - it is easy to detect both selection and completeness parameters at the same time. You can see that collection was selected, but selection is incomplete, unlike the previous version, when it was unclear whether the collection was partially selected or not selected at all.
It is also useful for selection expanding and control - now you can to select some object, find its collection in the list and expand the selection to the entire collection, or make its RTO setup if it is needed - now user's selection provide a very nice feedback to the CM's list, that gives feeling of a better overall control.
The scene collection still has a circle icon for comparison, so it can now be replaced to the diamond one.
Awesome job! Lovely)
Thanks. :)
And thanks for your detailed testing and explanations!
Yep, I agree and like how this has turned out very much.
I'll replace the scene collection's circle icons with the diamond ones and commit it to master :)
Excellent)
Zip Update for 2.93:
Collection_Manager_v2_21_3.zip
Here's selecting cumulative objects to test. The operator can be found in the specials menu in the CM popup.
Collection_Manager_v2_22_0.zip
Looking nice!
It is very useful to detect if your scene have cumulative objects, since they don't predictably follow RTO setups.
The only issue I found at the moment is an error when all the collections of a cumulative object is turned off by EC.
In this case function can't make a selection, so it would be nice to indicate this with info string, for example like "24/30 objects are selected".
Ah okay. Thanks.
Here's an update :)
Collection_Manager_v2_22_2.zip
Now it is just perfect.
Zip Update for 2.93:
Collection_Manager_v2_22_3.zip
Test for more easily adding QCD slots:
Collection_Manager_qcd_unassigned_slot_operator_test_01.zip
Nice and handy functionality!
I need to think about hiding menu item. It is weird if inactive menu item is hidden, it is usually greyed out in Blender.
Also, what if to name collections generated with this tools as Slots (Slot 1, Slot 2 ... Slot 20) in order to differentiate generated collections from manually created but not renamed.
This can be useful to track such collections by names, splitting dynamic (QCD) and static (regular collections) contexts.
Thanks :)
I know that menu items are usually greyed out, but this operator only works when there are less than 20 slots configured and there is no way to display why it's disabled. I think hiding could be a good option, or we just leave it enabled, or I suppose, people will probably be able to guess why it's greyed out, but I think that's my least favorite option.
I thought about naming them as slots, but in the end, they're just normal collections. Plus, if the slots are then unlinked from those collections, it'll be confusing seeing collections named slot X when they aren't actually QCD slots.
Being able to click on unassigned slots is so handy, since there haven't been any major problems, I think I'm going to just add it to master as it is now, and then we can change things later if needed.
Apologies for not being as active here for the past little bit, I've been involved with other things.
Nice!
I still thinking about generated names differentiations and also involved other things)
How about "Select cumulative collections" function for Specials, which will select all objects of a Linked(cumulative) collections?
There is also a need to select objects of a collections which are linked to other scenes to have the ability to detect them...
p.s. I am sorry but...
Such a... naming and such a... management are so confusing that it my raises my blood pressure every single time I touch them.
For a workflow designer who must be incredibly sensitive to even the tiniest issues, it is incredibly painful to even look at such implementations of a content management systems.
The defaults looks like they was originally designed especially to be confusing.
Such an issues are just like fire alarm screaming in the ear "every project you will start using such a system is doomed to destroy your health".
For the first point, I'm not sure whether you mean all objects in all cumulative collections or all objects in a single cumulative collection, but don't we already have that ('Select All Cumulative Objects' for #1 and the selection operator that was recently added for #2)?
For the second point, I didn't even know you could link objects to other scenes, heheh (I have only ever worked with 1 scene). But it should be easy enough to support. Is it selecting all objects in all collections that are linked to more than one scene, or selecting all objects within a specific collection that are linked to more than one scene that is needed?
I empathize with you.
It is a very complex system we're working with here, and there can be difficulties using it. Hopefully the workflow issues will eventually be resolved.
At this point I think we go to the deeper system design.
There are different ways to define a collection - list filtering, selecting all/some of its objects or assigning color.
Coloring is pretty flexible collection marking tool, can we technically obtain its support in CM?
This will allow to color desired collections types based on its properties, and provide extended operations with them, for example, reset colors, set specified color to all collections linked to other scenes, paint cumulative collections with magenta, select all objects of all collections that shares the same color, and other similar operations.
We can definitely support the color tags that are used in the outliner and provide extended operations for them. If you are thinking of custom arbitrary coloring outside of those 9 tags, then it may be possible, but would be more difficult.
I had been thinking of using the colored tags as an interface for grouping collection's visibility as a kind of alternate to QCD slots, so I'm not sure if the two use cases are compatible or what the best way forward is.
I think it would be an useful option to have a way to color a set of collections in a gradient of a color, like the bone groups, you also dont need infinite variations, just more than the few colors we currently have, maybe light, medium and high in terms of color saturation and value for each of the currently available colors, that would give the user more flexibility to organize the collections.
Color tags are originally invented in 80's software like autocad, to colorize objects and layers by demand.
Now autocad it has 256 colors palette to satisfy engineering demands.
3dsmax by default has reduced palette, with autocad palette support.
https://knowledge.autodesk.com/support/3ds-max/learn-explore/caas/CloudHelp/cloudhelp/2019/ENU/3DSMax-Modeling/files/GUID-844CB09D-F65A-4FAB-9763-001FD32A0920-htm.html
Blender has got nine colors, and without the ability to colorize collections in viewport.
I think CM should support the default blender palette anyway, since it is a minimal system requirement which is quite necessary to satisfy. Color tag is quite a property of a Blender's collection, alongside with name and RTOs.
CM will reach compatibility with vanilla solution - the ability to correspond to outliner, but also much more efficiency from using colors than vanilla solution because of a proper color management tools design anyway, so I think that supporring 9 vanilla tag colors solution is the best we can do.
Technically, I believe we could support as many colors as are wanted, but it would only apply to the CM, so for this reason, and also because it is much easier, I suggest that for now we stick to adding support for the nine color tags and adding color based management tools. I think we could also add in a tool to display the objects (at least most of them, stuff like empties and cameras I don't think can be set to a color) in the viewport based on the collection color, or use object color to show other things. One thing to figure out would be what color to show when an object is in multiple collections with different color tags.
A bit of general technical information about pallets that could be interesting and useful.
Size of a palette defines color contrast between swatches.
For example, 256 colors Autocad palette was built around technical application, so it allow to define 256 different types.
Such an application require black background to read the contrast between swatches properly, so there is a workflow-deendent background color separation in Autocad.
You can spot the difference between the same colors on this screenshot, the only difference is a background color, and black background allow to read all the 256 colors palette, while white - only the brightest colors.
Quite often AutoCAD experts argue which background is better, but in fact it depends on the type of work performed.
Just because the requirements of the designer and the engineer are different.
When I proposed collection viewport display I proposed to preserve some technical color to display cumulativity (like magenta that displayes lost textures), but as a system design information it was quite ignored.
The tread about collection colors was filled by features requests, like how it should look like instead of how it should work.
Since we are painting objects, I think there will be no problem to chose some additional color to represent cumulativity.
There will be the same problem with cumulativity - in current realization viewing and sending object is absolutely clear, because numbers disallow cumulativity.
When you set colors it is not easy to remember if some color was already used.
We also discussed [Multislots ]] paradigm in [ https:*developer.blender.org/T69577#1002257 | aug 2020 as a possible solution for extended collection trees viewing, but there was no time even to start.
I think that it is reasonable to start from basics - the ability to correspond colors to outliner, to set colors to collections, and the Clear colors function.
Clear colors function will require a design solution, for example, there will be need a Colors dropdown menu next to Specials for color-related features, but it is hard to say since we don't know how much there will be Specials or Color functions.
Found an issue with Ctrl+Shift+LMB collections selecting/deselecting - If collection is empty its nesting collections can't be deselected with such an action.
A video
Deselect issue.mp4
Can you confirm?
Thanks for sharing this, it is quite interesting and useful :)
Sure. That'll work.
Yeah, I remember that discussion. I think using colors to serve as a Multislot paradigm could work on the more artistic side of things. I have a couple ideas, but I need to test some things.
Yes, this sounds about right.
Thanks for reporting. Yes, I can confirm, and I'll look into it.
Zip Update for 3.0:
** Each unassigned slot operator has a tooltip specifying it's an unassigned slot, which slot number it corresponds to, and lists the hotkeys that can be used with it and their functions.
Collection_Manager_v2_23_1.zip
Yes, empty collections are working now!
Thank you)
Sorry for the long wait, but I think things are becoming clearer for me now. Here is a test for supporting collection colors. To use: click and hold on the collection icon to bring up a menu where you can set the color.
If all goes well, the plan is to add a click and hold menu to most of the other operators to allow for the continued expansion of operator functionality, efficiency, and clarity. After that, the plan is to add preferences for hotkeys, both for the keyboard and for the button hotkeys so that you can have a couple quick hotkeys for commonly used button actions and use the menu for the rest. Plus, this should allow us to save some space in the tooltips.
At least, this is my current plan, and as I go about adding in the menus I'll add in some missing convenience operators as well.
Collection_Manager_collection_color_test_01.zip
Hi! Nice update, it is very useful to have color information corresponding to the outliner!
One of possible further Specials can be "Paint objects colors from collections colors" to have the ability to view painted collection distribution right in the viewport by using object color viewport shading.
As a result it will look something like that:
I decided to organize a bit better test scene for Collections development.
CM_VID_ROOM_2-93 by 1D_Inc.zip
Some cross-hierarchical structures are organized as 3D texts for a better structural clarity and visual control.
Also posted this file there .
I noticed that CM stopped displaying linked (cumulative) collections, that belongs to several collections in case if you expand collections manually, while Expand all items buttons show them properly.
I painted them yellow for this screenshot (3-1-0 is used).
Manual collections expanding:
After Expand all items button:
Can you confirm that?
Thank you! And thanks for the comprehensive feedback!
Yes, that sounds like a good addition, as well as selecting all objects in a set of colored collections (e.g. select all objects in collections colored red, etc.), and isolating RTOs by collection color, but I want to leave these more complex things for now until I've reworked the base to be more solid. Although, if, while I'm adding in the menus and missing convenience functions, I see spots to implement collection color related stuff that'll be pretty easy, I'll add stuff.
Thank you very much for this, this is great!
Yes, I can confirm, but this isn't a new bug. Linked (cumulative) collections have never been displayed (supported) properly, and it's not an easy bug to solve, but I suppose it's time to tackle it.
Aw, okay, a known issue then. Probably, I forgot about it.
There is another potential issue I found with collections selection.
Ctrl+Shift+LMB supposes to add/remove nested (the entire branch) to/from a selection, but it fact it inverts existing one.
If some nested collections are already selected they inverts their state instead of following root collection's state, which can be confusing, especially if the branch's root collection is collapsed.
How do you think?
I think it will be enough to provide objects per collection coloring only at some point, since the rest can be achieved with vanilla functionality and functionality already presented in CM.
For example, if objects are already colored, you can select objects that share the same color with
Shift+G - Color, isolation can be achieved with further pressing=hotkey (isolate selected objects collections operator from CM) and so on.It is assumed that if you have some kind of an objects color scheme in your scene, you already have all the necessary functionality to use it.
No worries! It's about time I tackled it anyway.
Yup, that looks like a bug. I'll see what I can do.
This sounds alright, but what about stuff like lights, cameras, and armatures? While they technically have the viewport color property, it isn't exposed to the UI, so changing it could cause unexpected results for the user.
This is Blender, I never assume anything 😛
Thank you)
Ctrl+LMB works properly - resetting existing selection, so probably Ctrl+Shift+LMB has got inversion issue when additive logics was applied instead of resetting one.
Indeed. Well, how about to support geometry objects (meshes, curves) only?
First - it is a nice and accurate step to begin with, second - collections coloring is needed to navigate/control massive datasets, and geometry objects forms the most massive dataset that require such kind of visual handling (it is quite a specific task), third - they have this property exposed in UI, so they was born for this. Further possible steps can became more clear after testing that one. I think we can afford such design flexibility at this point.
I could probably try to argue with this argument, but you're goddamn right.
Yeah probably. Thanks for catching it!
Yes, I fully agree in supporting coloring object by collection, I was just suggesting that we should probably also have select objects by collection color as well. But you make an interesting point, we probably should limit coloring to objects that have the viewport color exposed to the UI, at least initially.
🙂