Page MenuHome

Shading: Rewrite Mapping node with dynamic inputs.
ClosedPublic

Authored by Omar Emara (OmarSquircleArt) on Aug 20 2019, 3:27 PM.

Details

Summary

This patch rewrites the Mapping node to support dynamic inputs. The
Max and Min options have been removed. They can be added as Min and
Max Vector Math nodes manually.

Texture nodes still use the old matrix-based mapping. A new SVM node
NODE_TEXTURE_MAPPING has been added to preserve this functionality.
Similarly, in GLSL, a mapping_mat4 function has been added.

This patch lacks versioning code as it depends on D5523. The code will
be added later when D5523 gets merged.

Diff Detail

Repository
rB Blender
Branch
mapping-node (branched from master)
Build Status
Buildable 4717
Build 4717: arc lint + arc unit

Event Timeline

intern/cycles/kernel/shaders/node_mapping.osl
51

The naming convention seems to be inconsistent here: type vs VectorIn

intern/cycles/kernel/shaders/node_mapping.osl
51

I don't think we can change those names. OSL automatically generates them for us and we have to use them. In this case, since an output and an input are both called Vector, OSL inserts an In at the end. Similarly, type is determined by the compiler.parameter function.

I played with the node a bit, it seems to work as expected.

This is how the node looks like now.

@Omar Emara (OmarSquircleArt) After looking at this new mapping node, I'm thinking that the rotation node patch D3789 should just be implemented in this node but as an alternative type called rotate.

void mapping_rotate(vec3 vector, vec3 location, vec3 rotation, vec3 scale, out vec3 result)
{
  result = (euler_to_mat3(rotation) * (vector - location) + location) * scale;
}

Of course, in the future it would be nice to have matrix support in the shader nodes.

  • Add versioning code to mapping node.

A file to test backward compatibility:

As @Charlie Jolly (charlie) noted, the mapping node rotation doesn't match the texture mapping rotation for some reason. Our Euler to matrix conversion follow the same order XYZ, and the functions are implemented based on the matrix from the wikipedia page on the topic, that is:


Not sure where the problem is, are the BLI eul_to_mat functions implemented wrongfully?

As @Charlie Jolly (charlie) noted, the mapping node rotation doesn't match the texture mapping rotation for some reason. Our Euler to matrix conversion follow the same order XYZ, and the functions are implemented based on the matrix from the wikipedia page on the topic, that is:

That is a ZYX rotation. Note the order of operations: X * (Y * (Z * vector))

  • Update mapping functions to match old mapping.
  • Add versioning code for Mapping node FCurves.

A file to test backward compatibility when the mapping node properties are animated.

  • Merge master and update patch.
This revision is now accepted and ready to land.Wed, Sep 4, 6:47 PM

This patch rewrites the Mapping node to support dynamic inputs. The
Max and Min options have been removed. They can be added as Min and
Max Vector Math nodes manually.

The problem is that Min and Max Vector Math Nodes don't really do the job as they should, instead all values are returned as Black.

Blender 2.80:


Blender 2.81.8:


EDIT:
OK so I dug poked a little tiny bit and wondered what if I flip to first maximum, then minimum, and voila, it works. But how is it possible that works? In any case, the way Blender 2.81.8 updates .blends right now is wrong. It puts Minimum first at 0 0 0, then Maximum at 1 1 1. Some math genius please inquire.