Improved Vector Mapping Node
Completed by Omar Ahmad During GSoC 2019
Problem
The vector mapping node doesn't allow you to access the Loc, Rot, Scale, Min, Max values with outside nodes. It all has to be done internally within the vector mapping node itself. This limits usage, and also makes certain scenarios more difficult to execute.
Proposal
Re-work the node! I propose we do something similar to what Jacques Lucke's animation nodes does with the Object Transforms Output. You can tic which values you want to appear, and they will just appear below, like making a larger and larger list. When they are tic'd, it exposes the values to outside sources. This way you can chose which values you want to be dealing with, possibly reducing clutter, OR completely filling the node out for maximum control. If a value is not tic'd it will default to the nodes default setting, 0 for location, 0 for rotation, 1 for scale etc.
With adobe purchasing out Algorithmic I know there is some unrest over one of the favorite software's for artists. This has spurred a lot of attention in the blender community to make blender a viable option for materials and painting etc. I think we will eventually get an update in the future that will fulfill peoples desires, but until then, how about a small step forward with an already great node?
11 Comments
Funny i was just thinking of that this morning. yes XYZ sca/rot./ loc is not accessible, its quite a handicap in some scenarios when creating a nodegroup
THIS GUY: made a node exatly like yours, it work perfectly and cost only one dollar, need to buy his online library addon for that (cost one dollar total) bis.interplanety.org/library/materials/item/451
* @dodododorian * this is just a group with math praise the doer and pay him the symbolic fee... then I'll put these out for free as groups or even as tut :)
a consideration for ui/ux of this:
and the xyz visual also for inpu in case one may just fiddle with one param ( may also add tile or even "pixelate" (posterize really) as in using mul + modulo for repeating uv/ floor or round for pixelating uv, mostly for npr use i guess)
it is a very necessary approach to rotation especially, as math group approaches seams slower to me. these all are very useful in advanced mapping / npr especially
may consider this a simple backup plan, to keep it simple
It's actually rally easy to do this with node groups (except for rotation). For translate/scale, just use Vector Math node. For rotation, you need to do some trigonometry-- take a look at this blenderartists post.
What I would like to see is the option to plug in a color/value field and remap its coordinates. For NPR with EEVEE, this would be a huge tool.
* @Josephbburg * I've seen this before, thanks for linking though. It's just one of those things I think should be built in, rather than having to create a custom node-group.
* @daniellapalme * I just made one for each axis and saved into my default .blend. There actually is a subtle distinction, at least, for normals. The math is different somehow.
* @Josephbburg * To me, if something is often needed by several people, even if it can be done via node goups it should shipped out of the box. disney-like ubershaders were possible, but now that we have the Principled shader node, everything is simpler.
* @-L0Lock- * I have two thought about that: one the one hand, node groups are better because you can open them up, modify them, and re-use them. However, I imagine built-in nodes probably have a performance benefit.
I think Blender should ship with default node groups, maybe?
* @Josephbburg * Node groups are way less user friendly than a single node. Especially when it's some complicated spaghetti meatballs stuff. Those who are confident with editing node groups usually don't bother creating theyr own ones anyway. While the others simply can't.
* @Josephbburg * I did such nodes for rotation move scale etc, even tiles or pixelate or other complications.. the group way seams way slower than mapping node, especially rotation ones or otherwise the math intensive ones... so I'd say such basic ops may very well be there by default
* @o.g.blender * I like having control over each parameter, so for now node groups are better for me... but a mapping node with node inputs would be better than my current solution. I think this one is in development. I feel like I've read some discussion about this on the devtalk forum, can't remember where.