How does StandardMaterial fix flickering with instanced planar quads?

Help & Support
1

I’m noticing a lot of flickering for instanced objects with own material while using the StandardMaterial is flicker free.
We’re using a custom material that inherits from pc.Material directly for multiple reasons, one of them being that we support generic instanced attributes in addition to transform matrix.
I’m curious how PC’s Standard Material achieves flicker free between instances of the same draw call?

Here’s a video showing use of SM, notice no flicker between ground shadow quads which are instanced and planar:

and here’s one with our own material with instances, notice the flicker between instances:

2

Interesting, looks like you are getting z fighting on your instances :thinking:

@mvaligursky or @Leonidas Any ideas on this one?

1 Like
3

Martin (@mvaligursky) may be able to verify this, but the issue may be coming from the AABB calculated for the shadows.

In the case of the instanced geometry it’s not calculated automatically to include the total bounding box. Most likely the shadows renderer is using the AABB of a single instance.

If that’s the case, then the fix is to update the AABB of your instanced mesh instance to include all instances (a more advanced case would be to include just the visible to the shadows camera instances).

2 Likes
4

I does look like z-fighting to me. Try to move them away from the ground a tiny bit?

2 Likes
5

The problem is not between the transparent shadow quads and the ground, if they’re are spread out they don’t flicker. They’re only flickering when they’re are overlapping with each other. But that doesn’t happen when using a standard material.
i’ve tried also adding a depth bias to the material but it doesn’t seem to fix the issue. I guess I could make it so that each instance has a bit of an offset on Y axis that would probably solve the issue but I still don’t get it how the standard material achieves non flickering on the self overlapping instanced quads.

The only difference between the way I’m instancing them is for the standard material I use only the transform matrix for instancing attributes and in the case of our custom material I can also control the transparency per instance via an additional vertex attribute.

6

Grab both cases with Spector JS and compare render state settings for those draw calls … Perhaps the standard material does not write to depth, which could be a good solution here I think.

1 Like
7

Thanks for the hint @mvaligursky, after taking a look at the frame grabs it seems that in case of the standard material the depth write mask is set to false so, as you assumed, the material in this case doesn’t write to depth. I guess I should try doing the same as it makes sense for this case.
Thank you guys!

1 Like