x

Search in
Sort by:

Question Status:

Search help

  • Simple searches use one or more words. Separate the words with spaces (cat dog) to search cat,dog or both. Separate the words with plus signs (cat +dog) to search for items that may contain cat but must contain dog.
  • You can further refine your search on the search results page, where you can search by keywords, author, topic. These can be combined with each other. Examples
    • cat dog --matches anything with cat,dog or both
    • cat +dog --searches for cat +dog where dog is a mandatory term
    • cat -dog -- searches for cat excluding any result containing dog
    • [cats] —will restrict your search to results with topic named "cats"
    • [cats] [dogs] —will restrict your search to results with both topics, "cats", and "dogs"

How can I reference a relative file path in an #include in a custom node?

Hiyo! I'm attempting to smooth over the process of including HLSL files in my materials. So far what I've found is that I can store code for the Custom node in an HLSL file by adding in the custom node's Code property:

 #include "C:/Shaders/ShaderCode.hlsl"
 return 0;

As you can see, the path is literal, which introduces a lot of issues with packaging and source control. Is there any way for me to use a relative file path or macro to include these files in source control and packaging? Preferably, the path would reference a path in the project folder.

Product Version: UE 4.15
Tags:
more ▼

asked Apr 21 '17 at 07:16 PM in Rendering

avatar image

Birblay
3 1 4 5

(comments are locked)
10|2000 characters needed characters left

1 answer: sort voted first

I believe you'd have to make it relative to the Engine/Shaders folder, as that's the path from which all the other #includes are resolved.

Be aware that what you're doing is the equivalent of pasting the contents of that file into an HLSL function that the engine generates for each custom node when it's translating the node graph into the code that gets passed to the shader compiler:

 <ReturnType> CustomNodeN (FMaterialPixelParameters Parameters, <OtherParameters>)
 {
     #include "your file"
 }

That is to say, only code that would be valid in such a context will work inside your #include file. You could not easily define new functions inside that file, for example, as HLSL does not support nested function definitions. This method also has the drawback of making it more difficult to figure out what's going on in the material later; you might be better off using material functions containing the custom nodes if you plan on reusing them over multiple materials. If your goal is just to have an file with a bunch of common shader functions you can call from your custom nodes, you could modify the MaterialTemplate.usf file to add the #include for your file at the top, so it's included automatically with every material shader that's compiled, though this will necessitate a recompile of all materials when you change that file.

For the custom version of the engine being used at our studio, we've added support for specifying a list of arbitrary #includes on the material (or material function) itself, to avoid changes to special-case stuff from forcing all materials to be recompiled. The list of files is specified on the material, and our artists then call the functions in those files from inside custom nodes. You could consider that route - it worked very well for us.

more ▼

answered Jan 19 '18 at 09:01 PM

avatar image

Dylan Barrie
41 3 4

(comments are locked)
10|2000 characters needed characters left
Your answer
toggle preview:

Up to 5 attachments (including images) can be used with a maximum of 5.2 MB each and 5.2 MB total.

Follow this question

Once you sign in you will be able to subscribe for any updates here

Answers to this question