Would the attribute node read any sort of data? Such as myobj['my_metadata']? Would it be possible for the attribute node to have two fields, one for the target object, and one for its property chain? This way we can take data from another object and drive the shader with this.
Awesome work btw @OmarEmaraDev. Your improvements provide similar features to what you find in Substance Designer.
Technicality aside, should it be done? Not sure if the developers will agree.
This was my plan initially, I wrote about this here. However, it appears I underestimated the complexity of those requirements. I am still looking into it, but it is most likely that I won’t be able to do it. Maybe a more experienced developer can make it happen, or maybe I will after GSoC when I know more. Sorry.
Thanks for all your work @OmarEmaraDev! Since nobody came up with this so far: A basic ‘switch node’ (based on the type of the first input socket) would be awesome in oder to compare parts of shaders and comps or even just to compare colour values using e.g. an int-slider, any expression or something. Cheers!
You mean something like this?
https://animation-nodes-manual.readthedocs.io/en/latest/user_guide/nodes/boolean/switch.html
Well, that switch would be math - greater than node… right? But I understand that this would be rather a layout thing that would switch off evaluation of one of the branches?
What I wanted to ask for is some lightweight version of what we already have - math mix mode. I often mix values, (e.g. Fac outputs from textures), and I’m kind of lazy to do the setup where result = input1 * Fac + input2 * (1 - Fac). Basically the very same as color mixer, only for 1 channel. I found out that setups that avoid color nodes as long as possible usually render much faster. I guess it might be not only because of the channel number, but also possible colorspace transforms ?
@jucas Currently, we are using an Integer Lattice as a base position and deviate based on the Jitter value. The lattice provide certain guarantees that helps performance. Consequently, arbitrary feature points positions is not feasible for performance reasons. And also due to design limitations. @linux_dr proposed utilizing different kind of lattices, but still not sure if this is the right approach.
I would love to have such node as well, perhaps for vectors as well. I will ask Brecht and come back to this in a later day.
Single channel (math) option would be also great for curves (called luma curve?) and for color-ramp(called greyscale ramp or whatever) - e.g. for roughness, metallic, e.t.c. these are often used and single channel is enough, would improve performance a lot. I often do a set of math nodes instead of these just for the shader to run faster.
sorry about using the wrong thread i copied every thing here again
Disclaimer. I haven’t shaded anything in my life LOL
I read on one of surgey patches which was about optimization to the shaders ,
that he couldn’t reliably tell the inner recursion of the shader I think … so he was not able to do more aggressive optimization because of it.
my idea is to add a tagging node which can help with that or maybe add tagging to the frame functionality.
this can be used by users as an annotation system to guide the optimization or can be used with an enum selector to create variation of the same shader without having to build multiple shaders and desconect and reconnect shader branches, you just have a selector e.g stylized , PPR , wet look and so on. it can also used for indicating version like v1.0 v2.1
All of This can be exposed in the normal menus so other team members (not specialized in shading) don’t have to mess with the shader or manage or assign different material during animation, they just animate the enum value.
It can also be used to have a named output sockets say for example the output of a branch is connected to a tag node with (layer 1 or layer 2 ) tag, which can be easier to query and use in add-ons or the blender UI as away to make a layering system
Which lead me to …
a multi input socket mix shader not just 2 like in the image but say 5 or 10, doesn’t need to be dynamic just fixed socket numbers, that can be used to make layers functionality, this idea is already being used by some addons to mimic layers by using the mix node, whoever you end up with alot of mix node that are very messy , so to avoid doing that the user add a mix rgb with 5 or 10 inputs and use one 3 nodes instead of 30 for example .
Even fixed number of sockets mix shader, they just have one with 5 and 10. That could save a lot of complexity .
each input socket will need to have its own blend mode that will be used to mix it with input of the socket underneath it and so on
this addons for example does that if you add a few layers and look at the node tree you will see a large number of mix rgb nodes being used
That Would be fantastic. 3ds max has this and it makes colour ramps a lot more powerful.
This idea maybe a bit hacky but could work for creating dinamic socket system at least for mix RBG node .
Basically you create a special kind of frame that cannot be opened you just add the frame and inside it you will have a mix RBG node already connected and on the frame you have a button to adds another node and connect it the same way
So internaly it’s small nodes as usual but in the UI you get something that looks like a normal node but is not .
It may even work for other node and it could be easier to code than dynamic sockets.
And since it can not be opened you’re guaranteed a certain structure that can be optimised during compilation time
Would the work done for the Vertex Colors be easily transferable to Vertex Weights?
Would be great to have modifiers and shading coupled for all kinds of purposes.
Not exactly. If I understand correctly, you want a Vertex Weight node. Not sure if we will have enough time to implement this, but I will try to.
Yeah, vertex weights would be great, but I understand if you don’t get to it. Great progress so far!
Speaking of time, I was wondering if you we’re still thinking of adding the spline info node. Or is it out of a ope right now?
This is what I am working on right now. I am having some trouble with it, so nothing to show yet.
Just a thought: what if the shader2rgb node had a vector socket that allowed you to move / distort the texture?
Adding a vector input/output to all the image and/or RGB related nodes would be useful.
I learned and used blender and Max side by side for a time and I never understood how to use Max’s color ramps as blender, they appear to me too cumbersome to use, I think wathever they do, it should be rethought cause they’re not intuitive…
Well, they don´t really work that differently. They remap the color values of some sort of input map, for example a noise texture, to something new. The blacks of the input map are turned into whatever is on the left side of the color ramp and the whites get turned into whatever is on the right side of the ramp. Everything in between gets turned into whatever is in the center of the ramp.
Now, the cool thing in Max is that you can not only input color values but also textures. This can be achieved in Blener as well but it is a lot easier to set up in Max.