Blender material/texture nodes - UI not updating

Ok, this issue has been bugging me for some time and I’d like to know if it’s something specific to my setup or a widely known issue.

I’m getting some wacky behaviour with the UI not updating properly for material and texture previews - particularly when nodes are brought into the equation. Also, the rendered output can be at odds with the scene setup.

Blender 2.4* and earlier occasionally had similar UI glitches, but not like this:

I’ve haven’t seen many comments about this on the forums. Apologies if it’s already been discussed somewhere.

I think everybody who has used nodes has encountered this behaviour at some point, and I’m fairly sure it is a known issue for the developers. It’s more of a nuisance than a hard problem, but you could file a bug report about it. (Before you do that, try and see if there is already a similar bug report by searching the tracker for “node preview update” or something like that)

Moved from “General Forums > Blender and CG Discussions” to “Support > Technical Support”

Thanks for the reply Zalamander.

While this isn’t a show-stopper I’d have thought it’d be regarded as a fairly major issue. Seems like it’s not on a lot of users radar…

If it’s not specific to my setup then I’m sure the devs are aware of it, but are probably snowed under by user requests for cool new features to be added :rolleyes:

To use an analogy; It’s like a mail client randomly linking up subject lines and dates with the wrong emails. IMO, this isn’t that different. Although to be fair, with a few exceptions, these glitches only occur when the material/tex nodes are being used - so I tend to avoid them.

Experienced users will know to expect this, but it’s got to be disconcerting to newbies learning the program.

The compositing nodes don’t have this UI update problem though.

I don’t know anything about Blender’s internals, but it looks like the notifiers and listeners aren’t doing their thing properly.

Fweeb; sorry, wasn’t sure where to post this. But I chose the other forum as it gets 40x the traffic :eyebrowlift2:

These bugs seem related:
http://projects.blender.org/tracker/index.php?func=detail&aid=21749
http://projects.blender.org/tracker/?group_id=9&atid=498&func=detail&aid=21925
http://projects.blender.org/tracker/?group_id=9&atid=498&func=detail&aid=20152
http://projects.blender.org/tracker/?group_id=9&atid=498&func=detail&aid=21289
http://projects.blender.org/tracker/?group_id=9&atid=498&func=detail&aid=19498
http://projects.blender.org/tracker/?group_id=9&atid=498&func=detail&aid=21166
http://projects.blender.org/tracker/?group_id=9&atid=498&func=detail&aid=19433
http://projects.blender.org/tracker/?group_id=9&atid=498&func=detail&aid=20549

For anyone that’s interested, some quotes from the devs:
Matt Ebb
I think this might be related to another issue in the tracker, where material icons in the material listview (top of material properties) aren’t updating properly. When I was tracking that down before it looked like it could have been an issue with the job system, it was refusing to start an icon render job while the shader preview job was active. Maybe we need a way to queue them one after the other.

I’ve looked into this, and I think it’s an issue with the threaded jobs? It seems that the jobs system blocks any other jobs of the same type (same owner), when one is running. The icon preview render and the shader preview render are using the same job type, so when the refresh is triggered, the icon preview gets blocked, and never happens.
Ton Roosendaal
Icon previews for materials are rendered (using rendering engine), only one render engine can run at a time. The preview render (or F12 render) will kill other jobs then. We have a basic design conflict here… there’s also not a “job queue” for cases like this.

On each material change a new preview is being rendered. However, on assigning a (new or any) material this didn’t happen, which caused this problem. I fixed that in svn.
For each icon a complete render job is being started, which has some overhead, so I prefer to be a bit conservative starting such renders for each draw.
From my limited understanding, it looks like the redraw bugs are being worked around on a per-bug-basis, instead of doing a significant redesign of the code that monitors user input and keeps the UI updated.

Keeping the UI responsive is obviously an important consideration - it’d be no good if Blender thrashed the CPU to keep things up to date.