Cycles: Zooming in rendered mode during update out of sync with intended zoom #34205

New Issue

Danny McGrath · 2013-02-11T16:19:40+01:00

Danny McGrath commented

2013-02-11 16:19:40 +01:00

%%%--- Operating System, Graphics card ---
Ubuntu 64bit, Nvidia GTX 550 Ti

- Blender version with error, and version that worked ---

r54463 (only tested as far back as 2.63 release, which is also affected)

- Short description of error ---

If you zoom with wheel mouse during render on GPU on a small area (maximized cycles will not do this as it doesn't render fast enough, nor will cpu for the same reason I assume), while looking through the camera (so you can tell the extents and proportion of the object to the camera bounds), sometimes you can land on a zoom where the object appears to have not fully zoomed to match the camera bounds. Moving the 3d cursor (or anything that updates cycles, for that matter), causes the view to update. very minor, but reporting as asked. See "before 3d cursor.png" and "after 3d cursor.png" attached to report for an idea.

- Steps for others to reproduce the error (preferably based on attached .blend file) ---

Set up a small cycles rendered editor, about the size of the default object inspector area (See "zoom bug.png")
Keep the preview sampling to something your GPU can render almost instantly (I used the default 10)
Zoom the rendered view in and out, and most of the time you can land it (as seen in "zoom bug.png") on an amount that causes cycles to miss a final update
If you get this, place the 3d cursor (or tab in/out of edit mode etc) to trigger the missing final event that "fixes" it

Assign to Brecht please :)
%%%

%%%--- Operating System, Graphics card --- Ubuntu 64bit, Nvidia GTX 550 Ti - Blender version with error, and version that worked --- r54463 (only tested as far back as 2.63 release, which is also affected) - Short description of error --- If you zoom with wheel mouse during render on GPU on a small area (maximized cycles will not do this as it doesn't render fast enough, nor will cpu for the same reason I assume), while looking through the camera (so you can tell the extents and proportion of the object to the camera bounds), sometimes you can land on a zoom where the object appears to have not fully zoomed to match the camera bounds. Moving the 3d cursor (or anything that updates cycles, for that matter), causes the view to update. very minor, but reporting as asked. See "before 3d cursor.png" and "after 3d cursor.png" attached to report for an idea. - Steps for others to reproduce the error (preferably based on attached .blend file) --- - Set up a small cycles rendered editor, about the size of the default object inspector area (See "zoom bug.png") - Keep the preview sampling to something your GPU can render almost instantly (I used the default 10) - Zoom the rendered view in and out, and most of the time you can land it (as seen in "zoom bug.png") on an amount that causes cycles to miss a final update - If you get this, place the 3d cursor (or tab in/out of edit mode etc) to trigger the missing final event that "fixes" it Assign to Brecht please :) %%%

Danny McGrath commented

2013-02-11 16:19:40 +01:00

Changed status to: 'Open'

Sergey Sharybin commented

2013-02-12 14:07:35 +01:00

%%%Brecht, stealing this one form you ;)

Shall be fixed in svn rev54491. Thanks for the report, closing.%%%

%%%Brecht, stealing this one form you ;) Shall be fixed in svn rev54491. Thanks for the report, closing.%%%

Danny McGrath commented

2013-02-12 21:22:44 +01:00

%%%hmm, seems that it only made it slightly more difficult to trigger.

See quick vid: http://download.blender.org/ftp/incoming/bugreports/cycles%20zoom%20bug.ogv

I noticed that when I retested, it still happened, but oddly enough not while I was loading my CPU a bit with the recording software. Since I already knew that a slow CPU isn't fast enough to trigger, on a hunch I tried lowering the GPU sample value, sure enough, it still triggers.

In all honestly, it's such a minor issue, but I figure that maybe you were preferring to solve properly instead of just reducing the timing needed to trigger? Anyways, keep open/fix/close as you see fit from here. Thanks! o/%%%

%%%hmm, seems that it only made it slightly more difficult to trigger. See quick vid: http://download.blender.org/ftp/incoming/bugreports/cycles%20zoom%20bug.ogv I noticed that when I retested, it still happened, but oddly enough not while I was loading my CPU a bit with the recording software. Since I already knew that a slow CPU isn't fast enough to trigger, on a hunch I tried lowering the GPU sample value, sure enough, it still triggers. In all honestly, it's such a minor issue, but I figure that maybe you were preferring to solve properly instead of just reducing the timing needed to trigger? Anyways, keep open/fix/close as you see fit from here. Thanks! o/%%%

Sergey Sharybin commented

2013-02-13 08:40:01 +01:00

%%%Ah, GPU thing. See how it could fail here. Will commit change soon :)%%%

Sergey Sharybin commented

2013-02-13 08:51:28 +01:00

%%%I've commited correction for GPU render at r54520. Think now issue shall be solved for real :)

If not -- poke me and i'll re-open report just one more time :)%%%

%%%I've commited correction for GPU render at r54520. Think now issue shall be solved for real :) If not -- poke me and i'll re-open report just one more time :)%%%

David M commented

2013-02-13 16:29:13 +01:00

%%%Some more info:

I can still reproduce this, even after r54520. I'm on win64 r54528, it happens on CPU and GPU.
All recent windows buildbot builds also show the problem (none are up to r54520 yet though).

thanks, David.
%%%

%%%Some more info: I can still reproduce this, even after r54520. I'm on win64 r54528, it happens on CPU and GPU. All recent windows buildbot builds also show the problem (none are up to r54520 yet though). thanks, David. %%%

Danny McGrath commented

2013-02-13 17:06:39 +01:00

%%%I can confirm that this still happens with blender-2.65-r54528-linux-glibc211-x86_64 from the buildbot%%%

David M commented

2013-02-13 17:10:45 +01:00

%%%FYI, r54528 from buildbot has the same problem.%%%

Sergey Sharybin commented

2013-02-13 17:36:09 +01:00

%%%Hrm.. Currently only could think of boost's conditional_variable::wait is not actually atomic :S Well, busy wait would solve issues here. Old friend better than two new fancy ones :)

Reopening, will patch the things either later tonight or tomorrow.%%%

%%%Hrm.. Currently only could think of boost's conditional_variable::wait is not actually atomic :S Well, busy wait would solve issues here. Old friend better than two new fancy ones :) Reopening, will patch the things either later tonight or tomorrow.%%%

Sergey Sharybin commented

2013-02-14 11:04:48 +01:00

%%%On the second review of the video that seems it's now not just an issue of cycles itself (changing 3d cursor location doesn't trigger cycles to redraw) but could be something with synchronization between events..

looking into code now trying to figure something out. Couldn't reproduce issue on own computer -- all this depends on timings which are different on different computers! :)%%%

%%%On the second review of the video that seems it's now not just an issue of cycles itself (changing 3d cursor location doesn't trigger cycles to redraw) but could be something with synchronization between events.. looking into code now trying to figure something out. Couldn't reproduce issue on own computer -- all this depends on timings which are different on different computers! :)%%%

Sergey Sharybin commented

2013-02-14 12:24:19 +01:00

%%%Ok, now i see the issue. Apparently, there's some timeout within which reset is not allowed. Perhaps this is so no reset happens too often for performance issues. And the thing is -- if camera changes too often, some reset could be missed because of this timeout.

There's a patch which seems to be solving this http://www.pasteall.org/39695/diff but would want Brecht to check on this issue too, maybe there's some clearer way to do this.

%%%

%%%Ok, now i see the issue. Apparently, there's some timeout within which reset is not allowed. Perhaps this is so no reset happens too often for performance issues. And the thing is -- if camera changes too often, some reset could be missed because of this timeout. There's a patch which seems to be solving this http://www.pasteall.org/39695/diff but would want Brecht to check on this issue too, maybe there's some clearer way to do this. %%%

Danny McGrath commented

2013-02-14 19:30:48 +01:00

%%%cool, this patch does seem to get rid of it here too.%%%

Sergey Sharybin commented

2013-02-15 10:16:19 +01:00

%%%After Brecht's feedback commited patch to svn rev54574. So let's try considering issue solved again :)%%%

Sergey Sharybin commented

2013-02-15 10:16:19 +01:00

Changed status from 'Open' to: 'Resolved'

Sergey Sharybin closed this issue

2013-02-15 10:16:19 +01:00

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

Cycles: Zooming in rendered mode during update out of sync with intended zoom #34205