Page MenuHome

Shading: Extend Vector Math Node with Sin, Cos, Tan and Wrap functions
ClosedPublic

Authored by Charlie Jolly (charlie) on Wed, Jan 29, 7:11 PM.

Details

Summary

This adds some extra functions recently added to the float Maths Node. Not all functions have been ported over in this patch.

Also:
+ Tidy up menu
+ Change node color to match other vector nodes, this helps distinguish vector and float nodes in the tree
+ Move shared OSL functions to new header math.h

Diff Detail

Repository
rB Blender

Event Timeline

Charlie Jolly (charlie) edited the summary of this revision. (Show Details)Wed, Jan 29, 7:11 PM

I'm not sure about sin, cos and tan. To me it doesn't make a lot of sense to apply these operations to a 3D vector, the meaning is not obvious, and I can't think of good examples where doing component-wise sin/cos/tan would make sense.

source/blender/makesrna/intern/rna_nodetree.c
199–221

These category names don't make a lot of sense to me. To me they are all math functions and vector functions. Maybe you can make a distinction between geometric functions and component-wise functions. But then add and subtract would be in the first category.

I'd probably just not try to name the categories, and only use the separator to organize them into columns.

I'm not sure about sin, cos and tan. To me it doesn't make a lot of sense to apply these operations to a 3D vector, the meaning is not obvious, and I can't think of good examples where doing component-wise sin/cos/tan would make sense.

both GLSL and OSL support it, I've seen it used in noise generators, the book of shaders has a live example on this page

Although at first sight it doesn't make a whole lot of sense sin on a vector both OSL and GLS clarify in the documentation the operation will be performed component wise

The rationale for adding extra functions is to ensure that scalar/float and vectors have the same operators available. This is pretty standard in OSL, GLSL and Godot for example and makes sense from a user perspective.
The only downside I can see is that the menu is bigger but that can be addressed by another patch in the future. This is the reason for putting the vector specific functions at the start of the menu so they are immediately accessible and have the other functions match the float math node menu.
Whether the functions are useful can be left to the artist to explore. 😃

Godot visual shader, for example, exposes the same functions for scalar and vector values.
https://godotengine.org/article/major-update-for-visual-shader-in-godot-3-2

Brecht Van Lommel (brecht) requested changes to this revision.Fri, Feb 7, 7:40 PM

Ok, the functionality is fine with me, just would like to see the "Vector Functions" and "Maths Functions" category names removed.

This revision now requires changes to proceed.Fri, Feb 7, 7:40 PM
Charlie Jolly (charlie) edited the summary of this revision. (Show Details)Sat, Feb 8, 6:41 AM
Charlie Jolly (charlie) marked an inline comment as done.

Address comments. Tidy menu.

Brecht Van Lommel (brecht) requested changes to this revision.Mon, Feb 10, 8:54 AM

I don't know why you made wrap use a vector, we should not have that overhead for other vector math operations that don't need it. To me it doesn't seem important and I would just change it back to float.

This revision now requires changes to proceed.Mon, Feb 10, 8:54 AM

@Brecht Van Lommel (brecht) I was going to add faceforward as a function which needs the extra vector socket so it made sense to expose this to the wrap function. It gets hidden in the UI if it's not needed.

Do unused sockets impact Cycles/Eevee memory usage? Is that what you mean by overhead?

In Cycles SVM it adds overhead in that it will write the default value to the stack, then load it.

What you can do is add a separate SVM node for operations that use different parameters, even if the shares the same Cycles shader node.

In Cycles SVM it adds overhead in that it will write the default value to the stack, then load it.
What you can do is add a separate SVM node for operations that use different parameters, even if the shares the same Cycles shader node.

Ok, that's useful, is there an example for this?

The UV map node is an example of this, but it's really just a matter of if/else in ::compile(SVMCompiler &compiler) and then adding another node in kernel/svm.

Split Vector3 param into a seperate node.
@Brecht Van Lommel (brecht) Not sure if this is the correct way but it seems to work ok.

Add label support after D6375 was committed.

Fix OSL includes after recent library update

This revision is now accepted and ready to land.Fri, Feb 14, 5:30 PM