Lines don't do corners

[De3d]

Non of the lines turn corners without breaking, through the entire corner.

Is this intended?

This is particularly ugly, and even odd on the animated line.

And the only line with segments for corners, to solve this problem, is the default line.

2019.1, latest, being used.

[azable]

I'm noticing the same issue. It only seems to affect VR deployments (using the Oculus Quest in my case); in the Unity editor and local PC builds, lines are capped just fine. I've narrowed it down to line 65 of MeshChain.cginc, where there is logic to detect whether we are rendering a billboard or pipe. For example, setting pipeFlag to 0 makes all segments billboards, and they render as expected in VR (but of course we don't want all segments to be billboards). I've tried a few modifications to no avail, such as comparing the world space positions of a vertex and its neighbour (rather than screen space). Has anyone found a fix or workaround for this?

[AndrewTHEManeri]

Thanks for the detailed repro there. I'll see if that happens on my rift and if not will look at testing on the Quest.

[azable]

Any luck reproducing this? It's a very strange issue, I can't seem to figure out why it only affects deployments

[AndrewTHEManeri]

I have reproduced this (the steps were very helpful) - it happens in general on android. Working on a fix. I suspect it's not actually line 65 where the problem lies (as I've replaced the step command with all manners of other ways of doing that calculation) but rather some compiler bad-optimization happening later on that uses the pipeflag

[azable]

You're right, I think this is some sort of compiler optimisation issue. I've come up with a fix by changing lines 78 and 79 of MeshChain.cginc to use branching instead of lerp (dependent on pipeFlag). This appears to change the compiled GLSL code significantly, though I haven't had time to decipher the compiled code to figure out exactly what's going on.

In other words, I replaced:
o.pos.x += lerp(billboardVec.x, perpVec.x, pipeFlag) * expandDistanceSource;
o.pos.y += lerp(billboardVec.y, perpVec.y, pipeFlag) * expandDistanceSource*aspectRatio;

...with the following:
o.pos.x += (pipeFlag ? perpVec.x : billboardVec.x) * expandDistanceSource;
o.pos.y += (pipeFlag ? perpVec.y : billboardVec.y) * expandDistanceSource*aspectRatio;

I'm happy to create a pull req with this fix if you wish. It does use branching which isn't as efficient, but it seems that the compiled GLSL code ends up using branching anyway (the converted type of pipeFlag ends up actually being a bool). I'm also not sure if there could be additional implications for treating pipeFlag as a bool in my fix. It might be safer to change its type to something non floating.

[JohnathanWells]

You're right, I think this is some sort of compiler optimisation issue. I've come up with a fix by changing lines 78 and 79 of MeshChain.cginc to use branching instead of lerp (dependent on pipeFlag). This appears to change the compiled GLSL code significantly, though I haven't had time to decipher the compiled code to figure out exactly what's going on.

In other words, I replaced:
o.pos.x += lerp(billboardVec.x, perpVec.x, pipeFlag) * expandDistanceSource;
o.pos.y += lerp(billboardVec.y, perpVec.y, pipeFlag) * expandDistanceSource*aspectRatio;

...with the following:
o.pos.x += (pipeFlag ? perpVec.x : billboardVec.x) * expandDistanceSource;
o.pos.y += (pipeFlag ? perpVec.y : billboardVec.y) * expandDistanceSource*aspectRatio;

I'm happy to create a pull req with this fix if you wish. It does use branching which isn't as efficient, but it seems that the compiled GLSL code ends up using branching anyway (the converted type of pipeFlag ends up actually being a bool). I'm also not sure if there could be additional implications for treating pipeFlag as a bool in my fix. It might be safer to change its type to something non floating.

Thank you alzab, that did it for me!

[myehiah]

You're right, I think this is some sort of compiler optimisation issue. I've come up with a fix by changing lines 78 and 79 of MeshChain.cginc to use branching instead of lerp (dependent on pipeFlag). This appears to change the compiled GLSL code significantly, though I haven't had time to decipher the compiled code to figure out exactly what's going on.

In other words, I replaced:
o.pos.x += lerp(billboardVec.x, perpVec.x, pipeFlag) * expandDistanceSource;
o.pos.y += lerp(billboardVec.y, perpVec.y, pipeFlag) * expandDistanceSource*aspectRatio;

...with the following:
o.pos.x += (pipeFlag ? perpVec.x : billboardVec.x) * expandDistanceSource;
o.pos.y += (pipeFlag ? perpVec.y : billboardVec.y) * expandDistanceSource*aspectRatio;

I'm happy to create a pull req with this fix if you wish. It does use branching which isn't as efficient, but it seems that the compiled GLSL code ends up using branching anyway (the converted type of pipeFlag ends up actually being a bool). I'm also not sure if there could be additional implications for treating pipeFlag as a bool in my fix. It might be safer to change its type to something non floating.

This works! Thanks a million alzab!