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 - [email protected] - 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: [email protected] >> Date: Sat, 1 Mar 2014 12:44:21 +0100 >> To: [email protected] >> 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 - [email protected] - 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: [email protected] >>>> To: [email protected] >>>> 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" < >>>> [email protected]> 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 >>>>> [email protected] >>>>> http://lists.blender.org/mailman/listinfo/bf-committers >>>>> >>>> _______________________________________________ >>>> 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 >> >> _______________________________________________ >> 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 _______________________________________________ Bf-committers mailing list [email protected] http://lists.blender.org/mailman/listinfo/bf-committers
