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" <[email protected]> wrote:
> On Mon, Mar 3, 2014 at 6:13 AM, Jed <[email protected]> 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 > [email protected] > http://lists.blender.org/mailman/listinfo/bf-committers > _______________________________________________ Bf-committers mailing list [email protected] http://lists.blender.org/mailman/listinfo/bf-committers
