Here for Unity 5 we’re wondering… should we remove some functionality from “fixed function” shaders in Unity 5.0? Specifically, we’re thinking about:
Remove TexGen support (things like “TexGen EyeLinear” on a texture property)
Remove texture matrix support (things like “Matrix [_Foobar]” on a texture property or SetTexture). This would also remove UNITY_MATRIX_TEXTUREn from actual shaders.
Remove some of more obscure SetTexture combiner modes (dot3, dot3rgba, signed add)
Reasons for why:
Some of that (specifically texture matrices) do incur quite some performance cost in our rendering stack. Even if nothing uses them!
All of the above is not widely used, but is quite a lot of code to maintain for each and every platform.
Yay/nay? Discuss.
Update: looks like the public has spoken. I’ll be removing these things (fixed function texgen, fixed function texture matrices, more obscure texture combiner modes). Yay, something like 2500 lines of code gone. Me likes.
Why is there even still ANY fixed-function stuff in Unity ShaderLab… ditch all of it, I say. Before Unity 5 is out next year, even the last GL-ES 1.x or OpenGL 1.x or DX7 devices remaining somewhere deep in the steppes of Mongolia will finally have died.
We already don’t support fixed function GPUs (DX7/GLES1.x). So “fixed function” shaders in Unity are essentially only a syntactic sugar - since they are really much shorter to write, if all you need is some really simple stuff. We’re thinking of leaving them in for simple stuff, but removing more exotic features (listed above).
I see no direct reason to keep them alive, given that (unless I forgot one) Unity 4.3 removed the last FFP graphics API from support anyway.
For some of the stuff, a simple shader macro would be welcome though depending on what you add to the ‘to remove’ list on top of what you have there (cubemap UVs, …)
What I consider somewhat harsh though is calling dot3 obscure, given its relevance on OpenGL ES 1.0 platforms (though that was partially neutred due to Unitys lack of stencil buffer support back then and lack of inbuilt shader that used it, which I personally never understood)
If one targets a low end mobile gadget, he should take things in hand and use cg shaders to do specific optimisation as much as possible.
I personally never used fixed function shaders with unity.
So, ditch them all.
I’m not a shader master, but I find ShaderLab syntax pretty painful. I’d love to remove most of the ShaderLab syntax to be honest. My recommendation would be to put more of the functionality of the shader onto the material/shader inspectors. Also automatically propagating material properties into the CG program would be nice as well.
3 ways to do the same thing is just too much (surf and vert/frag should be enough).
Eventually, I expect that most of this stuff would be handled by the über shader.
Since fixed function is gone, I would favor stripping all fixed function out and providing a simple upgrade guide with Cg snippets for the more “tricky” things fixed function does for you. Things like TexGen CubeReflect/SphereMap to assist people who were relying on those.
Yes, for an asteroid shader for a cold-call project pitch. This was before OpenGL ES 2 was a good option, so it’s irrelevant now.
@metaleap Hmm, I wrote that at 3am but what I was trying to convey not make sense?
What I meant to say is most of the settings that I use (Queue, ZTest/Write, BlendFunc, Stencil) could honestly be served by a custom shader inspector that auto-generates code and then double clicking a shader could just bring you to the auto-generated Shader allowing you to tweak the auto-generated shader.
I think you should remove everything that you’re just going to be translating into programmable pipeline languages anyway. There was a time when supporting fixed function was necessary or even had advantages over the programmable pipeline. Now it’s just another potential source of confusion for people learning to write shaders in Unity.
To be honest, I’d remove surface shaders too. Not only are they slow and inefficient but they’re also another source of confusion. Instead I would introduce more macros for Unity-CG. I would also kill off GLSL too (but obviously you compile to it), and leave one single clean shader language with maximum speed and flexibility, with the focus being on tools like shader forge.
I want Unity to focus on one shader language, and one single unified api for it. This will enable tools like Shader Forge to get more optimised, ultimately matching UE4’s node shader approach or going beyond.
So in my fantasy unity world there would be just Unity shaders, and Unity Compute Shaders.
Think big, be bold with your vision.
I don’t want old stinky poo lying around in Unity 5. I want a lean, mean fast and clean shader pipeline. People will mostly use Universal shader anyways, and there’s shader forge. Far better to clean up the docs with as well. Hell, some platforms don’t even work with fixed function shaders, and fixed function means people think they’re doing less typing. If you’re doing less typing and that’s the problem - use shader forge for gods sake.
Unity needs to mature and sometimes that means not spending time with old toys.
Actually - recently I was thinking of using sprite color as the light direction so that I could have a lot of normal mapped sprites without necessarily incurring a massive overhead (think DX7), but it was so klunky and frankly a bit ugly, I dropped it. I’m not sure it would be faster really? The concept was to avoid pixel lights.
In any case whenever unity asks the question “should we do this for speed?” the answer is always yes.
If anyone’s on the fence then next time your game is slow don’t come crying
Where’s your latest benchmark for this assertion? I’m just wondering because as far as I know either the GPU driver (on desktop) or Aras’ shader optimizer (for mobile / GLSL in general) would ultimately strip unused variables, inline functions, remove unreachable code etc…
I think Surface Shaders are pretty great… I mean I do custom vert/frag throughout myself, but I’m decidedly a freak… for people who want to get a project Done instead of tinker away somewhat aimlessly for years like I admittedly love doing, Surface Shaders are pretty damn cool!
Big fat nope from me. And again a case where I’m not myself a user of the feature in question but still have what I think is well-reasoned opinion: generally in terms of philosophy, I think Unity has to remain highly “hackable”. This is what keeps attracting me to it and stops from another futile and ultimately doomed attempt of writing an own renderer. There are indeed fringe use-cases where targeting only GL and handwritten GLSL may be imperative. I would even go further and say, give us much broader “#pragma -at-my-own-hackety-risk” access flags, not just pragma glsl but even pragma GL4-with-this-glsl-version-and-those-extensions. Some projects do totally warrant this, but wouldn’t quite warrant writing a completely separate engine (with parallel renderloop, cullings, etc. all the other non-shading-related machinations that Unity does well enough).
Guess what, people still can use ShaderForge, they still can use Surface Shaders, they still can use the new “standard shader”. But why artificially close already-half-open doors to some hacky fringe needs that no CryEngine or UnrealEngine would enable… so that newbies are less confused? That’s part and parcel of the “newbie learning ladder” we all need to climb. They are clearly instructed to use surface/standard shaders or else face the abyss of learning as you go
PS Vita and Mobile. Take your pick. If you’ve released much you’ll just know it’s night and day in performance. I wish it wasn’t so, but it is, but that’s logical because surface shaders do a lot of extra work. It’s nothing to do with optimisation. And your comment of tinker away aimlessly for years is redundant, it means you completely didn’t understand what Macro meant. It means you can pretty much code exactly the same as surface shaders, just with a clearly defined frag and vert. But then, that’s kinda what surface shaders are. But wrapping with magic code has limits, and ultimately that’s more overhead for Unity, instead of Unity just focussing on speed.
If you’re one of those people who believes coding a shader for longer than 10 mins is tinkering aimlessly, then perhaps you’d get a lot better results with shader forge (which doesn’t generate surface shaders).
So you don’t in fact, know what you’re commenting on? They are to all intents and purposes identical at the end, so one of them is pretty much redundant. In fact as far as I know, nobody actually uses GLSL directly any more. There’s no point. In this case cg->glsl is really nicely optimised. Given that cg is cross platform and GLSL isn’t, Unity should adopt and expand one of them to maturity and compile to the other.
I’m all for flexibility but when you’re so open minded your brain falls out, there’s no focus there and certainly no time to bring them all to an optimised maturity. I’m personally tired of how Unity is spread thin, and would like a sharp sword instead of a collection of rusty knives.