Height difference shader refuses to work

[ebon fjord]

Here I've got a shader that compares the height of all the points of an object to the player's height. Yes, taking B and multiplying by -1 is the intended behavior.

But the shader simply refuses to work. I've tested all the variables thoroughly. The object being compared is an object space of a line renderer whose points I can verify in the inspector. I am also debug logging the playerY variable being fed to it. (also checking the exposed playerY property of the shader)

I can verify that some of the points on the renderer are higher and some are lower than the player, hence some should be color 1 and some should be color 2 but they aren't. They are always the same color.

Why aren't they? The shader setup looks fine to me.

Yes, the renderer is in object space. Yes, it's askew by 90 degrees cause there's no "transform y" alignment option, hence getting the z.

Can anybody spot anything?

[warm thicket]

Okay I've got some questions:
1st: for what is the shader used?
2nd: What effect do you want to achieve?

[ebon fjord]

This is for a map charting system (via line renderer) where every X distance moved, a vector3 point is saved into a list.

Then it's rendered as an offset in local space on the x and y, but for z it's saved as point.y * smallMultiplier.

The purpose of this is as follows: it's a cave diving game with lots of vertical passages. I wanted the line renderer to work such that points lower than the player are color 1 and points higher than the player are color 2.

It's rendered on a tablet that's held by the player but it's in fact not 2d, but "slight" 3d due to the offset multiplier thing.

Anyway, I also get player.y * sameSmallMultiplier which is the playerY variable you see in shader graph.

Via debugging and inspector, I can confirm that some points are higher and some lower than the player, but they always show as one color.

[warm thicket]

Sorry but currently i am using normal Shaders and forgot everything about shader graph.

Can'T help. much

[acoustic leaf]

Why the -1 mult? Why subtract then use step? You can just do bigger than/less than to select a colour.
Also why use object space for the fragment position? Are you converting the player position correctly for this?

[ebon fjord]

1. -1 mult because the map is tilted by 90 degrees on the x so I can use align transform z cause the stupid line renderer doesn't do align transform y.

Aligning it to -90 would mirror the map and introduce some other issues. Doesn't matter.

2. I will eventually want to lerp the color as a gradient. I am just trying to get anything working for now

3. Object space because the calculation is already done for it. I.e. the object is set in object space as transform.y in world space * multiplier.

So it would be the same as getting world space position and multiplying by that mult.

The player position is correct. Both the player position and line points end up being around 0.002. Some are higher than the player, some are lower.

The playerY float is already done in c# with the same multiplier calculation

[acoustic leaf]

If you already convert the player position to object space then you do not need to do anything else after

because that would include rotation

Then you just need to "select a colour" or smoothstep or lerp based on it being above/below

[ebon fjord]

My subtraction was the "if statement" and step was color selection. Maybe I can do it cleaner but regardless...why isn't it working?

[acoustic leaf]

Over complication leading to bad values so what you test is always showing one of the two results

try with world space comparison to the player y value -> step -> lerp and then verify

[ebon fjord]

I did try world space too. Also, I can see the exposed float in the inspector and it looks good.

[bold tiger]

Yeah, I'd start with simpler logic to verify the variables used are indeed what you expect. Maybe even just output the z position to color directly(+one multiplied by - 1 to see if it really makes sense to multiply it).

[ebon fjord]

Yeah but the numbers are too small for such a test. I won't be able to tell the difference between 0.0021 and 0.0023.

Maybe I can devise a different test tho

[bold tiger]

maybe remap the expected range to 0-1.

[stiff viper]

Main thing to do is verifying your expectations, node by node if need be
I test using more than one mesh with the shader, so it becomes visible how different geometry shapes and positions affect it, a sample gradient node with remap to clearly tell what values I'm looking at, with a fraction node optionally if going way outside 0..1 range

[ebon fjord]

I can't understand why this doesn't work.

So I've done a bunch of test with fractions, remaps, this and that. The following are the only useful facts to me:

1. Instead of using playerY, I exposed a test float in the inspector. When that float is 0, the line between green and red is in the middle.

As I increase or decrease it, the line shifts up or down. So far so good.

2. When I move with it as the player, it doesn't seem to shift, even when I multiply the variable by 20. I don't see why this would be the case.

I have multiple points in the line renderer. Some have a higher z (height in this case) value and some have lower.

If player is at 0.02 after multiplication, and is in between line renderer points where point A is at 0.01 and point B is at 0.03, I don't understand why one line shouldn't be red and one green, regardless of the player moving with it.

We're just comparing floats here.

Maybe for some reason I can't do this with a shader. Maybe I should just set vertex color in the line renderer for each point.

I'm sure that would work but I'm also sure that's way less optimized as I would need to set it for every vertex in update

idk, maybe I'm just confused

[stiff viper]

A value from an exposed inspector property gives you different results from the exact same value when got based on the player's position? That can't be right

[ebon fjord]

The only thing that "could make sense " theoretically is the player moving keeps it at the same place because the tablet is parented to it, but I don't understand why that would be the case given the logic

[stiff viper]

Did you log the property you actually are passing to the shader when using player position for it

[ebon fjord]

Yes

as you can see, some values are higher and some lower than the points on the renderer

I know the renderer points have a negative sign, hence the * -1 in the shader

[inland marsh]

An if you used those exact same values logged on the exposed float property (instead of player position), it works ?

[ebon fjord]

actually, it doesn't work on the line renderer. It just worked on a sphere I was testing out.

So, it doesn't change color at all no matter what float I input, negative or positive.

The material preview changes color, but not the line renderer.

Hmmm

[inland marsh]

Then I think that now the thing to do is to make the float property intermediate solution to actually work with the line renderer.

[ebon fjord]

what do you actually mean by that?

[inland marsh]

Like, apply the shader to the line renderer, manually input the "player position Y" through an exposed property, and make it work with the line renderer.
Not play mode, no script that changes the values and mess things up.

[ebon fjord]

The line renderer is null before I move around and map some points. That's why I tested it on a sphere and it worked.

I suppose I could make a temporary static line renderer

[inland marsh]

You can also enter play mode, copy the line renderer, and then paste in edit mode.
It should make a carbon copy of the one in play mode

[ebon fjord]

Aha, that's good to know.

Will do that (now I have to go for work), but idk why it wouldn't work on this one even if I manually input a really high or a really low value; it should change color

but I have to test everything I guess

[stiff viper]

If the test is should be comparing apples to apples and it doesn't work, that's at least pointing towards an error, whether technical or in assumptions

That the test with the exact same value is actually in different editor state and/or on a different mesh is also a very notable point

[ebon fjord]

So the test has bore some results

I compared the sphere (background) and line renderer with the same material.

Just as I was about to post that the line renderer doesn't change color, it seems I haven't been trying values low enough (below 0 is enough for the ball).

Turns out the value of -558.085 about splits the line renderer line in half.

It will be fun figuring this one out

[stiff viper]

Remember that local space can include all kinds of hierarchically inherited transform values

The conversion is the one part we can't see, and the part the testing seems to be pointing towards

[ebon fjord]

everything up to the line renderer is at scale 1

I Debug.logged the player variable (irrelevant, cause I'm trying it manually anyway) and the line renderer components debugs the other values

what unity is trying to tell me, is that 0.02 - 558 = 0

and I will have to disagree with that

[stiff viper]

Is the "split" even aligned against the transform's Z axis as the SG indicates it should?

[ebon fjord]

You mean the actual height? I was just about to test that now

oh you mean is the z axis the right one to use? It is

I thought you meant does the split follow the actual height trajectory in the line renderer and I was about to test that

[stiff viper]

That would be good to know as it's not visible through the image

[stiff viper]

Not quite what I asked
Asking because according to the clues we have the split should be vertical, but here it looks horizontal
Though answering the latter question should confirm that

[ebon fjord]

I don't think that's true. It's rotated by 90 degrees on the x so z is height. The split seems horizontal because the differences in height are microscopic

but now I will remove the multiplier to better see height

[stiff viper]

If it's practically flat, then you wouldn't really know even if it was working right

[ebon fjord]

well, it would need to change color at least with a small change of the float but we'll see now

Yep, seems correct

[stiff viper]

Finally something to confirm with our eyes ^^

Line renderers are procedural geometry like particle systems, so in a similar way it's possible they may have some dynamic batching that combines their local spaces together

[ebon fjord]

yea basically the only remaining explanation I have is that Position (object) in shaders doesn't work for line renderers

that's about the only thing I can conclude from this

I mean, I could have very easily set the vertex color manually in code for every line in update, but I wanted to avoid that

this was supposed to be simple and good

[stiff viper]

Or you can do the coloring in world space relative to a position vector you set from a script to match the line's position

Or position and rotation if you wish

The only not-simple thing seems to be the goose chase itself

[ebon fjord]

that won't work. If I set it relative to the player, for example, if I raise the tablet above my head, it's going to turn green. If I lower it, it will turn red

[stiff viper]

That is not what I suggest, but instead of comparing the player position to the geometry local space as you do now, compare it to the object transform position and rotation, or arbitrary position and rotation

Nowadays you can get those values directly inside SG

[ebon fjord]

Actually, I don't understand what you mean. Isn't that what I said above?

And I don't understand what you mean by rotation.

[stiff viper]

I may have misspoken, so:
Instead of adding player world height to geometry forward axis and comparing to threshold (in local space)
I mean adding player world height to transform aka object forward axis and comparing to threshold (in world space)

Even if the comparison occurs in world space, it's purely relative to the rotated object's personal forward axis

Getting this transform forward axis in world space requires both position and rotation

[ebon fjord]

ah I could try it, but that's all under the assumption that object space is that which doesn't work

cause, again, I can see all the points in object space in the line renderer component and all the numbers check out. Should work.

Maybe it's possible to debug what values I'm getting with shader graph

[stiff viper]

Have you tried outputting object space position directly in a way that tells you what values are actually on it

Saturate, fraction, gradient all give you some kind of useful information about it

[ebon fjord]

yeah I am just doing that now

I plugged Position (object) directly into step (edge 0) and into base color

[stiff viper]

Step only tells you what's positive and what's negative
Doesn't tell you how large the range between 0 and 1 is, or where its midpoint is

[ebon fjord]

yes, as I'm just finding out

it gives me a gradient but that's because of color intensity, right?

it does work logically

[stiff viper]

Can you show what that means in this case

[ebon fjord]

what I mean is it gets whiter the more up I go and darker the more down I go

but that's because the color isn't normalized, right?

[stiff viper]

It is meant to be a gradient in any case
Saturating would cap it to 1, otherwise it keeps increasing beyond it and becoming brighter
With HDR it's nearly impossible to tell where "1" brightness is, even if saturated
That's why gradient node with a variety of colors helps

Normalizing at least with the node would set its length to 1, so it'd always be 1

[ebon fjord]

I thought it was meant to output 0 if less than 0 and 1 if it's more than zero with step (edge 0)

[stiff viper]

With Step yes, indeed

[ebon fjord]

well then I shouldn't be getting a gradient lol

[stiff viper]

That to me indicates a problem with how you're testing
Interference from post processing or lighting or similar

[ebon fjord]

you might assume that but the shader is unlit

in any case, shouldn't it turn black as soon as I drop it below 0?

[stiff viper]

Yes

Specifically when the input value goes below 0

[ebon fjord]

yes, it doesn't

ok, it doesn't even work in world space

yeah idk man

fuck this

[stiff viper]

That sounds like testing is again giving useful clues
Hard to do much but guess when you are showing so few images or footage of what you're testing and how, exactly

[ebon fjord]

yeah I mean ok

this is the current test

no matter how many units I move it up or down, it looks like this

then we have this

(this just plugs into base color, multiply is not used here)

[stiff viper]

HDRP uses "absolute world" iirc

[ebon fjord]

it's gray at 0, at 50 or at -50

[ebon fjord]

oh shit

[stiff viper]

Ideally these would not be cropped out, but mentioning them is about as good

[ebon fjord]

anyway, here is object -50

and object 50

[ebon fjord]

cause I have a bunch of disconnected ones so as not to confuse you. It's just position - split - step - base color

here is 200 with absolute world space

I mean 200 relative to the world, unparented

here is -200

at 0 in both spaces, I can't tell the difference when I slightly jiggle it up or down (which should be an instant flip from my understanding of step)

[bold tiger]

What position is it if it's not patented to anything? "unparented = -200" sound like world -200.

So yes, it will be black there.

[ebon fjord]

that grey one is +200, the bottom darker one is -200

[bold tiger]

OK. And that's with the shader graph you shared earlier?

[ebon fjord]

just above those last pics

[bold tiger]

Can you just leave the line renderer for a moment and use a quad or plane mesh?

Quad would be better, as it's vertical by default.

Scale it by 100 or something and see how it behaves with each of the coordinate spaces.

[ebon fjord]

I used a sphere a long way back. It worked with the original shader the way it was supposed to. Line renderer didn't

[bold tiger]

Yes, expect you never showed us anything. Did you try rotating/orienting the sphere the same way as the line renderer? Also, it could indeed be batching. I'd check the frame debugger to confirm that.

When you test with a line renderer make sure there's only one object

Also, the coordinate space of the points in the line renderer could possibly affect the results too.

[ebon fjord]

It can't be a batching issue when it works at arbitrary altitudes. My original shader would start changing color at like -558 height.

I also tested this simpler pure step shader and instead of changing from white to black, it gives a gradient.

I elongated one of the poitns by 5000 meters, and you can clearly see a gradient the more you move up/down

same thing happens when I use absolute world space without any parents

which eliminates scaling, coordinate space etc I guess

also, I showed a screenshot with a sphere switching colors, but the line renderer not doing that somewhere above

so the color change does happen, just not the way it's supposed to

and pure position into split (g/b) into step into base color gives a gradient over a large distance, instead of a black to white cutoff

[bold tiger]

I just scrolled up and couldn't find any sphere screenshots.

Anyways, if you actually want to see the numbers in the shader, you'll need to use shader debugger like that in PIX.

Do you have "use world position" checked in the line renderer?

I just tested a simple unlit shader with abs world position y plugged into output(and later with a step node in between too) and it works as expected with that toggle unchecked. With it checked, it treats the point positions as relative to world origin.

The only 2 quirks I can see is that checkbox and the difference between world and absolute world in hdrp.

[ebon fjord]

No, world position is off and I tried absolute world and object.

[bold tiger]

Well it worked in my simple repro case, so it must be something specific to your scenario that breaks it.
I'd try a simpler repro case in your project for sanity.

[ebon fjord]

when you say as expected, do you mean it just switches from black to white when it crosses a barrier, as I'd understand step to behave?

I have moving "artifacts" on a simple sphere with this setup

wait, I may have an idea

[stiff viper]

When debugging the color you should turn off post processing, sans for fixed exposure

[ebon fjord]

I think I figured it out

if I did, it's a unity bug, not mine

lemme check

[ebon fjord]

So, get this

Position (Object) is BROKEN for the line renderer, at least with my unity version or line renderer setup

it doesn't work: it just outputs world position

I figured that out when I set the step edge to the actual world position the line renderer was at and it started splitting it in half

so not only is there this issue, but this also means that even though my Z axis was up due to rotation, Y is actual height regardless because object position seems to be broken

so I had no chance to figure it out quickly because using z gave me a number which made no sense.

If I had used y, I would have figured out that step edge is at world height.

But because I was using z, the step happened at a seemingly random number I couldn't make sense of

so this is not on me IMO

seems like I won't be able to use object position for this one

[bold tiger]

With step, yes.

[bold tiger]

Can you show the line renderer component settings?

At the test time at runtime.

[ebon fjord]

Did you test object space tho? That seems to not work for me

[ebon fjord]

I'm at work now. Can show later, but x and y are irrelevant, z is around 0.02. If I go higher, new point is higher. If I go lower, it's lower, but it's always a smaller number like that

[ebon fjord]

So I tried this method and it finally works

it took me a bit to conceive of how to do it cause I'm stupid but I think this is what you meant:

this is my latest setup

so, step in this case had issues with flickering; I'm guessing due to the number being to small, so it flickered between red and green

smoothstep fixes that and also gives a gradient, which is something I wanted anyway

Shader is done, I can do more with the color and visuals, and then I'll need clipping etc. but the basic logic is done

It's crazy that I wasn't able to do this with object space when it was so simple.