Page 1 of 1

Relative file paths

Posted: Wed Apr 06, 2016 1:30 pm
by pixteur
In Octane for MODO is it possible to use relative file paths?

For example in the Kernel, Background Image… ? It always seems to be absolute which makes it hard to share files with other team members who do not work on a shared server.

Also inside of Octane Material Overrides, what is the best practice for loading images that are relative to the MODO project?

best

Re: Relative file paths

Posted: Wed Apr 06, 2016 1:40 pm
by face_off
For example in the Kernel, Background Image… ? It always seems to be absolute which makes it hard to share files with other team members who do not work on a shared server.
Yes, this is currently always a full file path, and is not something I can change in the short-term.
Also inside of Octane Material Overrides, what is the best practice for loading images that are relative to the MODO project?
IMO you should add all images to the Shader Tree, then add those images into your Octane Overrides - that way the Octane Override will read the image path from the Shader Tree Image item (which will be relative), amongst other benefits.

Paul

Re: Relative file paths

Posted: Wed Apr 06, 2016 2:05 pm
by Obizzz
face_off wrote:IMO you should add all images to the Shader Tree, then add those images into your Octane Overrides - that way the Octane Override will read the image path from the Shader Tree Image item (which will be relative), amongst other benefits.

Paul
That's usually how I do it but good to know.

I find the quickest way to setup the material is usually to set the basics in the shader tree and convert it.

What about saved presets though. How do those store image paths? I find I often have to relink the images.

Re: Relative file paths

Posted: Wed Apr 06, 2016 10:13 pm
by face_off
What about saved presets though. How do those store image paths? I find I often have to relink the images.
Any time the file path is explicitly entered in the Octane Image->Filepath channel it will be absolute, not relative. This could be changed, however my concern would be that that would lead to just as many lost assets when people move the .lxo and not the images. Perhaps a checkbox on the Octane Image node to control this? I will add this to the medium-term TODO list.

Paul

Re: Relative file paths

Posted: Wed Apr 06, 2016 10:45 pm
by Obizzz
face_off wrote:
What about saved presets though. How do those store image paths? I find I often have to relink the images.
Any time the file path is explicitly entered in the Octane Image->Filepath channel it will be absolute, not relative. This could be changed, however my concern would be that that would lead to just as many lost assets when people move the .lxo and not the images. Perhaps a checkbox on the Octane Image node to control this? I will add this to the medium-term TODO list.

Paul
That would be nice but as you say nothing critical so medium-term sounds good.

Re: Relative file paths

Posted: Thu Apr 07, 2016 3:31 pm
by pixteur
Thanks for the info.

I've decided to go the shader tree route to play it safe and seems to work fine. So it seems MODO should manage scene textures as much as possible, allowing to repurpose scenes for different render engines. If your using a project directory MODO can always find the images and even collect them. Whenever Octane manages a texture it it's paths are absolute and this kills any collaborative work on other machines, offices.

I wish the background filename could use a second MODO environment as its source.
Also I wish it would distort the texture to match the render resolution rather than change the render window proportions. I often stick a square image in MODO to use as a background in an environment mapped to a camera, and it adapts to whatever render resolution I have.

Re: Relative file paths

Posted: Thu Apr 07, 2016 5:34 pm
by Obizzz
pixteur wrote:Also I wish it would distort the texture to match the render resolution rather than change the render window proportions. I often stick a square image in MODO to use as a background in an environment mapped to a camera, and it adapts to whatever render resolution I have.
+1 and if I'm not mistaken that's the way it was in early versions of the plugin?