Viewport performance drops drastically after switching from atributte visualization to solid view #93440

Closed
opened 1 year ago by Diogo_Valadares · 27 comments

System Information
Operating system: Windows-10-10.0.19041-SP0 64 Bits
Graphics card: AMD Radeon RX 5700 XT ATI Technologies Inc. 4.5.14802 Core Profile Context 21.11.2 30.0.14005.1000

Blender Version
Broken: version: 3.0.0 Release Candidate, branch: master, commit date: 2021-11-25 17:24, hash: 2fb8c6805a

Short description of error

I have a curve with an specific setup of geometry nodes, that for some reason, if I go from solid mode->eevee->solid mode again, it slow downs performance drasticaly for no reason.
The problem also occurs on objects that contain Sculpt Vertex Colors.

Exact steps for others to reproduce the error

Open the file, switch to rendered view and then back to solid view. note that if you go back to eevee again the performace gets back to normal.

In the video below you can see the fps dropping in the corner. It wasn't recorded with default settings, but I tried restoring them and it gave me the same result

2021-11-27 20-52-26.mp4
geometry nodes slowdown.blend

Notes:

  • The problems seems to someway be related to the attributes that are being used in shader nodes or that are being visualized via vertex colors.
  • The amount of performance drop depends on the type of the attribute and where its stored.
  • It does trigger after using EEVEE or visualizing the vertex colors in Solid view, but it does not happens after switching from Cycles
  • in the case of Sculpt vertex colors, the performance drop stops if you change to sculpt mode
**System Information** Operating system: Windows-10-10.0.19041-SP0 64 Bits Graphics card: AMD Radeon RX 5700 XT ATI Technologies Inc. 4.5.14802 Core Profile Context 21.11.2 30.0.14005.1000 **Blender Version** Broken: version: 3.0.0 Release Candidate, branch: master, commit date: 2021-11-25 17:24, hash: `2fb8c6805a` **Short description of error** I have a curve with an specific setup of geometry nodes, that for some reason, if I go from solid mode->eevee->solid mode again, it slow downs performance drasticaly for no reason. The problem also occurs on objects that contain Sculpt Vertex Colors. **Exact steps for others to reproduce the error** Open the file, switch to rendered view and then back to solid view. note that if you go back to eevee again the performace gets back to normal. In the video below you can see the fps dropping in the corner. It wasn't recorded with default settings, but I tried restoring them and it gave me the same result [2021-11-27 20-52-26.mp4](https://archive.blender.org/developer/F12498407/2021-11-27_20-52-26.mp4) [geometry nodes slowdown.blend](https://archive.blender.org/developer/F12498408/geometry_nodes_slowdown.blend) Notes: - The problems seems to someway be related to the attributes that are being used in shader nodes or that are being visualized via vertex colors. - The amount of performance drop depends on the type of the attribute and where its stored. - It does trigger after using EEVEE or visualizing the vertex colors in Solid view, but it does not happens after switching from Cycles - in the case of Sculpt vertex colors, the performance drop stops if you change to sculpt mode
Poster

Added subscriber: @Diogo_Valadares

Added subscriber: @Diogo_Valadares
Collaborator

#96003 was marked as duplicate of this issue

#96003 was marked as duplicate of this issue
Collaborator

#95766 was marked as duplicate of this issue

#95766 was marked as duplicate of this issue
deadpin commented 1 year ago
Collaborator

Added subscriber: @deadpin

Added subscriber: @deadpin
deadpin commented 1 year ago
Collaborator

Changed status from 'Needs Triage' to: 'Confirmed'

Changed status from 'Needs Triage' to: 'Confirmed'
deadpin commented 1 year ago
Collaborator

Confirmed here too. Toggling the GN modifier off/on will also return performance back to normal.

Confirmed here too. Toggling the GN modifier off/on will also return performance back to normal.
costa commented 1 year ago

Added subscriber: @costa

Added subscriber: @costa
costa commented 1 year ago

Confirmed here too

Confirmed here too

Added subscriber: @lowpolysaac

Added subscriber: @lowpolysaac

This comment was removed by @lowpolysaac

*This comment was removed by @lowpolysaac*
Collaborator

Added subscriber: @HooglyBoogly

Added subscriber: @HooglyBoogly
Collaborator

If I apply the modifier, I can still reproduce this issue, so I don't think it's related to geometry nodes.

What I did find is that the tangents are being recalculated on every redraw, with blender::draw::extract_tan_ex_init being the main performance culprit here. I'm guessing that switching between EEVEE and workbench somehow messes up the mesh data extraction system. But I don't know much about that area.

If I apply the modifier, I can still reproduce this issue, so I don't think it's related to geometry nodes. What I did find is that the tangents are being recalculated on every redraw, with `blender::draw::extract_tan_ex_init` being the main performance culprit here. I'm guessing that switching between EEVEE and workbench somehow messes up the mesh data extraction system. But I don't know much about that area.
HooglyBoogly changed title from Geometry nodes reduces viewport performance drasticaly after switching from eevee to solid view to Viewport performance drops drastically after switching from eevee to solid view 1 year ago
Poster

I just got the same problem problem with another file(blender 3.1 alpha):
slowdown2.blend

If I apply the modifier, I can still reproduce this issue, so I don't think it's related to geometry nodes.

How did you apply the modifier? Converting it to mesh fixes the problem for me, I can't directly apply the modifier because its a curve and it contains construtive stuff and using a mesh as input and converting it to curves in geometry nodes also doesn't cause me problems.

I just got the same problem problem with another file(blender 3.1 alpha): [slowdown2.blend](https://archive.blender.org/developer/F12782300/slowdown2.blend) > If I apply the modifier, I can still reproduce this issue, so I don't think it's related to geometry nodes. How did you apply the modifier? Converting it to mesh fixes the problem for me, I can't directly apply the modifier because its a curve and it contains construtive stuff and using a mesh as input and converting it to curves in geometry nodes also doesn't cause me problems.
EAW commented 1 year ago

Added subscriber: @EAW

Added subscriber: @EAW
EAW commented 1 year ago

Reminds me of #78161 (Workbench refactor causes significant performance regression with workbench shadows). I wonder if there is something in Workbench’s code making it susceptible to have updates get called way too often.

Reminds me of #78161 (Workbench refactor causes significant performance regression with workbench shadows). I wonder if there is something in Workbench’s code making it susceptible to have updates get called way too often.
Collaborator

In #93440#1280689, @Diogo_Valadares wrote:

If I apply the modifier, I can still reproduce this issue, so I don't think it's related to geometry nodes.

How did you apply the modifier? Converting it to mesh fixes the problem for me

Ah, right, yes, I meant that I converted the object to a mesh object. That also initially fixed the problem for me, but then I toggled render and workbench a few more times and the problem came back.

> In #93440#1280689, @Diogo_Valadares wrote: >> If I apply the modifier, I can still reproduce this issue, so I don't think it's related to geometry nodes. > > How did you apply the modifier? Converting it to mesh fixes the problem for me Ah, right, yes, I meant that I converted the object to a mesh object. That also initially fixed the problem for me, but then I toggled render and workbench a few more times and the problem came back.
Poster

I decided to test this a little bit more and I found some things that might be what is causing the problem.

In both geometry nodes I sent, I'm transfering some attributes to the output of the geometry nodes, and right after I use them on the shader nodes.
image.png

Once I remove the attribute groups from the output, the problem doesn't happen anymore. Also, if the groups aren't being used by the shader, the problem does not occur too.
image.png

After applying the modifier the problem still occurs because the attributes are still stored on the mesh. Btw I don't know why but it also create those "anonymous attributes" that are the outputs of the geometry nodes even tho those attributes already exist with another name(but I think this is an unrelated problem)
image.png

Once you remove the atributes the problem does not occur anymore.

And after a close look I think the type of the attribute and where its stored makes a huge difference on how much the performance is affected. You can take a look at the first example, the only attribute being used is a generated "uvmap" that is a vector stored on face corners, and even tho its much simpler and less poly dense than the second file, it takes the fps to 6. the second file contains 5 float attributes stored on vertices and still have decent fps.

I decided to test this a little bit more and I found some things that might be what is causing the problem. In both geometry nodes I sent, I'm transfering some attributes to the output of the geometry nodes, and right after I use them on the shader nodes. ![image.png](https://archive.blender.org/developer/F12787492/image.png) Once I remove the attribute groups from the output, the problem doesn't happen anymore. Also, if the groups aren't being used by the shader, the problem does not occur too. ![image.png](https://archive.blender.org/developer/F12787489/image.png) After applying the modifier the problem still occurs because the attributes are still stored on the mesh. Btw I don't know why but it also create those "anonymous attributes" that are the outputs of the geometry nodes even tho those attributes already exist with another name(but I think this is an unrelated problem) ![image.png](https://archive.blender.org/developer/F12787500/image.png) Once you remove the atributes the problem does not occur anymore. And after a close look I think the type of the attribute and where its stored makes a huge difference on how much the performance is affected. You can take a look at the first example, the only attribute being used is a generated "uvmap" that is a vector stored on face corners, and even tho its much simpler and less poly dense than the second file, it takes the fps to 6. the second file contains 5 float attributes stored on vertices and still have decent fps.
Poster

Just noticed today that this glitch also occurs when using the Experimental Sculpt Vertex Colors, since its stored in attributes.

If stored to reguler vertex colors, it does not affect performance, even tho its seems to also be kept in the attributes.
image.png

Just noticed today that this glitch also occurs when using the Experimental Sculpt Vertex Colors, since its stored in attributes. If stored to reguler vertex colors, it does not affect performance, even tho its seems to also be kept in the attributes. ![image.png](https://archive.blender.org/developer/F12802441/image.png)
Poster

It seems like it doesn't even need to be in eevee for the performance to be affected. If you switch to vertex visualization in the regular solid view and then switch back, it also reduces the performance.

2022-01-12 13-08-55.mp4

It seems like it doesn't even need to be in eevee for the performance to be affected. If you switch to vertex visualization in the regular solid view and then switch back, it also reduces the performance. [2022-01-12 13-08-55.mp4](https://archive.blender.org/developer/F12802463/2022-01-12_13-08-55.mp4)
Diogo_Valadares changed title from Viewport performance drops drastically after switching from eevee to solid view to Viewport performance drops drastically after switching from atributte visualization to solid view 1 year ago

Added subscriber: @lictex_1

Added subscriber: @lictex_1
Collaborator

Added subscribers: @Rawalanche, @PratikPB2123

Added subscribers: @Rawalanche, @PratikPB2123
Collaborator

Added subscriber: @Olliver

Added subscriber: @Olliver

With #96003 being fixed I tested to see if the problem here was also fixed, and it seems so.

I tested in both 3.1 and 3.2 alpha but I'd like some confirmation for that in case I tested something wrong.

With #96003 being fixed I tested to see if the problem here was also fixed, and it seems so. I tested in both 3.1 and 3.2 alpha but I'd like some confirmation for that in case I tested something wrong.

should be a911f075d7 fixed this

should be a911f075d7aa823b215d4e7baf91ea4f5bd6099c fixed this

Changed status from 'Confirmed' to: 'Resolved'

Changed status from 'Confirmed' to: 'Resolved'
Diogo_Valadares closed this issue 11 months ago
Diogo_Valadares self-assigned this 11 months ago

should be a911f075d7 fixed this

I guess this task can be closed then.

> should be a911f075d7aa823b215d4e7baf91ea4f5bd6099c fixed this I guess this task can be closed then.

Added subscriber: @GaryRitchie

Added subscriber: @GaryRitchie
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/Collada
Interest/Compositing
Interest/Core
Interest/Cycles
Interest/Dependency Graph
Interest/Development Management
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/Modeling
Interest/Modifiers
Interest/Motion Tracking
Interest/Nodes & Physics
Interest/Overrides
Interest/Performance
Interest/Performance
Interest/Physics
Interest/Pipeline, Assets & I/O
Interest/Platforms, Builds, Tests & Devices
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
legacy module/Animation & Rigging
legacy module/Core
legacy module/Development Management
legacy module/Eevee & Viewport
legacy module/Grease Pencil
legacy module/Modeling
legacy module/Nodes & Physics
legacy module/Pipeline, Assets & IO
legacy module/Platforms, Builds, Tests & Devices
legacy module/Python API
legacy module/Rendering & Cycles
legacy module/Sculpt, Paint & Texture
legacy module/Triaging
legacy module/User Interface
legacy module/VFX & Video
legacy project/1.0.0-beta.2
legacy project/Asset Browser (Archived)
legacy project/BF Blender: 2.8
legacy project/BF Blender: After Release
legacy project/BF Blender: Next
legacy project/BF Blender: Regressions
legacy project/BF Blender: Unconfirmed
legacy project/Blender 2.70
legacy project/Code Quest
legacy project/Datablocks and Libraries
legacy project/Eevee
legacy project/Game Animation
legacy project/Game Audio
legacy project/Game Data Conversion
legacy project/Game Engine
legacy project/Game Logic
legacy project/Game Physics
legacy project/Game Python
legacy project/Game Rendering
legacy project/Game UI
legacy project/GPU / Viewport
legacy project/GSoC
legacy project/Infrastructure: Websites
legacy project/LibOverrides - Usability and UX
legacy project/Milestone 1: Basic, Local Asset Browser
legacy project/Nodes
legacy project/OpenGL Error
legacy project/Papercut
legacy project/Pose Library Basics
legacy project/Retrospective
legacy project/Tracker Curfew
legacy project/Wintab High Frequency
Meta/Good First Issue
Meta/Papercut
migration/requires-manual-verification
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 & Devices
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 Information 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
10 Participants
Notifications
Due Date

No due date set.

Dependencies

No dependencies set.

Reference: blender/blender#93440
Loading…
There is no content yet.