0
\$\begingroup\$

I'm quite newbie to shader programming.

I use Godot engine and after I see what can be done with shaders (eg. http://glslsandbox.com/e#53172.0) I realized that I MUST learn it no matter how hard it can be to understand the harder parts of it.

Till now I've used animated sprites or just make an animation in the animation editor.

I want to know if I gain perfomance by using shaders for example when I want to make a flag dragged by wind or I want to make something like in the example I linked.

I would think shaders are the fastest...but isn't it faster when there is a finished animation and you just have to make the game engine to use it?

\$\endgroup\$
  • 2
    \$\begingroup\$ The answer to "which is faster" is always contextual. A shader could be ALU-bound, where it's doing so much calculation to compute the perfect flag wobble that the simple shader cores can't keep up. A sprite animation could be texture bandwidth bound, where you're sampling so many different frames that the VRAM & texture cache can't keep up. So either one, in theory, could be faster or slower — depending on the total load on the various parts of your rendering pipeline at the time. But very likely, both options will be fast enough for your needs. The only way to know for sure is to profile it. \$\endgroup\$ – DMGregory Mar 8 at 12:45
3
\$\begingroup\$

Just because you can do something, it doesn't mean that you should. Shaders are amazing for making almost anything, but making those objects from scratch is more of a waste of time than anything.

The demos over at shadertoy and glslsandbox use these features because they can do it and they don't really have another option there.

Even if you could for instance create a flag with them, it would eat up way too much time of your life and it wouldn't really look any better than a sprite based approach. Combine this with slow/limited interaction between the CPU and the GPU and you'll have a hard time making a good game with this technique.

Most graphical libraries either have a built-in way to display animation or it's trivial using 2d sprites/textures. These give you a comparable result in seconds.

And yes, building procedural animation in shaders is slower than these. There's a reason bigger games don't use them as often (although as pointed out by DMGregory, games like Uncharted 4 do use this style of procedural animation). GPU cores are fast at basic things. Iterations and branching can slow them down a lot.

You should learn how to use shaders, yes. They're amazing, but if there are easier solutions, then go with those.

Using shaders also makes sure your future artists won't have any control over the animations you did. Updating them will take away precious development time from other places.

\$\endgroup\$
  • \$\begingroup\$ I'd quibble a bit with "use shaders for what they were intended for" - the whole point of a programmable graphics pipeline is that it's intended to do whatever you ask it to. I think it would be unnecessarily limiting to relegate shaders to "making objects feel real" when we can do so much more with them, and modern devices have the programmable graphics hardware there for us to use, whether we make use of it or not. So, I'd lean more to the side of "if there's something you want to do with shaders, try it!" and if performance problems arise, solve them once we know they're a real issue. \$\endgroup\$ – DMGregory Mar 8 at 14:29
  • \$\begingroup\$ @DMGregory I'll admit, rereading it now, the wording is quite bad and misleading. I'll give it another shot in a bit \$\endgroup\$ – Bálint Mar 8 at 14:30
  • 1
    \$\begingroup\$ "There's a reason bigger games don't use them" might also be misleading. AAA blockbuster games use shader animations extensively. Since OP mentioned wind-blown flags specifically, Uncharted 4 uses shaders to achieve this. Even where we do use texture flipbook animations for things like fire and smoke, it's not unusual to "amp up" these effects with a shader too. So while I agree with your point "you don't have to use shaders where a flipbook suffices," I think it's a bit overstated. \$\endgroup\$ – DMGregory Mar 8 at 17:33
  • \$\begingroup\$ @DMGregory I never said you can't, but given the experience he has with this stuff, it would not be advisable to do everything this way. And the way he worded the question gives me the suspicion that he wants to achieve almost everything using shaders. I'm only going against mindset \$\endgroup\$ – Bálint Mar 8 at 17:41
  • \$\begingroup\$ @DMGregory Although this might be only my opinion, but I don't think getting side-tracked and learning an entirely new skill from scratch and trying to do complicated tasks with it is not a good way to do gamedev \$\endgroup\$ – Bálint Mar 8 at 17:47
1
\$\begingroup\$

Performance-wise, direct pixel manipulation is almost always slower than the other techniques, because you have absolutely no hardware acceleration at all. Usually all the textures of your game live solely in the GPU RAM. Drawing a sprite somewhere on the screen is a pure GPU-internal operation. But if you want to do CPU pixel manipulation, you need to load the texture from GPU RAM into regular RAM, run your algorithm and then copy it back into GPU ram. That alone takes time. And then many common image operations are very parallelizable, so even the stuff you actually want to do likely runs faster on GPU than on CPU (but your mileage may vary, depending on what you actually want to do).

When it comes to choosing between pre-baked animation frames and procedural shader effects, you are dealing with a trade-off of computation time vs. memory. Cycling through different frames of the same animation is fast, but all the animation phases consume GPU RAM. A shader will likely take longer to compute the next frame (depending on how computationally expensive your shader is), but will use next to no video memory.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.