[bjorn.syse]

Great function! Just have a few questions in regards to it.

I prepare a scene in Rhino on Windows. Check the Pack and Go checkbox and Render to Mxs.

1. Then I open the .mxs in Studio in Os X, but am here forced to locate one of my HDRs. Now this was not a big pain for this particular scene, but I just thought maybe this was not supposed to be the case?



2. Also, Would it be possible to include the paths to the image and the mxi output, and make them relative aswell? They're still stored as absolute Windows paths.



3. What happened to the "Relocated paths" function? gone?

Best regards,

- Björn

[JDHill]

Hi Björn,

1. that shouldn't happen - could you tell me where this HDR is located (material, image based env.)? Maybe the plugin is not considering one of them.
2. I'm not sure, I'll have to do some testing
3. yes, but you should still be able to use the Maxwell_GatherFilesAndMakePathsRelative function

Cheers...

[bjorn.syse]

Hi again,

1. Yep, it's actually located in a 'textures' folder in the same directory (a result of using Relocated paths on that scene with that last plugin)
2. Cool, it would be great, cus it would mean I could just double-click on an mxs created in windows, in OS x and just start rendering right away.
3. Good stuff, it's still handy when working both via parallels and bootcamp,..

[JDHill]

So, on point 1, is it your opinion that the plugin is doing something wrong, or is it more that a file which should be found by Studio is not being found? I guess I mean, the file is given as its relative 'textures\HDR_BackTopLeft-_hdr'; does a file actually exist at that location? If so, then it would be Studio failing to find it - if not, then it would be a problem in the plugin's Pack and Go code.

[bjorn.syse]

Well, Judging only by the information given by the error message, it seems Studio has the path down as 'textures\HDR_BackTopLeft-_.hdr' and the texture/hdr does really exist in that relative location with the same name.

...however, the path separator is backslash, but I'm on OS X when opening it. Could that be the problem?

- Björn

[JDHill]

I don't really think so. The code in the plugin uses platform routines to build the relative file path, and it does so for all transferred textures using the same piece of code, so if that were the problem, it should be a problem for all textures in the scene. You can check that by deleting the textures folder - when you open the mxs, and the textures are not found, you should see that all textures are using the same convention; when you don't delete the textures, and they are found, the paths are fixed up on the fly, so you never see that in the mxs, they really were textures\texture.jpg.

Therefore, I'd tend to think it would have something to do with code inside of Studio, specifically regarding the paths in the image based env. channels; I'll try to duplicate it here and see what I can find.