Shader Forge - A visual, node-based shader editor

umm I see, those are several nodes!
Maybe and just maybe in the fure you could create a PixelDepth node...

 

You're right, so I did:

 

I'm trying to find this, but it seems like I'm sleepy I can't find the solution.

How can I get the existing color of the rendered scene in its current state behind the pixel currently being drawn?

I'm looking for something that looks like what the UDK node: DestColor.

 

http://acegikmo.com/shaderforge/nodes/?search=SceneColor

 

Wow man that was fast!
You're my heroe! so... waiting release 0.28

 

I feel like I wanna marry this thing sometimes already, not just when i'm messing with it, also when i'm thinking how i'm possibly going to do something then go 'oh yeah! shader forge!

I was somewhat getting the hang of writing shaders the traditional (but post assembly) way, but now I dont even know why I would bother. If I want mobile shaders then Marmosets got the super fancy ones, Echologin's got the ridiculously fast ones in core framework. For desktop, this, with i'll concede a lil anticipated help from some more specialised offerings. So thankyou for for making Unity even more of a joy to while my hours on

 

Just got rid of some custom PBR shaders and started using Shader Forge instead. Heres my result!



Hats of to Joachim for an excellent tool!

 

That's brilliantly amazing Coulianos

 

HI ! Acegikmo ! And everyone ! How are you !

Im Pretty Dazzled to see this Development endlessly Evolution, The New features are amazing !

Im Really waiting for the Custom Code Nodes And Nodes grouping Feature and Relief Shading as well 3D Volume Textures, Appear one day in Shaderforge.

As im here .. I Have here a Difficulty, And Maybe Someone can Help.

ACE. OR SOMEONE : CAN YOU SHOW US HOW TO CONVERT A GRAYSCALE BITMAP INTO A NORMAL MAP WITH SHADERFORGE ? Please ...
I know this was already talked before, but i cannot find it in either this or the older thread the info about it already ...

CAN YOU PLEASE SHOW US A SCREENSHOT OF THE NODES FOR IT ! ...

This is Really important in my project ...

THANKS SO MUCH !

KEEP UP THE GREATNESS OF CONSTANT WEEKLY IMPROVEMENTS !

SOULS.

 

Here's a way of constructing normals:

 

HI ACE!!! YEAY ! WHOHOO ! Amazing !!! You made my day !! ...

I tryed Endless times this week ... And i see now I Would never Reach it on my own !!

ANYWAY ! This Just proves the AWSOME POWER of ShaderForge ...

Imagine ( Mobile SHaders not needing the Extra Expensive Normals maps At all ! )
One Now can compress Normals In a Single Grayscale from RGB Channel And Still have the Alpha For OclusionThis way !
RGB Map, Normals Map And Oclusion Map in ONE SINGLE BITMAP ! Yhooho...

Its the kind of things would never be possible for feeble users before in unity !
Its amazing The Possibilities of Optimization SHaderForge opens !

And you even got the DISPLACEMNT ! Man that is Quite Crazy ...

YOU RULE ! THANKS MILLION MUCH !

SOULS

PS: MAN We reaaly need a Shader repository in Shaderforge official Site ... ( but its too delayed just to make it I understand that )
But how About Just a Simple Place At Shaderforge Site were users can Send SCREENSHOTS Of SHADERS !?
That would be easier ( for starts ) and actually very cool for reference and advertising of Shaderforge power !
Think about that ! - Hey THANK SO MUCH FOR EVERYTHING ! BEst Regards. ​

 

I've been preparing something like that, I'll publish it later tonight

 

Thank you for helping me in other post ...

I've managed to create water shader quite realistic thanks to your help with SceneDepth and BlendDepth node to achieve the color and softening around the edges, as well as an effect of splashing when using two different normal maps and using Lerp node and connection BlendDepth node in the Alpha Channel.

I want to ask if with current nodes, I can also achieve the effect of node DestDepth UDK.

DestDepth in UDK Existing outputs the depth of the rendered scene in its current state behind the pixel currently being drawn. It's pretty similar to DestColor (aka SceneColor in SF).

So... SceneDepth in SF equals DestDepth in UDK ?

Thanks like always

 

Well, yeah
http://acegikmo.com/shaderforge/nodes/?search=depth

 

Hey Acegikmo! First off, thanks for creating this awesome asset, I purchased it last night and made an icecube shader without too much trouble and it turned out the way I wanted for the most part.

My only issue is with displacement/tessellation. Is there a way to prevent the seam cracking (geometry splitting appart on uv/smoothing group splits)? I know that UDK had a fix for this, and maybe you do as well and I just don't know how to achieve it.

Any help would be appreciated,

Thanks!

 

Glad you like it
I don't know of any straightforward ways of solving vertex offset breakage, but there are two hacky solutions, that may work:

1. Bake normals into vertex colors instead of the geometry normals, and smooth the entire mesh
2. Bake your normals into a normal map, from a hard-edged version of your mesh, onto a full-smoothed version of your mesh
3. Create the outline version of the mesh separately in the model itself, for all assets that need it

None are perfect, but it should work to a degree!

 

I can't connect to your site.

 

Strange. Everything looks fine from my end. Maybe it was temporary?

 

I have a little thing to announce - the Shader Forge userbase is growing every day, and will soon reach a point where I can't keep up, which is awesome! I hope this place can lift some weight off of my shoulders, and help you all help each other, to create, edit, refine, and polish methods of working with shaders in Shader Forge, to spread your knowledge to everyone and learn from others

Feel free to start pages, edit pages, and make this brilliant!

Shader Forge Wiki

It's very much in its infancy, I hope we all can collaborate on this project

 

You, sir, are a gent, and i'd love to contribute. What I can suggest adding, as I cant find it, is a categorised list of shaderforge shaders much like the user contributed shaders in the unify wiki. This can be somewhat curated I think without too much trouble and a submission could consist of an image of the graph, a date of submission/version of shader forge, an image of the shader applied to a model appropriate to the category, an explanation and any supplementary code as needed.

I've promised to do all sorts of things lately but I think what i'll do first is after rifling through various textures im supposed to be rifling through today, ill spend a bit of time getting as many UDK shaders switched over as possible, if possible. I'll be making these generally available anyways but if there's a section in the wiki for them, they will without a doubt be submitted there and might start a nice start for what could be a definitive list of go-tos for Unity shader needs (Although its probably worth pointing out somewhere on the wiki that the shaders in their basic form are more suitable for desktop machines than mobiles)

Assuming I get anything of consequence ported, would you be ok with me pming you examples for the format, then maybe this section for a wiki could take on shape

And whatever cosmic force that governs this universe will bless you when you get to adding custom nodes and code i swear, but i'll do the above first to qualify it a bit (Plus i'm kinda stalled on a few of my projects till the custom nodes are made available)

To that end, I do have a few very good shaders available for transcribing to get started with but if anyone can supply me with links to further UDK shaders it would definitely be appreciated, only condition being that they are of high quality, ideally of extremely high quality.

 

Can you add shaders to the allowed file types?

 

Good question! I'm not sure what would be the best format. My approach to it is - if people learn the techniques, they can do whatever they want beyond that point. I see the Wiki more as a knowledge database rather than a shader database, though shaders and screenshots are of course central to it. The reason for this is that it would be nice to avoid a scenario where people never learn how to use SF, and only downloads shaders with it, which would be a bit of a shame since they would be missing out on the most fundamentally advantageous part of SF - flexibility!

But the Wiki isn't mine alone, it's by and for everyone, so, come up with an idea and see if people like the structure of it

I have started work on a custom code node, but it's far from finished. What do you need custom code nodes for, if I may ask?

Done!

 

Actually I quite agree with your philosophy there and perhaps supplying people with entire shaders is counterintuitive to the understanding of them and it would keep people reliant on the work of others. Perhaps what might be better would be something like submissions like your normal reconstruction snippet above, where it's ostensibly a self contained procedure that could be repurposed as a world machine-style macro for anyone with a shader needing that kind of functionality. When there was talk back a good few pages where jbooth was discussing the idea of a block of nodes having an 'API' of sorts, i wondered how hard it would be to actually collect them into a macro node thing, where it would have inputs and outputs but a, say double click would open it and you'd see the graph inside it.

When it came to sharing things with shader forge, maybe it would make more sense and encourage a better understanding of it and shaders on the whole for these macro nodes to be shared, as a file or in the wiki, instead of an entire shader, then common procedures could become easily available to the community and inserted into a graph easily alongside the shader specific structure. This would make it much easier to arrange graphs too and duplicate functionality around the graph, say you're doing something involving some complex but commonly used mathematics and so on. Just being able to wrap large sections of nodes into a minimised macro would be handy enough as even my 'simpler' shaders are becoming enormous, but shader creators making something ingenious or very helpful and submitting that 'function' to the wiki would be great, and a rather more mature answer than my previous 'give all your shaders away' suggestion.

It's also something I can figure out how best to split things when i'm cannibalising UDK shaders during the day

The above does rely a bit on further implementation by yourself (i think) and I have no idea how hard that might be but basically having the option to either specifically create a group/macro whatever you want to call it node, enter it and set up your node structure that way or select what nodes you'd like to group and have some 'create group' settings, maybe colour code them and stuff like that, would be tremendously helpful, make the top level graph much more organised and colour coding and suchlike of these would aid comprehension of the graph hugely. Then being able to export them as files, even text files, or submit images of them for the wiki could give shader forge a great selection of very powerful community created tools

The custom code node - good question, but basically most of the shaders i'm working on currently are ports from existing shaders where i'm trying to merge and improve as I go along. It makes sense to me to use shaderforge because its an immeasurably faster way to write and evaluate shaders than by text (And understand, no less). These shaders are pretty neat but some have some very complicated mathematics that are in different functions in the shader and trying to recreate them in nodes would take forever and result in absolutely enormous graphs (Although see my node grouping suggestion above). So that's one reason - there's lots of very snazzy already available shader code that's much faster to have as a few lines of text than a cosmos of connected nodes

The other example is i've got a really big idea for a shader i'm doing that relies a lot on noise functions and I can see my shaders in future relying more and more on noise functions, and calculating noise on a shader is well documented in some places, for all kinds of noise, so just being able to wrap up these functions in custom nodes would be really handy. In fact custom nodes would be a really nice thing to share on the wiki too if they were sufficiently helpful to the masses.

Really anywhere i've got lumps of pre-existing code that would involve complicated and confusing node structures would be great to put in a custom node, and that way you could repurpose custom nodes in exactly the same way as the idea above. I think these things would be appreciated by many and make shader forge very powerful, simply through organisation and comprehension of a graph improving productivity, and sharing of useful custom/grouped nodes helping everyone get the results they need while still having full understanding of their shader and how it works

 

Who, u do it ?? i cant put in terrain shaders (

 

Acegikmo , When u finished wiki ???

 

Thanks for the bunch of feedback!
Having nested nodes would definitely be lovely! I don't need any further convincing at all
However, it's a very complex thing to implement. Just to give a little perspective of how it looks from my end, here's a fragment of all the questions, design problems and technical issues that arise:

1. When modifying a Nested Node (NN), it has to update *all* shaders using that NN in particular. This can cause a ton of
2. Shaders save references to NNs, but should NNs be able to contain other NNs?
2a. If yes - The node tree needs some sort of browsing system to see which NN you're inside at the moment. You would also need to have a system for preventing a dependency loop when, for example, you have a NN called A and another called B. If B is using A, A cannot use B, because you'd get an infinite loop of nodes that would never end.
2b. If no - People are going to want to do it
3. The editor will need a new "mode" for editing a NN, that makes sense and is intuitive. You need to be able to assign which output is the primary output, and which inputs should be exposed.
4. The editor needs to handle the case where you try to open a shader that uses a NN that you don't have.
5. Sharing shaders is harder, because you have external dependencies, so it's no longer just a single .shader file, unless the NN save both an asset reference as well as a copy of its own data in the shader itself, which would be yet another system
6. If you're using properties in a NN, you can only use it once in each shader, without getting a name collision, and implementing a dynamic naming system would take time.

(and more, plus the fact that unforeseen consequences happen a lot)


I'm not saying I won't do it, and that I don't already have solutions to many of these problems, but it is something that will take time, and will also burst open a new section for people to find bugs and request a ton of new features in; which I already have a bunch of as it is!

Not quite sure if I understand your question, but, the wiki has just started, so it's not really finished yet no. However, Wikis should ideally never be finished, as they are to be kept up-to-date and polished with the latest techniques and information

 

haha, i see your dilemma.. well, if it helps, i dont think nested nodes should have nested nodes within them, at least not for a good deal of time. there, i just saved you a ton of work! *pats self on back*

in all seriousness though, i did labour the point so sorry bout that, ive full trust in your ability to get a strong implementation

as you didn't supply feedback regarding my needs for custom nodes, did my explanation make sense? (particularly in the context you might be approaching the task in)

As I do agree that making people over-reliant on a shader database is a little against what I consider a good ideology i'd wait out before I added anything I myself would have cooked up, if I ever do make something that useful, would you consider a 'Ports' section a more valid proposition, where shaders taken from elsewhere can be contributed. I'm fairly sure most would appreciate a collection of well enjoyed shaders from other engines, and I quite like the idea of taking that on for a bit, but I fully agree with the idea that people understand their shaders, meaning the section would be seperate, it could use the format I first outlined but very importantly crediting the original creator prominently, and if possible, an outline in the explanation of any significant parts of the shader, particularly if a node is named differently or has a slightly different function in shader forge.

I suppose thats a nice way to keep it neat, give people something to start with, and have a selection of shaders to pimp shaderforge with a little

I'm terrified of messing with the wiki myself unless my proposals are approved of cause the last thing I want to do is put my foot in it with someone elses hard work haha

I really need to get off my arse and get some of these things happening, ive spent the morning so far full of bright ideas and no legwork of worth at all

 

Don't take my angle on learning too seriously
Just start a page on the Wiki and experiment! It sounds quite appropriate to have a shader section, with more or less only node trees along with shaders. I guess the only thing I would want would be to link to all the techniques used in that particular shader, so people can learn how and why it works the way it does

Don't worry about editing/creating things on the Wiki! You can work on a Wiki page that isn't even linked on the front page for a while, if you don't think it's ready just yet, and you can always PM me and ask if it looks alright. But I really don't think it's an issue, so, go ahead

 

I think it's important for the Wiki to have "recipes", but not necessarily entire shaders. The entire advantage of a shader graph is in customizing shaders to individual uses, not in making standard shader libraries.

When I was teaching artists shader graphs at my old job, one of the first things I had them do was manually build a panner node. Doing this teaches them a lot about the fundamentals of shader coding; that it's all just numbers to be manipulated with math. However, asking them to do this every time then need to pan a texture is pointless; which is why we have a panner node, and the exact reason why a custom code node is needed.

I also learned that there were two kinds of artists; ones which wanted to learn everything they could about shaders, and ones which simply wanted to get things done and prefered pre-packaged functions in terms they understood. For instance, they would use the "multiply" blend mode, even though this is just a multiply node.

We didn't implement a "macro node" or custom code node at all in our system; rather, we just added the nodes we wanted in code, since it was an easy to extend system, only requiring a few lines of code to create a new node. Whenever I found a function an artist was doing that could be easily generalized (given a name that makes sense, etc), I would just add it to the library. However, this is not possible with SF because it is closed source, and I gather from various things said here that adding new nodes is not as easy as one would like, especially considering the way preview rendering currently works. I totally understand this decision, btw, as the needs can be filled in other ways.

Personally, I think your best bet in terms of time spent for power gained is with the custom code node. It has far less UI implications than the macro node does, and the community will quickly fill out the library with useful nodes. The people who can write a fur shader can do so in HLSL, and in most cases would prefer to. It will also prevent the need to add many types of nodes which would make the graph system more complex, such a looping constructs, which don't easily fit into the graph paradigm, or matrix operations, which are beyond the scope of the average shader graph user. It also means you are not required to teach or support those advance constructs, because they are not part of the base package, but rather extensions by the user/community. Additionally, the custom code node is a path to macro node generation, in that a macro node only needs to spit out the shader code for a custom code node using the existing code generation features. We can imagine all kinds of ways to make macro nodes spiffy (open/close, etc) - but honestly having them as separate files which simply generate a block of code is likely fine. And last, the custom code node is needed because Shader Forge is unworkable for complex shaders without it. I've written shaders that use half a dozen noise functions in them, and SF bogs down to a crawl when just one of those functions is in the graph. Even if that is sped up, having to manage all those nodes makes the use of these types of functions prohibitive, because it's a massive mess of copy and pasted nodes.

One side node, to make the custom code node work well, you'll likely want to change your preview rendering system to use the GPU. I love your idea of generating a compiled shader for each node and chaining the output of one into the input of the next; this would speed up preview rendering considerably and allow previews to be generated for custom code nodes. I'd take it without it, but it would be a shame to see the wonderful work you've done with the UI blighted by nodes which don't generate previews.

 

I'm considering opening up writing custom nodes, as in, writing them in C#, just like I do for all nodes.

I recently had to add a dynamic node loading system, because Marmoset have made two Skyshop nodes for Shader Forge now, which will be featured in their next update, so it's trivial to open that up really

However; the way I write nodes now though is not ideal, and has a lot of caveats, but it might be better in the end, as opposed to some sort of custom code node. What I worry about, is me making changes in the node system, and all custom nodes break along with it. Especially if people have started to use workarounds/hacks to "solve" problems in it.

 

Honestly, I think the custom code node is a safer solution, because like you mentioned, you could need to change something with the backend and everything gets broken. That would mean the wiki or any other repository would fill up with dead code, which is really bad for a product.

With a custom code node, it's mostly HLSL and some schema for naming the inputs/outputs, which is unlikely to change much, so the risk is far less. That said, I'd personally love to have full access to write nodes and give them snazzy UIs and options. I'd be happy to beta test that functionality by adding some useful nodes to shader forge and give you some thoughts on the backend if that would be useful.

 

hmm.. still won't let me upload a .shader file.

 

I'd love to test custom node spicing as well as actual material editor spicing up re my comment earlier about The Order but definitely my notion of a custom node at this point is essentially just to hold a function written in hlsl, I think what I mean is exactly as jbooth said, if you have a function outside of your main fragment shader block, which takes arguments you specify as inputs and the output is whatever it returns, that's custom nodes to me, as in I could create the shaders in shaderforge i'm working on fully with that functionality

I guess obviously it is more complicated for a sensible implementation as these functions can call other functions in themself, but the creator of the custom node, given the options should have the wherewithall to define ins and outs of functions called within the function themselves. I guess its a bit like you have a main set of inputs and outputs (it's initial arguments and its return value) and then for other functions called within this custom code (Which wuld also be custom nodes I imagine), these could possibly be called something like 'relationships'/'dependencies' or something, which reminds me again of how world machine is set out where, if you swap directions cause world machine goes left to right, you have inputs on the left of the node, outputs on the right of the node, and functions it could be dependent on along the top or bottom (bottom would probably be best in the shader forge layout). If the custom node/nodes it is dependent on aren't there or don't return a sensible value it could throw a friendly error?

Being no expert and definitely hardly the go-to man for this kind of work I dont know how helpful that is, but even if some of my shaderforge shaders were chiefly comprised of interconnected custom nodes, shaderforge would still be absolutely invaluable, and so far I find the kind of things youd put in a custom node are just boring maths that would just be unnecesary clutter on the graph as node networks (And actually harder to implement than just writing/copypastaing from another shader or webpage etc because it's just endless maths operators), the visual coherence and enjoyability of the whole process is greatly enhanced with shader forge and all the fun stuff for me is with the shaderforge nodes, as they're very helpful for the real graphical application of things where you can experiment and implement very quickly, something that custom nodes could be quite crap for (Hence the point of shaderforge at all

Custom nodes could also be something that would be great to be able to export and share on the wiki too, as given jbooths example of the kind of artist who just wants to get stuff done, someone supplying a nice selection of custom nodes specifically for different kinds of noise generation would be great

 

It should work now! (For real this time)

I started working on one a few days ago, but it's a bit limited. I got it to work anyhow

 

Ahh also, jbooth, i liked your idea of recipes and such, which could indeed be a pic of the graph and an explanation, it would be great to have the resources there in the wiki for people to get as familiar with the system as they like, and all be catered for

I'll ask you as you seem to be coming up with a lot of ideas, would you consider my earlier idea of supplying a shader section for complete shaders that are ports from other engines and editors worth making a page and layout for with the general feeling being that they are complete and ready to use but try place greater emphasis on the more educational aspects you folk are thinking up. Hence even naming the section 'ports' to i suppose make them seem of less value and explain as a disclaimer that in using those shaders you'll probably miss out on the benefits of understanding shaders made in shaderforge fully (In my experience that seems to be how minds work at times)

At the moment, since I don't like doing things by halves, i've finally got to getting stuff together for my demo which is in itself intended to show off as much unity stuff as possible (Ive got a lot of stuff) in a visually pleasing environment, so I can start making these ports in general to try them out in the scene, that'll get something there to be put in the wiki at least. Then if educational material is relevant to the shader as it grows (i'm expecting you to be doing a bunch of these things jbooth aha, it seems you have a passion for it) then it'll be worth adding to the shader's page

 

I think many people would want that, but honestly I think the asset store might be a better place for it. For instance, if the wiki has a library of completed shaders on it, no one has specific ownership of those shaders, and there's nothing making those shaders conform to common standards. For instance, it's unlikely they'll follow common naming conventions, have a common level of quality, support LOD options and the other things one would expect from a robust shader library.

Conversely, people building a shader pack on the asset store have a huge incentive to solve these issues well, even if that shader pack is given away free. They have a review system, direct contacts with the author, likely a single author who has a consistent style, etc.

That's why I'm personally more in favor of the shaders on the wiki being more about recipes; small fragments which show you how to perform a give operation which can be used in a larger shader, preferably with deep explanations for those that want to learn more. I'm also a proponent of it having a node library of custom nodes, so if I really just want a relief mapping effect I can download the node and install it into shader forge for use.

 

I started working on one a few days ago, but it's a bit limited. I got it to work anyhow

[/QUOTE]

That's already more swanky than the finished product i was expecting! I'm trying to think of a typical hlsl function you could test with it that would, I think, make that implementation perfectly suitable. I wonder if you could set the needed return value types, and their names on the right yourself at any point during the node editing and then the name could be highlighted inside the text field when it occurs, that might be a nice debugging thing, even have the output highlighted itself if no variables in the code match the set return. I was thinking of the other way of looking at it which could be adding the return statement at the end of the code as normal and the outputs be automatically generated from this, but i dont know if that's going against the design model of the editor. Maybe you could do both actually, that would kind of make sense - those who know a bit of hlsl would probably find it more convenient to add the return themselves and the node outputs pop up, but for those who aren't particularly familiar with hlsl but see the benefits of using custom nodes for some things (Anything with a lot of maths/notation basically) would understand setting the outputs manually a little more possibly

Custom nodes that node is dependant on i'd imagine could be detected automatically too? I don't know if it would be a pain in the neck identifying between an inbuilt function and your own function, but maybe there's something clever you could do there too, like if not automatically identifying it and filling in the output/input for these in the interface, have the ability to add a lil connector thing at the bottom with the name of the function its using (essentially the name of the other custom node its using) then highlight in a nice colour where it is occuring in the code and a link be made, then some really useful debugging could be done, which is nice since unity's is hopeless, like i guess doing it this way would make it very easy to tell if there havent been enough arguments passed to a node, if the arguments are the wrong type, stop the unity compiler crying about implicit downcasts and so on

 

Awesome! The only issue I see is that there's no way to have an additional function in there. Like, if I want to do something like:

float EaseHermite(float x)
{
return x * x * (3 - 2 * x);
}

float MyCustomFunction(float x)
{
for (int i = 0; i < 10; ++i)
x += EaseHermite(x);
return x;
}

which is common in noise routines and such. I can work around it, but it's just more typing. The only downside will be the shader getting larger due to repeated functionality; but I think the shader compiler might inline those functions anyway - I can't remember.

What would really be the icing on the cake is if I can then drag that node to the node window, give it a name and menu location, and have it show up in the menu as if it's a fully baked node.

 

You don't want to infer the output from the return value. That would prevent you from outputing multiple values. For instance, a parallax occlusion map node might output the final color and shadow value separately so the user can recombine them in different ways. An RGB -> HSV node might want to output the color (RGB) and a float 3, and the H, S, and V components separately. By passing everything in as out parameters, you can have as many outputs as you want.

 

I'm pretty much in agreement with all of that apart from the case of actual ports from elsewhere as i'm happy to, and would like to do then, they'd teach me a few things and start my own little shader library, but as they are openly available, are not my work really and even though it comes down to a personal quirk of mine i'd be very uncomfortable putting a pack of other peoples hard work on the unity asset store, just through implications. I'd see the ports as a rough and ready set of shaders people could go to if they want something quick, it can be specified that that is the spirit of them, and not to expect support for them, and it just be a place for, basically, quick fixes for temporary problems. I'm sure most developers intending to understand their own game would be averse to using a shader with no support and little comprehension of its functionality, but it would be a nice place for quick and easy solutions until more refined products are created. I know at least from personal experience the frustration of really needing any particular model or any particular shader fast simply so i've got something to help with visual cues, so them being there might offer some help in that way, and also a neat resource if you just want to quickly see what you can get out of shaderforge before honing in on exactly what you want.

Funny I say all this, mind, I havent even tried to 'transcribe' from udk to sf yet (although i know its been done) so it's a bit of a new thing, and i'm only really objecting in any way because i'd feel wrong putting them on the asset store, even for free, when they're so far away from my work, and not exactly what sf is about, imo. Given enough notice that they're on their own when using these shaders if they run into problems, this should minimise some complaining (Although i'll supply my email for direction if people cant comprehend the disclaimer) and hopefully they could help teach in a broad sense (If nothing else, lazy dev's games are going to all start to look like each others) it might send some custom actually in the asset store's direction, and to a 'recipe' section too, where people can get a proper education that will give them results they can predict and understand

 

@jbooth I didn't even think of that, dhoop, ah well i'm learning at least

I suppose your input on my idea for dependancy on other nodes would be useful too, i'm shooting out ideas but they may be a little more shortsighted than ideal

I was looking on shadertoy and in iq's article page for a straightforward noise function to test in the custom node but wasnt entirely confident that it would have the intended result, would you be able to supply one to acegikmo/the thread that might result in, say, a typical perlin that might work as proof of concept?

If there are noise functions that depend on other functions, that might then be a way to test the plugging in of other custom nodes too, with an explicable result if all goes well

 

I don't think nodes should be dependent on other nodes, other than via their inputs and outputs in a shader graph. I notice that in Shader Forge when you drag a rotate node into the graph it adds the UV node and connects it for you, which I find very odd; I would expect that anywhere you see UV as an input, it's just going to assume the UV values, like the texture node does. For custom nodes, as long as you can write a function to call from within the custom node, you should just include it there.

I'm pretty sure acegikmo can handle coming up with a function to test his custom nodes. For reference, here's the simplest noise function I can think of; a 1D value noise:

float2 Hash1D( float2 n ) { return frac(sin(n)*437.5453); }
float Noise1D( float val )
{
float p = floor(val);
float f = frac(val);
f = f * f * (3.0 - 2.0 * f);
float2 n = Hash1D(float2(p, p+1.0));
return lerp(n.x, n.y, f);
}

Simple enough that inlining the hash function is no big deal, though. Anyway, that will produce a single dimension of value noise.

 

Great buy! Awesome asset! I am new to shaders and I would love to see a tutorial on how to create area lights. Like the video posted with the orange and blue spheres giving off light and reflection on the ground.

Thanks!!


Mycoal.

 

@Jbooth You mean rather than visually connecting to the custom node with the function you need, you just call it by name? Thats a pretty sensible idea too! I guess some indication that the node exists would be helpful, i'm big on my visual indicator things aha. Would it make sense to indicate when a node can be called like this, without having to be specifically arranged on the graph? By dependant I meant, well, it calls a function/node in the code, and its ability to fulfil its purpose relies on that function/node being available. When organising your own library of custom nodes, i think it would be useful to signify this ability because semantically it feels like wether the node needs to be on the graph's 'workspace' to fulfil its purpose, or maybe the whole way the custom node operates is that it can call any other node by name if it's a useful function. I feel like i'm asking stupid questions yet not feeling that bad about it because it's helping my understanding a great deal haha, sorry if it gets annoying

 

bad, because reading that in the wiki, I began to understand much and what to do, I have a lot of questions in your shader, it is gorgeous, but I do not understand a lot !

 

No, there should never be functions which one node is dependent on at all. It should all be contained within that custom node; not referencing things which are not explicitly passed into the shader or defined with it. So if I make a noise function, I include all the code that noise function needs in that custom node.

 

Makes sense! The way i'm thinking about it is how one of the shaders i'm adapting is written, and it's a vertex/fragment shader as usual with 5 or 6 functions along in it, split that way clearly to make the fragment shader a lot more readable, some of which used by the fragment section and some of which use one of the other functions in the group, so I saw it in shaderforge as a custom node each representing one of those functions, you seeing each function seperately, visually, as a node, but their connections clearly visible. That may not be how a editor like this should work and i'm enjoying the education so thankyou, it'll be interesting seeing the outcome

As per your suggestion i'll make any derivative shaders from those made in other similar systems into one updated free asset store item, which would probably keep the wiki cleaner anyway, and i'll no doubt find within those some useful snippets for more educational use on the wiki

 

If the function is useful on it's own, by all means it could be done as a node and it's result plugged into another node. The problem comes when those functions end up being very specific and not useful on their own, or it makes the node which needs the function really complex. For instance, if I'm making a perlin noise function, there's no value added by having the hashing function as a second node - you don't really need to replace it with another one, and it's not that useful on it's own - so there's only downside in breaking it into it's own node. And since I need to feed that hashing function with very specific values generated by my input UVs, all of that would have to spill out into the graph and the user would suddenly have to know a lot more to use the node.

Where this could be potentially useful is in things like the curve used in the noise function's interpolation. For instance, I use hermite in my example, but if you're generating a normal from that data you really want to use a different curve because a hermite will produce discontinuities in a normal map. However, in these cases it's likely easier to make a second node than to extend the framework with extra features and making the system more complex. Some other shader graphs I've seen have options on the nodes, which force them to generate different code, so I've seen it solved that way as well. But either way, it seems wise to keep the types of inputs/outputs simple and keep the system simpler, IMO.

As for the pack, I am by no means the owner of the Wiki. If people think that's a good place for a shader library then so be it, have at it..

 

Thanks for the explanation!

When it comes to messing with the wiki I want to consider what actually reflects best on it, wether putting shaders on it would stop people really learning about them (when they really should learn), and also wether porting things around so blatantly reflects well, then on the other side, it would be good for new users to have somewhere they can go to grab decent useful shaders to get them off to a good start.

I suppose I can think more about it when I have a few done, and i'm definitely considering what was suggested a while back and only upload the information pertinent to shaderforge so I assume they'll be rebuilt and compiled upon loading them in sf, as well as an image of the node graph, that ways the shaders are indeed there for shader forge users and not plundered opportunistically

 

You can actually learn alot from UDK tutorials. Shader Forge is very similar to the material editor of the Unreal Development Toolkit. There are a few things to keep in mind though. SF deals with its default vectors in world space while UDK does in tangent space. If you are not sure about this terminology you should look it up in the WWW.
The wiki will grow in time. Until then - read the forums (Shaderlab section) and any tutorial you can get your hands on about shader programming
The GLSL programming book for Unity is a great source for starters.