Instanced objects get their viewport display color ignored (by design) #63830

Open
opened 2019-04-23 16:21:05 +02:00 by Dalai Felinto · 11 comments

Blender Version
Broken: 022ad41670
Worked: 022ad416702d~

Short description of error
Instanced objects get their viewport display color ignored.

This is by design, as you can see in 022ad41670:

DRW: use object color from instancer

Otherwise it's impossible to set the color of instanced library objects.
Follows convention of instancer controlling draw options.

Exact steps for others to reproduce the error
viewport-display.blend

My issues with the design
The original commit seems like a workaround for the fact that the override system is not implemented yet.
I find this too arbitrary and I would favour the flexibility of having a per-object granular viewport display object color instead (i.e., revert the mentioned commit).

**Blender Version** Broken: 022ad416702d Worked: 022ad416702d~ **Short description of error** Instanced objects get their viewport display color ignored. This is by design, as you can see in 022ad41670: ``` DRW: use object color from instancer Otherwise it's impossible to set the color of instanced library objects. Follows convention of instancer controlling draw options. ``` **Exact steps for others to reproduce the error** [viewport-display.blend](https://archive.blender.org/developer/F6969625/viewport-display.blend) **My issues with the design** The original commit seems like a workaround for the fact that the override system is not implemented yet. I find this too arbitrary and I would favour the flexibility of having a per-object granular viewport display object color instead (i.e., revert the mentioned commit).
Author
Owner

Added subscriber: @dfelinto

Added subscriber: @dfelinto

#73802 was marked as duplicate of this issue

#73802 was marked as duplicate of this issue
Campbell Barton was assigned by Dalai Felinto 2019-04-23 16:23:04 +02:00
Author
Owner
Added subscribers: @WilliamReynish, @mont29, @ideasman42, @pablovazquez
Author
Owner

@ideasman42 any strong instance on this?
@WilliamReynish & @pablovazquez thoughts?

(friendly poke to @mont29 to be sure this case is covered by the upcoming override system).

@ideasman42 any strong instance on this? @WilliamReynish & @pablovazquez thoughts? (friendly poke to @mont29 to be sure this case is covered by the upcoming override system).

Added subscriber: @brecht

Added subscriber: @brecht

Viewport display settings in general are inherited from the instancer, and it's really important to be able to do this for big scenes where you want to e.g. show just bounding boxes. It's arguable if object color is such a viewport display setting or not, I don't have a strong opinion on that.

To my knowledge, neither the library nor view layer override system design can efficiently handle this case. They rely on making actual copies of datablocks, but for instancing it's important that this does not happen and that instances use only little memory.

It is possible to have a lighter override system that is implemented in Eevee, Cycles and other renderers, where the extra memory cost would be just the changed properties. And as far as I know that's what the draw manager is sort of doing for this case. But the current override system design does not account for it, so it won't automatically solve this.

Viewport display settings in general are inherited from the instancer, and it's really important to be able to do this for big scenes where you want to e.g. show just bounding boxes. It's arguable if object color is such a viewport display setting or not, I don't have a strong opinion on that. To my knowledge, neither the library nor view layer override system design can efficiently handle this case. They rely on making actual copies of datablocks, but for instancing it's important that this does not happen and that instances use only little memory. It is possible to have a lighter override system that is implemented in Eevee, Cycles and other renderers, where the extra memory cost would be just the changed properties. And as far as I know that's what the draw manager is sort of doing for this case. But the current override system design does not account for it, so it won't automatically solve this.

While this case is border-line, I think in general it makes sense to use the instencer unless there is a strong reason not to.

  • Axis & Name: don't inherit since you typically only want to see the axis of the object your instancing, applying recursively would show a lot of noise.

  • In-Front: Should be controlled by the instancer because you might want to show a prop ontop over the backdrop without having to go in an edit multiple collections to adjust something you most likely want to change temporarily at the object level.

  • Color could be either, however we already have display colors for materials, and currently color manipulation is performed on the scene selection, eg:

    • Copy color to select.
    • Select same color.

The result of both of these actions is less useful if the colors you're adjusting aren't used.

Object colors are useful as a way to set your own local color identifiers, if the instanced objects colors are used there isn't an obvious way to select objects and set their color, it could end up being quite complicated especially with nested groups, or impossible - for shared objects.


Note that we should check on each of these options, currently 'in front' isn't using the instancers options.

While this case is border-line, I think in general it makes sense to use the instencer unless there is a strong reason not to. - Axis & Name: don't inherit since you typically only want to see the axis of the object your instancing, applying recursively would show a lot of noise. - In-Front: Should be controlled by the instancer because you might want to show a prop ontop over the backdrop without having to go in an edit multiple collections to adjust something you most likely want to change temporarily at the object level. - Color could be either, however we already have display colors for materials, and currently color manipulation is performed on the scene selection, eg: - Copy color to select. - Select same color. The result of both of these actions is less useful if the colors you're adjusting aren't used. Object colors are useful as a way to set your own local color identifiers, if the instanced objects colors are used there isn't an obvious way to select objects and set their color, it could end up being quite complicated especially with nested groups, or impossible - for shared objects. ---- *Note that we should check on each of these options, currently 'in front' isn't using the instancers options.*

Added subscriber: @crantisz

Added subscriber: @crantisz

This comment was removed by @crantisz

*This comment was removed by @crantisz*

Added subscriber: @JulienKaspar

Added subscriber: @JulienKaspar
Member

I originally brought this issue to Dalai because I am using vertex colors also for pre-viz in workbench just like material colors.
Interestingly when no vertex colors are detected, the color will default back to object colors.
Since I needed to define some objects as trasnparent I had to use object colors as a result since vertex colors don't have an alpha value.
This is where the issue of instancing came in since all instances replaced the object colors I had set up.

It's a corner case and I definitely get the justifications to keep the current design.
I instead propose that we could create a UI and implementation design to let the user choose if they want to use vertex colors with material or object colors as a fallback.
This of course would also need to be discussed with the planned change of the vertex colors in sculpt mode and attribute colors.

I originally brought this issue to Dalai because I am using vertex colors also for pre-viz in workbench just like material colors. Interestingly when no vertex colors are detected, the color will default back to object colors. Since I needed to define some objects as trasnparent I had to use object colors as a result since vertex colors don't have an alpha value. This is where the issue of instancing came in since all instances replaced the object colors I had set up. It's a corner case and I definitely get the justifications to keep the current design. I instead propose that we could create a UI and implementation design to let the user choose if they want to use vertex colors with material **or** object colors as a fallback. This of course would also need to be discussed with the planned change of the vertex colors in sculpt mode and attribute colors.
Sign in to join this conversation.
No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset Browser
Interest
Asset Browser Project Overview
Interest
Audio
Interest
Automated Testing
Interest
Blender Asset Bundle
Interest
BlendFile
Interest
Collada
Interest
Compatibility
Interest
Compositing
Interest
Core
Interest
Cycles
Interest
Dependency Graph
Interest
Development Management
Interest
EEVEE
Interest
EEVEE & Viewport
Interest
Freestyle
Interest
Geometry Nodes
Interest
Grease Pencil
Interest
ID Management
Interest
Images & Movies
Interest
Import Export
Interest
Line Art
Interest
Masking
Interest
Metal
Interest
Modeling
Interest
Modifiers
Interest
Motion Tracking
Interest
Nodes & Physics
Interest
OpenGL
Interest
Overlay
Interest
Overrides
Interest
Performance
Interest
Physics
Interest
Pipeline, Assets & IO
Interest
Platforms, Builds & Tests
Interest
Python API
Interest
Render & Cycles
Interest
Render Pipeline
Interest
Sculpt, Paint & Texture
Interest
Text Editor
Interest
Translations
Interest
Triaging
Interest
Undo
Interest
USD
Interest
User Interface
Interest
UV Editing
Interest
VFX & Video
Interest
Video Sequencer
Interest
Virtual Reality
Interest
Vulkan
Interest
Wayland
Interest
Workbench
Legacy
Blender 2.8 Project
Legacy
Milestone 1: Basic, Local Asset Browser
Legacy
OpenGL Error
Meta
Good First Issue
Meta
Papercut
Meta
Retrospective
Meta
Security
Module
Animation & Rigging
Module
Core
Module
Development Management
Module
EEVEE & Viewport
Module
Grease Pencil
Module
Modeling
Module
Nodes & Physics
Module
Pipeline, Assets & IO
Module
Platforms, Builds & Tests
Module
Python API
Module
Render & Cycles
Module
Sculpt, Paint & Texture
Module
Triaging
Module
User Interface
Module
VFX & Video
Platform
FreeBSD
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
6 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: blender/blender#63830
No description provided.