Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Relative shader includes #926

Merged
merged 1 commit into from May 2, 2022
Merged

Relative shader includes #926

merged 1 commit into from May 2, 2022

Conversation

jstone-lucasfilm
Copy link
Member

This changelist adds support for relative includes of shader source files in code generation, and makes all file includes relative within the MaterialX data libraries.

This allows clients to use arbitrary naming conventions for the root folder of their MaterialX data libraries, with "libraries" being the default name in the MaterialX distribution.

This changelist adds support for relative includes of shader source files in code generation, and makes all file includes relative within the MaterialX data libraries.

This allows clients to use arbitrary naming conventions for the root folder of their MaterialX data libraries, with "libraries" being the default name in the MaterialX distribution.
@ix-dcourtois
Copy link
Contributor

Hi, first off, thanks a lot for taking the time to make this change, it's highly appreciated!
I've reviewer the changes, and from what I can understand, I think that it would indeed allow us to upgrade without changing how the data library is deployed, compared to 1.38.3. I think we would have to reset the library prefix to an empty string, but otherwise the rest should work just fine.
I just hope that the changes to emitBlock and emitInclude in the ShaderGenerator class will not be too much of a bother for others (I've seen your announcement in the Slack channel, I hope other teams will take time to check this to avoid any surprise) (and maybe I should also start following that channel :p)
Regards,
Damien.

@rafalSFX
Copy link

rafalSFX commented May 2, 2022

Using relative paths seems like a good solution, that should address the problem of an arbitrary installation structure.

If the included files are not moved relative to the files that include them, all should work, as long as the preprocessor looks for the include files relative to the same directory (of the including file) too. Which I assume is the case for .mtlx, .osl, .glsl (etc) preprocessors.

@jstone-lucasfilm jstone-lucasfilm merged commit a345d13 into AcademySoftwareFoundation:main May 2, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants