[Elemental Shader Jam] Shallow Ocean

**UPDATE**


So, I cheated a bit and decided to make a shader in Unreal Engine 4. It's quite a bit of cheating since UE4 provides an awesome physically based rendering shading model to start with, and heaps and heaps of useful functions for you to use in your shaders without having to write them yourself, but I did learn a lot in the end!

I decided to make an ocean / watery globe with rocky islands and a little bit of transparency down into the water:





image

The shader has a dynamic parameter called Sea Level which you can control via script to change how much of the material is underwater and how much is above:

image
image

It takes advantage of a very cool function in UE4 called BumpOffset which does fake depth adjustment - like what they use for Parallax Bumpmapping. So the dark underwater areas look as if they are deeper than the lighter, shallower areas, when you rotate the ball around.

Here is the full Material Blueprint with comments:
http://i.imgur.com/j4QFFJw.jpg

Thanked by 1Elyaradine

Comments

  • Very cool! :D I (personally!) don't consider UE4 shaders cheating at all. I feel that the nose-based editor (the one they had in the UDK anyway; haven't tried the UE4 one) is fantastic for prototyping things without having to deal with syntax errors, and once you've got something that works in a node-based editor, optimizing it in code is somewhat* trivial imo. (*Not so trivial when you've got to test it on multiple mobile devices, but I don't think that's the point of the jam anyway!)

    One thing that I've always hated about having to do ocean/shore shaders in our games at work is how to get the frothing of waves convincing, especially the waves as they get close to the shore. Perhaps you could work on a way to get that in too? :)
  • Thanks! Originally I wasnt even going to have rock coming out of the water, but I thought it would be a cool excercise, so I havent explored shorelines fully, but I'll give it a try tonight and see if it looks any better!
  • OMG what, NODE BASED SHADERS!?!? So, you can what, drag and drop? Move things around? I want to hear more about THAT!! :D
  • Strumpy shader editor is a fantastic prototyping tool. But beware it uses surface shader which aren't great for performance.

    Now can someone tell me what the buzz word physics based shaders/rendering means? I don't actually know ;)
  • In terms of art, it's a way of working that's much more similar to offline rendering than in traditional game art. So where in game art you usually bake in your lighting, or bake in ambient occlusion, or you hand paint a bunch of light-based details, in a PBR workflow your shader handles all of the lighting for you. And if the PBR is energy conserving (which is usually the case), you can be sure that your material will never have a result that is brighter than the light that's shining on it, the way it works in the real world. But it also means that you can look up values of things in tables, and expect the same values to look the same in your game engine as you'd expect from reality. So it eliminates some of the guesswork if you're trying to make very realistic games.

    Overall, it means you're decoupling the lighting work from being baked in your textures, to being a separate piece of the pipeline that can be more dynamic and controllable. End result is you end up with more options, and an arguably faster way of authoring art assets, while generally being more expensive.
  • edited
    Now can someone tell me what the buzz word physics based shaders/rendering means? I don't actually know ;)
    Basically, all these years we've been using the phong lighting model (or similar models). These models are largely based on some observations about how things "should look", rather than any scientific models of how light behaves when it hits a surface.

    This can lead to some unrealistic looking results, for example: You could turn up the specular power term and have a shining white glint despite your object being in a rather dark room.

    Physically based rendering defines how things look based on actual the actual physical laws of light interacting with materials.

    In practice what this means is that instead of artists painting "the look of the material when lit" into their textures, they are instead defining the properties of the materials themselves. Instead of painting in the details and then choosing an appropriate shader, artists paint things like roughness maps to determine how much light is scattered when it hits the object.

    The advantage is then that the materials hold up much better in different lighting conditions. And in general, look much more realistic. Note that the goal of PBR is realistic lighting, if that's not your art style, then PBR is not for you.

    [Edit]

    John Carmack did an excellent talk on this subject.

    Also interestingly, there are libraries of PBR materials out there that are based on BDRF measurement from actual physical objects. So you can find out that wood has a roughness of x and steel has a roughness of y for example.
  • Tuism said:
    OMG what, NODE BASED SHADERS!?!? So, you can what, drag and drop? Move things around? I want to hear more about THAT!! :D
    Check this video out:



    I cant recommend the Unreal Engine enough, it's an awesome, industry-strength system!
    I skipped most of the introduction videos - feel free to go back and watch them, they're very easy to watch.


  • edited
    Thanks guys, I see now my guesses were way off! Thanks for enlightening me!

    I imagine though artists would still create a diffuse map, to at least define colours?
  • Yeah, most of the parts of the pipeline are the same; it's just how much lighting info you paint into them that's the real difference (i.e. none). In PBR, your "diffuse" describes the colour of something in flat/unlit light, and doesn't really make sense to be called a diffuse map any more, so it's called an albedo map, but its function is pretty much the same thing.

    And Unreal's strong! The only thing that puts me off personally is that I've gotten quite used to using C#, maybe python, and having to come to grips with something like UnrealScript or C++ kind of puts me off. In terms of art workflow though, they make some fantastic tools, some of which I've had to replicate in Unity to make Unity less frustrating to use. :P
  • And Unreal's strong! The only thing that puts me off personally is that I've gotten quite used to using C#, maybe python, and having to come to grips with something like UnrealScript or C++ kind of puts me off. In terms of art workflow though, they make some fantastic tools, some of which I've had to replicate in Unity to make Unity less frustrating to use. :P
    My feelings exactly, I'm getting to grips with C++ slowly, but I'd LOVE to rather have a nice and easy C# scripting language than have to do node-based programming which gets messy very quickly, or have to put in 20 years of programming experience before you can do *anything* in the engine...

  • So following @Elyaradine's prodding, I decided to work on my shader a bit more.



    Now it's got a shoreline, better normal mapping of the land areas, mix of plantlife and rock on the land areas, underwater areas are better lit and fade to deep blue when depth increases, Water surface now has more reflections and improved wave motion.
  • Wow, that's looking great! :D
    Thanked by 1Nitrogen
  • edited
    Thanks man! I'm really amazed how easy it was to do!
  • edited
    Some more purdy purdy (in game screenshots this time)

    image

    image

    image
  • edited
    Hey, the weekly Unreal Engine Twitch Broadcast showcased my shader! Woot :)

    Thanked by 1Tuism
  • Congrats! It's very pretty!
  • Wow, congrats! :D
Sign In or Register to comment.