Actually, the reality is exactly how I mentioned it, because the shader workshop holds you hand and takes you step-by-step through writing a normal mapping shader. Want to extend that with dynamic lights? The manual gives you a function you can copy into your code.

Except for a few exceptional cases, shaders don't take much time at all. I do everything in KarBOOM, and the shaders have had very little impact on development -- only a few days altogether, including rewrites as my needs change, and I've been working on this since September last year (although with some interference from university).

Between the shader workshops, the manual's great examples, and the way materials work and can be strung together in Gamestudio, it truly is very easy to learn to write shaders -- more so than in other engines.

Unity provides automatic dynamic lighting, for example, and because of that shaders have to be written in an unusual way, and the result uses unnecessary passes (although I don't know how it works with the new deferred renderer). It provides a global shadow system, but last I checked that was just CSM, which I've written a short tutorial for on my website.

I'm not suggesting teams need shader programmers, I'm saying if you have a Lite-C programmer with Commercial or Pro, you should already have a shader programmer.

Jibb

Again, it is way easier to drag a few nodes to a surface and to connect them. I just did it in Vision3d and I did it in C4 and UDK. There is a simple lighting node with connectors for Diffuse, Normal, SpecularColor, SpecExponent, SpecMultiplier, Opacity and AmbientColor. And I can drag TextureNodes or Constants or whatever to it.

I create shaders in minutes there and I dont have to care about the number of lights, fog, static or dynamic lighting. The lighting node contains all this. There are some general flags to activate alpha testing as an example.

But in the end an artist can create powerful shaders that way. And there is no exponential explosion of shaders for every number of lights.

And a workshop is even not necessary. It is very intuitive especially since most artists already know such node-editors from their 3d rendering applications.

Here are some images of how it works in Lightwave and in UDK. There is acutally no difference between realtime and still-rendering applications. It just works. And that is how most projects do their work, how most applications are built. So I said that this is how reality is today.

I guess it's a matter of preference -- programmer versus artist. I'd no sooner choose to click together a shader over writing one than click together a game rather than make something original.

Node-based is great for simple materials. Engines that provide such a system make it easy to meet some industry standards. But what is one to do when they want a multi-texture shader where some layers cast some shadows on others, some layers have true reflections, and so on?

Writing one's own shaders is good for performance, as well. Even for a more standard multi-texture shader, if only two layers need a specular map, I'll write a shader that only uses a spec map for those two layers.

Even the simple stuff I do differently every time for different projects. Maybe in one project I have an AO map, which will only affect ambient lighting, but in another project I can't be bothered and I bake AO into the diffuse texture. Or I might hard-code some hemispheric ambient lighting -- very little performance cost, but it can really add some shape to areas in shadow. These are simple, intuitive, artistic tweaks that aren't all going to be doable in a node-based editor.

I wouldn't start a project in another engine without learning to write my own shaders in that engine. Custom-made shaders get a better performance:prettiness ratio.

As it turns out, I also create shaders in minutes. And then I can spend hours tweaking them if I need to, adding things and changing things, and see the changes updated in real-time. Code is easy to reuse by modifying default.fx: I might have my own fog function that uses a cube-map rather than a single colour to get a good-looking atmospheric scattering effect in a sunset -- I'd write the function once and from then on call "niceFog(pos)" in any shader that uses it.

Jibb

But the difference is: Your shader will be very special, working on a certain amount of lights and on one platform only. The abstract node based way supports different platforms.

Besides that it is not only a programmer vs. artist point of view like you mentioned. The Vision engine as an example also has a dedicated low level shader editor aimed to programmers with a good shader code editor (with 3 pages for global settings of the library, vertex and pixel shader). There are pannels forthe shader library files of the engine, panels for global shader properties, enlisted effect hierarchies and a real-time preview of course.

Besides that they recommend to also load shaders from artists into this low level editor later for optimizations. So it is not an artist vs. programmers story, it is often a story of collaboration.

Anyway, most projects especially indie projects will not create many custom shaders on their own. All the basic shaders are already included (yes, terrain shaders as well). And there are good reasons for that.

If more people would realize how important shaders are, this would most probably change.
The problem is that most think that shaders are just for some eye candy stuff and forget/don´t know that they actually are an important part of the rendering pipeline and are needed to see anything at all.
The power of shaders mostly comes by writing many very specialized shaders doing just exactly what they need to do, instead of just few master shaders slowing things down by doing something without effect.
In my opinion every project needs someone able to program custom shaders, which btw is something artists usually are not good at with node based editors as they tend to make things too complex . At least that is my experience so far.

This might be true for absolute beginners, but even without any shder writing I am able to select a material without spec and without normal mapping as an example to render faster.

I would agree with you when it comes to mobile devices. But the engines I know also come with many dedicated shaders for each mobile platform. So it is already possible to select only the desired effect and not a master overkill shader.

As an example there is a normal mapping shader for iOS that has a fixed constant lighting position (one light only) to speed rendering up.

Besides that I am not sure what kind of "artists" you know of. But the ones I am in contact with all have a programming background and know for sure about performance issues.

What do you mean "one platform"? The shader will usually work on any Shader Model 2.0 or higher card. If Gamestudio supported Macs the shader will probably be written in Cg instead of HLSL, which is virtually the same thing except it works with OpenGL and DirectX.You were talking about how much easier it is to make shaders with node editors; I'm saying for someone like me it's actually easier to write them. I will always choose to write a shader in a few dozen lines -- less if I re-use stuff I've written before -- rather than use a node editor that's either too limited to do what I want, or too convoluted to be intuitive. Of course it's often a matter of collaboration when a team has enough personnel to do so, but that's just changing the topic.

No one is expected to be able to use Gamestudio without Lite-C. Why do people avoid HLSL like the plague? Shaders are IMO the easiest part of programming for these reasons:
1. They are short. In order to perform well, shaders are generally only a few dozen lines. The programmer will spend only a few minutes before they can see the effects of what they're doing, and from there they can make changes and see the changes as they're made in real-time.
2. They're simple. Until you start doing really fancy stuff, you probably won't touch loops, and you'll rarely use branches.
3. They are visual. Rather than a path-finding algorithm that needs to be tested under all sorts of circumstances, or movement algorithms that'll often fail in very specific cases, shaders will either look right, or look wrong. And it doesn't take much to make a scene look fantastic.
4. HLSL is intuitive. Forget vec_add and the like. Just add, multiply, subtract, divide with simple operators. Most functions work this way, too. For example: light.rgb += ambient.rgb; adds the corresponding components together. colour.rgb = colour.brg; swaps around colour channels.

IMO the lack of a visual shader editor is a hindrance only to those with no programming experience. I can only imagine how poor KarBOOM's performance would be if its shaders were put together in a node-editor and used the built-in effects of Unity, for example.

Jibb

That is your personal view and most developers see it exactly the other way around.

And what I mean with one platform: When working with a node editor I dont care about DirectX, OpenGL, HLSL, CG and so on. My algorithm works on all these platforms. Basically shaders are nothing like that, a couple of vertex and pixel operations and I dont see why a node based shader should have such a big performance difference. If that would be true, no professional engine would use it. UDK / Unreal as an example is very fast that way. So actually, without any testings I would not claim something like that.

There is for sure a difference, but I would not overestimate it hat much. I read such arguments often. C4 programmers as an example defend their C++ language at all costs. They always tell it is the best, fastest and whatever. But in reality I saw games programmed in Java as an example running big FPS worlds with huge terrains and interiors (Chrome as an example). Often people are too much focused on their tools instead on the final product that could be done with other tools as well.

But HLSL and Cg aren't platforms. They're languages. The only platforms (shader-wise) are DirectX and OpenGL -- HLSL only works on DirectX, which doesn't matter because so does Gamestudio; Cg works on both. One written shader will run on everything.
You should learn how to write shaders, then. Because I can make the claims I've made. The performance difference isn't big at all, depending on how you're willing to limit yourself (as I'll explain at the end of the post).
We've had FPS games since the early 90s. The graphics stuff is still done on hardware in OpenGL, so such an example says nothing about whether or not Java can replace C++ for game development, and as soon as the Java programmers try to push boundaries they'll find themselves going back to C++. It's a completely different scenario. Besides, what's that about people being too focused on the tools rather than the final product? The final product, whatever it is, can be achieved with Gamestudio -- Isn't the whole point of this discussion was whether or not Gamestudio is visually behind?

In terms of performance between node-based shaders and written shaders -- there'll probably be no difference between the exact same shader, but node based shaders are restrictive, and I don't care about built in effects at all. The only claims I made to a big performance difference was that KarBOOM would perform poorly if I tried to achieve the same thing with node editors and "industry standard" effects. And it is true:

How many games feature particle shadows? How many node editors will let you do that? Most shadow-mapping systems will use multiple views and depth-maps -- mine uses one view and a standard RGBA bmap that the particles also get rendered into for almost no extra cost. The whole playable field is one quad with a very unusual multi-texturing shader. The mix-map (or whatever one calls it) is generated by a series of post-processing effects based on the level data. The explosions are each a single sprite with a very fast shader generating the effect procedurally -- normals, internal lighting, sun-light, density, etc.

Jibb

You still did not get my point:

If a 16-year old ambitious boy starts to develop a game, he will learn a node based shader editor much faster than HLSL. He does not need to know the math behind it, how to format a variable, how to define a scalar, a vector, whatever. He does not know about what mathematical operation is faster compared to another and so on. He connects some nodes. And that is easier to understand. Because of that, they dont like to learn another programming language. There are alternatives.

Besides that small casual games like Carboom have a limited audience. It does not make sense to learn different languages and to write so much shaders. I know that you did not learn it in a few days. You gathered a lot of deep knowledge, hints and experience over years.
But to earn money with such a game, you have to finish it in a few months, just because such games bring only a couple of thousand dollars. But if such a game will be released on Windows only, it will probably sell even worse. It could make sense on mobile phones though.

Because of that you will not find many casual developers writing their own shaders. The other ones like Slin will find a dedicated job sooner or later in a game company and will write shader only there.

This tells us a lot. It will keep hard to convince hobby developers to write their own shader. You tried that a lot in the past. But when you convince somebody to write them and he will dive deep into this world, he will probably not finish a game but become a shader expert. If such an expert is willing to look into more than only Gamestudio. If he is similar to Slin, who looked into Irrlicht, Unity or iOS, then he has a a good chance to find a job in the industry.

This is acutally how the reality works.