Rendering ranges of sample chunks only works reliably for us after
Blender commit 7744203b7fde35a074faf232dda3595b78c5f14c (Tue Jan 29
18:08:12 2019 +0100).
Flamenco Server changed from expecting a fixed number of sample chunks to
a compile-time determined number of nonuniform chunks. The artist can now
influence the size of each render task by setting a maximum number of
samples per render task.
We shouldn't call any `gpu` functions in background mode. Since the texture
browser will never run when Blender is in background mode anyway, we can
simply assign `None` instead.
This includes using `''` instead of `None` in some cases where an empty
string conveys 'nothing' equally well as `None`; in such cases keeping the
type the same rather than switching to another type is preferred.
The `file_loading` function is called deferred by asyncio, and can thus
be called when the operator has already stopped loading. This is fixed by
not referring to `self` in that function, and taking the logger from the
outer scope.
Requires that the file is configured for rendering to Matroska video
files.
Audio is only extracted when there is an audio codec configured. This is
a bit arbitrary, but it's at least a way to tell whether the artist is
considering that there is audio of any relevance in the current blend
file.
This introduces version 2 of that file.
Version 1:
- Only the job doc was saved, with 'missing_files' added inside it.
Version 2:
- '_meta' key was added to indicate version.
- 'job' is saved in a 'job' key, 'misssing_files' still top-level key.
- 'exclusion_filter', 'project_settings', and
'flamenco_manager_settings' keys were added.
These are all needed to use FFmpeg on the worker to render a video from
rendered image sequences.
- fps: float, the scene FPS
- images_or_video: either 'images' or 'video', depending on what's being
output by Blender. We don't support using FFmpeg to join chunked videos
yet.
- output_file_extension: string like '.png' or '.exr', only set when
outputting images (since doing this for video requires a lookup table and
isn't even being used at the moment).
The problem was that there was too much storing done in an on-change
handler, causing things to be overwritten. By splitting up some functionality
and properly marking the "we're now loading" bits of code, its' solved.
They were ending up in a `local` directory next to the `blender_cloud`
directory. Probably something to do with newer setuptools? Had the same
issue in the Blender ID add-on.
