Shader Inj……Nah… Shader Nodes!

Home Forum Development Engine Development Discussion Shader Inj……Nah… Shader Nodes!

This topic contains 98 replies, has 31 voices, and was last updated by  rickard 4 days, 16 hours ago.

Viewing 15 posts - 1 through 15 (of 99 total)
  • Author
    Posts
  • #206314
    +30

    nehon
    1851p
    Keymaster

    Get over it, you’ll never have shader injection.

    After countless hours of dicussion in the core chat over almost a year (or was it two?), we finally got to a point of agreement on some concept on how to make the material system more flexible and less painful to maintain.

    This concept is called Shader Nodes and I recently took the shot to implement it.
    Today I’m fairly happy with what is done and I just made the commits of the whole system into the repo.

    So….what on earth is it?
    Shader nodes are self contained units of shader code that take inputs and give outputs.
    With this new system, you don’t write a shader, you assemble shader nodes and the system generates a shader for you.

    A shader node adds a feature to your shader, it can go from a simple texture fetch to hardware skinning for example.

    The nodes are connected by mappings between outputs and inputs.

    So for example, let’s say you’d like to add support for fog into the unshaded material.
    Just grab the material definition of the unshaded material, add the Fog shader node to it and make the relevant connections.

    So from now on, we are just gonna provide shader nodes, and users will make their own material definitions with what ever node they like.
    Of course, unshaded and lighting materials will be translated to this system, but you’ll now have to consider them as examples of material definitions.

    Note that if you are in love with monolithic shaders, you can still use them as before. The node system only work if there are no shaders defined in a technique (and ofc that shader nodes are declared)

    This has several advantages :
    – Very modular, build your shaders like legos.( you need at least some basic shader knowledge though)
    – Make the shader code a lot more concise and easy to maintain
    – You can add tons of features to your material, without having to care about the length of the code.
    – You can mix up your shader nodes with stock shader nodes, still having the benefit of bug fixes of our nodes.
    – It handles GLSL versions and generate the appropriate version for the GPU
    – And of course… that’s friggin awesome…

    I made a documentation that explains how to use them here.

    http://hub.jmonkeyengine.org/wiki/doku.php/jme3:advanced:jme3_shadernodes

    It may change over time, but at least you’ll have a complete overview of what the system can do.
    If you want to expriment, you have a UnshadedNodes.j3md material def in the repo, that is the unshaded material with additional fog support.
    You also have experimental nodes in Common/MatDefs/ShaderNodes

    I can’t talk about everything in one post because we got passed the TL;DR threshold a long time ago, so if you have questions, please ask, it will be my pleasure to answer.

    #206315
    +14

    nehon
    1851p
    Keymaster

    Now that I bored you to death with tech readings, that’s the awe effect moment.
    I couldn’t just stop with the system, I also made an editor for the SDK.(took me longer that the actual system actually :p )
    So here is a quick overview video of the editor, hopefully it will help you understand the system better.
    Enjoy
    [video]http://www.youtube.com/watch?v=IjvP4MWv0zg[/video]

    #206316
    +1

    Normen Hansen
    2778p
    Keymaster

    :D :o :affe:

    So in case anyone didn’t get it: We have modular shaders now and you can edit them visually :)

    #206318

    t0neg0d
    1223p
    Participant

    Amazing work!

    @nehon
    Some questions =)

    1. I assume we can still just write and use full shaders?
    2. When something changes in the structure of the shader using shader nodes, does it force a recompile? I assume the answer is yes… so how would one use branching for more dynamic shaders? My guess on this one is the branching would happen internal to specific nodes?
    3. How does inter-dependency work between nodes (i.e. The results of node 2 will effect if node 4 is executed at all… etc. Guess #3 You have to pass info along through the input/output variables.)
    4. If guess 3 is correct, are there any performance issues that come along with this? Not that it really matters… just wondering.

    I think that’s about the extent of my questions so far!

    #206319

    Brent Owens
    461p
    Keymaster

    :-o :mrgreen: !
    Excellent work Remy!

    #206320

    Wesley Shillingford
    833p
    Participant

    oh wow, this looks really sweet!! I didn’t even realise there was sound in that video, till the very end! :P will have to watch it again. AWEZOME!!!

    #206321
    +1

    zarch
    690p
    Keymaster

    But what are we going to tease people with vague hints about now? :o

    #206322

    Laurent
    83p
    Participant

    Very nice ! Lots of questions of course.

    Let’s begin by a simple one : How do you handle expressions ? Is there some kind of script module ?

    For example, if I want to make a lightMap effect, I multiply the lightMap grey level by the diffuse color. (to make it simple). How do you implement this with the editor ?

    Edit ; Ok I feel stupid. This is one example of your wiki page I didn’t read yet.
    But this is still valid for more complex expressions… Do we have to write a specific node for that ?

    #206323
    +1

    Skye Book
    367p
    Keymaster

    Remy, the shader king.

    #206324
    +2

    Normen Hansen
    2778p
    Keymaster

    @t0neg0d said:
    Amazing work!

    @nehon
    Some questions =)

    1. I assume we can still just write and use full shaders?
    2. When something changes in the structure of the shader using shader nodes, does it force a recompile? I assume the answer is yes… so how would one use branching for more dynamic shaders? My guess on this one is the branching would happen internal to specific nodes?
    3. How does inter-dependency work between nodes (i.e. The results of node 2 will effect if node 4 is executed at all… etc. Guess #3 You have to pass info along through the input/output variables.)
    4. If guess 3 is correct, are there any performance issues that come along with this? Not that it really matters… just wondering.

    I think that’s about the extent of my questions so far!

    1) TL;DR? :)
    2) Well sure but what use do you imagine where a shader changes each frame? A j3md compiles the shader nodes to a normal material definition like always..
    3) They have inputs and outputs, check the wiki manual that @nehon already wrote up for all who want to create shader node packs ;)
    4) Nah, its all happening as before. If it grabs shader node files in addition to the glsllibs and the main shader file thats not much overhead.

    @all: Make sure you check out the wiki page and video as well as the editor tomorrow before you kill @nehon by sucking the last bit of life out of him after this monumental effort ;)

    #206328

    madjack
    629p
    Participant

    Yes! Loving this! :D

    Only question I have is, how hard or how much work will it be to take an already existing big shader and translate it to ShaderNode

    Can’t wait to play with that after I’m done with the GUI stuff. :D

    #206329
    +1

    Normen Hansen
    2778p
    Keymaster

    @madjack said:
    Only question I have is, how hard or how much work will it be to take an already existing big shader and translate it to ShaderNode

    You monkeys tell us :)
    The content of this post is meant to be read as a straight information or question without an implicit dismissive stance or interest in having the other party feel offended unless there’s emotes that hint otherwise or there’s an increased use of exclamation marks and all-capital words.

    #206330

    kwando
    264p
    Keymaster

    This is (notice the big A –>) A w e s o m e !! I will for sure take this for a spin as soon as possible =) Really great work nehon!

    #206332
    +1

    madjack
    629p
    Participant

    @normen said:
    You monkeys tell us :)

    Fair enough. :P Probably won’t be me though as I’ve got a crapload of GUI to translate. I’ll still have fun when I get there. :D

    #206333
    +1

    Johan Maasing
    264p
    Participant

    I … just … wow :-o

Viewing 15 posts - 1 through 15 (of 99 total)

You must be logged in to reply to this topic.