You could use it to shuffle I guess, I’m not familiar with that functionality.
It is like a joined separate combine node but you can also keyframe the channels.
I have no prior knowledge of this kind of thing, so bear in mind. But two questions.
Can there be a button to make positive values to negative (and vice versa)? Is it out of scope for this function? Will it make the node unwieldy? Yes, I’m asking this because of OpenGL/DX normal thing.
I’d love to have an actual matrix dot product, not only for GN and Shader nodes, but also for Compositing. Do you know if there’s a proposal for it? And maybe even a type for holding matrices
In my eyes, doing any sort of arithmetic operation on the components is no longer swizzling and out of scope of the node. IMHO doing arithmetic on components should be in it’s own node. E.g. a vector math node with checkboxes for each component or something like that.
The ops are limited to what’s useful when manipulating vector/color channels. This was based on the comment for flipping and swizzling normals etc. I’d agree that anything more than this is out of scope.
For me most useful case is euler rotation reverse.
It includes not only swizzle and reflection, but reverse order rotation too (ZYX).
So it will be awesome to implement swizzle inside euler rotation too.
Sometimes I need to swap channels when I painted masks to wrong vertex colors. For example blush to blue and shades to red. But it is easier to read blush as red and shades as blue.
As much as I think the swizzle node is amazing, it can be easily replicated. I made this setup in 2 mins and in a way it’s even more powerful since you can multiply every axis, although UI wise it’s not as clean.
Yeah of course no doubt, it’s just that the user lacks some options to customize their node trees and create drop down menus or radio buttons (such as the swizzle node offer). I heard that Blender plans to implement some built-in node groups in their future updates so maybe this should get tackled in a smarter way IMHO
So this means that all arithmetic operations must conform upon only one idiom in order to have cohesive design. Which is good in terms of architecture to avoid confusion.
So in order to redefine what this node does is not about swizzling, but is more of a “converter”. As for example currently you might have implicit conversions at some given cases, such as RGB can be easily interpreted as XYZ in many cases since they have both have values ranging from 0…1.
This is a one-to-one conversion where the RGB sequence is the same as XYZ.
However in order to recapture the point of what the node of @Charlie does, is more like a more advanced converter, that allows lots of manual and explicit customization.
As @costavojik said, that you can create various node setups, but in some cases where you need to cut down the amount of setups, you would actually go for a very multifunctional and advanced converter node.
As for example supporting swizzling (123 -> 321), ranges (0..1 -> 0..255), or custom patterns with text input (ABC --> AA BB CC || AA AB AC BA BB BC CA CB CC || ...).
Let us see how this goes and we will thing more use cases.
that’s just kicking the trash down the road: now you’d have to justify that some vector operations get these checkboxes. and at that point you might also lament that the boxes are not available on all vector operations, and therefore decide to add these to the swizzle node too – just for consistency
i should started reading there
