search

GafferHQ / gaffer

Gaffer is a node-based application for lookdev, lighting and automation
http://www.gafferhq.org
BSD 3-Clause "New" or "Revised" License
955 stars 206 forks source link

GafferArnold "plugin_searchPath" hardcoded to OSL_SHADER_PATHS #5414

Closed JeremyBooks closed 1 year ago

JeremyBooks commented 1 year ago

Version: Gaffer 1.3.0.0-linux Third-party tools: Arnold Third-party modules: IECoreArnold

Description

I noticed when generating a scene description with the GafferArnold plugin, a "plugin_searchpath" options is set in the resulting scene hard coding the entire contents of the OSL_SHADER_PATHS env var. This can cause some conflict in Arnold with nodes being registered twice, in our case we have a wrapper for Arnolds Kick command which sets the required paths to the ARNOLD_PLUGINPATH var. This is also adding appleseed and cycle osl shaders to the arnold paths, which i feel is unnecessary.

It would be very ideal if this was either optional to avoid any conflicts with other pipelines.

I have fixed this on our end already, however it would be great to have a solution in a future release of Gaffer.

Steps to reproduce

  1. Produce any scene description with an ArnoldRender Node
  2. Open resulting .ass file and view "plugin_searchpath" option.

You can see this is happening in the code base here: https://github.com/GafferHQ/gaffer/blob/main/src/IECoreArnold/Renderer.cpp#L3450-L3464

johnhaddon commented 1 year ago

Unless something has changed, we need to include the OSL_SHADER_PATHS there, otherwise Arnold won't be able to find the shaders when we export OSL shading networks. The majority of OSL shaders are useable in any renderer, and that's one of the great benefits of using OSL, so I don't think we should limit portability arbitrarily by omitting the Cycles OSL shaders.

That's not to say we're not keen to resolve the conflicts you're seeing - could you provide a bit more detail about those?

One other option is that we omit OSL_SHADER_PATHS, and then hardcode the full path to the .oso file when exporting each OSL shader to Arnold, instead of outputting only the searchpath-relative path. But this has downsides too, in that the .ass file is now tied to a particular installation layout, and may not be portable between machines.

JeremyBooks commented 1 year ago

oh wow, I cant believe i misread this error this bad.. sorry. Arnold is actually trying to compile the ../gaffer/shaders/mandelbrot.osl shader and failing because we run our software on a read-only file system. I'm not too sure why Arnold is trying to compile it though, there is the oso file next to it

johnhaddon commented 1 year ago

I think Arnold maybe checks the timestamps and recompiles if the .osl is newer than the .oso - perhaps that's the case here?

JeremyBooks commented 1 year ago

wow you are right, the oso file is milliseconds older... the timestamps are all set on the files when its copied to its final location on the file server, that is interesting we have not seen this before..

I guess lets close this issue as its not related to Gaffer, thanks for the help John!

johnhaddon commented 1 year ago

I did a bit more due diligence and checked a vanilla download immediately after untarring it, and there the timestamps are preserved such that the .oso files are considerably newer. So yep, let's close this one - thanks for working through it.