Has anyone had any success mixing multi-compile with cginc includes? Its not working for me, but frustratingly if i comment out the multi-compile line and replace it with a simple define the exact same code works great.
Iāve tried numerous variations, tried adding all the includes and then checking the defines in the cginc files themselves etc and it just never works. Starting to think multi-compile is some how special compared to just using a define and is thus doing something different.
Yet if i leave the multi-compile line in and then add a define for the first value in the multi-compile then Unity complains that the same value has been defined twice, so there shouldnāt be any difference between them
sounds like obscure syntax, were there no results for multicompile and includes example shaders, when searching codewords for unity codes from pastebin etc?
I started using ifdef when I found checking for Unity defines such as UNITY_COMPILER_HLSL2GLSL would fail, at least I think it was that, something made me switch to ifdef.
Tried switching back to plain #if, no luck, though I get different errors, unmatched #endif.
I just donāt understand. As I said replace the multi-compile with a simple define and everything works great. So it must be something special with multi-compile. Tried in 4.3.4 and 4.5.0 no luck. So frustrating as it means iāll have to hand code dozens of shaders ;(
FYI
In Unity 4.3.4 using pragma multi-compile I get the error āShader compilation produced no results (compiler crashed?)ā.
In Unity 4.5.0 I get various pipe and file errors.
In all cases commenting out multi-compile and using define works great.
My code was just an example to show the problem. Its not an issue about materials, drawcalls or switching.
I have 5 different input modes for supplying the data (I just showed two in the example) each with two or three different algorithms that work on the data, all of which would need to work for standard Unity shader types (diffuse, specular, bumpdiffuse, bumpspec, reflection ā¦ etc), so the actual permutations become pretty big. Using multi-compile was an attempt to reduce the sheer number of shader versions iād have to write by hand.
Interestingly #pragmaās donāt seem to work when included from a .cginc file. When I put the #pragma surface directive inside a .cginc file Unity complained that it could not find a surface function reference (not exact wording). My guess is that a pass for #pragmaās is done before processing #include I find this inconsistent and was also inconvenient in my case.
did you try testing multicompile with the built in .cginc to see if there is the same error, if itās affected by file path? Unity - Manual: Built-in shader include files
sounds too advanced for me, i am curious about what code constructs you are arranging, multi compiles with different cgincās sounds like alot of code being permutated.
Thatās true, iāve found the same thing, iād even go as far as suggesting that no pragmaās may exist in include files, since none that Iāve happened to try have worked (e.g. only_renderers or exclude_renderers).
I donāt think file path has any bearing though.
For now I guess iāll just have to accept that multi-compile simply doesnāt work correctly when trying to use its defines to decide which includes to add.
If you can reproduce this in a very simple setup (just color shader, two includes, two multi_compile options) then Iād say submit a bug reportā¦ you can also try this workaround āwhich, based on your observations, should workā to ājust get on with itā:
Iāll be damned if I could understand any shader theory that was going around in this thread (pretty new to the stuff) but the fact that the answer was a mistake like this tickles me lol.
Nice work anyways would be cool to see some screens of the results?
