This seems to imply that it IS possible to import precompiled shaders, at least those built within Unity. I just can’t see how it would be done, so I’m kinda stuck with an FXO folder full of precompiled shaders that I can use in DirectX/XNA but not in unity. This is effectively forcing my hand as regards choice of framework for my game.
Can anyone spell it out for me ?
Specifically…
What format and extention does unity expect when importing a precompiled shader as an asset ?
If I can’t import it as an asset, what format classes and methods would I need to focus on in order to build the shader from a precompiled shader binary file at runtime ?
I note that unity’s PS output is significantly different to what I’m used to under C#+DirectX. Would importing a precompiled shader be dependent upon the shader being specifically ‘built for’ unity, or can Unity make use of standard shaders such as those produced by ATI and NVidia’s shader development tools ?
If anyone could point me in the right direction I’d much appreciate it,
Unity can technically use precompiled ARB and D3D compiled vertex and fragment shaders, because that’s how it compiles Cg shaders itself. However, even if you surround your precompiled shaders with the appropriate bits of Shaderlab, it’s unlikely that they’ll work the way you want in Unity.
If you have one, just name it Compiled-Name.shader, put in your project and it will work (2.6.1 compiled shader will only work in 2.6.1 and 3.0 compiled shaders will only work in 3.0)
I agree with Daniel, even if you get them in there is little chance they work as each engine exposes different data etc, so something that works here doesn’t there, stuff that works in ATI / NVIDIAs shader composing tool won’t work in most places at all and stuff like this.
They are to develop the base, then you have to port it over to Unity shaders
Problem is, I’ve looked at the “compiled shader” output of Unity and it is essentially “shader ASM”, ie. readable - not tokenised. What I have is a binary shader… Essentially the same thing, but already tokenised.
So, I wonder, is it possible to get unity to expose the underlying interfaces, such as OpenGL or DirectX so that I could take over at some point in the BeginScene - EndScene - Present cycle and render ‘special’ objects by hand.
Is there a hook or event for doing this, perhaps in the Pro version ?
Failing this I’m probably going to have to forget about licensing Unity Pro and instead go with XNA.
I do see one way forward, at least technically: The shaders I have are useable under license but the source is not unless I buy an unbearably expensive source license… whilst I could disassemble the binaries and create an ASM version of the shaders using a “unity compiled shader output” as a general template - I feel sure this would break the terms of my licensing (reverse engineering, decompilation, etc)
No you can not inject shaders from outside, not even with plugins. The render pipeline isn’t touchable in any form. Even if it were, your shader wouldn’t work as it was written for a specific environment with specific expecations on setup etc which is for granted not the case as it would be a unity shader if it were written for the environment in question here.
So you can decide to get the shader in a usable form to port it for usage with unity or it won’t work at all I fear.
I am also sure that shaders from crysis imported to Unity won’t work at all.
The link you’ve posted (on unity answers) relates directly to using compiled Unity shaders.
There are 19 shaders, but only half of them could be considered well understood or general. There are some procedural effects for electrical damage, various shielding FX and some very pretty wormholes that I doubt I could reproduce as I haven’t a clue how they are done. They even got rid of my particle thrusters and now I have an amazing volumetric-looking effect in a cheaper time-based shader.
There is a very pretty set of effects for warps and jumpgates that I haven’t seen elsewhere. The blooms and regular ones with Bump/Refl/Spec/Emiss/Tint masks I could probably redo for unity as I’ve written similar in HLSL from modified examples.
But above all there’s also the small matter that I’ve paid for these effects, they work, they’re vendor agnostic, they have a well thought out fallback chain (aparrently) and remaking them (even if I could) would seriously cut into my time. They do work under DX though, so I’m thinking to keep unity for rapidly prototyping scenes, levels and gameplay but developing under XNA this time around.
Obviously they weren’t.
They were targeted at a very specific case and that likely was FX as used by XNA and if you use barebone DX, which means totally engine unfriendly commonly as general DX / OGL based engines can not handle such FX (or corresponding export to other shader envs) at all.
Thats unhappily a rather standard thing as engines for optimization purposes have specific setups in their pipelines and either the shader complies to it or it won’t work.
The only way to use “whatever you want” is writting your own engine or using one thats barebone enough to not be advanced where it would stop supporting it again too
That being said, I don’t see a point in vendor agnostic shaders that are not written for a specific engine, as they are just useless agnostic for any realtime engine usage. (its naturally different if you write an own engine to use them or if you can / intend to use them in a modeller that supports the shader type)