Godot: GLES2 batching bug with shared shader material

[oeleo1]

Godot version:
3.2.2-beta2

OS/device including version:
Windows 10

Issue description:
Kudos for the work on 2d batching! As a bonus, here is a simple bug which appears when using a shared material on two sprites. When only one sprite is visible, the sprite is distorted cf. the simplest of shaders in the material.

But when the same sprite is duplicated and both are visible, they start rotating around. Easy to see in the attached minimal project when toggling visibility of one of the sprites.

Steps to reproduce:
In the attached project, toggle visibility of on of the sprites sharing the same shader material.

Minimal reproduction project:
gles2_batching_bug.zip

[lawnjelly]

Haha that's an impressive bug!! :grin:

To be honest with you I was a little sad at the lack of bugs in the latest beta, I missed fixing them. Although this should really be a good thing!

Ok this bug looks pretty simple actually, and easy to fix. I think it's because it is reading the vertex position in the shader, and normally that is fine, but with batches using software transform, the item transform is baked into the command transform.

So the sin and cos are being multiplied by the baked (global) value instead of the local position. The easy solution is just to disable batching if the shader is reading the vertex. There may be a few more instances in custom shaders that need a similar tweak in the future, I noticed this while dealing with the new MODULATE keyword. Luckily they are very easy to fix, as the framework is already in there! :+1:

[oeleo1]

Happy to submit quality bugs :-)

Hm. Note that if the material of Sprite2 is made unique the problem disappears. Does that corroborate your hunch on the cause of the issue?

[lawnjelly]

Very probably, I've already fixed it, just preparing PR now. :+1:

Yes the unique material fixes it because different materials prevent the 2 sprites batching together, and thus there is no baked transforms.

[akien-mga]

Fixed by #38669.

[oeleo1]

To my surprise with the latest beta3 we observe the same visual regression despite the fix.

Looking at it more closely, the reason is that contrary to the reproduction project submitted here, the custom shader we use has "render_mode unshaded;".

You can thus reproduce the same problem with the same reproduction project by adding "render_mode unshaded;" to the shader material. I include the modified project again for convenience.
gles2_batching_bug2.zip

I guess this has to be reopened, unless a new issue would be more appropriate.

[lawnjelly]

I guess this has to be reopened, unless a new issue would be more appropriate.

I'll take a look! :+1:

    if (r_ris.shader_cache && !unshaded) {

Ah looks like a very small oversight on my part. Should have it fixed in a jiffy! :grin:

I think I'd foolishly skim read, thinking that unshaded meant not using a shader. But unshaded can have a shader, so it is shaded, just not _shaded_. :rofl:

[oeleo1]

Thanks. And I love the frame debugging feature 🥇 Can't wait for polys to get in...

[akien-mga]

Fixed by #38979.