Filepaths are not remmaped after making a library item local *POSTPONED, AFTER 2.60*
Closed, ResolvedPublic

Description

please see unzip bug_1.zip:

//main.blend
//assets/library.blend
//assets/textures/uv.png

1) open main.blend
2) with linked object selected make the object local
--- things still work
3) now make the mesh local
--- the old reference to //textures/uv.png (from the library.blend) is no longer valid. It should be remapped to //assets/textures/uv.png

Forcing refresh of the texture (go to edit mode, or simply click in the texture panel) will "make it broken" (pink color for the object).
The reason the link is crashed in this moment is because the mesh face is linking to the image datablock (in uv panel).

A variation of this bug can be seen in bug_2.zip (same file/folder structure)
1) repeat steps 1, and 3
2) make the material and the texture locals.
If you look at the image datablock in the texture channel it says //textures/uv.png (which should be broken by now) but the image still behaves ok until we save close and re-open blender (rendering or launching the bge still doesn't give you a clue that something is broken).

Thanks

Details

Type
Bug

sorry small edit. In both cases I only see the problem after save/reload the file or clicking in reload texture. So nevermind the second files.

This is easy enough to fix but infact there are many places where we should fix it.

I looked into it and propose to replace BLI_bpath iterator with a path walker function which can take either a main (walk over all paths), or a single ID - which would help for making local.

To do this I need to rewrite parts of BLI_bpath and `make local` code also needs some fixing (outliner for eg doesn't call correct funcs).



Talked with Alex who's interested in looking into this one. assigning.

Attaching more tests for make local: linked brush with image, linked world, and linked object with texface + material that use the same image. Also attaching a patch that implements make_local_image. The patch improves the behaviour of id_make_local in a number of ways, but does not yet improve path handling.

Patch details:
- Refactor for make_local_* functions: boilerplate code for flagging ID as local now contained in function id_set_local.
- Added function to make an image local.
- When making local image, looking for refs in texface and brushes too.
- make_local_mesh no longer makes texface images local; that must be done as a separate step (e.g. in the UV editor). This prevents an image from being made local prematurely, e.g. if it is also used by a linked texture.

Path fixes and more make_local_ functions will be added soon.

Dalai, how does your recent work on texface affect this code?

Hi Alex. It doesn't change this at all. period :)

Cool. The patch is almost done; should have something for you to test in the next day or two.

Added another version of the patch that should fix this bug. Dalai, could you test it please?

New change: Added a visitor that changes paths to/from relative. Using it to rewrite image paths when making local.

This should be extended to work for other ID types, such as sound, text and fluid cache.

Alex, the patch you sent is not svn-friend (it's a git one, right?)
Can you make a patch that I can simply apply ? Thanks

Ah yes, sorry. Here's a Tortoise-friendly patch: image_local_2_svn.patch

I've tested this fairly well, I think, so I'll probably commit it tomorrow.

Hi Alex, I still have a bug with your patch.

In my test in windows the path was:
//textures/caribbeanReefSharkC.png

After making the image datablock local I get:
//\Assets\textures\caribbeanReefSharkC.png

Instead I should get:
//../../Assets/textures/caribbeanReefSharkC.png


The work file is at: C:\project\Scenes\Scene03\Scene03.blend
The texture file is at: C:\project\Assets\textures\caribbeanReefSharkC.png
The library file is at: C:\project\Assets\caribbeanReefShark.blend

Thanks for picking that up, Dalai!

Added a test case that demonstrates that, and updated the patch to fix it. The path rewriting code now makes (a local copy of) the library path absolute before using it to resolve the image path.

@Alex, looked at the patch, I think it needs to work differently.
There is no gaurentee that the library path is relative to the current blend file, it could be an indirectly linked library.

This could still be resolved using Libary->parent but suggest to use library->filepath instead and have the base path always absolute (even add an assert if first 2 chars are "//" just to be sure).

You might have noticed that Library->filepath is only set on reading currently so when renaming the library we need to make sure its updated but think this is outside the scope of you're patch and we can solve later.

To make the change suggested is minimal, remove path absolute conversion and pass library->filepath rather than library->name.

update, Library->filepath is kept in sync now.
since this was only set on read you dont need to worry about old files having it unset.

Thanks for the review Campbell, and for fixing lib->filepath. New patch attached that makes use of that field: image_local_5_svn.patch. This patch also fixes a regression in making groups local from the outliner. See image_local_4-5.diff for the changes between the last patch and this one.

Under review at http://codereview.appspot.com/5297056

Fix committed, r41292.

The path visitor should be used for other IDs. I have a partial patch for that; may commit soon but will discuss plans with Campbell.

Dalai, can you verify that this fixes the issue in Windows?

Dalai confirmed the fix in IRC.

Alex Fraser (z0r) closed this task as "Resolved".Oct 26 2011, 2:02 PM