Using a shader for both image effect and textures

[Noisecrime]

Hi,

I’ve been playing around with various image filters and coding up shaders for them. In many cases the filter would work just as well for materials on meshes as it would as a full screen Image effect. However for Image effects the shader pass states for culling and depth is normally set up as ‘ZTest Always Cull Off ZWrite Off’ presumably for the most efficient rendering. Of course these settings are not desirable when rendering meshes.

The easy solution would be to simply duplicate the shader, have one for Image Effects and one for general mesh rendering with different settings for the pass states in them. Trouble is that means duplicating the full shader code making it more awkward and prone to errors when updating as you have to change two different copies.

Is there some ‘clean’ method to accomplish having a single code base that is used in multiple shaders, where only the pass states of culling and depth setting are changed?

[Aras]

@Noisecrime

Is there some ‘clean’ method to accomplish having a single code base that is used in multiple shaders, where only the pass states of culling and depth setting are changed?

Currently, a workaround would be to create two shaders, but put most of the “actual” HLSL code into a separate include file. So you’d still have the Shader,Properties,SubShader,Pass etc. bits duplicated (almost), but what’s inside of CGPROGRAM blocks you could just #include.

That said, just last week I’ve landed a feature into trunk where things like blend/cull/z/… states can be driven by material properties. E.g. you could have “ZWrite [MyWriteFlag]”, and MyWriteFlag would be a float property, where zero means “off” and non-zero means “on”. With any luck this should ship in Unity 4.3. So not terribly soon, but not far away either.

[Noisecrime]

Thx Aras.

I think for now in most cases I could definitely get away with using an 'include as you suggest. Its not very tidy but it sure beats having duplicate versions of the same code around.

The new 4.3 feature sounds great though, look forward to using that.

[Lulucifer]

@Aras

That said, just last week I’ve landed a feature into trunk where things like blend/cull/z/… states can be driven by material properties. E.g. you could have “ZWrite [MyWriteFlag]”, and MyWriteFlag would be a float property, where zero means “off” and non-zero means “on”. With any luck this should ship in Unity 4.3. So not terribly soon, but not far away either.

That would be gorgeous:smile:

[Reanimate_L]

@Aras

Currently, a workaround would be to create two shaders, but put most of the “actual” HLSL code into a separate include file. So you’d still have the Shader,Properties,SubShader,Pass etc. bits duplicated (almost), but what’s inside of CGPROGRAM blocks you could just #include.

That said, just last week I’ve landed a feature into trunk where things like blend/cull/z/… states can be driven by material properties. E.g. you could have “ZWrite [MyWriteFlag]”, and MyWriteFlag would be a float property, where zero means “off” and non-zero means “on”. With any luck this should ship in Unity 4.3. So not terribly soon, but not far away either.

4.3??? 4.2 is not even released…is there a link so we can see the changes log of the future update?

[Aras]

@Reanimate_L

4.3??? 4.2 is not even released…

4.2 is all but “done” as far as features go by now; we’re polishing them and fixing bugs. So all the “feature development” that goes on right now is for 4.3 or later.

is there a link so we can see the changes log of the future update?

On our internal wiki, yeah Otherwise, we’ve kind of learned to not pre-announce features unless we’re really sure they will ship. Remember the GUI story, right?

[jchow]

Hi! Did this feature ever make it into 4.3?

[EDIT] And would there be a way to modify the stencil parameters like the reference value, actions, masks, and comparison?