Jump to content


Effects algorithms and shader implementation


17 replies to this topic

#1 Gnarlyman

    Valued Member

  • Members
  • PipPipPip
  • 109 posts
  • LocationMilwaukee

Posted 20 May 2012 - 07:29 PM

Sorry for the small mass of questions in a row here on the forum...at Starbucks brainstorming/studying, have a bunch of curiosity and questions swimming around.

So. As a photographer who uses, of course, photoshop and its myriad of layer and effect styles, I've been increasingly curious of late if the algorithms that drive layer styles and filter effects can be a)known/accessed (I.e., I assume they're not patented and are generally known?), and b)be implemented in shaders? If so, could creative uses of a few passes within a shader be used to, in effect, produce layer styles, blending styles, effects, etc. as is done in Photoshop?

#2 rouncer

    Senior Member

  • Members
  • PipPipPipPip
  • 2722 posts

Posted 20 May 2012 - 07:56 PM

a- i think youd have to come up with the algorythms from scratch, but you can look as much as you want before you implement, theres no law against that.

b- indeed yes, in a parallel type way, which will give you more performance than photoshop, but youll have to code them in a way so all the fragments can be calculated at the same time (which is how pixel shaders work)
you used to be able to fit a game on a disk, then you used to be able to fit a game on a cd, then you used to be able to fit a game on a dvd, now you can barely fit one on your harddrive.

#3 Reedbeta

    DevMaster Staff

  • Administrators
  • 5306 posts
  • LocationBellevue, WA

Posted 21 May 2012 - 06:28 AM

It depends on which specific Photoshop features you're talking about. For some of them it's well known how they work and you could implement them yourself, e.g. Gaussian blur, render clouds, levels adjust, and basic layer composition. For more sophisticated effects it's some proprietary algorithm, so as rouncer says you'd have to observe what it does in various situations and try to guess at how to implement it, which might be very difficult. And I'd wager that a lot of the more sophisticated Photoshop effects are patented or patent-encumbered somehow...the crazy world of software patents being what it is in the USA today.
reedbeta.com - developer blog, OpenGL demos, and other projects

#4 rouncer

    Senior Member

  • Members
  • PipPipPipPip
  • 2722 posts

Posted 21 May 2012 - 06:34 AM

Note, the brushes themselves can be performed by the pixel shader too, as well as the filters.
you used to be able to fit a game on a disk, then you used to be able to fit a game on a cd, then you used to be able to fit a game on a dvd, now you can barely fit one on your harddrive.

#5 geon

    Senior Member

  • Members
  • PipPipPipPip
  • 939 posts

Posted 21 May 2012 - 10:17 AM

View Postrouncer, on 20 May 2012 - 07:56 PM, said:

you can look as much as you want before you implement, theres no law against that.

To be pedantic, in some jurisdictions (the US?), you cannot legally implement the algorithm if you have studied how the original software does it. It is, however, still legal to do "clean room" reverse engineering, where one person studies how the original works, and writes a detailed specification of exactly what it will produce, and a second person writes the actual implementation.

It's silly, I know.

#6 TheNut

    Senior Member

  • Moderators
  • 1699 posts
  • LocationThornhill, ON

Posted 21 May 2012 - 11:05 AM

If you're interested in learning the blending modes, you can read about them and get their formulas from the SVG Compositing Specificaiton. As for filter effects, some are well known and discussed (blur, sharp, emboss, normal maps, noise), others are not. Generally though, you don't need to know how someone else did it. It's best to learn the basics like colour curves, HSL and HSV colour mapping, gamma correction, blending modes, and so on. Once you have the basics, you will have your toolbox for creating new effects and it will continue to grow. Anything mathematical (lens distortion, swirls, pinching, etc.) is public domain and dirt easy to implement. So whenever you see something and think there's a formula to do it, there probably is.
http://www.nutty.ca - Being a nut has its advantages.

#7 Gnarlyman

    Valued Member

  • Members
  • PipPipPip
  • 109 posts
  • LocationMilwaukee

Posted 23 May 2012 - 01:43 AM

Hey, thanks everyone, awesome. Er, well, obviously not easy stuff, but great information nonetheless. So...for instance, in a modern AAA game, how advanced do the shaders get/how much of the actual polished look gets done via some really pro shaders? Or, is it simply the fact that these dudes who make them are on huge dev teams with the best software available? Like I just asked on another post, I've been wondering lately as to the exacts reasons-slash-technical whatnots that make the big games "look the way the do" when, in essence, us indies have the same toolsets and coding techniques at our disposal.

#8 rouncer

    Senior Member

  • Members
  • PipPipPipPip
  • 2722 posts

Posted 23 May 2012 - 11:51 AM

most shaders are really simple, because authors dont want to hurt the gpu, simple solutions often work well enough already.
Learning real time is often more simplified logic than the offline counterpart, take subsurface scattering for example, sure, you can use importance sampling http://www.google.co...DuubwLsviegIVHg but just blurring results in a similar effect for way less computation. http://lesterbanks.c...tic-human-skin/
you used to be able to fit a game on a disk, then you used to be able to fit a game on a cd, then you used to be able to fit a game on a dvd, now you can barely fit one on your harddrive.

#9 Reedbeta

    DevMaster Staff

  • Administrators
  • 5306 posts
  • LocationBellevue, WA

Posted 23 May 2012 - 06:54 PM

Shaders can get pretty complicated. We had a total of ~75K lines of shader code in Infamous 2. (That includes blank lines, comments, annotations, and a lot of boilerplate forced on us by the shading languages, but still...it's a lot of code. :))
reedbeta.com - developer blog, OpenGL demos, and other projects

#10 Reedbeta

    DevMaster Staff

  • Administrators
  • 5306 posts
  • LocationBellevue, WA

Posted 24 May 2012 - 04:46 PM

Uhm, steave, want to add some context for that paper abstract you posted? What does that have to do with the rest of this thread?
reedbeta.com - developer blog, OpenGL demos, and other projects

#11 geon

    Senior Member

  • Members
  • PipPipPipPip
  • 939 posts

Posted 24 May 2012 - 06:39 PM

View PostReedbeta, on 24 May 2012 - 04:46 PM, said:

Uhm, steave, want to add some context for that paper abstract you posted? What does that have to do with the rest of this thread?

It's probably a spambot of some kind. I've seen that a lot lately, seemingly generated content, just barely relevant to the discussion. I think it might be an attempt to build up a more credible history before posting the spam links. Google is obviously working hard to identify spam on forums.

#12 Reedbeta

    DevMaster Staff

  • Administrators
  • 5306 posts
  • LocationBellevue, WA

Posted 24 May 2012 - 07:19 PM

Yeah, you're probably right. I deleted it. I don't get it though. There were no links in his post, signature, or user info. Maybe the idea is to come back and add those later. It's weird.
reedbeta.com - developer blog, OpenGL demos, and other projects

#13 Alienizer

    Member

  • Members
  • PipPipPipPip
  • 435 posts

Posted 24 May 2012 - 07:33 PM

I had a board a year ago where spambots hit me hard. It was reading the posts and made up its own post from the content, and it kind of made sense at first, but not smart enough. One day, spambots will have full vocabulary AI in them, and you won't be able to tell if it's spam or not.

#14 Reedbeta

    DevMaster Staff

  • Administrators
  • 5306 posts
  • LocationBellevue, WA

Posted 24 May 2012 - 07:44 PM

View PostAlienizer, on 24 May 2012 - 07:33 PM, said:

One day, spambots will have full vocabulary AI in them, and you won't be able to tell if it's spam or not.

http://xkcd.com/810/ ;)
reedbeta.com - developer blog, OpenGL demos, and other projects

#15 Alienizer

    Member

  • Members
  • PipPipPipPip
  • 435 posts

Posted 24 May 2012 - 07:49 PM

:lol: :lol: :lol:

#16 Gnarlyman

    Valued Member

  • Members
  • PipPipPip
  • 109 posts
  • LocationMilwaukee

Posted 26 May 2012 - 04:08 AM

You worked on Infamous 2 Reedbeta? Gnarly.

So, Reedbeta, are such complicated shaders out there for usage for a fellow like me who really doesn't have the mad skillz at this point to code them by hand? Or, are such shaders as the ones you used for such a AAA title kept behind some amount of lock 'n key from indies like myself? I'm trying to develop an asset library right now, focusing on shaders in particular. It'd be great to have some high-end ones.

#17 Reedbeta

    DevMaster Staff

  • Administrators
  • 5306 posts
  • LocationBellevue, WA

Posted 26 May 2012 - 05:45 AM

I don't know of a library of open-source shaders like that, but I'm sure some exist. I think TheNut had some suggestions in one of the other threads? But in any case, shaders tend not to be all that portable from one engine to another, for some reason. The algorithms are portable, but the shader code itself isn't, due to many differing details of how the shaders are hooked up to the engine and how the renderer works. And most of the algorithms we used for Infamous and Infamous 2 were pretty standard, e.g. Blinn-Phong shading, SSAO, etc. Actually, a good deal of the complexity came just from supporting many minor features to make life easier for our artists. For example, on almost any of our shaders you can turn on an optional color shift that alters the colors in the texture - for instance, you could turn a red brick wall into a green one or something. The artists use that to add variation to the textures without actually adding more textures (which would take up more memory, which is very precious on a console). They'd have one brick texture and use the color shift to make different colored walls, instead of having 5 different brick textures in various colors. Many shaders also supported things like skinned characters, UV scrolling, texture atlases, having multiple texture layers blended together, emissive textures, etc. There were some special ones like subsurface scattering for skin and anisotropic shading for hair. All of our shaders have to work in Maya as well as in the engine, so in many cases there was some code specifically for Maya in there. There were shaders for applying postprocessing effects like fog, DoF, bloom and color correction (using fairly standard algorithms). And there were a bunch of shaders for basic operations like resizing an image, clearing a render target or doing a Gaussian blur (you have to implement such things yourself on a console; they're not built into the API, since it's so low-level). It adds up to a lot, but the majority of it isn't rocket science. :)
reedbeta.com - developer blog, OpenGL demos, and other projects

#18 Vilem Otte

    Valued Member

  • Members
  • PipPipPipPip
  • 345 posts

Posted 29 May 2012 - 03:15 PM

Sadly I haven't worked on such large games like Infamous or Infamous 2 ... but in our technology we do it the other way Reedbeta does.

Though the shame is, that we're still missing editing tools (and mostly we still have the tools in development) - we offer artists to create zillion x zillion pixels megatextures - while this says, that our artists can actually do as big textures as they want, there are still some major problems (F.e. how to create such big textures with standard editing tools like 3ds max, mudbox, etc? - some 16k x 16k - good, but!). So in our last project we actually used only standard 4k x 4k and some 8k x 8k textures which actually did fit into VRAM - megatextures weren't used at all :huh: (and I spent so much time figuring out how to make them faster and faster :ph34r:)

Of course it really depends on what are one targeting (I doubt this solution would work well on consoles, in fact we only target PC - Linux (primarily) and Windows (secondarily) platform in our current project.

Note. that in our current project, which is really funny, we might also not actually use megatextures again. I hope that everything will go according to plan and I'll have something quite large to show during the summer. :ph34r:
My blog about game development (and not just game development) - http://gameprogramme...y.blogspot.com/

If you don't know how to speed up application, go "roarrrrrr!", hit the compiler with the club and use -O3 :D





1 user(s) are reading this topic

0 members, 1 guests, 0 anonymous users