- multiuser enviroment are strange also in studios.
- QCD are easy to use, also to manage. I use it in same way that you told. But it’s true taht you need to remember the layers.
- It’s really useful
- Actually we have a sem-QCD system. Devs only need to improve it
That’s easy - we will use collections in that case.
Nice picture, but it is a bit out of scope. It would be right, if we would ask to replace collections with QCD completely. But it is not true)
We need collections as well as proper QCD system on top of it, because they are, actually, different types of systems, and are needed for different certain types of production. They are not “replaceable”)
We don’t want them apart, we need them together, as it splits community by workflow type.
That means, that you don’t need it. That’s ok)
But does this mean that if you don’t need something, then nobody needs it?
In further I will explain what QCD were designed for. There are several pages left. It’s a complex question.
Currently Blender 2.8 has a QCD system, but it is not sufficiently developed to reach it’s full potential, since it was made outside the context of production requirements.
Those pages are from conversation with devs. I made them month ago and just posting them here.
Well, finally, pages, that describes wide range of concave / constructive workflow process, micromanagement and type of context terms.
page 5
page 6
The type of content context affects the workflow type.
Folder system is a nice example for context type explanation.
- When user creates folders like “House project”, “BMW x5 model”, “Wedding photos” - it is static context, a context that can have short name, that is suitable for common layer systems.
- When user creates folder “11111”, “New folder 2”, “URGENT”, “Misc”, “To sort”, that means that user faced with a dynamic context, that cannot be described with a couple of words, and only the content itself determines its purpose in that case.
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) into a static context (final models, scenes or products).
So, we need a proper QCD-driven micromanagement tool to handle dynamic context.
2 Likes
By the way, here is video about how Maya users trying to overcome industry standards speed limits.
They are forced to make visibility animation in order to get a bit portion of QCD system flexibility.
U(2) = 3, so 3 keyframes are needed just to have ability to view full combinations of 2 elements.
So they are editing animations for static objects, and calling this “a nice tip”, even if Maya has a common layers system for decades. So, it’s all about speed.
U(5) = 31, so ,to process all possible combinations of 5 objects, you need 31 frames or 31 view layers.
We have dozens of such objects, even on average projects, so absence of proper micromanagement engine turns into a huge problem.
2 Likes
There were no layer system in blender.
There were visibility slots system accidently called “layers”
Collections are an attempt to bring common layer system to Blender.
Just like tagging system was called “groups”, move as “grab” and other things, unlike in industry standarts.
Well, there are no “new workflows”, there are “different workflows”.
You don’t need quick visibility navigation, because your work is creative, not constructive.
Quick Content Display system (those “squares” or “layers”) are needed for wide range of
complex constructive workflows.
Your work is not related to that kind of workflow, so it is ok that you don’t need and don’t understand why such system is needed. A lot of people have creative workflows, they never faces situations, that constructive workflow people faces just daily)
So this split is between creative and constructive workflows people.
sooner or later it will come out an addon that will restore the situation of blender 2.7x layers…
precisely because we need this type of constructive workflows
Here are a problems with it
I’m really interested in different ways of working but I have no idea what you mean besides there’s a difference between the layers systems in pre/post 2.8.
That and you are doing Autocad type of stuff? I guess if you can get away with using a Maya alternative for an Autocad alternative that’s pretty cool. It’s not like blender has to only be for goofy artistic stuff, but l imagine you’ll be waiting a while for the creative issues to be ironed out first. But who knows maybe I’m wrong, or misunderstanding what you even meant.
I’m going to go grab 2.79 again or maybe just checkout and build 279 for the heck of it and try to figure it out myself. All I’ve ever cared about was show / hide different groups but since you actually have experience with both layers systems, I’d like to learn if you have a video I can watch or something
Interesting stuff I’ll be checking it out in a while. Whether it affects what I’m doing it’s good to know about it at least a little bit
That’s the main point - this depends from certain type of your production.
Basically
- If you are managing massive and complex scenes (archiviz, animations), you need Collections system to effectively manage static (predefined) context.
- If you are producing complex assets with multiple references of different type, LODs, variations, and other inplace temporal data (engineering, gamedev), you need QCD system to effectively manage dynamic (temporal) context.
Also could you give specific use cases? For example “I am a <role, eg animator>, I want to . Using old layers, I would , now I must .” You’ve explained how things are different, but I’m not clear on why that matters. When designing UX, it’s important to focus on what the user is trying to accomplish. You’ve explained what is different, but it’s not clear to me why that matters.
For quick hiding/showing collections, there is shift+Num, so there is quick unencumbered hotkey control. That is what you want with “Quick Content Display System”/CQD.
Objects may be linked in multiple collections, so to me they seem to have the same versatility and even more unlimited combinatorics. But perhaps there is a specific use case that it makes a difference?
Combinatorics means ability to compare several states of the system.
You can try to compare 5 different states of entire outliner in a second.
You will make it once, maybe twice… but you will never want to work like that.
a specific use case
For sure. As it was told before, QCD is needed to handle dynamic context, for wide range of
complex constructive workflows. It’s main goal of QCD is speed of combinational access.
But what is the point of your question? If you are asking, it means that your work is not related to this area anyway)
Numeric QCD slot control (that “shift+Num” thing) is a part of the QCD system.
It was about to be removed. Why do you give us an example of what we saved?
1 Like
It does not make any sense to me at all, maybe I do understand it wrong. You say that 2.79 “layer system” is quick, how could I use that? When I managed layers in 2.7, I forgot what was where after 5 minutes (not literally), I had to click on every layer to find my stuff, usually wasting time for that and also for waiting while modifiers get executed again.
Whatever 2.79 layer system was it is not a match for collections.
I guess, if you click with mouse, you definitely understand it wrong)
Again - QCD system is needed to handle dynamic context.
That means, that you cannot manage that type of contexts using names.
Those slots are used for temporal data you have to forget after modeling.
That’s how dynamic contextual separation works.
It is immediate access to any combination of determined visibilities, that is needed to survive during any kind of complex assembly modeling, that requires multiple references of different type and also has several states or LODs.
Whatever 2.79 layer system was it is not a match for collections.
Both QCD and Collection systems are completely different systems that are needed for different cases, different purposes, different context types and for different stages of work. There is no kind of “matching”.
We may need QCD (for complex asset/assembly creation), Collections (for complex scene content management), both of them (like we does), or none of them (for tasks like sculpting or shader setup).
2 Likes
Again, should this QCD be managed on user side? It sounds like some resource management system for videogame engine, rather than human-friendly system.
I see it in this way: whatever blender 2.79 had as a layer system (call it any way you want), it did not do its job well, because a user had 20 identical unnamed buttons. You say it could do some great stuff, how does it work on my side? Do I still have to press those 20 unlabeled buttons? If it should be something under the hood, why should I care?
I ran through your slide again - 20 hidings or isolations displayed in one place, nice, but I can see only 20 buttons, that I used just to speed up slow 2.79 viewport, because it is not user friendly, it is not human-friendly.
How should QCD UI look like?
I see it in this way: whatever blender 2.79 had as a layer system (call it any way you want), it did not do its job well, because a user had 20 identical unnamed buttons.
2.79 never had a “common layer system”. But it had content management system.
What do you mean under “it’s job”? Systems never have a job, it has a purpose, and job is what users have.
First you must determine what kind of job the system needs to handle in order to determine if it does it “bad” or “good”.
Example - HDD system have a purpose of storing files (its goal is capacity). It can be used as a RAM (for swap files), but as a RAM system it will always be bad.
How should QCD UI look like?
UI of every system have to satisfy specific demands, declared by its purpose.
1 Like
Near as I can tell, 1D’s describing a tag-based organizational system — built around bit arrays instead of strings or integers — that can be used to filter what’s displayed in the viewport.
Blender lets you filter the viewport hierarchically (collections) and categorically (object type visibility). You can piece together a tag system using custom properties and object/collection naming schemes, but that approach has scalability issues that a C implementation of bit array tags wouldn’t face.
If you’ve had the ‘folders vs tags’ conversation, you know the usual use cases.