Remap Float Range

63 views
Skip to first unread message

Victor Barbosa

unread,
Jul 17, 2024, 7:44:52 AM7/17/24
to gaffer-dev
Hi Gaffer team,

I am trying to use a OSL RemapFloat node to help me normalize a floating value from another node and then drive the "radius" attribute on a OSL ColorCurve node, please see file attached.

I wondering why the output of the OSL RemapFloat node is always outputting 0 no matter what settings or values I use in the node. I need help to understand what I am doing wrong.


Many thanks
Victor Barbosa
rempaRangeTest.gfr

eric...@gmail.com

unread,
Jul 17, 2024, 11:23:10 AM7/17/24
to gaffer-dev
I think it's a problem with your AttributeQuery node rather than the RemapFloat node. Assuming you have a scene with geometry plugged into the CustomAttributes node, you'll need to set the location to something that exists in the scene.

I'm guessing that you're using `.` to try and get the current location being processed? In Gaffer that would _normally_ be `${scene:path}`. Except that variable is removed when evaluating shader networks, so you're always going to get the default value. If you rename the attribute to `render:test` (the `render:` makes Gaffer output the attribute to the renderer), it will be available to an OSLInFloat shader under the name `test`. So you wouldn't need an AttributeQuery.

Victor Barbosa

unread,
Jul 18, 2024, 10:11:13 AM7/18/24
to gaffer-dev
Hey Eric I appreciate your replay, 

But what puzzles me, is that a node like "cyclesValue" where stores a float value connected to a the "input" of a "oslRemapFloat" node is not working, which I would suppose it is the most simplistic setup.
Even if I connect directly the "cycleValue" node to the radius of the "oslColorSpline" node, the value displayed in the "node editor" still at 0, where the input node is set to output 10.

Also if I set manually the input value in the remap float node, its output value still 0. Another example that it is not working is connecting the value node to a multiply node's "input1.r" parameter, the multiply node displays "0" in the node editor for the input1 plug.

I hope it make sense. 
image_2024-07-18_070740927.png
Screenshot from 2024-07-18 07-08-18.png

eric...@gmail.com

unread,
Jul 18, 2024, 11:09:36 AM7/18/24
to gaffer-dev
Ah ok, I see what you mean. The values shown in the node editor are not taken from the shader itself. To do that we'd have to be evaluating the shader output to get the value. That would make sense for a simple shader like `cyclesValue`, but would not make much sense for a more complicated shader, like one that depends on point position or some other varying value.

Are you previewing the shader with the shader ball? That for me is not working for some reason. But if I set the viewer to my scene and activate the Cycles viewport mode with `shading` set to `full`, or a traditional interactive render with catalogue, it works as expected.

I'll look into why the Cycles shaderball isn't working.

Victor Barbosa

unread,
Jul 18, 2024, 1:26:36 PM7/18/24
to gaffer-dev

Hey Eric,

I am comparing what I see on the node inspector and what I get with python. So both are giving me "0" value, so I believe the problem is not related to shader ball. 
As shown in the attached image, I created a RemapFloat node and set value of 10 to the "in" parameter, then set the in range to -30 to 50. Then I ran a python code to query the "out" value from the RemapFloat node expecting to get some value besides "0", but no luck.


It looks like the node is not even working.
Screenshot from 2024-07-18 10-21-31.png

eric...@gmail.com

unread,
Jul 18, 2024, 3:06:13 PM7/18/24
to gaffer-dev
Out plugs on shader nodes don't evaluate the shader, so you're always going to get back some default value assigned to the plug when using `getValue()`.

If you want to see the shader output, I think the only way is to create a scene and assign the shader directly to an object. You don't need to use a Cycles BSDF, you can assign the RemapFloat shader to a cube, for example, and an Interactive Render or Cycles viewport will show you the value of that shader.

The reason my shader ball was not working was because it was defaulting to Arnold as the renderer for OSL shaders, not Cycles. If you're having the same problem, you can clear your `ARNOLD_ROOT` environment variable so that Gaffer doesn't load Arnold functions.

- Eric

Victor Barbosa

unread,
Jul 18, 2024, 6:26:41 PM7/18/24
to gaffer-dev
I am a bit confused about you calling a "oslRemapFloat" a shader. 
All I would like to do, is to normalize an input value between 0 -1 range. I can achieve it in Maya by using a remap range node. In Blender is the same thing with "Map Range" node.

Am I confusing some concept about math nodes in Gaffer?? Or "oslRemapFloat" is not meant to be used like the way I am trying to?

Many thanks

Daniel Dresser

unread,
Jul 19, 2024, 4:06:08 AM7/19/24
to gaffer-dev
Yeah, in Gaffer the osl-prefixed nodes are shader nodes, and it's true we don't currently have a way to drive inputs to arbitrary Gaffer nodes from the output of a shader - all you can do with shaders is hook them up to an OSLObject or OSLImage, or use a ShaderAssignment to assign them, and then render. Thinking about using node networks to drive arbitrary Gaffer node inputs, there are some interesting ideas here - we could create a node that evaluates a shader network with specified input and uses that to drive an arbitrary plug ( and maybe at the very least we should make it an error to try and directly use the output of a shader, instead of connecting it to something that needs a shader connection ... that would have made it a lot more obvious what's going on ).

Anyway, I suspect the reason this hasn't come up to much is that most people who are wanting to drive arbitrary node inputs are happy using expressions - you can create an expression, set it to OSL mode, and put whatever OSL you want in there if you're happy typing it. But it could be interesting to survey more Gaffer users and see if there are people who would be interested in some way of building expressions using little nodes instead of typing expressions.

-Daniel

Victor Barbosa

unread,
Jul 19, 2024, 9:10:13 AM7/19/24
to gaffer-dev
Hey Daniel,

Thanks a lot for taking the time to explain it. I think there is a lot to gain offering artists to do math operations with a library of math nodes that are not necessary shaders, and allow lookdev artists and lighters with less scripting experience to use nodes instead, also in my opinion there is the clarity in using math nodes instead of expressions, where a network of nodes is more obvious and clear to understand than obscured or hidden expressions in expression nodes. 

Anyways, great stuff.
All the best
Victor Barbosa

Reply all
Reply to author
Forward
0 new messages