Sculpt Mode performance drop with Overlays #56466

Closed
opened 2018-08-20 17:29:31 +02:00 by Julien Kaspar · 14 comments
Member

Blender Version
Broken: d2e70455cf

Short description of error
When disabling Overlays in Sculpt mode the overlay color disappears as well and the performance increases drastically. None of the individual overlay settings seem to cause the performance drop so it might be connected to the overlay color or something else.

**Blender Version** Broken: d2e70455cf4 **Short description of error** When disabling Overlays in Sculpt mode the overlay color disappears as well and the performance increases drastically. None of the individual overlay settings seem to cause the performance drop so it might be connected to the overlay color or something else.
Author
Member

Added subscriber: @JulienKaspar

Added subscriber: @JulienKaspar

Added subscribers: @fclem, @mont29

Added subscribers: @fclem, @mont29
Clément Foucault was assigned by Bastien Montagne 2018-08-21 17:12:45 +02:00

Not sure that is a bug, I guess the whole overlay system is doomed to have some impact over performances… But @fclem shall know more. :)

Not sure that is a bug, I guess the whole overlay system is doomed to have some impact over performances… But @fclem shall know more. :)

Changed status from 'Open' to: 'Archived'

Changed status from 'Open' to: 'Archived'

Well it's because the sculpt mode overlay is considered as an overlay (huh). So it draws the mesh twice. There is not much we can do because this is by design.

Well it's because the sculpt mode overlay is considered as an overlay (huh). So it draws the mesh twice. There is not much we can do because this is by design.
Author
Member

@fclem But this is still going to be resolved at some point, preferably before the beta? This seems like a big flaw to me in terms of performance. If the design dictates that the mesh is always going to be drawn twice then it should be changed/adjusted to fix the issue, right?

@fclem But this is still going to be resolved at some point, preferably before the beta? This seems like a big flaw to me in terms of performance. If the design dictates that the mesh is always going to be drawn twice then it should be changed/adjusted to fix the issue, right?

Added subscribers: @MikeErwin, @dfelinto, @brecht

Added subscribers: @MikeErwin, @dfelinto, @brecht

This was a concern I had all the way back when we designed this. But @dfelinto and @MikeErwin told me to not worry about this.

In another hand it does allow us to have decoupling of overlays representation and the underlying render so that you have the same overlay result in eevee and solid mode. Mixing the overlay with the actual shading step would make everything way more complicated.
Also the mesh is rendered as many times there is overlays plus 1. So if you are in sculpt mode + face orientation enabled + wireframe that makes 4 render. We could try to batch face orientation + wireframe together but that's increasing complexity. Batching all overlays together is also a dead end (IMO).

So if someone has an Idea about how to solve this issue I would like to hear it.

Tagging @brecht if he has an opinion.

That said, @JulienKaspar how much of a difference does it makes? is it twice as slow?

This was a concern I had all the way back when we designed this. But @dfelinto and @MikeErwin told me to not worry about this. In another hand it does allow us to have decoupling of overlays representation and the underlying render so that you have the same overlay result in eevee and solid mode. Mixing the overlay with the actual shading step would make everything way more complicated. Also the mesh is rendered as many times there is overlays plus 1. So if you are in sculpt mode + face orientation enabled + wireframe that makes 4 render. We could try to batch face orientation + wireframe together but that's increasing complexity. Batching all overlays together is also a dead end (IMO). So if someone has an Idea about how to solve this issue I would like to hear it. Tagging @brecht if he has an opinion. That said, @JulienKaspar how much of a difference does it makes? is it twice as slow?

It's not clear to me what this sculpt overlay is doing. I see 3 things:

  • Show Diffuse Color: this option seems pointless as workbench/eevee can already do it, this is a legacy thing from when sculpt mode did not support drawing materials. Let's remove it?
  • Show Mask: this is needed, but we should be able to avoid drawing it if there is no masking used.
  • Darkening of the mesh even when the above two options are disabled, seems the color defaults to 0.8. Let's remove this behavior as well.

So perhaps it's acceptable if masking, face orientation and wireframe cause some slowdown. Maybe masking could be put into workbench shaders if performance matters a lot. But in the simple cases we can avoid drawing the mesh twice?

It's not clear to me what this sculpt overlay is doing. I see 3 things: * Show Diffuse Color: this option seems pointless as workbench/eevee can already do it, this is a legacy thing from when sculpt mode did not support drawing materials. Let's remove it? * Show Mask: this is needed, but we should be able to avoid drawing it if there is no masking used. * Darkening of the mesh even when the above two options are disabled, seems the color defaults to 0.8. Let's remove this behavior as well. So perhaps it's acceptable if masking, face orientation and wireframe cause some slowdown. Maybe masking could be put into workbench shaders if performance matters a lot. But in the simple cases we can avoid drawing the mesh twice?

Changed status from 'Archived' to: 'Open'

Changed status from 'Archived' to: 'Open'

The idea of having a mode owning the data representation is to make it faster, not slower. For example it allows the sculpt mode to draw straight from BVHs, mesh edit mode from BMesh, ... But if you have an overlay that needs to be updated at every edit there is so much we can do.

Having a dedicated engine for sculpting also allows (in the future) to support mesh preview of to be sculpted mesh and other fancy options.

Anyways, I agree with brecht's suggestions.

The idea of having a mode owning the data representation is to make it faster, not slower. For example it allows the sculpt mode to draw straight from BVHs, mesh edit mode from BMesh, ... But if you have an overlay that needs to be updated at every edit there is so much we can do. Having a dedicated engine for sculpting also allows (in the future) to support mesh preview of to be sculpted mesh and other fancy options. Anyways, I agree with brecht's suggestions.
Author
Member

@fclem I think it takes double the performance with overlays on but all additional overlay options disabled. With wireframes, etc it gets drastically worse.

I also agree with Brecht. When using the overlays like wireframe & face orientation the slowdown is alright and to be expected but I am all for removing the extra color differences etc.

@fclem I think it takes double the performance with overlays on but all additional overlay options disabled. With wireframes, etc it gets drastically worse. I also agree with Brecht. When using the overlays like wireframe & face orientation the slowdown is alright and to be expected but I am all for removing the extra color differences etc.

This issue was referenced by 0ba3a1a686

This issue was referenced by 0ba3a1a6863a4b5960933df7d5a12d158da5d0d0

Changed status from 'Open' to: 'Resolved'

Changed status from 'Open' to: 'Resolved'
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
Interest: X11
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#56466
No description provided.