Fly/Walk in viewport, Workbench/Eevee do not stop rendering at sample limit #80871

New Issue

AnsonX10 · 2020-09-17T10:09:43+02:00

AnsonX10 commented

2020-09-17 10:09:43 +02:00

System Information
Operating system: Windows-10-10.0.19041-SP0 64 Bits
Graphics card: GeForce GTX 760/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 451.67

Blender Version
Broken since at least 2.80 and still broken in 2.91.0 Alpha, branch: master, commit date: 2020-09-18 16:11, hash: 7b988188dc

Short description of error
When using Walk or Fly navigation modes using any built-in renderer except Cycles, the viewport will render the specified number of samples, then start again from sample 1 and repeat indefinitely, even if the navigation is motionless. This can be seen visibly. If set to 1 sample, it still re-renders it indefinitely. This can be confirmed via GPU usage.

Exact steps for others to reproduce the error
Enter walk or fly mode in any scene, using any viewport mode, and any renderer except Cycles. If you have a hard time seeing it, you can use Eevee and any volume shader to more easily see each sample as it's rendered.

Misc notes
I'm aware Workbench's render settings are anti-aliasing samples instead of sample count, but it still re-renders those anti-aliasing samples.

It's not a pressing problem, but it does waste GPU resources and can introduce visible flickering. It should either stop rendering when it reaches the set number of samples (like orbit), or stop rendering after 1 sample regardless of sample limit. The latter would actually be more useful in my use case, even for regular orbiting. My proposal: It could pause for about 500-1000ms (configurable?) before rendering sample 2 and onward. This would improve viewport responsiveness, but still retain the benefits of rendering the full quality version during navigation.

**System Information** Operating system: Windows-10-10.0.19041-SP0 64 Bits Graphics card: GeForce GTX 760/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 451.67 **Blender Version** Broken since at least 2.80 and still broken in 2.91.0 Alpha, branch: master, commit date: 2020-09-18 16:11, hash: `7b988188dc` **Short description of error** When using Walk or Fly navigation modes using any built-in renderer except Cycles, the viewport will render the specified number of samples, then start again from sample 1 and repeat indefinitely, *even if the navigation is motionless.* This can be seen visibly. If set to 1 sample, it still re-renders it indefinitely. This can be confirmed via GPU usage. **Exact steps for others to reproduce the error** Enter walk or fly mode in any scene, using any viewport mode, and any renderer except Cycles. If you have a hard time seeing it, you can use Eevee and any volume shader to more easily see each sample as it's rendered. **Misc notes** I'm aware Workbench's render settings are anti-aliasing samples instead of sample count, but it still re-renders those anti-aliasing samples. It's not a pressing problem, but it does waste GPU resources and can introduce visible flickering. It should either stop rendering when it reaches the set number of samples (like orbit), or stop rendering after 1 sample regardless of sample limit. The latter would actually be more useful in my use case, even for regular orbiting. My proposal: It could pause for about 500-1000ms (configurable?) before rendering sample 2 and onward. This would improve viewport responsiveness, but still retain the benefits of rendering the full quality version during navigation.

AnsonX10 commented

2020-09-17 10:09:43 +02:00

Added subscriber: @AnsonX10

blender-admin commented

2020-09-17 10:09:43 +02:00

#88506 was marked as duplicate of this issue

Bent Hillerkus commented

2020-09-17 10:23:11 +02:00

Added subscriber: @bent

Germano Cavalcante commented

2020-09-18 17:29:44 +02:00

Added subscriber: @mano-wii

Germano Cavalcante commented

2020-09-18 17:29:44 +02:00

I can't reproduce, or I don't know if I understand the problem correctly.
What are the steps to reproduce the bug?

A guideline for making a good bug report can be found at https://wiki.blender.org/wiki/Process/Bug_Reports

I can't reproduce, or I don't know if I understand the problem correctly. What are the steps to reproduce the bug? A guideline for making a good bug report can be found at https://wiki.blender.org/wiki/Process/Bug_Reports

Bent Hillerkus commented

2020-09-18 17:50:40 +02:00

I can reproduce the issue:

The viewport is constantly being redrawn in Walk mode, even if the camera position hasn't changed.

System Information
Operating system: Linux-5.8.9-2-MANJARO-x86_64-with-glibc2.17 64 Bits
Graphics card: Mesa DRI Intel(R) UHD Graphics 620 (KBL GT2) Intel Open Source Technology Center 4.6 (Core Profile) Mesa 20.1.5

Blender Version
Broken: version: 2.90.0, branch: master, commit date: 2020-08-31 11:26, hash: 0330d1af29

I can reproduce the issue: ![Screen Capture_Blender_20200918174328.gif](https://archive.blender.org/developer/F8896082/Screen_Capture_Blender_20200918174328.gif) The viewport is constantly being redrawn in Walk mode, even if the camera position hasn't changed. **System Information** Operating system: Linux-5.8.9-2-MANJARO-x86_64-with-glibc2.17 64 Bits Graphics card: Mesa DRI Intel(R) UHD Graphics 620 (KBL GT2) Intel Open Source Technology Center 4.6 (Core Profile) Mesa 20.1.5 **Blender Version** Broken: version: 2.90.0, branch: master, commit date: 2020-08-31 11:26, hash: `0330d1af29`

Germano Cavalcante commented

2020-09-18 18:13:19 +02:00

So the description in the report should be:

**Short description of error**
When using Walk or Fly navigation modes (using lookdev, rendered view or Eevee), the viewport will be constantly updated even if the navigation is motionless.

**Exact steps for others to reproduce the error**
- Use any debug tool (for example RenderDoc)
- In the default scene, activate Walk Navigation

Observe the constant updating of frames

This report is missing:

Short description of the error
Exact steps to redo the error.

@AnsonX10, can I edit the description of this report to correspond to the bug shown by @bent?

So the description in the report should be: ``` **Short description of error** When using Walk or Fly navigation modes (using lookdev, rendered view or Eevee), the viewport will be constantly updated even if the navigation is motionless. **Exact steps for others to reproduce the error** - Use any debug tool (for example RenderDoc) - In the default scene, activate Walk Navigation Observe the constant updating of frames ``` This report is missing: - Short description of the error - Exact steps to redo the error. @AnsonX10, can I edit the description of this report to correspond to the bug shown by @bent?

AnsonX10 changed title from ~~Fly/Walk in viewport, Solid/Eevee do not stop rendering at sample limit~~ to Fly/Walk in viewport, Workbench/Eevee do not stop rendering at sample limit

2020-09-19 08:05:29 +02:00

AnsonX10 commented

2020-09-19 08:12:38 +02:00

I assumed the method of reproduction was self-evident. My bad. I've updated the description for you. A debug tool is definitely not needed: This problem is visible to the naked eye, although it is more apparent on finely detailed textures, volumes, and other things that are affected strongly by sample count.

Germano Cavalcante commented

2020-09-21 15:25:38 +02:00

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

Jeroen Bakker commented

2020-09-25 11:54:18 +02:00

Added subscriber: @Jeroen-Bakker

Jeroen Bakker commented

2020-09-25 11:54:18 +02:00

This is caused by the tagging of the viewport by the walk/fly operator on each timer tick. The current operator tags to redraw on each timer tick. So it works as the operator was designed.

static void flyEvent(FlyInfo *fly, const wmEvent *event)
{
  if (event->type == TIMER && event->customdata == fly->timer) {
    fly->redraw = 1;
  }
  ...

Cycles has its own copy of the scene and therefore can decide in more detail if there are actual changes. In order to do the same for EEVEE/Workbench we could a similar trick, but it will double the memory and transformation what will lead to less performance. Not sure that is what we want. Also this is development as everything works as designed.

The proposed solution is new development as it does not fit within the current implementation. We could probably fix the most common cases by being more picky on when to redraw. Eg timer event + change of view.

The timer event is needed to "simulate" the separation of a render and event loop (like games do). When doing timer event + check on view, the shadows will still flicker a lot. When only doing a check on the view, the fly/walk will be less smooth as the drawing performance will influence the interactivity.

This is caused by the tagging of the viewport by the walk/fly operator on each timer tick. The current operator tags to redraw on each timer tick. So it works as the operator was designed. ``` static void flyEvent(FlyInfo *fly, const wmEvent *event) { if (event->type == TIMER && event->customdata == fly->timer) { fly->redraw = 1; } ... ``` Cycles has its own copy of the scene and therefore can decide in more detail if there are actual changes. In order to do the same for EEVEE/Workbench we could a similar trick, but it will double the memory and transformation what will lead to less performance. Not sure that is what we want. Also this is development as everything works as designed. The proposed solution is new development as it does not fit within the current implementation. We could probably fix the most common cases by being more picky on when to redraw. Eg timer event + change of view. The timer event is needed to "simulate" the separation of a render and event loop (like games do). When doing timer event + check on view, the shadows will still flicker a lot. When only doing a check on the view, the fly/walk will be less smooth as the drawing performance will influence the interactivity.

AnsonX10 commented

2020-09-26 00:59:03 +02:00

@Jeroen-Bakker But it works perfectly when orbiting using middle mouse. The separation of render and event loops are clearly not needed in that case. Is this true? Or am I missing something.

And in case anyone wants my opinion, personally I would gladly give up some extra memory to fix the continuous GPU usage and any amount of flickering.

@Jeroen-Bakker But it works perfectly when orbiting using middle mouse. The separation of render and event loops are clearly not needed in that case. Is this true? Or am I missing something. And in case anyone wants my opinion, personally I would gladly give up some extra memory to fix the continuous GPU usage and *any* amount of flickering.

Germano Cavalcante commented

2021-05-24 18:15:12 +02:00

Added subscribers: @NoBlahBlah, @Calra, @Firepal

Jacob Merrill commented

2021-05-24 22:47:50 +02:00

Added subscriber: @JacobMerrill-1

Jacob Merrill commented

2021-05-24 22:47:50 +02:00

youle recently created a upbge patch to render all the samples in 1 frame if you want
allowing full quality shadows during preview - removing the pulsing completely

https://github.com/UPBGE/upbge/pull/1474

https://www.youtube.com/watch?v=hxhDbJ7NHQI

youle recently created a upbge patch to render all the samples in 1 frame if you want allowing full quality shadows during preview - removing the pulsing completely https://github.com/UPBGE/upbge/pull/1474 https://www.youtube.com/watch?v=hxhDbJ7NHQI

Philipp Oeser removed the

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Fly/Walk in viewport, Workbench/Eevee do not stop rendering at sample limit #80871