This surface shader thing is totally awesome!!!

When do we get a more comprehensive documentation about all this?

Right now I’m a bit frustrated as I feel somewhat limited to trial and error and copy/paste from other shaders to make it all work.

There are simple things that are probably obvious to you guys but that are not to newcomers. For instance, I couldn’t find a way to disable lighting altogether other than creating a custom lighting model that simply returns 0 (there’s gotta be a more efficient way to do that, right ).

The result is that I probably get shaders that are much longer than needed. Simple example: I couldn’t get a basic glass shader (transparent fresnel bump reflective cubemap, no lighting) to compile to shader model 2.0 (plain and easy writing the whole thing without surface shaders, but I definitely want to stick to your pipeline as much as I can).

Tks!!

It seems to me that geometry shaders and compute shaders are not very often used for “regular scene objects”, but more for special-purpose cases. And when we’ll have DX10/11, you could write your own, just like in Unity 3.0 you can write your own vertex & pixel shaders if that’s your thing. Just for 99% of the cases where you want to write a shader for a lit surface, using this code generation approach (surface shaders) seems to be much easier.

Tessellation in DX11 also seems like something that a shader author wouldn’t want to deal with in 99% of the cases when writing shaders for regular objects. Unless I want to exploit tessellation for some funky purpose, all I’d want to do is check “use tessellation” checkbox, and have everything else “just happen” for me.

@harmless: this is actually totally unrelated to GPU skinning.

@FXCarl: in a sense, yes. It’s also similar to OpenShadingLanguage as well. Why we didn’t go with either of those? Because they both are primarily targeted at offline / non-realtime rendering; and also because efficient & open compilers into actual GPU shaders don’t exist for them yet. With “surface shaders”, we aren’t inventing a new programming language at all; it’s just Cg/HLSL, so we can use existing compilers on the different platforms. We’re just generating “the boring code” instead of forcing you to type it.

Hope the “couple simple lighting models are built-in” are also built-in-to the documentation

@Minevr
Indeed, the shader horse died quickly. Wait… what!?

If you are not rolling any visual editor, I strongly suggest you put up a dozen or more tutorials on how to learn to edit shaders in Unity 3. I have limited knowledge on that side, what I learned come from the excellent book SHADERS for game programmers and artist. Even after that, complicated terms and medium to hard shader seems beyond reach. Do you have on your side have any book suggestions that we could benefit on to learn this complex area of 3d programming ?

I dabbled in Shader Programming for Unity 2.x but never really managed to get my training weels off so to speak. I just never found enough time to become intimate with a shader language during development. However, this looks to make shader programming a much more worthwhile investment of production time for small indy teams which is where Unity really shines.

- “when you declare a texture property (_MainTex), the UV sets are generated”… that was exactly my first concern. If each time you declare a texture property (_MainTex) a UV stream is generated, then I have no way to have 2 textures share the same UV set without wasting a whole uv stream (memory concerns here), as the second one will be generated automatically by the underlying engine.
Unless some clever work is done by the compiler through detecting inside the vertex shader that the second uv set if never really referenced by any instruction.
…Or unless uv stream get generated only if explicit uv set are exported (in the same channel order ?)

- About Syntax highlighting; I just thought that Unity 3 would integrate its own shader editor (without having to use an external one), like what Virtools guys did.
This isn’t a big concern thou, but because Aras introduce this formalism of “surface shader” inside Unity it’d have been nice to see the “irrelevant part” really grayed out in the editor (just like in this blog). So you don’t get confused
If there’s no integrated shader editor planed in Unity 3 then my question makes no sense obviously

-UVs: when you declare a texture property (_MainTex), the UV sets are generated. If you want access to these generated UVs, you must pass them as input to your surface shaders (uv_MainTex)(the name is important!). Then, tex2D takes in a sampler2D for the texture and the UV set that you want to use as coordinates.

-Syntax highlighting? The code that Aras greyed out are uninteresting as he clearly said “grayed out bits that are not really interesting.” The syntax highlighting in your editor is really something specific to your chosen editor. If your editor is highlighting functions and structs in Unity 2.x cgshader code, then it will be the same in Unity 3.x as the Input is just a struct, and surface and lighting functions are just functions.

- Ok, it seems I’m missing something with UV sets. I thought the float2 uv stream were generated (filled) by the engine automatically if a texture was declared in the shader code, but considering what you’re saying this isn’t the case… I just have to figure out how to declare a new UV set (RTFM

- Abut syntax highlighting, my concern was: is the part you wrote in grey in your example is supposed to be greyed in the shader editor also, or is there some nice and special colors to make it more readable, or is there no special treatment at all in wich case it is interpreted as standard HLSL while in fact it’s not really (like the CGPROGRAM, Tags or Properties words wich have special meannings).