Object-based Layer Management Feature

Proposal Info

Areas: Layers, Core, UX
Proposal Type: Overhaul

Overview

Object-based Layer Management Feature:

Use “objects” to manage layers. Similar to Unity, each object can have multiple components (layers) attached. This allows us to more easily control the visibility (show/hide), opacity, position, etc. of layers that exist in different locations. Selecting an object is equivalent to selecting multiple layers. Objects can also have parent–child relationships.

The concept of “objects” works very well: they can represent different characters, body parts, weapons, equipment, and so on. Use object-oriented thinking for classification and drawing, and layer-based thinking for ordering.

Proposal status: open-for-discussion
Discussion ends: 2026-05-06

Thank you for your proposal! A few questions though.

What components do you consider? How is an “object” different to using folders? Selecting a folder does select multiple layers, folder has properties like a mask, filters and so on.

Why object-component model would work better than layer tree? Technically, nodes are just objects with multiple properties, although their behavior is defined up-front.

Sorry that I didn’t explain it clearly before.

The Object Management panel and the Layer Management panel are complementary. The purpose of object management is to make up for the limitations of the layer panel. It’s not a matter of which one is better or which one replaces the other—they are meant to coexist and handle different responsibilities.

For example, in everyday drawing, suppose there are two characters, A and B. A’s hand is in front of B, but A’s body is behind B. In this case, folders cannot store all of character A’s layers together without disrupting the layer order. However, by keeping the layer hierarchy unchanged and using the Object Manager for classification, selecting the required layers later becomes much smoother and more convenient.

In short, the Object Manager exists to better organize and select layers, preventing layer clutter and compensating for the difficulty of classification in the layer panel and folders. The layer panel focuses solely on ordering, while the object panel handles classification.

As someone who has worked in game art for many years, I feel that none of the current drawing software can handle classification well. They are all essentially the same: they only provide layer ordering, not true categorization. Examples of messy layer structures are everywhere.

Characters, equipment, bodies, limbs, environments, another character… the layers of these objects often interleave in front of and behind each other, making it impossible to categorize them using “folders.”

That’s why I believe managing layers through objects is the best approach to classification. Objects are responsible only for categorization, not ordering. The layer panel, on the other hand, should focus solely on sorting layers.

I think I understand what you mean, objects are more like a logical hierarchy, while layers are render hierarchy.

There is still one unknown for me, what about those components? If let’s say, a parent object of character “A” has some kind of component like “Opacity”, if object hierarchy is used purely for management purpose, you can’t easily create opacity tree as it conflicts with layer’s opacity tree.

I worked in game dev for quite some time, so I understand how it works in game engines, but having two coexisting hierachies, which could influence rendering is troublesome

First, an object’s only components are “layers.” When we click on an object, it is equivalent to selecting all the layers attached to it.

When we click on a component within the object, the focus goes to that component, which is equivalent to selecting that specific layer. Holding Shift or Ctrl to select multiple components is equivalent to selecting multiple layers.

As for adjusting opacity, that should be done in the Layers panel. The Object panel does not need to provide opacity controls at all. Its sole purpose is to categorize layers and facilitate layer selection. It does not handle any rendering, and any modifications to layers remain the responsibility of the Layers panel.

Selecting a parent object is equivalent to selecting its own layers as well as all the layers of its child objects. Essentially, it is just like using Ctrl to multi-select several layers.

All adjustments to opacity and visibility (show/hide) are handled in the Layers panel.

As in game engines. Groups or rather collections(to borrow a term from blender instead). It’s more of a metadata tag rather than struct in the hierarchical sense I suppose.

Not necessarily. Or rather that depends on the engine. In Unity for example, child-parent relationship plays crucial role in determining transform tree.

I’m not talking about the scenegraph. Groups or as I said, collections in blender. That is separate from the parenting relationship in the scenegraph.