Comments on: Shaders must die

By: Aras Pranckevičius

Aras Pranckevičius — Fri, 22 Oct 2010 17:04:53 +0000

@eatit: you’re taking “shaders must die” a bit too literally. All I’m trying to achieve with this is to not force the user to write boring, repetitive code to handle lighting/shadows/etc. In each & every shader you do (95% of the time of course), you’d add exactly the same code to handle those things. There’s no reason whatsoever to write that code when it can be automatically generated. Which is exactly what Surface Shaders in Unity 3 do.

If you want to write raw vertex/pixel shaders without this helper thingy (surface shaders), more power to you.

By: eatit

eatit — Fri, 22 Oct 2010 16:18:16 +0000

This is the most absurd piece of horseshit I have ever read. The programmable pipeline is one of the most important graphics developments in the past decade. Just because an individual does not have the mental facilities to understand how modern computer graphics actually work, it does not mean that we can propose for eradication of amazing features. This is the biggest problem with abstraction platforms like Unity, they encourage people to ignore what is actually going on in the hardware in favor of some proprietary crutch. It leads to poor programming, inefficiency, and it removes the retard-filter from the game industry.

By: Unity Technologies Blog » Blog Archive » Unity 3 technology – Surface Shaders

Sat, 17 Jul 2010 12:39:05 +0000

[...] a year ago I had a thought that “Shaders must die” (part 1, part 2, part 3). And what do you know – turns out we’re doing this in Unity 3. We call [...]

By: Jashan

Jashan — Sat, 27 Mar 2010 15:50:28 +0000

It’s awesome that at some point in time (me hopes 3.0 ;-) ) Shaders (in the old form) *will* die – at least in Unity. I totally see your point with the abstraction levels and I’m really looking forward to “working on the abstraction level needed for the problem at hand”. So far, I found shaders “somewhat esoteric” and my feeling is that the reason for that is exactly that I have to dive into an abstraction level I’d just rather not have to deal with. I also don’t write my own engine in C++ and instead use the convenience of Unity and writing down my game logic in C# for that same reason – it will be an awesome day when this will also work for materials (with the possibility of always “doing the really complex stuff” if so needed).

By: Marc

Marc — Mon, 15 Mar 2010 22:57:57 +0000

As if a node based shader authoring environment is any better than using the shader language directly.
To me an optimal solution would be ShaderLab / Torques Material System with the possibility to hook in own shader functions for specific “slots” so pretty much a bit like the logical seperation of the work instead of the hardware dictated seperation of it.

Such a system works for all kind of users and is flexible to extend yet easy enough to allow any kind of user working with it and on top of that it allows teams to create their own editors on top to work with it if they want to.

The above mentioned OSL is a nice idea but a decade too late at least out of my view. With all the high level shader languages and the shader authoring tools I don’t see a reason for it at all.

By: Aras Pranckevičius

Aras Pranckevičius — Sat, 23 Jan 2010 06:18:04 +0000

Yes, OpenShadingLanguage has some very nice ideas. It’s more targeted at offline CPU rendering right now though.

By: Spudd86

Spudd86 — Sat, 23 Jan 2010 06:14:38 +0000

http://code.google.com/p/openshadinglanguage/

By: hornet

hornet — Wed, 03 Jun 2009 08:54:55 +0000

…a shader language as such, no matter the granularity, is the wrong abstraction layer for users. They need a nice graphical user-interface for materials, like the one exposed in ue3, and the one that almost made it into unity a couple of years back :)

By: Lost in the Triangles » Blog Archive » Shaders must die, part 3

Lost in the Triangles » Blog Archive » Shaders must die, part 3 — Sun, 10 May 2009 15:24:28 +0000

[...] the series (see Part 1, Part [...]

By: Lost in the Triangles » Blog Archive » Shaders must die, part 2

Lost in the Triangles » Blog Archive » Shaders must die, part 2 — Thu, 07 May 2009 21:35:55 +0000

[...] « Shaders must die [...]

By: ReJ

ReJ — Thu, 07 May 2009 07:52:08 +0000

Jad: I would not call it repeating, it’s something TODO :)

Number of engines actually do that already. But definitely a TODO for Unity.

By: hcpizzi

hcpizzi — Wed, 06 May 2009 10:55:48 +0000

I can’t but agree with you. As you say, it’s old concepts, but not too widespread in the realtime arena.

I’d like to implement this at some point. I like to think of it as “declarative shaders”, in contrast to current “imperative shaders”. As with declarative programming, you express WHAT you want, and not HOW you want it.

As you mention, with this approach you can even test different variations, depending on where you run each piece of the puzzle and how you combine them, so as you say you can move from a forward renderer to a deferred just by instructing the tool to do so.

And you can even output the final shaders for hand tuning and optimization if you want to get the most out of them!!

By: Aras Pranckevičius

Aras Pranckevičius — Tue, 05 May 2009 16:55:43 +0000

@Jad: Renderman Shading Language has separation of surface, light, volume, imager and displacement shaders. So yeah, I’m only repeating what has been invented ages ago.

By: Dock

Dock — Tue, 05 May 2009 13:55:56 +0000

I could happily live without “shaders” as we know them. Too many programmers I know enjoy the fact that they keep artists ‘away’ a bit too much.

By: Aras Pranckevičius

Aras Pranckevičius — Tue, 05 May 2009 13:21:00 +0000

@tulcod: whoops, fixed. Yes, I’m not proposing changing the shader language, instead I want to use some “higher level language” that has backends for various hardware shaders. This “higher level language” should not be tied into how the hardware operates though (for most uses).

By: tulcod

tulcod — Tue, 05 May 2009 13:17:35 +0000

“Most of this can wrong” ??
?
??!

proofread your articles better next time ;)

i kinda agree with you, btw: shaders aren’t in an ideal state right now. but i don’t know if changing the shader language would fix this. rather, there should be some kind of compiler which compiles what you propose to the shaders we’re used to. this compiler could later be extended to support raytracing and all that. i think this makes more sense, since it doesn’t stop you from using traditional shaders, which can be very powerful