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

Campbell Barton ideasman42 at gmail.com
Sat Mar 1 13:44:08 CET 2014


Hi Ton,

The solutions you describe is nearly what we have already.

We've gone to a fair effort to ensure absolute paths don't happen
(when the user preference is set to use relative paths),

However there are 2 cases which I've noticed fail still...
- MS-Windows when one path on C:, another on D,E,F... drive, relative
fails - we cant help this.
- When users link to paths on their desktop or so, You end up with
paths like "//../../../../home/user/Desktop/reference.jpg"

As you suggest, a way to make it to use paths outside the projects
domain would be helpful.

As for checking paths are relative, you can use File -> External Data
-> Make All Paths Relative, It will report if any paths fail to become
relative.
Theres also an operator there to report missing files.

Though for open movies we ended up having some more comprehensive
scripts to report any anomalies since we wanted to report very large
images (for example), since they would suck up too much memory.

----

Even if we have really good checking - In my experience artists manage
to get themselves is a mess with this stuff quickly (especially when
they're in a rush), linking reference images - making temp blend files
and linking from those then removing the files, not updating to recent
revisions of library assets and committing work linking to old files.

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.

This doesn't necessarily need to be built into Blender, we could just
make sure Python has a way to identify such situations and allow for a
script to define which case is an error, since projects often have
difrerent requirements and use Python scripts to manage render setup
already.

On Sat, Mar 1, 2014 at 10:44 PM, Ton Roosendaal <ton at blender.org> wrote:
> Hi,
>
> Let's be clear; options, warnings, and especially YES-NO requesters are all signs of lazy and weak design.
>
> The best way to solve this is to prevent this from happening. I know Daniel's cause, and it's just because a path was absolute, and not relative. Either a bug or a user error.
>
> Solution: make the fact user works on a project with relative paths much more visible and in control. The project path (from where relativeness works) has to be explicit somehow. And especially - if user decides to use a file outside the project domain - it can just refuse that, throw big warnings, move it inside the domain, or pack it even.
>
> Secondary: make a tool (operator) that checks for paths to be proper relative. That tool can be used at will (user), or a scripter can use it configure Blender to make it automatic. That then can be sort-of doing what's being proposed below, but it's only a debugging tool.
>
> The work we plan for Gooseberry's asset/project system is all about this. Sanitize how data is being referenced, re-used, shared, linked, stored, versioned, copied, and so on. There's the real job.
>
> -Ton-
>
> --------------------------------------------------------
> Ton Roosendaal  -  ton at blender.org   -   www.blender.org
> Chairman Blender Foundation - Producer Blender Institute
> Entrepotdok 57A  -  1018AD Amsterdam  -  The Netherlands
>
>
>
> On 1 Mar, 2014, at 2:52, patrick boelens wrote:
>
>> The only problem I see with this solution is when you actually know you're missing resources (i.e.: third-party textures), but want to render regardless.
>>
>> I think for headless mode this would probably be less of an issue, especially considering who uses that and in which situations.
>>
>> Perhaps for GUI-Blender we could show a confirmation screen, operator-style?
>>
>> "You are about to render with missing resources (see render_errors.txt). Would you like to continue?" -> [Yes | No].
>>
>> The second thing I'd like to address is: How do we make it clear to the user which resources are missing? Could a linked in .blend not be found, or is it a texture's image? Again, for headless mode it could probably just be printed to the console, so no issues there. But for regular use, perhaps a textblock could be created? This would give room to provide all the needed info. For instance:
>>
>> Missing Mesh Data "Circle.042" from "./Costumes.blend"
>> Objects affected: Cloak
>>
>> Missing ../../textures/eyes.png in texture "Eyes.002"
>> Materials affected: Face1, Face2
>> Objects affected: Elf_F, Elf_M, Elf_M.001
>>
>> Missing ../../textures/mouth.png in texture "Face"
>> Materials affected: Face1, Face2
>> Objects affected: Elf_F, Elf_M, Elf_M.001
>>
>> Just thinking out loud here. =)
>>
>> Cheers,
>> Patrick
>>
>>> Date: Fri, 28 Feb 2014 21:29:48 -0300
>>> From: venomgfx at gmail.com
>>> To: bf-committers at blender.org
>>> Subject: Re: [Bf-committers] Proposed change for (not) rendering with        missing links
>>>
>>> +1
>>>
>>> Rendering with missing textures is never desired. An option (by default) to
>>> have it stop the render immediately would save plenty of render time. This
>>> option could be turned off in the user pref if desired.
>>> On Feb 28, 2014 8:57 PM, "Daniel Salazar - patazstudio.com" <
>>> zanqdo at gmail.com> wrote:
>>>
>>>> Hi there, recently we lost about 24 hours of rendering time because a
>>>> texture was missing in some computer. And we can't rely on the famous
>>>> purple color to notice this errors, in this case it was a subtle hair
>>>> length texture or it could be another type of data like linking from
>>>> other blends.
>>>>
>>>> I want to propose we change the renderer behavior to refuse rendering
>>>> if there's a missing link. At the very least this should be
>>>> implemented by default in background mode, with an optional parameter
>>>> to ignore missing textures.
>>>>
>>>> kind regards,
>>>>
>>>> Daniel Salazar
>>>> patazstudio.com
>>>> _______________________________________________
>>>> Bf-committers mailing list
>>>> Bf-committers at blender.org
>>>> http://lists.blender.org/mailman/listinfo/bf-committers
>>>>
>>> _______________________________________________
>>> Bf-committers mailing list
>>> Bf-committers at blender.org
>>> http://lists.blender.org/mailman/listinfo/bf-committers
>>
>> _______________________________________________
>> Bf-committers mailing list
>> Bf-committers at blender.org
>> http://lists.blender.org/mailman/listinfo/bf-committers
>
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers



-- 
- Campbell


More information about the Bf-committers mailing list