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

Ton Roosendaal ton at blender.org
Sat Mar 1 14:33:05 CET 2014


Hi,

If you work all alone, you can do what you want.

If you want to give the project to someone else (or render farm, or commit it to a version system) it should include such libraries. A project 'domain' can be as flexible as we want it, and be as limited too.

-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 13:29, Juan Pablo Bouza wrote:

> Ton Wrote:
> 
> "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."
> 
> -1 to any proposal that would force assets to be inside of the project domain. For instance, you may want to have a texture library that is in some place of yo computer, and forcing things to be copied to the folder of the project is just a waste of disk space.
> I prefer big warnings and a more explicit relative path control :)
> 
> 
> 
> 
> 
>> From: ton at blender.org
>> Date: Sat, 1 Mar 2014 12:44:21 +0100
>> To: bf-committers at blender.org
>> Subject: Re: [Bf-committers] Proposed change for (not) rendering with	missing links
>> 
>> 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
> 		 	   		  
> _______________________________________________
> 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