[LWRP] Certain primitives get their world position as local position in their shaders

Hello

Having this issue in both 2018.2.6 with LWRP 3.0.0 as well as 2018.3.0. Haven't gotten around to trying it out in 2019.

It appears as if certain primitives (planes, quads, cubes, cylinders) get their world positions as local positions in their shaders IF there are more than one of that type in view. Same issue occurs with a model an artist built in Blender which was also a plane.

I've tried in LWRP, HDRP and standard, only see the issue in LWRP.

I've tested with a super simple shader: based on the object's y position (v.vertex.y), compare it to a step value and use the result as albedo, so it'll return black or white.

Adjusting the step value, everything behaves as expected. Setting the editor to LWRP, suddenly certain objects mentioned above use their world positions in place of local, so need to set the material to their world y position for the same effect. If there is only 1 e.g. cube in view, it works. If a second one enters view, issue appears.

Spheres and cylinders are unaffected.

Sorry if this is a known issue, I couldn't find anything about it. I hope I'm not missing something, but I have a hard time seeing this is how it's supposed to work.

Attached the shader I used to debug this.

 

Have also submitted a bug report with an example
1117576

 

maybe thats from batching, see DisableBatching tag here:
https://docs.unity3d.com/Manual/SL-SubShaderTags.html

 

Interesting, that works. Thanks!

I tried disabling Static and Dynamic batching as one of the first things I did, since it looked like a batching issue, but that was apparently not sufficient. Adding that tag works, though. One issue is that shaders generated in the graph have this enabled, so it's cumbersome to manually add every time.

That leads to some follow-up questions though. Why does this only happen in LWRP? And why does it only affect certain object types? And how does setting the tag in the shader differ from globally disabling batching features?

 

don't really know.. but doesn't lwrp has its own settings for batching?

also can check with Frame debugger to see why certain objects won't get batched
can see list of some of the causes here,
https://github.com/Unity-Technologies/BatchBreakingCause

 

Oh crap, you are right. I forgot about that...
Disabling it in the LWRP settings gets rid of the issue.

So fiddled around a bit more to confirm, and yes: it's the dynamic batching that does it. Sp type of object doesn't matter, as long as it's elible for dynamic batching, the issue occurs.

GPU Instancing does not cause this issue.

Thanks again

 

Followup for anyone interested

Did some testing, it seems it all boils down to batching in the end and is probably by design

I said it only affected LWRP; that was because LWRP has its own dynamic batching setting. I tried again with HD and standard, and could reproduce the behaviour with toggling the batching settings in the player settings accordingly. Setting the static batching flags on the game objects, the same behaviour is reproduced in the capsules and spheres as well, i.e. objects that aren't automatically dynamically batched.

So I can accept that this happens and why it happens, however I don't fully understand why worldposition would be used as local position. Even when batched, the local position should be the same?