Mesh Cache Is Evaluated When Display Type Is Bounds or Outline Display Flag Is Off #77115

New Issue

Atomic · 2020-05-27T21:46:25+02:00

Atomic commented

2020-05-27 21:46:25 +02:00

System Information
Operating system: Windows 7 SP1
Graphics card: nVidia GTX 660

Blender Version
Broken: version: 2.90 (sub 0), branch: master, commit date: 2020-05-08 16:22, hash: 6f985574b7
Worked: (newest version of Blender that worked as expected)

Short description of error
Mesh Cache Is Evaluated When Display Type Is Bounds

Exact steps for others to reproduce the error
I noticed this when I imported an animated 266GB Alembic. I wanted to work on a camera move, so I set the imported object to bounds. I noticed no improvement in performance. Blender was still pulling all the Alembic data when the frame changed. I turned off the object in the outliner and I experienced the same problem. I tracked this down to the MeshCache modifier. Even when the object is turned off and set to show bounds, the modifiers are still evaluated. This problem may affect other modifiers as well.

A simple fix would be to not evaluate the MeshCache modifier if the object is not displayed or set to bounds.

**System Information** Operating system: Windows 7 SP1 Graphics card: nVidia GTX 660 **Blender Version** Broken: version: 2.90 (sub 0), branch: master, commit date: 2020-05-08 16:22, hash: 6f985574b775 Worked: (newest version of Blender that worked as expected) **Short description of error** Mesh Cache Is Evaluated When Display Type Is Bounds **Exact steps for others to reproduce the error** I noticed this when I imported an animated 266GB Alembic. I wanted to work on a camera move, so I set the imported object to bounds. I noticed no improvement in performance. Blender was still pulling all the Alembic data when the frame changed. I turned off the object in the outliner and I experienced the same problem. I tracked this down to the MeshCache modifier. Even when the object is turned off and set to show bounds, the modifiers are still evaluated. This problem may affect other modifiers as well. A simple fix would be to not evaluate the MeshCache modifier if the object is not displayed or set to bounds.

Atomic commented

2020-05-27 21:46:25 +02:00

Added subscriber: @AtomP

Germano Cavalcante commented

2020-05-28 16:22:45 +02:00

Added subscriber: @mano-wii

Germano Cavalcante commented

2020-05-28 16:22:45 +02:00

Can you provide a simple file showing the problem?

Philipp Oeser commented

2020-05-29 14:29:15 +02:00

Added subscriber: @lichtwerk

Philipp Oeser commented

2020-05-29 14:29:15 +02:00

Changed status from 'Needs Triage' to: 'Needs User Info'

Philipp Oeser commented

2020-05-29 14:29:15 +02:00

In addition to providing an example .blend file:

Even when the object is turned off and set to show bounds, the modifiers are still evaluated

I would expect the modifier to run if you set the object to show bounds (it has to get the correct bounds from the data after all, no?)
How to you "turn the object off"? Is the modifier enabled for the viewport? Is the object enabled for the viewport?

In addition to providing an example .blend file: > Even when the object is turned off and set to show bounds, the modifiers are still evaluated - I would expect the modifier to run if you set the object to show bounds (it has to get the correct bounds from the data after all, no?) - How to you "turn the object off"? Is the modifier enabled for the viewport? Is the object enabled for the viewport?

Atomic commented

2020-05-30 16:22:00 +02:00

I guess I can see your point about fetching the bounds from a deforming source. Perhaps there is a more efficient way to do that with with an Alembic file, which might already provide that data internally, instead of calculating it every frame?

However, when the object is turned off, by using the icon in the Outliner, there is no reason to evaluate any modifiers on that object.

I am attaching a simple example, that uses a highly subdivided Suzanne followed by an animated displace. When I scrub forward one frame, Blender takes time to revise the mesh. I turn off the mesh in the viewport, and try the same thing again. When I scrub forward one frame, I experience the same laggy mesh update that is then discarded and not displayed in the viewport.

Is there really a need to update mesh objects that are not displayed? After all, the user did turn off the display for a reason. My reason was to regain lost performance in the app, to work on a camera move. I do understand that there could be dependencies or drivers that may not update, but as the end user, I'm willing to accept that caveat. After all, everything will update as it should, once I re-enable the display flag.

29_modifier_timeline_update_issue.blend

I guess I can see your point about fetching the bounds from a deforming source. Perhaps there is a more efficient way to do that with with an Alembic file, which might already provide that data internally, instead of calculating it every frame? However, when the object is turned off, by using the icon in the Outliner, there is no reason to evaluate any modifiers on that object. I am attaching a simple example, that uses a highly subdivided Suzanne followed by an animated displace. When I scrub forward one frame, Blender takes time to revise the mesh. I turn off the mesh in the viewport, and try the same thing again. When I scrub forward one frame, I experience the same laggy mesh update that is then discarded and not displayed in the viewport. Is there really a need to update mesh objects that are not displayed? After all, the user did turn off the display for a reason. My reason was to regain lost performance in the app, to work on a camera move. I do understand that there could be dependencies or drivers that may not update, but as the end user, I'm willing to accept that caveat. After all, everything will update as it should, once I re-enable the display flag. [29_modifier_timeline_update_issue.blend](https://archive.blender.org/developer/F8565641/29_modifier_timeline_update_issue.blend)

Germano Cavalcante commented

2020-06-01 14:27:56 +02:00

Changed status from 'Needs User Info' to: 'Needs Triage'

Richard Antalik commented

2020-06-01 22:33:29 +02:00

Added subscriber: @iss

Richard Antalik commented

2020-06-01 22:33:29 +02:00

In #77115#941401, @AtomP wrote:
I am attaching a simple example, that uses a highly subdivided Suzanne followed by an animated displace. When I scrub forward one frame, Blender takes time to revise the mesh. I turn off the mesh in the viewport, and try the same thing again. When I scrub forward one frame, I experience the same laggy mesh update that is then discarded and not displayed in the viewport.

I can not reproduce this.
What are the steps?

> In #77115#941401, @AtomP wrote: > I am attaching a simple example, that uses a highly subdivided Suzanne followed by an animated displace. When I scrub forward one frame, Blender takes time to revise the mesh. I turn off the mesh in the viewport, and try the same thing again. When I scrub forward one frame, I experience the same laggy mesh update that is then discarded and not displayed in the viewport. I can not reproduce this. What are the steps?

Richard Antalik commented

2020-06-01 22:33:39 +02:00

Changed status from 'Needs Triage' to: 'Needs User Info'

Atomic commented

2020-06-02 14:50:52 +02:00

Here is a snarky video that demonstrates how to reproduce the error.
reproduce_error.mp4

NOTE: If you have an amazing super computer (which most of us don't), try cranking up the subdivision count until you experience some viewport delay, then attempt what is demonstrated in the video, simply moving to the next frame with the Outliner visibility icon turned off for the Suzanne object.

I would expect, moving forward, that the datasets a user is going to pass through Blender are only going to get larger and larger. This Suzanne scene is simply a portable example file, As I mentioned in the first post, I was cranking a 266Gb Alembic through Blender when I discovered this performance bug.

Here is a snarky video that demonstrates how to reproduce the error. [reproduce_error.mp4](https://archive.blender.org/developer/F8572050/reproduce_error.mp4) NOTE: If you have an amazing super computer (which most of us don't), try cranking up the subdivision count until you experience some viewport delay, then attempt what is demonstrated in the video, simply moving to the next frame with the Outliner visibility icon turned off for the Suzanne object. I would expect, moving forward, that the datasets a user is going to pass through Blender are only going to get larger and larger. This Suzanne scene is simply a portable example file, As I mentioned in the first post, I was cranking a 266Gb Alembic through Blender when I discovered this performance bug.

Campbell Barton commented

2020-06-16 05:26:42 +02:00

Changed status from 'Needs User Info' to: 'Confirmed'

Sybren A. Stüvel commented

2020-08-14 15:34:27 +02:00

Added subscriber: @dr.sybren

Sybren A. Stüvel commented

2020-08-14 15:34:27 +02:00

@AtomP Please keep the snarkyness out of these reports and keep the language clean. This is not the way to motivate people help you solve your problem.

Sybren A. Stüvel commented

2020-08-14 15:48:17 +02:00

As I see it, there are two different things reported here:

When the object is hidden using the "Hide in Viewport" setting, its modifiers are still evaluated. This is working as designed, as per the 2.80 release notes. Granted, this isn't clear from the Blender manual, so I'll write a bit there to make it more explicit. You can use the "Disable in Viewport" setting in the outliner to fully disable the object and prevent modifiers from being evaluated.
When the object is set to only display as bounding box, the mesh data is still all loaded from Alembic. I think it would be an interesting feature to only load the bounding box from the Alembic file when the object is set to show as bounding box only. However, this would be a new feature in blender, rather than a bug fix.

As I see it, there are two different things reported here: - When the object is hidden using the "Hide in Viewport" setting, its modifiers are still evaluated. This is working as designed, as per [the 2.80 release notes](https://wiki.blender.org/wiki/Reference/Release_Notes/2.80/Layers#Visibility). Granted, this isn't clear from the Blender manual, so I'll write a bit there to make it more explicit. You can use the "Disable in Viewport" setting in the outliner to fully disable the object and prevent modifiers from being evaluated. - When the object is set to only display as bounding box, the mesh data is still all loaded from Alembic. I think it would be an interesting feature to only load the bounding box from the Alembic file when the object is set to show as bounding box only. However, this would be a new feature in blender, rather than a bug fix.

Sybren A. Stüvel commented

2020-08-14 16:08:11 +02:00

I've updated the manual for the 1st point in my previous comment. This leaves the "don't load Alembic mesh when drawing as bounding box" feature, which is interesting but will have to be designed & planned separately.

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Mesh Cache Is Evaluated When Display Type Is Bounds or Outline Display Flag Is Off #77115