Layers maniphest

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.

No, it’s about strings, integers, and types of specific content management that need them.

Currently Blender have both integers (QCD) and strings (Collections) systems, but current QCD system realization disallow to control combinatorics, and current Collection system realization is insufficient and confusing in complex scenes management.

Therefore, both systems must be improved to become more useful for the purposes for which they were intended.

2 Likes

I’m not entirely sure what part of my comment you’re responding to. I wasn’t speaking metaphorically and I wasn’t alluding to the differences between collections and the old layer system.

I brought up integers and strings in the context of tag-based filtering. The data types used for a tag system can have a significant impact on the system’s look and feel, and I didn’t want to create the impression that I was describing a keyword-centric or rating-centric system.

It’s a little hard to imagine the purpose of such a system.

I think the part of what he is talking about is how to address the collection from pipeline scripts, right now collection cannot be reliabley addressed from a script because the do not have a predictable addressing schema . There adrees change through their lifecycle based on their position in the higherarchy .

So basically you can create a script that will send your assets to the same layer, that will survive the layer being renamed or moved in the outliner I think?.

a static predictable internal address for collection would make this system more easy to manage in a pipeline.

Perhaps a scheme similar to what is used in networking could help by using three disgnation for collection

  • it’s name for the user it could be named anything
  • It’s dynamic address aka IP which can change with reordering in the outliner, can be used for manually managing the collection from the UI by the User
  • a static internal address aka Mac address that doesn’t change at all, with maybe a certain range reserved to be assigned by pipeline scripts for special purpose layers and the rest of the range is just incremented for when it doesn’t matter

By doing it that way you can have scripts that will implement cqd with any hacks

The “types of contrast” is interesting because I’m teaching someone Blender and one question I got is “why are there two render menus”.

What she was referring to was the Render menu and the Rendering workspace, which looked the same to her.

A few hours in, she was still confused which was which, and still had trouble differentiating between what is a menu and what is a workspace, because looking at the top of the screen, the only difference is an ever so slight value difference on their backgrounds.

1 Like

I’m not sure that this can be determined as a major problem - Collections system was designed to bring maximum flexibility, and name-related addressing is quite enough to work with any kind of static contextual separation. Mac-addressing for scripts can be solved as collection name prefix, to avoid manual name changes, but such scripting is pretty much rare case anyway.

However, in business, content management systems assessment concerns not only flexibility but also management effectiveness. The dependence is almost linear - the simpler the system, the simpler the management it requires, the more flexible the system, the more complex management mechanism is required for effective system management.

The problem is that this was completely ignored when developing the collection management system.

Management system is all about daily usability of a system. The management task to be solved is a business problem, and sound like that -
make urgent corrections to the scene containing 500 collections of the 6th level of nesting, in which all possible types of visibility and several view layers are used, made by several artists who are inaccessible now.
That’s just common situation in business.

Currently we’ve got a system with 3 types of visibility control for every collection (EC, VV, DV):
RTOs

Two of them are structurally-dependent (VV, DV), two of them are interconnected (EC, VV), that brings insane amount of flexibility to the system, but it’s not even possible in Blender to confidently and non-destructively (temporarily) isolate a Collection in order to immediately verify its contents without loosing current collections setup, to properly configure or check up what will be rendered, and so on.

Actually, almost any action in outliner currently leads to loosing your current setup, that makes managing complex muly-user projects incredibly tough.

So it’s all about making Blender’s vertical (hierarchical) navigation usable for complex projects management, immune to large business stress tests cases and suitable for teamwork.

3 Likes

I did a poor job of explaining things — I was talking about a tag-based filtering system, not UUID’s. UUID’s are more of an asset engine thing, although I can see how they’d play a role in collection instancing.

Tags are a form of descriptive metadata that can be used to identify the objects they’re attached to. If you’ve rated a song in your favorite music player or attached a color label to an image you’ve used tags. If you’ve used Instagram, Twitter, or Steam, you’ve used tags. If you’ve used Windows Explorer you’ve (hopefully) used tags. They’re pretty common, and extremely useful.

Tags aren’t limited to ratings and keywords; you can use just about any data type you can think of with the right UI. For bit array tags the ‘right UI’ would probably look like a block of toggles, similar to Blender’s old layer system, paired with a switch to turn the tag filter on and off.

I assumed 1D was talking about a bit array tag system because, frankly, it’s the only way I can see to efficiently implement what he’s suggested. Tag based filtering can work both across and within hierarchical structures, and it can provide a way to set and restore viewport visibility without touching the rest of the outliner. Bit array tags themselves are a byte weird, but the general framework could be incredibly useful.

yeah this is also confusing to me

A bit about types of systems and their purposes.

  • Collections system, as a Common layer system from 3dsmax or Maya, is intended for handling static context - it is needed for complex scene setup.
  • Layers/QCD (Quick content display system) - for dynamic one - it is needed for quick access in complex constructive multirefrenced modeling.
    So, they cannot be compared.

If you played modern games, like Fallout 4, Far Cry or Dying Light, the inventory slots there works like a Collection system, and the Weapon selector slots - like Layers/QCD.
They work together, and Weapon selector is just a dedicated (accurately numerated) part of inventory.


It is impossible to say that weapon selector is better than inventory, or inventory better than weapon selector - they are different content management systems that behaves differently, and are needed for different purposes.

This way, comparing Collections and QCD systems is like comparing how much animation in Dope Sheet is better than in NLA editor.
So, we can perform complex constructive multirefrenced modeling in 2.79 with Layers/QCD, “or” make complex scene setup in 2.8x with Collections, instead of making both in 2.8x, what caused the community split between hardcore modellers and artists.

Layers/QCD system’s goal is speed of combinational access.
It has got one of the best realization of dynamic context management system in modern CG, even modern games takes that concept, it has got the best realization in comparison with other software.
The problem of 2.79 is not that there are Layers, but that there are only Layers.

Collections system’s goal is capacity.
In terms of production processes any content management system is characterized at least by two parameters - flexibility of possibilities and efficiency of management of these possibilities.
Collections system have to be checked by the laws of static context management system, and it have a lot of issues to fix and improve to became a good static content management system, as it have low efficiency of management of its possibilities, even in comparison with similar systems in other software.

3 Likes

In fact, the QCD system is the answer to the question “how complex model can you build in your software without getting ripped”.
We are currently trying to reconstruct the QCD system to make Blender compatible with the multirefrence modeling workflow.

2 Likes

Thinking of making proper video about Content Management systems.
It will take time, but hope to come out with nice explanations.


may 31

Finally, the ability to clone a view layer, including while copying a scene, has been added.
https://developer.blender.org/D6862

It was completely unexpected that it is possible to create a scene setup system without being able to clone the actual scene setup. To satisfy production needs we were forced to create a phantom mode that works like temporal view layer, to explore scene setup.

3 Likes

Well, after 2 months of production, video is finally ready.

6 Likes

@1D_Inc Having you “fight” for layers and snapping tools is a guarantee that one day we will have something really powerful in this blender area :fist:

A lot of the problems mainly come from two decisions that make things very complex to manage. Much more so then in other 3D applications.

  1. The ability to have the same object in multiple Collections. Not to mention hierarchy related issues with this.
  2. Merging rendering & scene management in one setup, aka the View Layer.

I do like the way Collections makes a ‘standardized’ way of Collecting objects inside a scene into one convenient ‘package’, especially for linking or appending, but for a lot of users it became the preferred way of organizing the scene. Which is wrong imho, and I think the ‘Scene’ should be default in the Outliner on startup. Not the view layer.
CAD based models with tons of hierarchies is a good example why the Scene should be default.
Even for a experienced 3d user it makes a confusing combo of scene management & Collections for grouping (and unfortunately… rendering)

For splitting & rendering out your scene, most applications split out the scene (organisation) and render setups. Yes, there is overlap, but they are mostly separate identities.
It makes for a much cleaner organisation, especially in larger groups.

I applaud your work and video, but it only shows me the flaws in the current system, and another addon should not be the way to go here.

The Collections concept should be revised to make it less confusing and more manageable.
For now, it’s all over the place, and a bit of a mess.