Material and Shader don't expose property list

Unity Engine
1

Looking at the documentation for Material:

and Shader:

I don’t see a way that I can get a list of properties on the material or the list of properties in the shader.

Once you have the property name it can be modified. But how would you get the property names by script?

2

One suggestion is that there are about a dozen property names in the built-in shaders and just use the HasProperty on that list to check if the shader/material has them.

But that’s not a complete solution.

3

So do you want a generic property name enumetation (so a script could iterate over the properties)? Or just a way to see the property names?

With the first approach, the question is: ok, if the script gets all the property names… then what? It probably still does not know what those properties do…

For the second approach - upcoming Unity 2.5 will have an improved shader inspector that among other things will show all the properties to you (with names, types etc.).

4

Yes the enumerator option is the best.

I’d need to know the property names and types. The existing API is good to get the property values.

I’m doing this in the player, so I can change the diffuse and normal maps in game to see how it looks.

5

I still fail to see how an enumeration API would solve this.

Suppose your game wants to change diffuse normalmap textures.

And the shader has those texture properties: _KazkasKeisto, _DarVienas, _Mano. Now, that’s three textures. Which one is the diffuse one? Which one is the normal map? Maybe none of them?

6

First of all, sorry for bring this one up again.

Aras, I agree with your premise for runtime. But I ask you this: Why create an artificial limitation? It’s not like it will create any kind of overhead.

There are all kinds of reasons to access material/shader properties in editor scripts, like custom property editing widgets, overriding/boxing of properties, detecting similar materials based on pre-determined property thresholds for batching or detecting when properties are modified. Limiting this to known properties won’t allow expansion of certain editor utilities to custom shaders.

You might argue that Unity wasn’t designed for that, but once you open your API for editor expansion you need to expect this kind of request.

7

I have a use case for this ! (within the editor, I don’t see why it should be used at runtime for now)

I want to replace some textures on specific tagged materials. If I want to be able to export to Flash, I need to replace DDS textures(1) on the materials to be able to build. I have PNG versions of the same textures and I need to switch between the DXT ones and PNG ones. If I were able to list the properties on Material I would be able to replace them but this is not possible right now.

Also, support platform specific assets is quite poor in Unity. I there was something to say that in the Flash version, I want this specific texture on this material instead of another one, I would not need to replace my DXT textures… Maybe a naming convention like they do in the BitSquid tech : bitsquid: development blog: Platform Specific Resources

(1) We need them in our game, there are different images in the mipmaps (we don’t care about that in Flash though)

8

I also request this feature.
I would find it very useful, for example you could write a script to set properties of many materials (batch processing).
Also it would be cool to access the default values for those properties.

9

I approved TomasRiker answer. I got a scene and during my scripting batch I want find all the properties of each shader that I batch to do the average of each which is a float or a numeric value.

So it would be cool to acces to the current value and/or default one.

10

Hello

Me too, need of property list to use the desired slot texture in an UV Editor plugin.
Actually a just use mainTexture by i want let user choose the slot to display !

11

Hello

I too needs the expose of the shader’s properties.
In my case, I need to compare materials to see if they are redondants and then combine them.
So I need :

  • first to compare their shaders (no problem with the renderer.material.shader)
  • then to compare each property (Name, Type, Value (with a tolerance for the numeric ones))
    But, as I use custom shaders (with custom properties, for exemple a shader that use vertex color and face normal to blend between 6 different sets of texture), I have numerous custom properties.
    The properties are listed without problem in the material editor, so it exist a way to list them. It should be a way for us to access it, as long as you allow us to create custom shaders.
    We can’t count on the shader writers to always use the same properties name and synthax (I’m not alone), so with the expose of the properties the code would be totally adaptable.
12

I’m trying to do exactly the same thing. It seems like the functionality exists in the internal ShaderUtil class. It just isn’t exposed in the public API.

13

Bump. The closest thing we’re given is HasProperty, which seems to follow a frustrating “we know best” approach that’s at odds with the whole Unity philosophy - give us the tools and watch what amazing things we can do that you never considered. Aras is right in principle, but one thing I that bugs me about middleware is the one-shoe-size-for-all ideology that inevitably creeps in here and there.

The same logic is applied to Prefabs, in the way you can’t see more than one layer down in a Prefab in Project view. Not because it can’t be done, but because people might mis-use it. :sad:

14

Bump. Even if it’s only for editor purposes, I think it’s a good idea to have this feature. I have scripts that animate shader properties, having to write the properties names can lead to mistype errors.

15

Bump, would also like this - though, as a non-editor class.

It would allow us to use fuzzy search criteria in finding a texture property. For example, we can assume that any texture property containing “normal”, or “bump” regardless of case, would be a bumpmap.

Ideally, all shaders would use the same naming convention, but that’s just not the reality of things, and we don’t want to rely on the assumption that there is a convention.

Currently, in order to find which texture property is likely to be a bump map, we have to iterate through this list of possible names:

“_Bumpmap”, “_BumpMap”, “_Bump”, “_Normalmap”, “_NormalMap”, “_Normals”, “_Normal”, “_bumpmap”, “_bumpMap”, “_bump”, “_normalmap”, “_normalMap”, “_normals”, “_normal”, “Bumpmap”, “BumpMap”, “Bump”, “Normalmap”, “NormalMap”, “Normals”, “Normal”, “bumpmap”, “bumpMap”, “bump”, “normalmap”, “normalMap”, “normals”, “normal”

Obviously, it would be far faster, cleaner, and more robust to just iterate through the properties a texture DOES have and then filtering out the results to find the best candidate, rather than coming up with all the possibilities before hand and then testing each one.

16

Bump

This time for a Material Serializer/Deserializer

17

@Aras For my material serializer enumerating material properties would be preferred to enumerating shader properties. If my poking around with the editor is any indication, these are different sets. A material can have values when there is no shader property - which has the effect that if the shader is changed this property could be applied to the new shader. A shader can also have properties the material does not have set, which results in the shader using a default value. I would like for these behaviors to be replicated exactly for the purposes of the serializer, which would require enumerating material properties.

Also, the ShaderUtil class would be insufficient for this purpose. For one, it’s Editor only. Also, the ShaderPropertyType enumeration does not include every material parameter type. For example, Matrix is absent from ShaderPropertyType, but there is a GetMatrix/SetMatrix pair on Material.