Shader Graph - object position node is wrong on multiple objects

Unity Engine
, , ,
1

Hello everyone,

I am experimenting on a shader and struggling as I am not very familiar with the shaders.

Using shader graph on LWRP

What I am trying to do is very simple. I am using the object node the get the world position of the object to displace the whole mesh upwards according to the mesh’s position.

The thing is it works when I create a single mesh with the material but when there are more than 1 object, the object node starts to give exact same position for all objects (or maybe their average position?).

The workaround is disabling the dynamic batching on LWRP settings. then it works as intended. here is a very simple scene view of the working system

soo finally my question:

  1. is it worth disabling the dynamic batching? do I lose too much?

  2. is it possible to disable dynamic batching on only 1 shader using shader graph? and again is it even worth for single shading?

  3. is there any other way to handle this? (I can create a shader variable and set it on awake to use as the object position node)

I didn’t put a video to show how it’s not working with dynamic batching but basically all of the tiles, wherever they are have exact same displacement as they all have the same data from the object node.

Thanks

2

I had a similar issue, and solved it by assigning a new material (with the same shader) to each object. You can manually duplicate the material, or programmatically new Material(yourMaterial);.

Although I would also like to know if there is more elegant solution.

3

For normal shaders there is a DisableBatching tag than can say that a shader is not available for batching, but i have not seen a way to enable it in the shadergraph.

4

Disable dynamic batching and enable the SRP batcher instead.

1 Like
5

@bgolus in my case dynamic batching was already disabled and SRP batching enabled. I even disabled static batching just to check. I’m still on 2019.2.8f1 so the behavior might differ in a newer version.

In the end I went along with copying the material, I won’t have more than 1-2 instances at most times so I’m not worried. But it would be nice to find a better solution.

6

I have the same issue as described above. Is there any kind of workaround using a custom function node?

7

Nope. Support has to be added at a much higher level. The only solution right now is to not use Shader Graph, or to hand modify the generated shader code from Shader Graph.

8

Hey @bgolus , if I were willing to learn to do this without Shader Graph, where would you recommend I start?

thanks

9

Define “do this”.
If it’s “fix the bug described in this thread”, then AFAIK it’s already fixed.
If it’s “write shaders for SRPs”, please don’t ask off topic questions in existing threads.

10

Ah right, I meant to say solve this bug via shader code rather than resorting to multiple, identical materials.
I’ll consider my question out of scope then, cheers and thanks for your time.

11

If the issue still exists when using Shader Graph, then it’s something that should be reported as still being a problem, assuming you’ve already disabled dynamic and static batching.

If you want to fix the issue by modifying the shader code manually, then it would depend on what the problem is that’s causing it. I do not personally remember what the specific cause of the issue was to be honest, but I vaguely remember it being something surprisingly nasty, like the matrices used to calculate world space being bogus while the vertex shader section of the Shader Graph code was running, and then set correctly just afterwards. But I could be wrong, it’s been almost a year and I don’t use the SRPs with any regularity.

12

The only solution I have found for my self is duplicating the Material in runtime using this script:

public class MaterialDuplicator : MonoBehaviour
{
  void Awake()
  {
    Renderer renderer = gameObject.GetComponent<Renderer>();
    renderer.material = new Material(renderer.material);
  }
}

Attach this script to the Object with the Renderer

13

Interesting. It was only happening in play mode but I am guessing the objects are marked static and being batched resulting in bogus object space.

Thanks for the thread. I guess for draw calls this could get expensive for large numbers of objects…

1 Like