MaterialPropertyBlock

visionOS Beta Mixed Reality (Immersive) Apps
1

Are MaterialPropertyBlocks supported? We seem to be just getting default values coming through

2

MaterialPropertyBlock is not supported. You need to create unique material instances, if you need different material properties on different renderers.

1 Like
3

Are there plans for this to be supported, or is this a limitation of the platform?

4

Maybe @kapolka can shed some light on this?

5

We would like to support MaterialPropertyBlocks eventually, but we don’t have a timeline for it at the moment.

1 Like
6

Possibly related. Getting a fail with these errors:

[Diagnostics] EXCEPTION ArgumentNullException in PolySpatialCore:
at (wrapper managed-to-native) UnityEngine.MaterialPropertyBlock.SetTextureImpl(UnityEngine.MaterialPropertyBlock,int,UnityEngine.Texture)

Followed by this one, twice:

ArgumentNullException: Value cannot be null.
Parameter name: value
UnityEngine.MaterialPropertyBlock.SetTexture (System.Int32 nameID, UnityEngine.Texture value) (at :0)

I assumed from this thread that it would fail silently, but it’s throwing exceptions. Problem is that I’ve ensured there are no creations of - or references to - MaterialPropertyBlocks.

Any ideas on something else that may be causing it?

Not sure if this is the culprit, but the simulator is crashing when loading this project via PlayToDevice.

Thanks.

7

I’m guessing the null is a texture that didn’t get converted. Would it be possible to add a default texture - as with the famous magenta - so we can get an idea what textures aren’t converting?

8

Could you submit a repro case as a bug report and let me know the incident number (IN-#####)?

I can’t tell exactly where this is coming from without a full stack trace, but I’m assuming that you’re seeing this in editor play mode (since that should be the only place where we call MaterialPropertyBlock.SetTexture). We call that function specifically for the lightmap and reflection probe textures, and my best guess is that maybe you have non-directional lightmaps, in which case we would send null for the directional lightmap texture. I can fix the underlying exception (either by assigning a default texture, as you say, or not setting anything), although I’m not sure how that will affect the light maps (if you’re even using them).

Does the project also crash when running it in the simulator (that is, not in Play to Device)?

9

Thanks for getting back so quickly! A load of useful info there. Will log a bug and package up a minimal repro project.

I’ll look into the lightmap issue - thanks for the clue. We are using them.

Crash only when sim run from PlayToDevice. OK with local build and run via Xcode.

1 Like
10

Just wanted to get back, letting you know I’ve removed the offending issues. It was basically the same process I’d need to do to create a minimal repro.

I stripped the scene down until it ran in the sim, then added back content incrementally. For testing, did a brute force conversion of all shaders (mostly ShaderGraph) to URP lit. Made sure no optimised skinned mesh renderers (there was one lurking in a very large composite mesh), backed directional-only light.

Thanks again for your input.

1 Like