"Print a value" custom function node code for Unity ShaderGraph

DebugNode.hlsl

// Quick try at doing a "print value" node for Unity ShaderGraph.
// Tested on Unity 2019.2.17 with ShaderGraph 6.9.2.
//
// Use with CustomFunction node, with two inputs:
// - Vector1 Value, the value to display,
// - Vector2 UV, the UVs of area to display at.
// And one output:
// - Vector4 Color, the color.
// Function name is DoDebug.

// "print in shader" based on this excellent ShaderToy by @P_Malin:
// https://www.shadertoy.com/view/4sBSWW

float DigitBin(const int x)
{
    return x==0?480599.0:x==1?139810.0:x==2?476951.0:x==3?476999.0:x==4?350020.0:x==5?464711.0:x==6?464727.0:x==7?476228.0:x==8?481111.0:x==9?481095.0:0.0;
}

float PrintValue(float2 vStringCoords, float fValue, float fMaxDigits, float fDecimalPlaces)
{
    if ((vStringCoords.y < 0.0) || (vStringCoords.y >= 1.0))
        return 0.0;

    bool bNeg = (fValue < 0.0);
    fValue = abs(fValue);

    float fLog10Value = log2(abs(fValue)) / log2(10.0);
    float fBiggestIndex = max(floor(fLog10Value), 0.0);
    float fDigitIndex = fMaxDigits - floor(vStringCoords.x);
    float fCharBin = 0.0;
    if (fDigitIndex > (-fDecimalPlaces - 1.01))
    {
        if(fDigitIndex > fBiggestIndex)
        {
            if((bNeg) && (fDigitIndex < (fBiggestIndex+1.5))) fCharBin = 1792.0;
        }
        else
        {
            if(fDigitIndex == -1.0)
            {
                if(fDecimalPlaces > 0.0) fCharBin = 2.0;
            }
            else
            {
                float fReducedRangeValue = fValue;
                if(fDigitIndex < 0.0) { fReducedRangeValue = frac( fValue ); fDigitIndex += 1.0; }
                float fDigitValue = (abs(fReducedRangeValue / (pow(10.0, fDigitIndex))));
                fCharBin = DigitBin(int(floor(fmod(fDigitValue, 10.0))));
            }
        }
    }
    return floor(fmod((fCharBin / pow(2.0, floor(frac(vStringCoords.x) * 4.0) + (floor(vStringCoords.y * 5.0) * 4.0))), 2.0));
}

float PrintValue(const in float2 fragCoord, const in float2 vPixelCoords, const in float2 vFontSize, const in float fValue, const in float fMaxDigits, const in float fDecimalPlaces)
{
    float2 vStringCharCoords = (fragCoord.xy - vPixelCoords) / vFontSize;
    return PrintValue( vStringCharCoords, fValue, fMaxDigits, fDecimalPlaces );
}

void DoDebug_float(float val, float2 uv, out float4 res)
{
    res = float4(0.3,0.2,0.1,1);
    res = PrintValue(uv*200, float2(10,100), float2(8,15), val, 10, 3);
}

It wouldn't let me enter 4 digits before and after the decimal place unfortunately. But all these tests produce slightly incorrect results:

314.159 -> 314.158

14.15 -> 13.149

4.1 -> 4.099

Even when using a divide block though to produce 1/2 (0.5), which should be exactly representable in a float, the result is still incorrect at 0.599:

The same is true for 1/4 (0.249), 1/8 (0.124).

Hmmmm, ok. Thanks for those! I'll investigate this as soon as I can.

Ok, I've got an update.

It seems that the cause is a rounding error happening in line 47.
The division that happens after exponentiation (before taking the absolute value) is not returning correctly.

The following is a test run I made with Value being 0.01 (and getting 0.009 in the shader output).

Here is the state before the division, where r0.z has fReducedValue and r0.w has the result of pow(10, fDigitIndex):

And here is after the division:

It was expected to have 1 at r0.z

This is not an issue with this shader, so all I can to do is file a bug report and try to find a workaround. I'll keep you updated if I manage to find one.

---

UPDATE:
Turns out the issue is NOT in the division, but one step earlier. On the exponentiation. In its first step (log instruction).

These three lines in the assembly are the entire pow function in action. Note that the result is going into r0.w.

In r0.z is the original 0.01 typed inside the Shader Graph. Note how the values are different (least significant bit is off by one).

0.01 in Hexadecimal, following IEE-754, is 3C23D70A. r0.z is correct, r0.w is off by one.
This error seems to be happening due to precision error. As the result of log2(10) in 32-bit is 3.32192802 and in 64-bit is 3.3219280948873623478703194294894. This difference of ~0.000000075 is propagating itself on the next two lines, causing the issue. The more negative fDigitIndex is, the more imprecise the result of pow gets.
I say this because, when I try to do the math myself using those different precisions, the error shows up with 32-bit but not 64-bit.

Since we can't request 64-bit precision for a specific node, I'll try to create a custom pow function, less performant of course, that avoids this issue.

@Arlorean Workaround found! You can check my fork for a "fixed" version.
https://gist.github.com/bestknighter/660e6a53cf6a6643618d8531f962be2c

Thanks @bestknighter, that's great work. I'll use your forked version.

Small issue...

@emilioparker are you using my fork? This version has some small bugs with float precision and I made a workaround on my fork.

King

Building upon the work of @aras-p and @bestknighter, I've developed a DebugSubGraph to streamline the process of setting up debug nodes .

Building upon the work of @aras-p and @bestknighter, I've developed a DebugSubGraph to streamline the process of setting up debug nodes .

Wow! Amazing stuff! Thank you for crediting us! That's very much appreciated.

I am new to shaders, and printing values seems like an awesome tool, but one thing that puzzles me is that the printing using the debugsubgraph depends on position. When I attach a position node, I get nonsense numbers. This makes sense, since the position node changes depending on where you are, but I figured I'd share since this interaction is hilarious and this may help other users. Also if anyone knows how to use this tool to debug things with position nodes or view direction nodes, let me know

I am new to shaders, and printing values seems like an awesome tool, but one thing that puzzles me is that the printing using the debugsubgraph depends on position. When I attach a position node, I get nonsense numbers. This makes sense, since the position node changes depending on where you are, but I figured I'd share since this interaction is hilarious and this may help other users. Also if anyone knows how to use this tool to debug things with position nodes or view direction nodes, let me know

Hahaha yep, that's totally by design.
The only way I can think of achieving what you want is by some kind of way making Position node (or some other node between it and Multiply) output a single value. Just like using a Texture Sampler with locked UV coordinates instead of the vertex/fragment UV. Maybe outputting the world position of the object instead of the vertex/fragment? I'm not sure how doable this is. I can't think of anything beyond this right now, sorry about that.