Relocated Scenes - Corrupted Material File Paths

[frip51]

Hey there,
long time no see... how's things around here?

I've come across an urgent task that got me puzzled:
In order to introduce a new folder structure, it has become neccessary to migrate all projects to a different location.
Our Rhino projects that were handled locally will be integrated in respective project folders on a network drive.

Is there any way to prevent material file paths from getting broken in the process?
Something like Pack&Go?

Even if there's a bit of manual work involved (since we're not just moving one huge folder but every project on its own), it would help a lot to see a routine/script/... work out the migration of single project folders to a specified new location.
Help is much appreciated!! =))


Cheers,
Matt

[Micha_cg]

If you enable DR and set the shared folder path like you want, than all maps of the scene are collected there. It starts fast, if you disable all slaves before or the list is empty. So far I know are maps found, if they are placed within the work directory (where the Rhino files saved), also VfR should try to search within directories in the work directory. If it dosn't work, you could set the new path for one texture. If I remember me right this could help to find the new path.

[frip51]

Micha, altes Haus!
Fact is, I've got more than one location for texture mapping files.
One for the "universal" textures and, say, one more for project specific textures.

The current folder tree is:
X:\Data\Projects\Project Name\Rhino Models\Version XY\Rhino File.3dm
X:\Data\Projects\Project Name\tex\Texture File.jpg
X:\Data\Rhino\Textures\Sub Folder X\Universal Texture.jpg


In the future, there will be "public" projects with following path types:
Y:\Company Branch\Department XY\Projects XY\Different Type of Project Name\design\Rhino\Rhino Models\Version XY\Rhino File.3dm
Y:\Company Branch\Department XY\Projects XY\Different Type of Project Name\design\Rhino\tex\Texture File.jpg
Y:\Company Branch\Department XY\Rhino\Textures\Sub Folder X\Universal Texture.jpg

And, there will be "hidden" projects with following path types:
Y:\Company Branch\Blabla\Original Project Name\design\Rhino\Rhino Models\Version XY\Rhino File.3dm
Y:\Company Branch\Blabla\Original Project Name\design\Rhino\tex\Texture File.jpg
Y:\Company Branch\Department XY\Rhino\Textures\Sub Folder X\Universal Texture.jpg


As long as there is no tool that re-writes file paths, all texture links will be broken. (
Looks like the original sturcture was rubbish in the first place...


Cheers,
Matt

[wcmansp]

I'm not sure if it will help in your situation but we took the hint, above, that Micha had offered in some earlier forum entry, that VfR adds a search path for each imported material, and built two shared material libraries. Both contain the same materials. One is the traditional folder organization, a human-organized collection of "People", "Wood", "Ceramics"... People can copy some or all of these textures to their local machines and put them anywhere they want. The second shared material library consists of all the .vismat and .jpg support files from all these materials in one single folder (the "Preview" .png files are not needed for this) -- no sub-folders. If any single material from this folder is imported into a Rhino VfR file, all the materials in the folder are automatically now included in the search path for any material used in the file; if VfR can't find a file in its original location ("C:\VRAY materials\Cement\<something>...") it will still find it in this server location and render successfully.

Our objective was to try to simplify rendering for students, where the mechanics of search paths are difficult to convey. You may have some different needs, e.g. for the security of some textures, but it may be possible, just by lumping all kinds of textures in the single-folder version of the library, to obscure what is being used by any particular group. At any rate, if you absolutely need to get one of these more complicated files rendered, this would allow that to happen without having to re-map each texture individually.

One additional tweak. It may be possible to create a Rhino script that handles the injection of one of these single-folder textures in a Rhino file (e.g. a visLoadVismat operation), just to simplify the process. The texture doesn't have to actually be used in the file (ie. assigned to an object) -- it can just be some dummy texture from that location. We didn't pursue that particular tack because the renderfarm product we're using lets us inject that as part of their processing; it happens after the submission of the file, so students don't have to do anything special, and, because that version of the file never replaces their original version, there's no change from their perspective.

--Bill