Material shading doesn't reflect animated texture nodes #49418

New Issue

gandalf3 · 2016-09-21T09:30:13+02:00

gandalf3 commented

2016-09-21 09:30:13 +02:00

System Information
Archlinux

Blender Version
Broken: latest master (586c589)

Short description of error
Material shading doesn't refresh every frame to reflect keyframes on material nodes, even when rendered with OpenGL render

Exact steps for others to reproduce the error

Open animated_material_nodes_not_updated_material_shading.blend
Play animation in material shading (nothing appears to happen)
Play animation in rendered shading (something appears to happen)

**System Information** Archlinux **Blender Version** Broken: latest master (586c589) **Short description of error** Material shading doesn't refresh every frame to reflect keyframes on material nodes, even when rendered with OpenGL render **Exact steps for others to reproduce the error** 1. Open [animated_material_nodes_not_updated_material_shading.blend](https://archive.blender.org/developer/F365555/animated_material_nodes_not_updated_material_shading.blend) 2. Play animation in material shading (nothing appears to happen) 3. Play animation in rendered shading (something appears to happen)

gandalf3 commented

2016-09-21 09:30:13 +02:00

Changed status to: 'Open'

gandalf3 commented

2016-09-21 09:30:13 +02:00

Added subscriber: @gandalf3

Sergey Sharybin commented

2016-09-21 10:33:39 +02:00

Added subscriber: @Sergey

Sergey Sharybin commented

2016-09-21 10:33:39 +02:00

Changed status from 'Open' to: 'Archived'

Sergey Sharybin closed this issue

2016-09-21 10:33:39 +02:00

Sergey Sharybin self-assigned this 2016-09-21 10:33:39 +02:00

Sergey Sharybin commented

2016-09-21 10:33:39 +02:00

Thanks for the report, but this is a known limitation. With current design of shaders and dependency graph it's not possible to avoid GLSL code re-compilation when something changes in the graph, even if it's just a new value of some slider. And in order to keep fps at possible maximum any GLSL update is disabled during playback, this is because GLSL compilaiton is not cheap.

Hopefully this will be addressed in the new viewport, but for now it is a known limitation.

Thanks for the report, but this is a known limitation. With current design of shaders and dependency graph it's not possible to avoid GLSL code re-compilation when something changes in the graph, even if it's just a new value of some slider. And in order to keep fps at possible maximum any GLSL update is disabled during playback, this is because GLSL compilaiton is not cheap. Hopefully this will be addressed in the new viewport, but for now it is a known limitation.

gandalf3 commented

2016-09-21 20:37:44 +02:00

@Sergey I see, thanks.

Out of curiosity, I added a frame change handler to the example .blend to update the material on every frame.

opengl render took 4:38
8 sample cycles render took 3:38

However, the interesting part is:
After performing an opengl render (or even just playing the animation in the viewport once), opengl suddenly starts working in realtime (viewport playback at a solid 24fps, opengl render in 17 seconds).

I assume there is some sort of caching going on, but strangely I can't find any way of invalidating this cache. Opengl is still fast after restarting blender and re-opening the file. Changing a value on the material made it slow, but changing it back made it fast again.

Where is this cache stored? Is it ever freed?

@Sergey I see, thanks. Out of curiosity, I added a frame change handler to the example .blend to update the material on every frame. opengl render took 4:38 8 sample cycles render took 3:38 However, the interesting part is: After performing an opengl render (or even just playing the animation in the viewport once), opengl suddenly starts working in realtime (viewport playback at a solid 24fps, opengl render in 17 seconds). I assume there is some sort of caching going on, but strangely I can't find any way of invalidating this cache. Opengl is still fast after restarting blender and re-opening the file. Changing a value on the material made it slow, but changing it back made it fast again. Where is this cache stored? Is it ever freed?

Sergey Sharybin commented

2016-09-21 21:29:12 +02:00

Not sure about GLSL, but CUDA/OpenCL is cached by drivers. GLSL might have similar behavior, which kind of makes sense. Where it's stored is kind of underfined. On linux it's usually ~/.nv for the persistent cache. There might also be some in-process cache in the driver.

But that's all more a speculation. Blender doesn't do any caching here on it's own.

Not sure about GLSL, but CUDA/OpenCL is cached by drivers. GLSL might have similar behavior, which kind of makes sense. Where it's stored is kind of underfined. On linux it's usually ~/.nv for the persistent cache. There might also be some in-process cache in the driver. But that's all more a speculation. Blender doesn't do any caching here on it's own.

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

Material shading doesn't reflect animated texture nodes #49418