Home

API scene.frame_set might not correctly set frame
Closed, InvalidPublic

Description
This bug happens when I try to run a self-written batch render script through "blender -b file.blend -P script.py". API scene.frame_set of bpy.data.scenes might not be able to set current frame for render. This problem exists with blender 2.63a on Mac OS X 10.7. I'm not able to test on other platforms at the moment.

3 files are attached to recreate this problem. And here are the steps to reproduce the two .blend files.

1. Load factory default
2. Set current frame to 20
3. Press "+" at scenes drop-down to create a new scene, select "Full Copy", and leave the name as is
4. Set current frame to 40 (when the current scene is "Scene.001")
5. Save the file as bug_test2.blend (when the current scene is "Scene.001")
6. Switch the current scene back to "Scene" (the default one), and save the file as bug_test.blend

Run the script, note that the script has "scene.frame_set(100)" to set current frame to 100 before rendering. And here are the commands and outputs

/Applications/blender/blender.app/Contents/MacOS/blender -b bug_test.blend -P bug_test.py
read blend: /Users/bill/Desktop/bug_test.blend
Fra:100 Mem:5.10M (0.10M, peak 5.20M) | Preparing Scene data
Fra:100 Mem:5.11M (0.10M, peak 5.20M) | Preparing Scene data
Fra:100 Mem:5.11M (0.10M, peak 5.20M) | Creating Shadowbuffers
Fra:100 Mem:5.11M (0.10M, peak 5.20M) | Raytree.. preparing
Fra:100 Mem:5.11M (0.10M, peak 5.20M) | Raytree.. building
Fra:100 Mem:5.12M (0.10M, peak 5.23M) | Raytree finished
Fra:100 Mem:5.12M (0.10M, peak 5.23M) | Creating Environment maps
Fra:100 Mem:5.12M (0.10M, peak 5.23M) | Caching Point Densities
Fra:100 Mem:5.12M (0.10M, peak 5.23M) Sce: Scene Ve:8 Fa:6 La:1
Fra:100 Mem:5.12M (0.10M, peak 5.23M) | Loading voxel datasets
Fra:100 Mem:5.12M (0.10M, peak 5.23M) Sce: Scene Ve:8 Fa:6 La:1
Fra:100 Mem:5.12M (0.10M, peak 5.23M) | SSS preprocessing
Fra:100 Mem:5.12M (0.10M, peak 5.23M) | Volume preprocessing
Fra:100 Mem:5.12M (0.10M, peak 5.23M) Sce: Scene Ve:8 Fa:6 La:1
Fra:100 Mem:5.12M (0.10M, peak 5.23M) Sce: Scene Ve:8 Fa:6 La:1
Fra:100 Mem:5.13M (0.51M, peak 6.77M) | Scene, Part 1-4
Fra:100 Mem:5.13M (0.45M, peak 6.77M) | Scene, Part 2-4
Fra:100 Mem:5.13M (0.40M, peak 6.77M) | Scene, Part 3-4
Fra:100 Mem:5.13M (0.34M, peak 6.77M) | Scene, Part 4-4
Fra:100 Mem:4.96M (0.29M, peak 6.77M) Sce: Scene Ve:8 Fa:6 La:1
Fra:100 Mem:5.13M (0.29M, peak 5.42M) | Preparing Scene data
Fra:100 Mem:5.13M (0.29M, peak 5.42M) | Creating Shadowbuffers
Fra:100 Mem:5.13M (0.29M, peak 5.42M) | Raytree.. preparing
Fra:100 Mem:5.13M (0.29M, peak 5.42M) | Raytree.. building
Fra:100 Mem:5.15M (0.29M, peak 5.45M) | Raytree finished
Fra:100 Mem:5.15M (0.29M, peak 5.45M) | Creating Environment maps
Fra:100 Mem:5.15M (0.29M, peak 5.45M) | Caching Point Densities
Fra:100 Mem:5.15M (0.29M, peak 5.45M) Sce: Scene.001 Ve:8 Fa:6 La:1
Fra:100 Mem:5.15M (0.29M, peak 5.45M) | Loading voxel datasets
Fra:100 Mem:5.15M (0.29M, peak 5.45M) Sce: Scene.001 Ve:8 Fa:6 La:1
Fra:100 Mem:5.15M (0.29M, peak 5.45M) | SSS preprocessing
Fra:100 Mem:5.15M (0.29M, peak 5.45M) | Volume preprocessing
Fra:100 Mem:5.15M (0.29M, peak 5.45M) Sce: Scene.001 Ve:8 Fa:6 La:1
Fra:100 Mem:5.15M (0.29M, peak 5.45M) Sce: Scene.001 Ve:8 Fa:6 La:1
Fra:100 Mem:5.16M (0.70M, peak 6.98M) | Scene.001, Part 1-4
Fra:100 Mem:5.16M (0.65M, peak 6.98M) | Scene.001, Part 2-4
Fra:100 Mem:5.16M (0.59M, peak 6.98M) | Scene.001, Part 3-4
Fra:100 Mem:5.16M (0.53M, peak 6.98M) | Scene.001, Part 4-4
Fra:100 Mem:4.99M (0.48M, peak 6.98M) Sce: Scene.001 Ve:8 Fa:6 La:1

/Applications/blender/blender.app/Contents/MacOS/blender -b bug_test2.blend -P bug_test.py
read blend: /Users/bill/Desktop/bug_test2.blend
Fra:40 Mem:5.11M (0.10M, peak 5.21M) | Preparing Scene data
Fra:40 Mem:5.11M (0.10M, peak 5.21M) | Preparing Scene data
Fra:40 Mem:5.11M (0.10M, peak 5.21M) | Creating Shadowbuffers
Fra:40 Mem:5.11M (0.10M, peak 5.21M) | Raytree.. preparing
Fra:40 Mem:5.11M (0.10M, peak 5.21M) | Raytree.. building
Fra:40 Mem:5.13M (0.10M, peak 5.24M) | Raytree finished
Fra:40 Mem:5.13M (0.10M, peak 5.24M) | Creating Environment maps
Fra:40 Mem:5.13M (0.10M, peak 5.24M) | Caching Point Densities
Fra:40 Mem:5.13M (0.10M, peak 5.24M) Sce: Scene Ve:8 Fa:6 La:1
Fra:40 Mem:5.13M (0.10M, peak 5.24M) | Loading voxel datasets
Fra:40 Mem:5.13M (0.10M, peak 5.24M) Sce: Scene Ve:8 Fa:6 La:1
Fra:40 Mem:5.13M (0.10M, peak 5.24M) | SSS preprocessing
Fra:40 Mem:5.13M (0.10M, peak 5.24M) | Volume preprocessing
Fra:40 Mem:5.13M (0.10M, peak 5.24M) Sce: Scene Ve:8 Fa:6 La:1
Fra:40 Mem:5.13M (0.10M, peak 5.24M) Sce: Scene Ve:8 Fa:6 La:1
Fra:40 Mem:5.14M (0.51M, peak 6.74M) | Scene, Part 1-4
Fra:40 Mem:5.13M (0.45M, peak 6.74M) | Scene, Part 2-4
Fra:40 Mem:5.13M (0.40M, peak 6.74M) | Scene, Part 3-4
Fra:40 Mem:5.13M (0.34M, peak 6.74M) | Scene, Part 4-4
Fra:40 Mem:4.97M (0.29M, peak 6.74M) Sce: Scene Ve:8 Fa:6 La:1
Fra:100 Mem:5.13M (0.29M, peak 5.42M) | Preparing Scene data
Fra:100 Mem:5.13M (0.29M, peak 5.42M) | Creating Shadowbuffers
Fra:100 Mem:5.13M (0.29M, peak 5.42M) | Raytree.. preparing
Fra:100 Mem:5.13M (0.29M, peak 5.42M) | Raytree.. building
Fra:100 Mem:5.15M (0.29M, peak 5.45M) | Raytree finished
Fra:100 Mem:5.15M (0.29M, peak 5.45M) | Creating Environment maps
Fra:100 Mem:5.15M (0.29M, peak 5.45M) | Caching Point Densities
Fra:100 Mem:5.15M (0.29M, peak 5.45M) Sce: Scene.001 Ve:8 Fa:6 La:1
Fra:100 Mem:5.15M (0.29M, peak 5.45M) | Loading voxel datasets
Fra:100 Mem:5.15M (0.29M, peak 5.45M) Sce: Scene.001 Ve:8 Fa:6 La:1
Fra:100 Mem:5.15M (0.29M, peak 5.45M) | SSS preprocessing
Fra:100 Mem:5.15M (0.29M, peak 5.45M) | Volume preprocessing
Fra:100 Mem:5.15M (0.29M, peak 5.45M) Sce: Scene.001 Ve:8 Fa:6 La:1
Fra:100 Mem:5.15M (0.29M, peak 5.45M) Sce: Scene.001 Ve:8 Fa:6 La:1
Fra:100 Mem:5.16M (0.70M, peak 6.98M) | Scene.001, Part 1-4
Fra:100 Mem:5.16M (0.65M, peak 6.98M) | Scene.001, Part 2-4
Fra:100 Mem:5.16M (0.59M, peak 6.98M) | Scene.001, Part 3-4
Fra:100 Mem:5.16M (0.53M, peak 6.98M) | Scene.001, Part 4-4
Fra:100 Mem:4.99M (0.48M, peak 6.98M) Sce: Scene.001 Ve:8 Fa:6 La:1

Note that for "bug_test2.blend", the first scene is rendered at frame 40, which is the current frame of "Scene.001", frame_set is not able to change the current frame for this file.

The only difference (obvious) between the two files, is the second file is saved with a non-default scene as the current scene. I've tested many situations, and it appears that "frame_set" API will only work correctly when the default scene is active upon saving.

I've got a file with dozens of scenes. And even though in the above case, "Scene.001" does have correct frame, there's no guarantee that other scenes will have correct frames. The pattern appeared to be random.
dna (Dan Eicher) added a comment.Via Old WorldJul 10 2012, 11:38 PM
Not really sure if this could be considered a bug since the operator in question is called "Render *active* scene" and the 'problem' is that it is using the frame from the context's active scene instead of the named scene in the op call.

The 'randomness' is from the order of the scenes in bpy.data.scenes, the 'correct' frame only gets set once it hits whichever one happens to be the currently active scene -- bpy.context.scene.frame_set() explicitly sets this.
heshiming (Shiming He) added a comment.Via Old WorldJul 11 2012, 1:08 AM
@DanEicher , operator render is not just for the active scene, I mean it does have a "scene" argument. And regarding the "context", it appears that when launched with "-b file.blend", there will be no access to the context.

Batch rendering should not need GUI, that's why I believe such operations should work. And I don't think it has anything to do with python's random key in a dictionary, considering blender does everything correctly in the first file.
dna (Dan Eicher) added a comment.Via Old WorldJul 11 2012, 2:00 AM
What I meant is it works correctly if you add bpy.context.scene.frame_set(100) before looping through the scenes because somewhere while rendering it gets the frame number from the active scene instead of the one you tell it to render thus explaining the randomness.

...which may or may not be intentional -- not sure why it decides to get some settings from the active scene and others from the scene passed in through the op so it could quite possibly not be a bug -- though it is a little weird.
heshiming (Shiming He) added a comment.Via Old WorldJul 11 2012, 2:08 AM
@DanEicher, you are right putting this line does solve this particular problem. But as I'm looping through the scenes, I'm treating scenes as a dictionary data. I don't think blender will use scene in the current loop as the "active scene". Isn't there some confusion here?

And if operator render will only recognize the active scene, why there's a scene argument here?

Plus, I read somewhere that I should avoid use "context" altogether when launching blender without GUI.
wet_sponge (Aaron Symons) added a comment.Via Old WorldJul 18 2012, 1:41 PM
Hi,

You mentioned in your initial post that you're using frame_set() to set the current frame. I'll be honest, I'm not sure what that is used for, but frame_current() will set the current frame in the timeline. This is both readable and writable.

Also, in your last post you mentioned avoiding the use of "context" when launching Blender without GUI. I think this sounds correct, as "context" is based on user input, and what area the user is focusing on, etc. To access scenes, and such without using "context" you can go through the data: bpy.data.scenes["SceneName"], or bpy.data.scenes[0].

Anywho, as I've mentioned; I'm not familiar with what frame_set() is supposed to do, but I hope I've helped in some way. :)
heshiming (Shiming He) added a comment.Via Old WorldJul 18 2012, 3:29 PM
@AaronSymons, I'm not sure about the difference either. I tried both, the results are the same. Plus, it's mentioned in the API doc that one should use frame_set instead of current_frame.

The weirdness about context is that I previously assumed I have no access to it without the GUI. Several APIs are reporting errors, and google told me this fact. But Dan Eicher's method does work. I guess it's the matter of some underlying design issue.
brecht (Brecht Van Lommel) added a comment.Via Old WorldSep 4 2012, 1:48 PM
I don't think there's a bug here. It would be nice to work context-less in background mode, but operators simply will not work without context. They are not so much a programming API, they are user tools. They will work the same way regardless if the UI is open or not, though the context is more limited, you only have things like scene and active object, not screen or area specific context.

Making them work differently depending if we are in background mode would lead to issues as scripts would work subtly different depending on how you run them, that's going to be problematic too. Ideally we should both have the user tools and a complete context-less programming API available, but for now the only way to do some things is to use operators.

Regarding frame_set, that will update animations which frame_current will not. If you render it might not make a difference, since that will do those same updates already as part of render.
brecht (Brecht Van Lommel) closed this task as "Invalid".Via Old WorldSep 4 2012, 1:48 PM

Add Comment