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

Juan Pablo Bouza jpbouza at hotmail.com
Sat Mar 1 13:29:38 CET 2014


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
 		 	   		  


More information about the Bf-committers mailing list