[b-kandor]

Hi,

After download assests or using the modo plugin to convert modo materials. I'm always left with texture paths pointing to my local c drive. Afterwards if I attempt to pack and go the scene to a network drive the paths are NOT changed, but remain pointing to my c drive. This causes obvious problems when network rendering.

edit*, to expand on this: Pack and go does copy the texture files to the new folder, but if you use the 'texture list' command in studio's material editor it will show the new and old path as separate items, the old path will not vanish until you delete or rename the local file. This is super arduous.

Is pack and go broken? Or am I doing something wrong? I remember pack and go working perfectly in the past, but it's a real struggle now to correct these c drive paths.

[JDHill]

In theory, it should not much matter what the actual paths are in mxs and mxm files, since the engine will try to search for textures in the current directory, a ./textures subdirectory, and any other search paths you have set up. In other words, if you see an error complaining about a missing resource, and the path given is c:\dir\file.ext, it really means that not only could file.ext not be found at c:\dir, but that it also could not be found by any search method. Therefore, the first thing would be to be absolutely sure the file is being included in the pack & go, by confirming its existence on the target machine; once that is sure (and I guess it is, given your description), you can then try making sure to explicitly set a search path, either in Maxwell/MXED/Studio preferences, or in the network job setup, if you're network rendering. If after doing so the file still cannot be found, then we'll need to drill down into what might be the problem, by looking at the console output from e.g. Maxwell's Console panel.

[b-kandor]

Thanks Jd,

I have theories but not proven yet. For example, if a texture is originally written local, like c:\texture\ Then later you browse to the same file on a network drive, the original c:\ path is still embedded in the texture pickers dropdown. It seems that if the original path is still valid that the scene sees that as a dependency.

My issue from yesterday was that yes, pack and go worked, but the textures list and therefore the coop dialogue from maxwell monitor still listed the old unused c:\ path as a dependency until I actually went and changed the c:\ path foldername and reopened the scene in maxwell studio, then resaved. It was the only way to get maxwell to 'forget' about the c:\ path.

Hope all is well...!

[JDHill]

Doing well here, and hope you are too -- I'm currently in the middle of some things, but I'll try to set up a similar scenario later tonight and see what's happening.

[JDHill]

Apologies for the delay, the stuff I was working on took a bit longer than expected. On the topic, I'm trying to figure out a sequence of steps to reproduce, but there are plenty of open questions, and I have not yet been successful in observing a failure. Starting from the beginning, I:

• 1. Open Studio, import a plane, and assign it the default material.
  2. Set refl0 in that material to point to a texture at c:\test.png.
  3. Start the network manager, and a render node, on my local machine.
  4. Start a render node on an osx machine on my network.

I gather that the objective is to render this mxs cooperatively, so I naively click the network render button in Studio, set my image & mxi paths to point to a network location (which is really on my local machine, but referred to in UNC format), check the Send Dependencies box, and click OK. This works fine, with no further steps, but I need to figure out where pack & go comes into the picture.

So, rather than do that, I step back, and try using pack & go to save the scene, with its dependencies, to a network-accessible location. So, I do that, then close Studio, and open Maxwell Monitor directly, and set up a coop job. The previous job is still set up in the network manager, so first, I use Remove Job to clear that out, then run Add Job > Cooperative. I browse to the MXS written by pack & go, set up the output paths, check Send Dependencies, and run the job, which works fine.

Needing to try something else, I next open the original MXS in studio again, and use pack & go to save it to a folder on my mac. I then close the monitor on my local (win 8.1) machine, log into my mac, start the monitor there, and set up a similar coop job, but this time pointing to the mxs I just saved to the mac with pack & go. As before, I set up the output paths, check Send Dependencies, and start the job, which again works fine.

So basically, I'm not yet seeing where the problem comes in; I tried two ways (i.e. with/without using pack & go) of cooperatively rendering the scene from the machine on which it was created, and I also tried a third way, rendering it from a different machine, which is running a totally different OS. So, I think I'll need a much more specific description of what you're doing, and when/where/how it is failing.