Comments on: Shaders must die

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