MaterialPropertyBlock

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

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

1 Like

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

Maybe @kapolka can shed some light on this?

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

3 Likes

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.

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?

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)?

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

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

Just wondering if support for MaterialPropertyBlocks might be coming any time soon?

They’re on the list to implement, but we haven’t started working on support for them yet. Hopefully soon.

Is there a timeline for support? Lack of support is quite an issue for us. I’ve added it as a suggestion to the MR roadmap as it doesn’t seem to be on there.

Thanks for adding it as a suggestion! We have support for this ready for our next release, which should be soon, though I don’t have a specific timeline. It also requires some changes to the Unity runtime, though, so you may have to wait until a new version of Unity is release with those changes and upgrade, or use a workaround that we will provide (manually dirtying the MeshRenderer whenever you change its property block).

@kapolka Is support for MaterialPropertyBlock now added in PolySpatial 1.2.3? I had a look through the release notes, but didn’t spot anything

Yes; the release notes say “Added support for MaterialPropertyBlocks (currently requires dirtying the renderer via Unity.PolySpatial.PolySpatialObjectUtils.MarkDirty).” AFAIK, calling MarkDirty should not be necessary if you use Unity 2022.3.27+.

2 Likes

Thanks! Sorry, I mised that :slight_smile:

1 Like

@kapolka Hi, I’m on Unity 2022.3.27 & PolySpatial 1.2.3. I have the same problem. I have SpriteRenderer with simple material. Material uses Sprites/Default shader. In unity editor I have an error, but on device I don’t have any problems.

[Diagnostics] EXCEPTION ArgumentNullException in PolySpatialCore:
  at (wrapper managed-to-native) UnityEngine.MaterialPropertyBlock.SetTextureImpl(UnityEngine.MaterialPropertyBlock,int,UnityEngine.Texture)
  at UnityEngine.MaterialPropertyBlock.SetTexture (System.Int32 nameID, UnityEngine.Texture value) [0x00001] in /Users/bokken/build/output/unity/unity/Runtime/Export/Shaders/MaterialPropertyBlock.cs:113 
  at Unity.PolySpatial.Internals.UnitySceneGraphEntity.CreateOrUpdateSpriteRenderer (Unity.PolySpatial.Internals.PolySpatialSpriteRenderData spriteRenderData) [0x0002f]

We currently don’t support MaterialPropertyBlocks on SpriteRenderers; only on MeshRenderers, SkinnedMeshRenderers, and ParticleSystemRenderers. I’m not sure if that’s the issue you’re seeing, but it looks like for some reason there’s no texture set on your SpriteRenderer. I don’t know why that would be, but the fact that the Draw Mode option is disabled might be related. At any rate, if you submit a repro case as a bug report and let us know the incident number (IN-#####), we can take a look.

@kapolka I reproduced the issue on your VisionOsTemplate project (1.2.3). Here is the bug report: IN-76653