The attached .blend file contains a simple cube with a material based on a magic texture and an image texture.
the image texture is also assigned to the cube as UV texture. This example uses GLSL mode.
The attached .blend file also contains a step by step description how to reproduce the (inconsistent?) behaviour.
The system actually behaves as i expect it to behave as long as i do NOT store it as .blend file.
When i store it as .blend file and reopen the stored .blend file, then the behaviour of the bake tool changes.
I also recorded a video to demonstrate what I see in my computer as i am unsrure if maybe i just see
some error due to a wrong build:
http://www.youtube.com/watch?v=yNxjz67Q4sE&feature=youtu.be
If anything is unclear, please ask me back. I tried hard to explain the issue in the nlender irc this afternoon.
And it looks like i am confusing myself with that issue. Please if its not a bug, can you give me a short
explanation what is going wrong here ?
thanks!
-Gaia-
Description
Event Timeline
The issue is that using a texture for rendering and baking causes a feedback loop (baking to same image thats being rendered).
This wasn't being detected, it still fails but it reports there is a feedback loop now.
fixed r50541.
closing.
There is still something wrong:
- open the attached file "cube_feedback_loop.blend"
the cube displays black (expected)
- Hover the mouse over the Bake button.
- Click the Bake button but do NOT(!) move the mouse.
The texture renders black, no error reported.
- Wait for some time (seconds, minutes, whatever ...) without moving the mouse.
- Move the mouse a tiny bit.
An Error message appears in the info bar: "Feedback loop detected"
I expect to see the error message right after i clicked on the Bake-Button,
and independent from mouse moves.
My environment is:
- Windows 7 64 bit (32 bit blender release build with cmake and visual c++ express)
- blender 50577
- nvidia gtx480
This sounds like a UI glitch - rather than an issue with baking, keeping open since its still a bug.
I will revert this, and assign to self for investigation. The 'add mousemove' in a thread job is not the solution, it is causing modal tools to go bezerk.
(for example grab gets 20+ mousemoves per second now when a preview render job runs).
@Ton, I cant redo 20+ mouse moves per second problem, Running with --debug-jobs, shows one job per preview and its not more then one a second, also good to give revisions - revert was r56883.
Note that this is calling from the main thread (no running in thread job), so no threading issues here.
Ill check on issue reported in commit log of r56883.
Ok, can redo the feedback loop bug now,
Checking on this simple example and I get an unrelated crash in r58177 (press bake in cube_feedback_loop.blend 3x times -> crash)
fixed crash mentioned above.
Checking on the UI glitch further. This seems to be more a UI/notifier/listener bug the related to baking.
Attached a patch 'notify_report.diff', This should work but doesn't, the listener isn't handling the notifier until after a mouse-move.
The remaining issue is a small UI glitch, https://developer.blender.org/T32537#5 -
Issue remains but this is minor enough I think its not useful to keep the issue open.