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

David McSween 3pointedit at gmail.com
Wed Mar 5 23:23:36 CET 2014


Does the new Amaranth addon address this issue?
https://github.com/venomgfx/amaranth/ or perhaps being a script means that
it to could be missing.
On 3 Mar 2014 12:24, "Campbell Barton" <ideasman42 at gmail.com> wrote:

> 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
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>


More information about the Bf-committers mailing list