[Bf-committers] Proposed change for (not) rendering with missing links

[Campbell Barton]

On Mon, Mar 3, 2014 at 6:13 AM, Jed <jedfrechette at gmail.com> wrote:
> Campbell Barton wrote
>> So as for the original request - I think a way to consider certain
>> errors fatal could be useful.
>>
>> Example of options to abort on...
>>
>> - missing library blend.
>> - missing file (image/sculpt/movie... etc)
>> - missing pointcache (if it can't be generated)
>> - script error (error in driver or any script passed via --python
>> argument)
>> - invalid fcurve rna paths.
>>
>> Failing silently on errors like this can be really annoying especially
>> if you do hrs of rendering only to find the result is useless
>
> I'm imagining something like Scribus's Preflight Verifier. It ships with a
> few default profiles that will do various sanity checks depending on the
> intended output format. The user can define their own profiles. It can be
> run manually but by default it will run at export time before rendering. If
> it detects an issue it will describe the issue and give you the option of
> canceling the render or ignoring the issue and continuing (maybe I moved my
> .blend file to intentionally break all of my texture paths because I wanted
> a quick clay render and couldn't be bothered to turn them off). If you
> really don't want automatic checking before export/render it can be
> disabled, although given how much better computers are than humans at
> keeping track of large numbers of assets and doing this sort of validation
> I'm not sure when that would be desirable.

Yep, keep this in user control is good and what we've been doing (for
example when you save to a different directory you can choose to remap
relative paths, or not).

Regarding computers being better at checking errors, I think you
underestimate the number of false-positives,
In my experience there just ends up being a lot of cases which you
could consider an error but don't really end up mattering in practice
and its near impossible for the compter to know for sure what to
really consider an error.

Maybe you have missing multires data on an object which is far away,
or missing texture on a hidden object or so, a texture is missing from
an material...

But the far off object can move closer or the hidden object can have
its state animated and Python can switch materials at runtime.

Anyway - Im all for improving tools here, just to say I found defining
these problems as errors on large projects quite impractical, though
if artists are prepared to be a bit more careful and Blender behaves
well, its still worth trying to improve on this where we can.


> Like you indicated for the open movies, I'm guessing a lot of people are
> already using their own homebrew scripts to do similar sorts of things.
> Although that's easy enough to do, it would be nice if Blender shipped with
> a more well defined framework for running preflight checks as well as a few
> default profiles. That way casual users would get the benefit of checks
> without having to write them and TDs who need more complex checks would only
> need to write a profile (presumably a Python script) and wouldn't need to
> worry about all the back-end logistics, how to present the results to the
> user, etc.
>
> Note that there is no reason preflight checks should be limited to rendering
> checks. For example, all of the geometry checks that can be done in the 3D
> printing toolbox could be converted to a "3D printing" preflight profile.

Sure, we could have some blend-lint tool with enough flexibility to be
used by both render-farms, exporters and standalone - or run
recursively on a project directory,
This works nice for paths but there is still the case for runtime
errors (like broken drivers of failed scripts) which would be good to
solve for renderfarms too.


-- 
- Campbell